C/C ++ unit test theory (9)

3.2 high efficiency test:

 

The previous section introduced some seemingly efficient methods. How can we test the efficiency? True efficiency cannot ignore the key factor of human intelligence.

Because it is impossible for a tool to automatically understand the design functions of the Code, only the personnel can understand it. Therefore, only the wisdom of people involved in the code in a timely manner can the tool do the right thing and achieve real efficiency.

 

The main task of testing is to use cases. In this respect, tools can perform a lot of automated work, including generating test code, generating test cases, and identifying missing test cases.

 

Generate Test code
The generation process should support human intervention in a timely manner to specify the data that needs to be initialized and determined for output, so as to avoid omission and garbage generation.

Is the interface for generating test code. You can manually specify the data to be initialized and output.

Generate Test Cases
To efficiently establish and manage use cases, data and code should be separated and use data tables to establish and manage use cases. To further improve efficiency, tools should support table conversion without coding.

 

 

Is the data table interface. Data can be automatically moved to a table, including external input, internal input, and expected output without additional code.

To automatically generate use case data effectively, manual intervention should also be performed in a timely manner.

 

 

Is the interface for generating case data. You can manually specify the valid range and segment of the data, and then automatically generate the data. Segmentation points are further classifications within the valid range. For example, an integer indicating age ranges from 0 to 200. However, the program must judge and process the segments less than 10 years old, these are children, and they make judgments and actions for those over 60 years old. These are retired old people.

 

 

Data sometimes needs to be combined for testing. A popular combination method is orthogonal method. After practice, we found that orthogonal method is not suitable for unit testing for two reasons: one is that there are too many generated use cases, and the other is that the orthogonal method has little to do with the code functions, and there will be many omissions. Therefore, the data combination must be manually specified. The tool automatically lists the possible combinations of data. For the selected combination, the overwrite is guaranteed when the use case is generated.

 

Identify missing Use Cases
The missing use cases are mainly used to achieve high coverage. White-box coverage is the basic indicator for measuring the test effect. For white-box coverage, we will further introduce how to ensure the test effect. White-box coverage has one feature: When it exceeds the upper limit, several use cases may complete most of the coverage, the remaining coverage is difficult to achieve, and the white-box coverage is insufficient, which means that some use cases are missing, it is difficult to find out the missing use cases.

 

 

There are six types of commonly used white box coverage. The others are relatively easy to understand. The correction and determination condition coverage, that is, MC/DC, is complicated. Let's first introduce it.

 

 

MC/DC requires that each condition affect the decision result independently. Specifically, for each condition C in the decision, two use cases or two computations are required. The value of condition C is the opposite, if the values of other conditions are the same, the calculation result is the opposite. Let's take a look at the example below:
For Condition A, the values of Case 1 and Case 2 are the opposite. The values of B and C are the same, and the results are the opposite.
For Condition B, the values of Use Case 1 and Use Case 3 and B are the opposite. The values of A and C are the same, and the results are the opposite.
For condition C, the values of Case 2 and case 4 and C are the opposite. The values of A and B are the same, and the results are the opposite.
These four use cases complete the MC/DC for this decision.

 

What can tools do in identifying missing use cases? Generally, to create a new use case, you do not need to change all input. Generally, you only need to change one input. Therefore, for an unoverwritten logical unit, the tool can calculate an approximate use case from an existing use case, that is, the minimum number of use cases is changed. You can also generate a modification prompt based on the Code logic. In this way, you can modify the approximate use case based on the modification prompt to get a new use case. This is also a typical application that combines the computing power of a tool with human intelligence.

 

 

Is the white box use case designer interface. When we specify a logical unit not covered, open the case designer and modify the approximate case as prompted, we can create a new case that can overwrite the specified target.

 

MC/DC is a mandatory standard for civil aircraft in Europe and the United States. In fact, MC/DC is also under some doubts, because it is too difficult to complete. Such a decision:
A & (B | C) & (D & E) | (f | G) & (H | I | j) | K)
If there are eleven conditions, it is difficult to complete at least 12 Use Cases for MC/DC? If the white-box case designer is used, it can be completed in about three minutes.