Shulou(Shulou.com)06/03 Report--

The object of unit test is the smallest unit of software design-module. The unit test is based on a detailed description, and the unit test should design test cases for all important control paths in the module in order to find errors within the module. Unit testing mostly uses white-box testing technology, and multiple modules in the system can be tested in parallel.

Unit test task

Unit testing tasks include: 1 module interface test; 2 module local data structure test; 3 module boundary condition test; 4 module independent execution path test; 5 module error handling path test.

Module interface testing is the basis of unit testing. Other tests are meaningful only if the data can flow in and out of the module correctly. The following factors should be considered in testing whether the interface is correct or not:

1 whether the number of actual parameters entered is the same as that of formal parameters

2 whether the actual parameters input match the attributes of the formal parameters

3 whether the dimensions of the actual parameters input are consistent with those of the formal parameters

4 whether the number of actual parameters given when calling other modules is the same as the number of formal parameters of the tuned module

5 whether the attributes of the actual parameters given when calling other modules match the formal parameter attributes of the module being called

6 whether the dimension of the actual parameters given when calling other modules is consistent with that of the tuned module

7 whether the number, attributes and order of the parameters used when calling the predefined function are correct

8 whether there is a parameter reference independent of the current entry point

9 whether read-only parameters have been modified

10 whether the definition of the whole process variable is consistent with each module

11 whether some constraints are passed as parameters.

If external inputs and outputs are included in the module, the following factors should also be considered:

1 whether the file attributes are correct

2 whether the OPEN/CLOSE statement is correct

3 whether the format description matches the input and output statements

4 whether the buffer size matches the record length

5 whether the file has been opened before use

6 whether the end of the file is processed

7 whether input / output errors are handled

8 whether there are any textual errors in the output information

The purpose of checking the local data structure is to ensure that the data temporarily stored in the module is complete and correct during the execution of the program. Local data structures are often the source of errors, so test cases should be carefully designed to find the following types of errors:

1 inappropriate or incompatible type description

2 variables have no initial value

3 error in variable initialization or default value

4 incorrect variable name (misspelled or incorrectly truncated)

(5) overflow, underflow and address exception.

In addition to local data structures, unit testing should also check the impact of global data (such as the common area of FORTRAN) on the module if possible.

Each independent execution path should be tested in the module, and the basic task of unit testing is to ensure that each statement in the module is executed at least once. Test cases are designed to find errors caused by miscalculations, incorrect comparisons, and inappropriate control flows. At this time, basic path testing and loop testing are the most commonly used and effective testing techniques. Common errors in calculation include:

1 misunderstood or misused operator priority

2 mixed type operation

3 the initial value of variable is wrong.

4 the precision is not enough

(5) the expression symbol is wrong.

Comparative judgment is often closely related to control flow, and test cases should also focus on finding the following errors:

1 compare objects of different data types

2 wrong use of logical operators or precedence

Due to the limitation of computer representation, it is expected that two quantities that are equal in theory but not equal in practice are expected to be equal.

4 error in comparison operation or variable

5 cycle termination condition may not occur

6 cannot exit when iteration diverges

7 modified the loop variable incorrectly.

A good design should be able to foresee all kinds of error conditions and preset various error handling pathways, which also need to be carefully tested, which should focus on the following problems:

1 the error message output is difficult to understand

2 the recorded errors are not consistent with the actual errors encountered

3 before the error handling segment customized by the program runs, the system has intervened

(4) improper exception handling

5 there is not enough positioning error information in the error statement.

Boundary condition testing is the last and most important task in unit testing. It is well known that software often fails on the boundary. Using boundary value analysis technology to design test cases for boundary values and their left and right is likely to find new errors.

Unit testing process

It is generally believed that unit testing should start immediately after coding, when the source program is completed and has passed review and compilation checks. The design of test cases should be combined with the review work, and selecting test data according to the design information will increase the possibility of finding all kinds of errors mentioned above. When determining the test case, the expected results should be given.

A driver module (driver) and / or several pile modules (stub) should be developed for the test module. The following figure shows the general unit test environment. In most cases, the driver module is called the "main program". It receives the test data and passes it to the tested module. After the tested module is called, the "main program" prints the "enter-exit" message.

Driver module and pile module are the software used for testing, not part of the software product, but it requires a certain amount of development cost. If the driver and pile module are relatively simple, the actual cost is relatively low. Unfortunately, only simple driver modules and pile modules can not complete the testing tasks of some modules, and the unit testing of these modules can only use the comprehensive testing methods discussed below.

Improving the cohesion of modules simplifies unit testing. if only one module can be completed, the number of test cases required will be significantly reduced, and errors in the module will be easier to find.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.