1. white box testing
White box testing, also known as structural testing, is mainly used in the unit testing phase. Its premise is that the program can be regarded as being packed in a transparent white box, and the tester fully knows the structure and processing algorithm of the program. This method designs test cases according to the internal logic of the program, and checks whether the main execution paths in the program can work normally according to the predetermined requirements.
White box testing designs test cases according to the internal logic of the software. The commonly used technique is logic coverage. There are six main coverage standards: statement coverage, decision coverage, condition coverage, decision/condition coverage, combined condition coverage and path coverage.
(1) Statement coverage. Statement coverage refers to selecting enough test cases so that each statement of the program under test is executed at least once when these test cases are run. Obviously, statement coverage is a very weak coverage criterion.
(2) Determining coverage. Decision coverage, also known as branch coverage, means that not only every statement is executed at least once, but every possible result (branch) of each decision is executed at least once. Decision coverage is stronger than statement coverage, but the coverage of program logic is still not high.
(3) Condition coverage. The meaning of conditional coverage is not only to execute each statement at least once, but also to make each condition in the decision expression obtain various possible results. Condition coverage does not necessarily include decision coverage, and decision coverage does not necessarily include condition coverage.
(4) Judgment/condition coverage. Logic coverage that satisfies both decision coverage and condition coverage is called decision/condition coverage. It means that enough test cases are selected so that all possible results of each condition in the decision expression appear at least once, and all possible results of each decision itself appear at least once.
(5) Condition combination coverage. The meaning of condition combination coverage is to select enough test cases so that all possible combinations of condition results in each decision expression appear at least once.
Obviously, a test case that satisfies condition combination coverage must also satisfy decision/condition coverage. Therefore, conditional combination coverage is the strongest of the five coverage criteria above. However, conditional combination coverage cannot yet guarantee that all possible paths in the program are traversed at least once.
(6) Path coverage. The meaning of path coverage is to select enough test cases so that each possible execution path of the program is passed at least once (if there is a loop in the program, each loop path is required to be passed at least once).
2. black box testing
Black box testing, also known as functional testing, is mainly used in integration testing and confirmation testing phases. It regards the software as an opaque black box, and does not consider (or understand) the internal structure and processing algorithms of the software at all. It only checks whether the software functions can be used normally according to the requirements of the software requirements specification, and whether the software can properly receive input. Data and generate correct output information, whether the software can maintain the integrity of external information (such as files and databases) during operation.
Black-box testing designs test cases according to the functions stipulated in the software requirements specification, and it does not consider the internal structure and processing algorithms of the software.
Commonly used black-box testing techniques include equivalence class partitioning, boundary value analysis, error guessing, and cause-and-effect diagrams.
(1) Equivalence class division
When designing test cases, equivalence class division is the most widely used black-box testing method.
The so-called equivalence class is a set of input domains. For the input values in an equivalence class, they have the same function of revealing errors in the program. That is, if an input data in the equivalence class can detect an error, then the equivalence class
The other input data in the equivalence class can also detect the same error; conversely, if an input data in the equivalence class cannot detect a certain error, then the other input data in the equivalence class cannot detect this error (unless the A subset of an equivalence class also belongs to another equivalence class).
Invalid equivalence classes are used to test abnormal input data, so each invalid equivalence class may detect errors in the software, so a test case should be designed for each invalid equivalence class.
(2) Boundary value analysis
Experience shows that software is most prone to errors when it handles edge cases. Design some test cases so that the software runs just near the boundary, and the possibility of exposing software errors will be greater.
Usually, the boundary of each equivalence class should be tested emphatically, and the selected test data should be exactly equal to, slightly smaller than, or slightly larger than the boundary value.
(3) Wrong speculation
The error guessing method mainly relies on the tester's experience and intuition to select some of the most likely programs to cause program errors from various possible test programs.
(4) Causal diagram
The cause-and-effect graph method designs test cases based on the causal relationship between input conditions and output results. It first checks various combinations of input conditions, and finds out the dependence of output results on input conditions, and then tests for each output condition. Combination design test cases.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive