Although there are many articles and documents about this on the Internet, the author once shared the PPT of “System Test Case Design” on Baidu, but I think that including the original PPT that I posted, there are some defects. Therefore, for this topic, I will systematically introduce how to design system test cases from scratch. It is hoped that it will serve as a guide for testers or other test-related personnel.
Software test case design from scratch
1. The basic concepts of test cases
I have repeatedly mentioned the importance of basic theories and basic concepts in various test articles or internal training meetings. So before I start, I will start with the basic concepts of test cases.
1. What is a test case?
A test case (Test Case) is a set of test inputs, execution conditions, and expected results prepared for a particular goal in order to test a program path or verify whether a function meets a specific requirement. In layman’s terms, a test case is to verify whether a program or a function meets a specified test requirement by explaining the preconditions for test execution, the operation steps performed, and the expected results corresponding to each step.
2. What is included in the test case?
To emphasize, the test cases mentioned here mainly refer to software (system) functional test cases. Usually the content of the use case includes the test target (purpose), demand label (usually corresponding to the demand number in the demand document), preset conditions (such as the required network configuration, environment configuration, etc.), and input data (such as the account used for the test, etc.) Data), test steps, expected results, passing standards (under what circumstances the use case is successfully executed), etc.
3. Different test types have different use case content
Depending on the type of test, the content of the use case is often different. For example, interface tests are generally content checklists (also called checklists), and unit tests are specific codes written based on frameworks such as Junit.
4. What is the purpose of designing test cases?
I believe everyone is clear about the design purpose of the test case, but I think it is necessary to list its purpose as detailed as possible:
Help us execute tests scientifically and orderly, and find defects in the software (system) as much as possible;
It is convenient to repeat the test in order to reproduce the defect (very important when describing the bug to the development);
During regression testing, verify whether the defect is repaired;
Avoid disorderly tests and improve the efficiency of test execution;
It is convenient to calculate the workload, so that the test can be carried out more according to the time plan;
Make the test process more convenient to manage, including tracking test progress, execution status, etc.;
It is convenient to extract the basic test cases after the test, so that they can be reused later and improve work efficiency.
Because test cases have so many uses above, the scientific and reasonable design of test cases plays a vital role in the quality of our software testing.
2. What are the basis of test cases?
The basis for the design of test cases is mainly user (or market) demand specifications, software (system) demand specifications, and various specifications (such as industry specifications, general specifications (standards), etc.). When designing specific test execution steps, documents such as outline design, detailed design, and database design should also be added (provided that these documents can correctly meet the needs of users, and if possible, test and review these documents).
The primary task of test case design is to decompose test requirement points and design corresponding use cases for each requirement point to ensure that every requirement is covered.
Regarding the test basis, often some testers may be affected by a considerable number of companies with agile development or development processes that are not standardized, resulting in some misunderstandings:
The basis of test case design is by no means the software itself. That is, it is wrong to design use cases with the finished software, which may cause the results of the test to be quite different from the results expected by the users.
Software requirements specifications cannot be guaranteed to be correct, often because each person’s different understanding of user needs causes different results. So if there is a need to review this link, take it seriously, and boldly raise it when there is a discrepancy in understanding.
User and software requirements are only part of the test basis (and the most important part), and the basis should also include industry standards (such as industry standards for finance, banking, and communications), general standards and specifications (such as ISO standards, national laws and regulations), etc.
In the case of agile development, your basis may only be UI design prototypes, functional description documents, etc. In this case, if possible, you should learn more details from the demand designer as much as possible.
3. Introduction to commonly used design methods for test cases
To make your own test cases as scientific and reasonable as possible, and to find more defects, it is inseparable from the use of methods. Next, I will introduce the commonly used test methods.
1. Equivalence class division method
Equivalently divide a set of input fields. In this set, each input condition is equivalent. If one of the inputs does not cause a problem, then we assume that other input conditions in the set will not find errors when testing. , This is the equivalence class division method.
Generally, the equivalence class classification method is divided into effective equivalence class and invalid equivalence class: effective equivalence class, that is, the set of meaningful input data that is reasonable for the description of the program’s requirements, and can be tested by using it Whether the program achieves the expected function and performance; invalid equivalence class is unreasonable for the program’s requirement description, and a collection of meaningless input data, which can be used to test the program’s ability to process invalid data .
The principles for establishing equivalence classes are:
If the input condition specifies the value range or the number of values, one valid equivalence class and two invalid equivalence classes can be established. For example, if the user name input has a specified length between 6 and 12 characters, the effective equivalence class should be a character string with a character length greater than or equal to 6 and less than or equal to 12; two invalid equivalents are less than 6 characters and greater than 12 Character string.
If the input condition is a Boolean quantity (that is, the condition is the input Boolean value true or 1), then a valid equivalence class and an invalid equivalence class can be established.
If a set of values of input data is specified, and the program needs to process each input value separately, then a valid equivalence class must be established for each specified input value, and for all values except this set of values An invalid equivalence class. If the ATM machine only supports withdrawals with positive integers of 100, 300, 500, 1000, 2000, then these numbers are a valid equivalence class, and (-∞,100), (100,300), (300,500), (500,1000) ), (1000,2000), (2000, +∞) are all invalid equivalence classes. Of course, the real cash machine also supports manual input of an integer of 100 for withdrawal, we will not discuss it here.
If the rules that the input data must comply with are specified, then a valid equivalence class (that is, data that obeys the rules) and several invalid equivalence classes (data that violates the rules from different angles) can be established. For example: Enter the user password when registering, and the password must be composed of numbers or letters. The effective equivalent class is “password is a combination of numbers and letters”, and the invalid equivalent class is “password includes Chinese” and “password includes other symbols” “Wait.
If it is known that the elements in the equivalence classes that have been divided are handled differently in the program, they should be further divided into smaller equivalence classes.
2. Boundary value analysis method
The theoretical basis of the boundary value analysis method is to assume that most errors occur on the boundary of various input conditions. If values near the boundary will not cause program errors, then other values may also cause program errors. Very small. The boundary value usage conditions include: the input condition clarifies the value range of a value, or the number of values, or the input condition clarifies an ordered set.
There are also some principles for establishing boundary values:
If the input condition or output condition specifies the value range and the valid condition includes the value boundary, you can set the value for the boundary and slightly beyond the boundary respectively. For example, the user name input string specifies the length between 6-12 characters, if The length of the input character is denoted by X. The input length range of the character string is 6<=X<=12, and the boundary values are: 5, 6, 12, 13.
If the input condition or output condition specifies the value range and the valid condition does not include the value boundary, you can select the value for the boundary and slightly within the boundary respectively. For example, the user name can enter the string length X and the range is 6.
If the input or output field is an ordered set (such as a sequential file, a table, etc.), attention should be paid to selecting the first and last elements of the ordered set and the elements outside the set but close to the set as the boundary, for example: input file name introduction Between fname0101~fname0120, the boundary values are fname0100, fname0101, fname0120, fname0121.
