Fundamentals of software Testing-Unit Test theory section

One, Unit test

1. Definition : Unit testing is a test of the basic components of a software, such as functions (function or procedure) or a method of a class.

2. Unit definition : The unit has some basic properties, such as clear function, specification definition, explicit and other parts of the interface definition, etc., can be clearly separated from the other units of the same program.

In traditional structured programming languages, such as C, the unit of test is usually a function or sub-process; In object-oriented languages, such as C + +, the basic unit of testing is the method of a class or class.

3. Basic unit : The basic unit does not necessarily refer to a specific function (functions or procedure) or a method of a class, and, when implemented, may also correspond to a set of functions in multiple program files.

4. Objects : Documents and code.

5. Purpose : Whether the document and requirements are consistent /logical detection of the code itself /document and code consistency.

Example 1: An absolute value function, document: When the input parameter x>=0, return x, otherwise return-x; The code is written in x>0, return x, otherwise return-x;

Example 2: For a defined pointer variable, a direct reference is not initialized. This pointer variable points to an address that is randomly generated at run time, which may be a memory address that can only be accessed by the system or memory address used by other software, in which case an error occurs;

Second, unit testing focus on

1. Interface of the unit (static test)

The cell interface is the set of input and output correspondence, and the dynamic test of the unit is simply an input to the unit, and then check that the output is the same as expected.

If the data is not properly input and output, the unit test will not be discussed, so the unit interface needs to be tested as follows:

A. The input and output parameters of the unit under test are consistent with the description in the number, attribute, and order of the detailed design, and the code implementation should be consistent with the design, and the interface is easy to be neglected;

B. Whether to modify the only input parameters of the form-do not modify the input only the formal parameters, otherwise it may lead to incorrect data modification;

C. Whether the constraint condition is transmitted by the form parameter → avoids the constraint condition passing through the form parameter, prevents the control coupling between the elements;

2. Local Data structure ---development tools

The local data structure of the unit is the most common source of errors, and you should design test cases to check for the following kinds of errors:

A. Check for incorrect or inconsistent data types;

B. The pointer is not initialized;

C. The data type defined is incorrect, such as int a=65536;

D. Errors that occur during the copy process, such as NUM1 copy, into Num2;

E. Forced transformation, resulting in loss of precision, such as int a;float b;a=b will result in loss of precision;

3. Standalone Path

Testing for basic execution paths and loops can reveal a number of errors. Design a test case to find errors due to incorrect calculations, incorrect comparisons, or abnormal control flow surfaces:

A. The prioritization of operations is incorrect or misinterpreted, such as: A=b+c>>2 is not equivalent to A=B+C/4;

B. Wrong way of operation; a=b++; unlike a=++b;

C. Comparison of different data types; unsigned int a;int b;while (a>b);

D. " Difference 1 Wrong ", incorrect multi-loop or less loop once, for (i=0;i<=100;i++) Loop 101 times instead of 100 times;

E. Incorrect or impossible cyclic termination conditions, while (|a|<0), resulting in a dead loop;

F. Incorrect variables and comparators in relational expressions; if (x==1) written if (x=1)

G. When encountering divergent iterations, the loop cannot be terminated, so the iteration should be used with caution and the call hierarchy cannot be too deep;

H. Improper modification of cyclic variables, etc. while (i);

4. Boundary conditions ---coverage Test level

Errors on the boundary are common, for example: in nth times of n cycles, errors occur when the maximum minimum value is taken, especially in the case of data flow, where there is an error in the control flow that is exactly equal to, greater than, or less than the determined comparison value.

int a[10];
for (i=1;i<=10;i++)
{
Sum=sum+a[i];
}

5. Error handling ---Description accurate or not

The more perfect unit design requirements can anticipate the conditions of error, and set appropriate error handling, so that in case of program error, the error program can be rescheduled to ensure its logical correctness.

A. The description of the error is not specific or difficult to understand, such as user login interface, enter the user name password error code00001;

B. The description of the error is insufficient to locate the error and determine the cause of the failure, such as failed login;

C. The error displayed is inconsistent with the actual, such as the user name is wrong, but the password error is displayed;

D. Incorrect handling of error conditions, such as incorrect password display, but can still log on after clicking OK;

E. Before the error is processed, the error condition has caused the system to intervene, such as the serious error causes the operating system to intervene;

Third, how to conduct unit testing

1. Unit test environment

One class calls another: Import/instantiation (NEW)

Drive unit:

A. Receive test data, including test case inputs and expected outputs;

B. Transmit the test case input to the unit to be tested;

C. Compare the actual output of the measured unit with the expected output to obtain the test results;

D. Output the test results to the specified location;

such as: Test the addition function

void driver () {
int sum=0;
Sum=add (a); B
if (2==sum)//c
printf ("ok!\n"); D
Else
printf ("fail!\n");
}

2. Unit Test Strategy

A. Isolated test strategy

Method: The pile module and the driver module are designed for each module regardless of the relationship between each module and other modules. Separate unit tests for each module, as shown in:

Advantages: Simple and easy to operate, can achieve high coverage, can be carried out in parallel; pure unit testing;

Disadvantages: The driving function and the pile function are of great workload and low efficiency.

B. Top-down unit test strategy

Method: First the topmost unit is tested, and the unit called by the top layer is made into a pile module. Secondly, the second layer is tested, using the unit tested above to do the driver module. And so on until you have finished testing all the modules.

Advantages: It can save the development workload of the driving function, the test efficiency is high;

Cons: As one of the units being tested is added, the test process will become more complex and the cost of development and maintenance will increase;

C. Bottom-up testing

Method: The module calls the lowest layer module in the hierarchy diagram, simulates the module that calls the module, and then does the unit test on the above layer, and then makes the pile module with the module which has been tested. And so on, until all modules have been tested.

Advantages: Can save the pile function development workload, testing efficiency is high;

Disadvantage: Not purely unit testing, the test quality of the underlying function will have a great impact on the test of the upper function;

Iv. Four phases of unit testing

1. Unit Test Planning phase: Complete Unit test plan

2. Unit Test Design phase: Complete Unit test plan

3. Unit Test Implementation phase: Complete unit test Cases, Unit test procedures, unit test scripts, and data files

4. Unit Test Execution phase: Execute unit Test case, modify discovered problem and perform regression test, submit Unit test Report

V. Unit Testing Principles

1. Unit test the new code or modify much of the code.

2. Unit tests are conducted according to the unit test plan and program, eliminating the randomness of the test.

3. The Unit test Plan, Unit testing program, Unit test case, etc. must be guaranteed to be reviewed.

4. When the test case test results are inconsistent with the expected results, the execution of the unit test must record the actual test results truthfully.

5. Unit tests can only be completed when the end criterion in the test plan is reached.

6. Need to achieve a certain code coverage requirements for the unit under test.

Fundamentals of software Testing-Unit Test theory section