Test cases are a scientific organization and summary of software testing behavior, with the purpose of transforming software testing behavior into a manageable model. Test cases are one of the ways to specifically quantify testing. Test cases are also different for different software. Generally speaking, there are seven categories of commonly used testing methods. Equivalence class division, boundary value, scenario method, decision table, cause and effect diagram, error inference method, orthogonal testing method.
Equivalence class division
Equivalence class division is to divide all possible input data into several areas, and then take a small amount of representative data from each area for testing. Every input condition in this area is equivalent.
boundary value testing
Boundary value testing is a method of testing the boundaries of a program's input domain. The purpose of boundary value testing is to detect errors by testing boundary conditions and cover the boundary conditions of the input domain to the greatest extent. It is necessary to consider the actual behavior of the program and determine reasonable boundary values for testing.
Scenario testing method
Scenario testing is a method of designing test cases based on typical user scenarios. The scenario testing method starts from the user's perspective and designs test cases based on specific usage scenarios, which can well reflect the actual usage of the system. But more test cases may be needed to cover different scenarios, and should be used in conjunction with other use case design methods.
Analyze typical scenarios in which users use the system. Such as login scenarios, payment scenarios, etc.
Identify key steps for each scenario. For example, the login scenario includes entering user name, password, clicking the login button, etc.
Design use cases to cover the main success path of the scenario. Such as the test case of normal login process.
Design test cases for abnormal scenarios. Such as the password is wrong.
Consider combining scenarios. For example, payment is made while logged in.
Prioritize the design of use cases for high-risk scenarios. Such as payment scene.
decision table method
It will be used when there is a relationship between input and output. The relevant parts of the business will be sorted out using a decision table, and then combined with each item of the decision table to do a test to refine the boundary value of the equivalence class. . Decision tables are suitable for solving combinations of multiple logical conditions. List various logical combinations to avoid omissions. Repeated operations cannot be expressed.
The judgment table includes condition piles, condition items, action piles, and action items.
Condition pile: List all conditions, the order does not matter;
Condition item: List the values of all possible situations for the corresponding condition;
Action pile: lists possible actions, the order does not matter;
Action item: List the actions to be taken when the condition item takes various values.
cause and effect diagram
It is a method that uses graphical methods to analyze various combinations of inputs to design test cases. It is suitable for checking various combinations of program input conditions.
error inference
A method to design test cases in a targeted manner based on experience and intuition to speculate on all possible errors in the program. List all possible errors in the program and special situations where errors are likely to occur, select test cases based on them, and combine them with the actual situation of the software to make targeted guesses about where problems may occur and design use cases accordingly.
orthogonal experimental design method
When there are many input conditions, the number of use cases designed by design methods such as cause-and-effect diagrams is often staggering. The orthogonal method can effectively reduce the number of use cases. The core idea of the orthogonal method is to select representative points for testing from a large amount of test data, thereby reducing the number of test cases.
Tips on test case design
The seven major categories of testing methods have been introduced above. Below, we will share with you several tips for quickly designing use cases from a practical perspective.
1. According to the needs, first split the large function points as the main use cases. For example, common additions, deletions, modifications and queries are major functional points and can be used as main use cases.
2. Use equivalence class division. Design use cases by classification. The basic classification can start with positive scenarios and negative scenarios. For example, use cases can be designed separately for two scenarios: successful creation and failed creation.
3. Make good use of boundary values and can be used in conjunction with equivalence classes. Tests sometimes involve a large amount of data, and it is inefficient to traverse all the data. If it is performed manually, it is more difficult to cover all the data. A more efficient approach is to first divide the equivalence classes and then select some parameters from the equivalence classes for testing. Boundary values are the most likely to cause problems among all optional parameters of equivalence classes. Therefore, boundary values are generally selected as the focus of testing.
4. Consider combinatorial testing. When searching, multiple fields can be used to search. When designing use cases, it is necessary to cover the search scenarios using a combination of these fields.
5. Consider path coverage. For functional verification with operation sequence, it is recommended to make a flow chart to cover all paths to avoid omissions.
For example, the common sequence of online shopping is adding products to the shopping cart - selecting products in the shopping cart - submitting the order - paying. During this process, the user may cancel the order or return at any step. It is necessary to ensure that these operation paths are included in the use case. designing.
6. Think about hidden needs. For example: performance, compatibility, stability, security, user experience, etc. If it is not clearly defined, you need to take the initiative to understand it to avoid omissions.
7. Interface display and detailed test points can be included in functional use cases, but be careful not to cover too much in one use case. Use case granularity is a very important point in use case design. It is generally recommended to design a use case for each function point. But sometimes, for interface display and detailed test points, if the use cases are designed separately, the use cases will be too large. In actual work, these points can be integrated into functional test cases, but be careful not to cause the original use cases to deviate from the focus or granularity. is too big.