Construct an ideal module self-test structure
Wenhm@sina.com)
Software test has a lot of work (industrial statistics reached 40% to 60% of the total development time), and there is a large part of the automation, so the test will bring the quality, cost and cycle of the entire development. Very significant effect.
The recommended automation unit test recommended in Extreme Programming (XP) means that the test code is written before writing code, and the code is tested in a certain stage. The automation unit test can bring the following benefits:
l Since the test code (test case) is increasing, these tests always let us write the code to the correct direction, so that we will not pay for the previous mistake.
l Since automatic testing can be achieved, it can solve the problem of regression testing of manual difficulty.
We follow the "Establishing Test => Law Test by => Re-establishing the test => re-test pass" mode, step by step, step by step.
1. Several key links of test code
An general analysis of the test code can be found that the test code has a similar structure. Each test case is executed to include the test data initialization, the code to be tested, verify the correctness of the test results, see Figure 1-1 .
Figure 1-1 General flow of test code
Since the test code generally contains the three parts in Figure 1-1, we must improve the test code to make it good structure as long as you start from these three aspects.
1) Separate the test data and test results from the test code
When using the CXXUnit series test tool development test code, it is found that the general programmers are mixed together, and the same test results are mixed with the test code, which has caused the management of test cases and test results. Management is very difficult. Because data and results to manage each use case are actually managed these code. And for a function (or function), each additional new test case is added, there is a similar code, and the logic of the code is actually consistent, and the difference between the previous test code is in initialization data, the test results are different. This actually also leads to a repetition of the code.
We can separate the test data and test results from the test code, so that a function (or function) test code will be able to test multiple sets of test data, which can be tested by multi-group testing. The result is verified.
2) Put the test data and test results into the file and save it by directory
The test data and test results are separated from the test code to better manage code and test data, put the data and results of each test case in a file, and the file name or file can be indicated. Test the name of the case enclosure, which is more convenient to manage, see Figure 1-2.
Figure 1-2 Files and catalog structures
It can be seen from Figure 1-2 that the test case is very intuitive. From the directory name, you can know the test case for that function, which can know which aspect of this test case is known from the test case document name. When a feature test case can be divided into many categories, we can also create a test case classification subdirectory, so that different types of test instances can be separated from convenient management (see Figure 2-1).
3) Bind the test data and test results together
When each test case corresponds to the test result, the test results can be embedded in the test code. When different test cases should correspond to different test results, the test results should also be separated from the test code according to 1). come out. In order not to confuse the relationship between test data and test results, placed them in the same file. Here is an example, and the contents of the test case in February in February in Figure 1-2 are shown in Figure 1-3:
Figure 1-3 Structure of test case
As can be seen from Figure 1-3, the test data and test results are placed together to increase readability and maintenance.
4) A test code to run multiple test cases
How to make a test program to perform multi-group data test and results? 3) The test cases have been tested into the category, and organized by the corresponding directory structure. At this point, the test program only needs to take a test case file from the test directory, then perform the initialization, then perform the test, the final comparison test result; test a use case file, then remove a file to test, so loop until all use cases The files have been measured, see Figure 1-4 for details. Figure 1-4 Flowchart of a test code test multiple test cases
2. Test case management scheme design
If there is more data groups to be tested with boundary data, the test code prepared by the general CXXUnit series is the initialization code, and then the corresponding function is called, and then call the corresponding function. Function test. This results in:
During the entire process of automatic test, the maintenanceability of the test case will affect the difficulty of future test cases, good self-test procedures should be able to expand test cases.
When using the CXXUnit series test tool to develop test code, you can test the test code in the test code for some simple tests. However, when a function or function is to perform a lot of group data (such as boundary data), use this method to repeat the test code, and may write a large number of repetitive test code every additional test case.
Example: To test the code for the periodic meeting to make an appointment, you want to test the following sets of data:
1) Periodic meeting
1.1) Periodic meeting by the number of times a number of times
1.2) Periodic meeting of the end time to terminate
2) Cycle meeting per week
... (content and 1.1, 1.2 agree)
3) Periodic meeting per month
... (content and 1.1, 1.2 agree)
4) Periodic meeting held annually
... (content and 1.1, 1.2 agree)
l With the increase in the number of test data groups, a large number of test code for repeated actions will appear, and the only difference between these test code is different due to the initialization data.
l When a function requires one or two test cases, test cases can be controlled and managed in the test code. When a function test requires a large number of test cases (see example), a large number of test cases are embedded in the code. It will be difficult to manage, you have to know if an exemption has already been able to traverse the test code.
2.1 Test case directory structure
It is necessary to design a set of architecture that can well manage and add test cases.
When a function has a lot of group test data, we can store all test case data in the file to separate the test cases and test code. Since the test case is exist from the test code, it can be easily managed and maintained. We can build a directory for each function (or function) to be tested, each test case placed in a separate text file, put all the test data files corresponding to the function in this directory, when testing data You can also create a corresponding subdirectory in the directory, classify. This makes it possible to facilitate the management of test cases, and the test program is only focused on test logic. It is also discussed based on the example of the reservation function of the test cycle.
Figure 2-1 Test case directory structure
As can be seen from Figure 2-1, when a function (or function) is used, it can also be divided by the subdirectories under the "Supreme Directory of a function test case". If it feels that it is not fine enough to Continue to deepen the directory level until the classification is relatively clear.
Since the test case data and test code are separated, it is not necessary to modify the test code for a new test case for a function (or function), simply add new test case files to the test data directory of this feature. I.e. The function's test procedure is performed for each test case file (including the use case files in the subdirectory) of the corresponding test data each time.
The directory structure is used to make a division, which is convenient for future management. As a good program should have good readability and maintenance, good test data should also have good readability and maintenance.
2.2 Test case file structure
The test case file is stored in the test example initialized data and the test data after the test. The structure of the data uses the format of the general configuration file, see Figure 2-2 for details. Figure 2-2 Structure of test case file
1) Segment name
The concept of the segment is used in the configuration file, and the paramesis in C does not affect each other in the keywords in each segment, and the section is paragraph.
2) Keywords
The keyword is used to mark the value of different elements, and Key is the name of the keyword, the name of the keyword is not distinguished.
3) value
Each keyword corresponds to a value, value is a value, and the value is distinguished.
4) Note
Support for a single line of comments, the contents of the character "#" are comments.
5) row structure
The structure of a line can only be the following:
l [section]
l Key = Value
l
l One of the above three in the above plus
2.3 Test Program Universal Library
After the test data is separated from the test code, add the code to manage the test data file and parsing the test data file. This part of the code is common, and they can organize them to use the library to develop test programs.
Figure 2-3 Test procedure and test universal library relationship diagram
2.3.1 Managing Test Data Files
The functions of the library that manages the test data file are as follows:
1) Get the interface of all test file paths under the directory
Can find all the test files (such as "* .ini" files) in a directory (including the "* .ini" file).
2) Get the interface of the next test file
Provide the user with the path to the next test file, if no next test file is returned.
2.3.2 Analyzing the library of test files
The function of the library of parsing the test file is as follows:
1) File analysis interface
A test file is parsed in the file structure in the 2.2 test case file structure.
2) Get the value of the interface
Provide users with values corresponding to a certain keyword in a certain segment in the test file.
Since the structure of the test file is consistent with the general configuration file structure, you can use the existing library to implement (such as the configuration file parsing class in the PWLIB).
3. Summary
A complete test case contains test data and test code, which brings a lot of redundancy to test cases when testing data and code are mixed together, and bring many redundancy to the test code. This paper proposes the idea of separating test data and test code, and explains how to separate. After the test data is separated from the test code, the test data is simple and convenient.
4. Reference
CPPUnit Home: http://cppunit.sourceforge.net/
XProgramming Homepage: http://www.xprogramming.com
4. About the author
Wenyi, currently paying attention to software development automatic testing, you can contact me via email wenhm@sina.com.
