white box testing
White Box Testing (White Box Testing) is also known as structural testing, transparent box testing, logic-driven testing or code-based testing. White box testing only tests the internal structure and processing process of the software product, but does not test the function of the software product. It is used to correct the errors in the description, representation and specification of the software system, which is the premise of further testing.
The four principles followed by white box testing:
- Ensure that all paths in a module are tested at least once;
- All logical values are tested for both true and false
- Check that the program's internal data structures are valid;
- Check upper and lower boundaries and run all cycles within operable range
static white box testing
White box testing is divided into static and dynamic. Static testing refers to manual analysis and inspection of programs and documents without running the program. Below are the failure modes checked by static white box testing.
- Memory Leak Fault (Memory Leak Fault, MLF)
- Out of Bounds Array Access Fault OBAF
- Using Uninitialized Variable Fault (UVF)
- NULL Pointer Dereference Fault NPDF
- Illegal Computing Fault ILCF
- Dead Loop Fault DLF
- Resource Leakage (RLF)
- Concurrency Fault
- security breach failure
- question code failure
Simply put, static white box testing is to look at the code to find bugs
Dynamic White Box Testing
White box testing is divided into static and dynamic. Dynamic testing refers to running the program under test to check the difference between the running result and the expected result, and to analyze performance such as running efficiency and robustness.
Dynamic white box testing process:
- Select a valid value in the definition domain, or an invalid value outside the definition domain; (idea of equivalence class division)
- The chosen value determines the expected result;
- Execute the program with selected values;
- Comparing the execution result with the expected result determined by the selected value, if it does not match the program, there is an error
logic coverage test
In order to meet the four principles of white-box testing, it is necessary to use the logic coverage testing method to design test cases. Logic coverage testing is a method of designing test cases based on the internal logic structure of the program. First, it needs to analyze the structure of the code and draw a flow chart.
The code is shown in the picture:
The corresponding structure diagram is as follows:
Note: Numbers in circles represent lines of code
Afterwards, logic coverage is carried out. Due to the different goals of coverage testing, logic coverage can be divided into: statement coverage, decision coverage, condition coverage, decision/condition coverage, condition combination coverage and path coverage.
override method | introduce |
---|---|
statement coverage | Choose enough test cases that each executable statement in the program is executed at least once . |
decision coverage | By executing enough test cases, each decision in the program obtains a "true" value and a "false" value at least once, that is, each "true" branch and "false" branch in the program undergoes at least one Once , also known as "branch coverage". |
condition coverage | Design enough test cases so that each possible value (true/false) of each condition contained in each decision in the program is satisfied at least once . |
Judgment/Condition Override | Design enough test cases so that all cases (true/false) of each condition contained in each judgment in the program appear at least once, and the judgment result (true/false) of each judgment itself also occurs at least once. A test case that satisfies decision/condition coverage must satisfy both decision coverage and condition coverage |
Condition combination coverage | By executing enough test cases, all possible condition value combinations of each decision in the program appear at least once. Test cases satisfying combined coverage must satisfy decision coverage, condition coverage and decision/condition coverage |
path coverage | Design enough test cases to cover all possible paths in the program |
From the introduction in the table, we can see that from top to bottom, the method covers more paths. The paths covered by other methods are not comprehensive, so why not use path coverage directly? This is because if multiple judgments and multiple loops appear in the program, the number of possible paths will increase sharply, so that it is impossible to realize path coverage.
In order to solve the above problems, the basic path coverage appeared . It analyzes the cycle complexity of the program control flow graph on the basis of the program control flow graph, derives a set of basic executable paths (independent paths), and then designs test case.
Pros and cons of each override method:
在实际测试中,即使对于路径数很有限的程序已经做到路径覆盖,仍然不能保证被测试程序的正确性,还需要采用其他测试方法进行补充。
data flow test
Data flow test analysis often focuses on deficiencies in definition/reference exceptions, and is used for the following three aspects of testing.
- variable is defined, but never used (referenced)
- The variable used is not defined
- variable is defined twice before being used
Early data flow tests were mainly used to detect some warning messages when programming, such as "defined variables are not used, etc.", these problems cannot be detected by simple syntax analyzers or semantic analyzers .
Program instrumentation
Inserting a statement to record dynamic characteristics in a specific part of the program is ultimately to record some important historical events that occurred during program execution. For example, record the change of certain variable values, the range of change, etc. during the program execution. These inserted statements are often referred to as "probes" or "probe points".
Summarize
- The white box testing method develops test cases based on the source code of the program under test. Common white-box testing methods include logic coverage, data flow testing, path analysis, and program instrumentation .
- Logic coverage designs test cases based on the internal logic structure of the program, and requires a certain degree of coverage of the structure of the program under test, such as statement coverage, decision coverage, condition coverage, decision/condition coverage, condition combination coverage, and path coverage . Path coverage is the strongest logic coverage criterion, in fact we can only selectively test some representative paths in the program.
If the article is helpful to you, remember to like, bookmark, and add attention. I will share some dry goods from time to time...
END Supporting Learning Resources Sharing
Finally: In order to give back to the die-hard fans, I have compiled a complete software testing video learning tutorial for you. If you need it, you can get it for free 【保证100%免费】
加入我的软件测试交流qq群:110685036免费获取~(同行大佬一起学术交流,每晚都有大佬直播分享技术知识点)
Software Testing Interview Documentation
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
How to obtain the full set of information: