overview
White box testing is a testing method that designs test data or test cases according to the internal logic structure and coding structure of the program and completes the test. It is also called structural testing, transparent box testing, logic-driven testing, or code-based testing. White box testing is a test case design method. The box refers to the software under test. White box means that the box is visible, that is, it is clear what is inside the box and how it works. The "white box" method fully understands the internal logical structure of the program and tests all logical paths. The "white box" approach is exhaustive path testing.
Purpose
By checking the logical structure inside the software, the logical path in the software is covered and tested. Set up checkpoints at different places in the program to check the status of the program to determine whether the actual running status is consistent with the expected status.
Classification
White box testing is generally divided into two categories: static analysis methods and dynamic analysis methods.
Static analysis is a technique for testing a program without executing it. It mainly evaluates the programming format and structure of the software. The key function of static analysis is to check whether the software representation and description are consistent, whether there are conflicts or ambiguities.
Dynamic analysis is the analysis of the behavior of a software system before, during, and after its execution in a simulated or real environment. Dynamic analysis involves the formal execution of a program under a controlled environment with specified expected results. It shows whether a system is correct or incorrect in its checked state. Among dynamic analysis techniques, the most important technique is path and branch testing.
features
- Test data can be constructed so that specific program parts are tested;
- There are certain measures of adequacy;
- More tools are available;
- Usually only used for unit testing.
Principle (test content)
- All independent paths to program modules are tested at least once.
- For all logical judgments, both true and false cases need to be tested.
- Executes the body of the loop both within the bounds of the loop and within the bounds .
- Check (test) the validity of a program's internal data structures .
Introduction to Test Method
White box testing testing methods: code inspection, static structural analysis, static quality measurement, logic coverage, basic path testing, domain testing, symbolic testing, path coverage and program variation.
The coverage criteria of white box testing include logic coverage, loop coverage and basic path testing. The logic coverage includes statement coverage, decision coverage, condition coverage, decision/condition coverage, condition combination coverage and path coverage.
Test Method - Logic Coverage
Example of test program flow chart (hereinafter referred to as legend ):
1. Statement coverage
Design enough test cases so that each statement is executed at least once.
For legend: test case:
a = 2,b = 0,x = 3
Make the two discriminants both take the true value, and the sentence coverage can be achieved. However, if the "and" in the first discriminant is changed to "or", or the condition in the second discriminant is changed to "x<1", the selected test cases cannot detect these errors. Therefore, statement coverage is a weak coverage criterion.
advantage:
- Check all statements;
- The code with simple structure has better test effect;
- Easy to automate;
- High code coverage;
- In the case of program block coverage, the source code in the program block is not considered.
Errors that cannot be detected by statement coverage:
- Wrong conditional statement, for example: a > 1 & b == 0 → a > 0 & b ==0
- Logical operations (&, &&, ||) errors, for example: a > 1 && b == 0 → a >1 || b == 0
- Loop statement error (wrong number of loops, wrong exit loop condition)
2. Judgment coverage (branch coverage)
Design enough test cases so that each branch of each decision in the program is executed at least once. While statements, switch statements, exception handling, jump statements, and ternary operators can all be tested using branch coverage.
For legend: test case:
(1) a = 3,b = 0,x = 1 (acd路径执行)
(2) a = 2,b = 1,x = 3 （abe路径执行）
Designing the above two test cases achieves branch coverage.
Branch coverage is performed, and statement coverage is actually performed as well. Decision coverage has the same drawbacks as statement coverage.
3. Condition coverage
Execute enough test cases so that the possible values of each condition in each decision are satisfied at least once, but not all branches may be covered.
For the legend: There are 4 conditions in the flowchart: a > 1, b = 0, a = 2, x > 1. At point a: a > 1, a <= 1, b = 0, b != 0 and other results; at point b: a = 2, a != 2, x > 1, x <= 1 and other results. Test case:
(1) a = 2,b = 0,x = 1 (ace路径执行)
(2) a = 1,b = 1,x = 2 （abe路径执行）
The above two test cases are designed to achieve conditional coverage.
Pros and cons of conditional overrides:
- Can check all conditional errors;
- Cannot implement checks for each branch;
- Increased number of test cases.
4. Judgment/Condition Coverage
Design enough test cases to satisfy condition coverage and decision coverage at the same time, so that all possible values of each condition in the judgment are satisfied at least once, and at the same time, all possible judgment results of each judgment are executed at least once. That is: all possible condition value combinations of each decision are executed at least once.
For legend: test case:
(1) a = 2 ,b = 0,x = 4 (ace路径执行)
(2) a = 1 ,b = 1,x = 1 （abd路径执行）
The above two test cases are designed to achieve decision/conditional coverage, and conditional coverage can also be achieved separately. So sometimes decision/conditional coverage is not stronger than conditional coverage.
Branch-condition override pros and cons:
- Not only considers each condition, but also considers each branch, and the ability to find errors is stronger than branch coverage and condition coverage;
- does not fully cover all paths;
- Increased number of test cases.
5. Condition combination coverage
Design enough test cases so that each combination of conditions in each judgment occurs at least once.
For the legend: There are 4 conditions in the flowchart: a > 1, b = 0, a = 2, x > 1. Therefore, the test case should satisfy 8 combinations:
1：a > 1,b = 0
2：a > 1,b != 0
3：a <= 1,b = 0
4：a <= 1,b != 0
5：a = 2,x > 1
6：a = 2,x <= 1
7：a !=2,x > 1
8：a != 2,x <= 1
Test case:
(1) a = 2 ,b = 0,x = 4 满足1、5组合
(2) a = 2 ,b = 1,x = 1 满足2、6组合
(3) a = 1 ,b = 0,x = 2 满足3、7组合
(4) a = 1 ,b = 1,x = 1 满足4、8组合
A test case that satisfies conditional combination coverage must also satisfy the criteria of decision coverage, condition coverage and decision/condition coverage. However, satisfying the combined coverage of the conditions does not necessarily make every path in the program executed. The above 4 sets of test cases did not test the path acd.
6. Path coverage
Design enough test cases so that all paths in the program are executed at least once.
For the legend: There are 4 paths in the flowchart: ace, abd, abe, acd.
Test case:
(1) a = 2 ,b = 0,x = 3 覆盖ace
(2) a = 2 ,b = 1,x = 1 覆盖abe
(3) a = 1 ,b = 0,x = 1 覆盖abd
(4) a = 3 ,b = 0,x = 1 覆盖acd