Unit Test Content _ Unit Test

Unit tests consist of a set of independent tests, each of which is directed to a separate program unit in the software. Unit tests do not check whether the program unit works well, but instead check that the behavior of individual program units is correct. In unit testing, the tester is based on a detailed design specification and a list of source programs, understand the I/O conditions of the module and the logical structure of the module, mainly using the test cases of white box test, supplemented by black box test test cases, so that any reasonable and unreasonable input must be able to identify and respond. This requires a desktop check and code review of all the local and global data structures, external interfaces, and key parts of the program code for the program.

The test work performed in unit tests is conducted to examine the tested modules in 5 main areas:

1. Module Interface Test

At the beginning of the unit test, you should test the data flow through all the tested modules. If the data does not enter and output normally, then all other tests will not be able to explain the problem. Myers a checklist for interface testing in the book on software testing:

The number of module input parameters is the same as the number of module form parameters.
The parameter attributes of each input of the module are consistent with the corresponding formal parameter attributes.
The parameter types entered by the module are consistent with the corresponding formal parameter types.
Whether the number of arguments passed to the called module is the same as the number of called module parameters.
Whether the property that is passed to the argument of the invoked module is the same as the property of the called Module parameter.
The type of the argument that is passed to the called module is the same type as the called Module parameter.
The order and number of arguments are correct when referencing internal functions.
Whether to reference a parameter that is not relevant to the current entry.
The variable used for the input has not changed.
The definition of a global variable is consistent when it passes through different modules.
Restricts whether the condition is passed as a formal parameter.
When using external resources, check availability and release resources in a timely manner, such as memory, files, hard disks, ports, and so on.

When a module uses an external device for an input/output operation, it must extend the interface test and attach the following test items:

Whether the file's properties are correct.
Whether the open and close statements are correct.
Whether the specified format matches the I/O statement.
Whether the size of the buffer matches the size of the record.
Whether the file is open before using the file.
Whether the condition of the end of the document is arranged.
I/O errors are checked and processed.
Whether there is a literal error in the output information.

2. Local Data structure test

The local data structure of the module is the most common source of error, and test cases should be designed to check for the following errors:

Incorrect or inconsistent data type description.
Use a variable that has not been assigned or has not been initialized.
The default value for the wrong initial value or error.
The variable name is spelled incorrectly or incorrectly written--an external variable or function is used.
Inconsistent data type.
The impact of global data on modules.
Array is out of bounds.
Illegal pointers.

3. Path Testing

Check for program errors caused by calculation errors, decision errors, and control flow errors. Since it is not possible to perform exhaustive testing at the time of testing, test cases are designed based on the "white box" test and the "black box" test case design method to test the important execution path in the module. The important execution path refers to the execution path of the algorithm, control, data processing and so on, and it is an important task to selectively test the execution path because of the complicated and error-prone path. Test cases should be designed to find errors caused by incorrect calculations, incorrect comparisons, or abnormal control flows, and a large number of path errors can be detected by testing the basic execution path and loop.

In the path test, to check the errors are: Dead code, wrong calculation priority, algorithm error, mixed with different kinds of operation, initialization is incorrect, precision error--Compare operation error, assignment error, expression of incorrect symbol-->, >=;=, = =,. =, use error for loop variable--bad assignment and other errors.

Comparing operations with control flow is closely related, test case design needs to be aware of the error of discovering comparison operations:

Comparison of different data types.
Incorrect logical operator or precedence.
Because of the problem of floating-point arithmetic precision, the two values are different.
Incorrect variables and comparison characters in a relational expression.
"1 Error", that is, the condition in the abnormal or nonexistent loop.
You cannot jump out of loops when you encounter divergent loops.
The loop cannot be terminated when a divergent iteration is encountered.
Incorrect modification of the loop variable.

4. Error Handling Test

An error-handling path is a path that can cause error handling and an error-handling path, where the error handler schedules the execution route, or notifies the user to handle it, or simply stops execution and causes the program to enter a secure wait state. Testers should be aware that every line of program code can be executed to a small probability that the error will not occur and not be tested. General software error handling tests should consider the following possible errors:

Whether the description of the error is difficult to understand and whether the error can be positioned.
The error displayed is consistent with the actual error;
Whether the error condition is handled correctly or not;
Whether or not the error condition has caused the system to intervene before the error is processed.

......

This article is reproduced from the 51Testing Software test Network, view the full text: http://www.51testing.com/html/17/n-238717.html