White-box testing technology-methods and practices

White-box testing technology-methods and practices

Author: Zhang yuanli
Http://blog.csdn.net/vincetest

 

3.1 white box Testing Method

I. Use Case Design
1. Composition of test cases (in unit test, test cases are basically composed of test scripts)
1) Prerequisites for Use Cases
2) environment required by modules/units under test (global variable assignment or entity initialization)
3) start the test driver
4) set the pile
5) Call the tested module. [Source: Zhang yuanli's blog: http://blog.csdn.net/vincetest]
6) set the expected output condition judgment
7) restore the environment (including clearing piles)

2. Design Principles of Test Cases
1) A good test case is that no errors have been found;
2) the test case should consist of the test input data and the expected output result;
3) Reasonable input conditions and unreasonable input conditions should be included in the test case design;
4) design test cases for system running;
5) design test cases for positive testing;
6) design test cases for reverse testing;
7) design test cases to meet special needs;
8) design test cases for code coverage;

 

3. Use Case Design Method
1) Export and release specifications (specifications)
2) Equivalence Class Division
3) Boundary Value Analysis
4) State Transfer Test Method
5) Branch Test Method
6) condition test method [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
7) data definition-test method (also known as data flow test method)
8) Internal Boundary Value Test Method
9) incorrect prediction
For detailed design methods, see test case design White Paper.

 

4. Specific test case design
1) Declaration Test
2) path Test
3) cyclic testing
4) nested loops
5) Test the Boundary Value
6) Interface Test
7) confirm the test
8) Transaction test [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]

 

Ii. Use Case execution

• Generally, unit tests are conducted using commercial or self-developed testing tools. Test Cases are written on the testing tools, and test cases are all some test scripts, all are saved as files. Therefore, the execution process of the test case is mainly completed by the test tool according to the specific test case script, in this way, case management and execution are flexible.
• In a specific scenario, such as a stress test or a limit test, a good example is usually prepared in advance when the test execution takes a long time (more than a few hours ), test Cases are executed on idle machines or non-working hours, which saves time.
• Note the following when executing the use case: [Source: Zhang yuanli's blog: http://blog.csdn.net/vincetest]
  1. Execution Process of the program-facilitating the construction of divergent Use Cases
  2. Do not let go of any details-such details may be a problem

Iii. Test optimization and Strategies
1. Test Case Optimization

2. test execution optimization

3. Test Strategy
1) What are the key modules?
2) which programs are the most complex and error-prone?
3) which programs are relatively independent and should be tested in advance?
4) which programs are most likely to spread errors? [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
5) which programs have the least confidence of developers?
6) 80-20 Principle: 80% of defects are collected in 20% of modules, and errors may occur frequently after errors are corrected. This should be included in the testing focus.

3.2 white box test and evaluation

1. Test completeness evaluation: It mainly checks whether all test cases have been executed during the test, and whether the new test cases have been updated in a timely manner.

2. code coverage evaluation is mainly based on the statement coverage report provided by the code coverage tool to check whether the report meets the requirements in the solution. The company requires that the statement coverage reach 100%. However, in many cases, it is difficult to achieve the first round of test cases after execution. In this case, the coverage rate should be analyzed during the evaluation process, mainly from the following aspects: [Source: zhang yuanli's blog http://blog.csdn.net/vincetest]

1) impossible paths or conditions
2) unattainable or redundant code
3) Inadequate test cases
3. Test Coverage:
1) function coverage
2) input domain Overwrite
3) Output domain coverage
4) function interaction coverage
5) code execution Overwrite

Most effective test cases come from analysis, rather than rashly designing test cases to achieve test coverage. Do not misunderstand test coverage. test coverage is not our goal. It is just a way to evaluate the test and provides guidance and basis for the test.

[Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
 

 

4. Test Coverage Evaluation:

• Location-independent call coverage (licc)
  Licc = (number of non-repeated function calls covered/Number of non-repeated function calls) * 100%
• Location-dependent call coverage (ldcc)
  Ldcc = (number of function calls covered/number of all function calls) * 100%

Case: [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
Void func (int I)
{
Call1 ();
If (I = 2) call2 ();
Else if (I = 3) call3 ();
Else call1 ();
}

 

After calling func (2) and func (3), we evaluate the coverage of func () as follows:
Licc: 3/3 = 100%
Ldcc: 3/4 = 75%

 

5. Test Design Evaluation:
Test Case coverage (TCC), also known as test case coverage, is designed based on the relationship between the frequency of use of the tested function in the formal test and the total number of branches in the function definition. It is defined as follows:
TCC = Total number of calls to the tested function in the use case/total number of function-defined branches

The total number of branches of a function is defined as follows: total number of function branches = 1 + total number of IF Statements * 2 + total number of while statements * 2 + total number of for statements * 2, the IF statement has two branches: True and Fals. In principle, it is complete to design two tests. The while statement is similar to the for statement. A use case should be designed at least once for a loop, A use case should also be designed when you do not enter it at a time. Therefore, After calculating the total number of if, while, and for statements, multiply the number by 2. However, if a function does not use these three control statements, at least one test case should also be designed to test it, which is the additional meaning of 1 in the above formula.

3.3 white box testing implementation

Prerequisites

• Ideological unity
  The quality department and project owner should pay sufficient attention to the issue and list unit test output as equally important as code output.
• Complete process support
  It mainly refers to the completeness of the design documents, such as the detailed design manual, because the detailed design manual is an important basis for white box testing.
• Implementation method [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
  1) Select a relatively important and complex Module
  2) Select a project with relatively low progress
  3) white box testers are generally developers
• Test Tool Selection

 

3.4 white box testing practices

I. Introduction to industry testing tools
1. codetest
2. rtrt (rational test realtime)
3. vctester
4. cppunit/cunit
5. cantata ++
6. C ++ Test

For details about testing tools, see Introduction to commonly used embedded software white box testing tools

 

Ii. Use the test tool vctester (refer to the Case demonstration)
1. Introduction to vctester (Test principle)
2. Build a test environment
3. Script system [Source: Zhang yuanli's blog http://blog.csdn.net/vincetest]
4. Access to tested elements (types, variables, and functions)
5. Construction of test elements (parameters, piles, and testing frameworks)
6. test execution (online test)
7. Coverage Evaluation (code coverage and test coverage)
8. code editing, compilation, and debugging
9. Test report
For more information, visit the official website of vctester: www.eztester.com.

 

Related Articles:

White-box testing technology-white-box Testing Theory

White-box testing technology-Unit Testing Theory

Welcome to repost this article, reprinted please indicate the source of the article: Zhang yuanli's blog http://blog.csdn.net/vincetest