Software Test Summary (II)

 

This section describes the unit test, the first step of hierarchical testing. Before learning about unit testing, let's look at a simple main program tree module diagram:

 

A module test is a test at the underlying layer. For example, a unit test is a purple module in the test. Unit testing is the basis of the entire test. Errors Found in unit testing account for about 2/3 of the total program errors, the objective of unit testing is to make the underlying modules meet the requirements described in the module through static and dynamic tests on the underlying modules of the program.

Unit test:

 

 

The Module Interface Test mainly checks whether the data can pass the module correctly. The data structure test aims to maintain the integrity of the internal data of the program. The important path test is a basic task of unit test, it mainly performs coverage analysis. The program is most prone to errors on the boundary, so the boundary condition test is essential. The main point of the error handling test is that an error occurs at work, whether the error handling measures are valid.

General steps for unit testing:

During the compilation process, the main check object is the syntax error in the Code. The static analyzer checks the analysis using dedicated tools, and the code review mainly relies on manual, both step 2 and Step 3 are static analysis based on checking for structural errors. dynamic testing is the final step of unit testing, focusing on discovering functional errors of units, the white-box test or black-box test method can be used for testing. The white-box test and black-box test will be described in detail later. You can see these two methods here.

Code reviews are organized in two forms: 1. Desk checks, where programmers review their own code and are only applicable to small programs. 2. It is conducted in group meetings and divided into two types: inquiry and code review, which are suitable for programs of various sizes.

Unit testing is not an independent program. In multi-module programs, modules can call each other. During unit testing, several module replacements are often required for the tested modules, the replacement module is only simplified for real modules. You only need to simulate some functions directly related to the tested modules.

Based on experience, when a problem is detected at the unit level, the problem must be in that unit. If a defect is found during integration of multiple unit modules, it must be related to the interaction between modules. In practice, there are few exceptions.

All right, this section ends. The next section describes the second step of hierarchical test-integration test. Thank you!