Chapter 2 Design of Test Cases
2.2 Black box testing
2.2.1 Equivalent division
When testing a program, the tester is restricted to finding the subset for testing from all possible inputs. The subset that is found must be correct and the subset that can find the most errors.
The carefully selected set of test examples should have two characteristics:
- Strictly control the increase of test cases. In order to achieve reasonable testing, each test case must reflect as many different input conditions as possible, so as to minimize the total number of test cases
- Covers most of the possible test inputs, that is, some errors will be found when using this specific set, and some errors will be missed if this specific input set is not used.
In order to satisfy the above two characteristics, the input range of the program should be divided as far as possible into a limited number of equivalence classes. It is reasonable to assume that the representative data of each equivalence class tested is equivalent to any other test of that class. data. In other words, if a test case of the equivalence class finds a certain error, other use cases of the equivalence class should also be able to find the same error. On the contrary, if the test case fails to find an error, then we can expect that other test cases in the equivalence class will not find errors, and other tests of the equivalence class will not appear in other equivalence classes.
Equivalence class testing method There are two main steps in designing test cases: 1. Determine equivalence class 2. Generate test cases
Determine the pricing category
To determine the equivalence class is to select each input condition and divide it into two or more groups. The division of two groups: the effective equivalence class represents the valid input, and the invalid equivalence class represents any other possibility The input (that is, incorrect input value), so follow the test principle, the tester should pay special attention to invalid and unexpected input;
Generate test cases
Use the equivalence class to generate test cases, the process is as follows:
- Set a different number for each equivalence class
- Write new test cases to cover as many valid equivalence classes as possible that have not been covered until all valid equivalence classes are covered by test cases
- Write a new test case to cover one and only one invalid equivalence class that has not been covered until all invalid equivalence classes are covered by the test case
You can use a single test case to cover multiple valid equivalence classes, which can reduce the redundancy of the use cases, but try to cover a single invalid equivalence class with a single test case, because some specific input error checks may block or replace others Check for input errors.
Examples of determining equivalence classes
1. The input condition specifies a value range of 1-999, then the effective equivalence class is 1<=X<=999, and the two invalid equivalence classes are X<1 and X>999
2. The input conditions specify the number of values. For example, one to six owners of a car can be registered, and one pricing class and two invalid equivalent classes can be determined (no car owner, more than 6 car owners),
3. The input conditions specify the type of input. Each type is a valid equivalence class. If you can enter more than one, then a combination of multiple valid types is also a valid equivalence class. Types other than the described input type are invalid, etc. Price class, if you can enter more than one, the combination of invalid equivalence class and valid equivalence class is also invalid equivalence class;
4. The input conditions may be relatively broad. It is necessary to determine the large equivalent categories, and then subdivide the smaller equivalent categories.
The equivalence division method is much better than the random selection of test cases, but there are still shortcomings. This method ignores certain types of high-efficiency test cases. The method is introduced below: boundary value analysis to make up for the shortcomings.
2.2.2 Boundary value analysis
Experience has shown that test cases that consider boundary conditions have a higher test return rate than other test cases that do not consider boundary conditions. The so-called boundary refers to those states in the equivalence class of input and output that are just at the boundary, or beyond the boundary, or below the boundary. There are two differences between the boundary value analysis method and the equivalent division method:
- Boundary value analysis requires selecting one or more elements so that each boundary of the equivalence class is tested once.
- Boundary testing needs to consider the output results more, and design boundary test cases from the output results
The boundary value test is not defined in detail, but some general guidelines are provided:
- If the input condition specifies the input value range, the valid input test case and the invalid input test case that just crossed the boundary should be set for the input boundary. For example, if the input condition specifies an integer ranging from 1 to 999, then the design test case is 1 And 999, 0 and 1000 four test cases.
- If the input specifies the number of input values, then test cases should be designed for the minimum number of inputs, the maximum number of inputs, and one greater than the maximum number and one less than the minimum number.
- If the input or output is an ordered sequence, you should consider entering the wrong sequence and paying attention to the first and last sequence of the output.
The boundary value seems relatively simple, but in actual work, the boundary can be defined quickly and accurately, and program errors can be quickly found. In some cases, it is likely that the developer has not considered the scenario. The point is that some boundary conditions will be ignored and not easy to find.
2.2.3 Causality Diagram Analysis
Causality diagram analysis is to consider the logical relationship between input and output, combine the input conditions, and select test cases according to the logical relationship. However, in actual work, this cause and effect diagram analysis is rarely used, and it is logically complicated to speak. Describe again.
2.3 Summary
Each test method can provide a set of specific test cases, but none of them can provide a complete set of test cases. A reasonable combination of test methods will ultimately result in a relatively complete test case.
To achieve extensive and in-depth testing is not easy, and the most extensive test case design can ensure that every error is exposed. This means that if the team intends to do further in-depth testing, if enough time is invested in test case design and test result analysis, and the problems found can be solved in time, the final product will be software with complete functions and high reliability.