Recently, many friends are interviewing for new jobs to prepare. So I sorted out the basic workflow of software testing and the writing methods of some test cases. The general content is as follows. I hope these contents are helpful to everyone.

First of all, as a tester, you need to understand the business and analyze the requirements.

Why should testers participate in requirements analysis? In other words, what is the purpose of test requirements analysis?

First, turn user requirements into functional requirements.

1) Progress of test scope

2) Measurement processing branch.

3) Measure the scenario of demand business.

4) Define the input, processing and output corresponding to its functions.

5) Convert implicit demand into explicit demand.

Second, make clear the five elements of testing activities.

What are the test requirements, decide how to test, define the test time, determine the tester, determine the test environment, the skills, tools and corresponding background knowledge needed for the test, and the risks that may be encountered during the test. Test requirements need to be as detailed and clear as possible to avoid test omissions and misunderstandings.

So, how to analyze the test requirements next?

1) confirmation function

(Business functions, auxiliary functions, data constraints, usability requirements, editing constraints, parameter requirements, permission requirements, performance constraints)

1. business functions: functions or details directly related to the actual business of users;

2. Auxiliary functions: some functions or details that assist in completing business functions, such as setting filter conditions;

3. Data constraint: the details of the function are mainly used to control the display range of data and the relationship between data when the function is executed;

4. Ease of use requirements: functional details must be provided in the product to facilitate the operation and use of functions, such as shortcut keys;

5. Editing constraints: the details of the function, some constraints on the input data items when the function is executed, such as: only numbers can be input;

6. Parameter requirements: the details of the function need to be treated differently according to different parameter settings when the function is executed;

7. Permission requirements: the details of a function are treated differently according to different permissions during the execution of the function, excluding directly restricting the permissions of a function;

8. Performance constraints: the details of the function and the performance requirements that must be met when executing the function;

2) scene analysis

1. Consider the callers of scenarios: consider which external modules or systems are called by the services provided by each scenario, and find out all callers. Call preconditions and constraints should be considered. Each call can be considered as a big business process (generally, the business with external interaction has a high error rate and needs to be focused on).

2. Consider the relationship between various scenarios within the system: to form an internal business process, it is necessary to analyze the constraint relationship between scenarios, realize conditions, and organize various business flow charts.

3) Mining hidden demand

This requires the experience accumulation of test engineers:

1) General or specified business processes

2) Traverse each business process branch

3) Clearly specify the business processes that cannot be used.

4) Business processes that are not clearly defined but should not be used.

5) Other abnormal or nonconforming operations.

Next, let's talk about test case design.

1. How to design a test case?

Before writing test cases, we need to have a clear understanding of the requirements of the project, know what to test, what order to test and what requirements to cover. As test case writers, we should not only know the common test case writing methods, but also know the design, functional specifications, user usage scenarios and program/module structure of the software under test.

step

1) test requirements analysis: after getting the software requirements specification from the project department, start to analyze the project requirements, sort out the test requirements through your own analysis and understanding, and clearly analyze the functions of the tested object. Clarify the relationship between test cases and requirements in test cases, that is, one or more test cases correspond to one test requirement.

2) Business process analysis: After analyzing the requirements, the business process of each function, the business combination of different function points and the implied requirements of the project are defined. If it is a complex test case design, first draw the business process of the software. From the business process, we should get the following information:

A. what is the main process?

B. what is the conditional substitution process?

C. what is the data flow direction?

D. what are the key judgment conditions?

3) Test case design:

After completing the above two steps, you can design test cases. Functional test cases should consider boundaries, anomalies and performance as much as possible in order to find more hidden problems. Common methods for designing test cases:

Equivalence class → boundary value → causality diagram → decision table → state transition → orthogonal experiment → scenario method → error inference (note: when writing test cases, try not to take valid equivalence class, but take invalid equivalence class).

4) Department self-inspection and internal audit after writing:

① Whether the description of the test case itself is clear and the language is accurate; Whether there is ambiguity;

② Whether the content of the test case is complete and clearly contains the input and expected output results; Whether the test steps are clear;

③ Whether the test data used in the test case is appropriate and accurate;

④ Whether the test cases are instructive or not, and whether they can flexibly guide software test engineers to find more defects through test cases instead of limiting their thinking;

⑤ Whether to consider the efficiency of test case execution. Whether the verification points of repeated steps are the same; Or whether there is redundancy in the design of test cases. All these may lead to inefficient execution of test cases;

⑦ Draw the software requirements tracking matrix to verify whether the test cases completely cover the requirements and verify the coverage rate of the test cases;

Whether the test case fully meets the requirements of the software. This is actually a bit difficult to do. Considering the relationship between time and cost, it should be decided according to the specific situation.

5) Test cases are updated and improved:

After the test case is written, it needs to be improved continuously. In the case of changing requirements or new functions, test cases must be modified and updated. At the same time, it is found that the design of test cases is not well thought out and needs to be revised and improved. After the software is delivered for use, customers feedback software defects, which are caused by loopholes in test cases and need to be improved.

Then, the process of test case execution.

First, build a test environment, prepare test data and make predictions. After the prediction is passed, enter the formal test according to the test case. Effective test execution can maximize the value of test cases. Therefore, the execution of the test case specification is helpful to better find the defects in the code. According to personal test work experience, good test execution should include the following contents:

① If the evaluation test execution time is insufficient during the test execution, the risk shall be reported in time. In line with the principle of quality first and progress second.

② Test cases are executed in priority order, usually in basic, detailed and abnormal order.

③ Use cases that are not executed or marked as deleted or invalid shall indicate the reasons.

④ Test cases (scenarios, operation steps, checkpoints, etc.). ) In the implementation process, there are questions that need to be clarified by the test designer.

⑤ Test execution needs to check the checkpoints described in the use case one by one to avoid omission.

⑥ It may be a bug to pay attention to the defect scenes that are difficult to reproduce.

⑦ During the execution, we found some cases that were missed in the previous design, which need to be added to the use case document and verified.

It is suggested that testers cross-execute repeated test cases, and the use case execution is immune to the same tester. Avoid possible defects that have been missed so far. If necessary, it is recommended to keep the test results and make them visible. So as to facilitate the comparison of test results between different versions. The confirmed problems should be delivered in time according to the requirements of the bill of lading (specification and defect classification).

Pet-name ruby tracking problem list repair and regression verification problem list. At the end of each test, find out whether there is a core file. After the test, upload the final test case document to the archive directory to realize the reuse of the test case.

The above is aimed at the general software testing process. If it is an automated test, there should be scripts written and run according to the test cases. I may not elaborate here. I hope you can comment below and make me perfect.

Finally, if it meets the accurate requirements, write a test report according to the test situation to evaluate the quality of the whole test process and version.

Test report refers to writing the test process and results into documents, analyzing the problems and defects found, providing the basis for correcting the quality problems of software and laying the foundation for software acceptance and delivery. The test report is the final document output of the test phase. An excellent test manager or tester should have good documentation skills. A detailed test report contains enough information, including the evaluation of product quality and test process. The test report is based on the data collected during the test and the analysis of the final test results.