Live XP: (5) Test Management
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
No matter from that point, to ensure the quality of the software, the test work is less. Testing often is often ignored. For agile methods, lean programming, how to ensure the effectiveness of the test? How to reduce the cost of the test? It is two problems that are primarily considered in the test. Testing process
It is not easy to do a good job. Testing work and software development is closely related, but the self-contained system. Test is not a separate stage or activity, the test itself is a process, has its own life cycle, starting from the test plan, the formulation of the test case, the structure design of the test code, test code. The life cycle of the test and the software development life cycle are screwed together, interacting. Of course, we are still the old saying that Rome is not built a day. For us, it is still from a simple start.
When we talk about lean programming theory, the concept of comprehensive quality management has been discussed: every link in the production process needs to be responsible for quality, rather than leave quality issues to the final quality inspectors. This has a good reference for software development. The most headache in software development is quality problems because people's behavior is too uncertain. After a long software development cycle, the software gradually molds, but defects also slowly increase, trying to solve long-term accumulation problems in the final juncture is not a good practice. Software is developed to this time, discovery and modification of defects need to pay great consideration.
We said that the final test is not important, but software quality issues should pay attention to the entire software process.
Minimum unit of test
The important idea of testing problems is on the management of tests, how to manage all tests in a project, as well as their related documents, related code, how to define testers responsibilities, how to coordinate the relationship between testers and developers ?
XP test priority and automation test practice is a very good practice, and we have also mentioned this practice more than once, but the unit test of XP emphasized, many people have some misunderstandings:
The examples provided in XP are too simple, unable to combine with the production environment. The unit test in XP only provides a specific operational idea for testing, but it does not replace other test principles. How to test, how to organize tests, how to manage tests, these are defined by different software organizations. The test code itself is not adapted to change. The ideal condition for black box test is that external behavior is not changed due to changes in internal behavior. When the demand or changes in the design, the internal behavior of a code needs to be changed, but external behavior does not need to change, so that the unit testing for external interfaces does not need to change, but this rule is violated, we need Pay the double price of the test code. Therefore, the design of the test code itself is very particular.
Unit test (sometimes referred to as class test) is a test level test, which is the minimum unit of test. XP value is very important to this minimum unit. We observe the test priority framework XUnit, found that it uses a combination mode to organize a large number of units of units to form a complete test network. Therefore, XP's ideas is very simple: the minimum unit test can be done well, and the system test can be done. This idea is not necessarily correct, but the idea of paying attention to the minimum unit is absolutely correct. Each component is correct, the last software is not necessarily correct, but the component is incorrect, the last software must be incorrect.
Test priority
Test priorities and unit tests belong to the same practice in XP, but they are still distinguished. Test priority emphasis behavior, write test before writing code, the unit test mainly refers to the scope or level of the test. We said that test priority practice is really concerned, is not a test to be prior to code, the key is whether you can write a code suitable for testing, whether you can consider the design from the perspective of testing, consider code. From another perspective, insist on test priority practice, you can consider problems from an external interface and client perspective, which ensures better connection between the various modules of the software system, and developers Thinking, it will also gradually implement it from simple considerations, transfer to the thinking of software structure. This is the real idea of testing priority. Insisition to write test, just a measures to help you change thinking habits. For some excellent programmers, as long as it can reach the purpose, it is not the most critical. In fact, test is a difficult thing, because many times, we can't completely simulate the test environment, or the cost of completely simulate the test environment is too high. Software development is always carried out under a fixed time and cost, so we must use small cost as much as possible to achieve our key targets. Many of the books about the test are difficult to test, but in fact, there are many more contents that are difficult to test. For example, a business logic, which uses 14 business entities and some other classes, how to test it? With the Mock Object method, the cost of establishing the FixTure will be high, in addition, if the entity class is controlled (for example, the entity class can initialize the data instead of acquiring data from the database), this test costs It is also acceptable if it is not (for example, the technology provided by a third party), this cost will be higher. There are many similar situations, but why do you have these problems? One of the great reasons is that we have not really putting tests as an important part of software development, insisting on testing priority thinking, can greatly reduce test costs. Modern software development often relies on specific middleware or development platforms. If these third-party products do not provide a powerful testing mechanism, it is often difficult to conduct a comprehensive test of the final product. For example, a JSP / Serverlet environment provided in J2EE, analog HTTP input and output is a difficult thing. If the test is not considered in the software design phase, the final test will be inch. However, in fact, if the problem is considered in the software design, it is not too much coupling between the business code and the environment control code. In this way, the test work can be done for independent business code, and this cost will be much lower.
Public class userlog {public service () {// is difficult to test code // need to test business code}}
It is noted that in the above example class, the code to provide services is divided into two parts. Part is a code provided by the framework, which is difficult to test simulation. This class has a lot of code, such as the processing of HTTPREQUEST, the data to simulate the data of HTTP It is more complicated. This increases the difficulty of testing. And this part of the processing is often the functionality provided by the platform and does not require testing. The second part is the key business code, which is the core of the test. So, on the one hand, it is difficult to build a test environment, and on the other hand, it is necessary to test the business code. Therefore, we naturally think of separating the business code to be tested:
Public class userlog {public static void write (String name) {// Write user information;}} public class userlogadapter {public service () {// difficult to test code UserLog.Write (name);}}
In this way, the test can be performed for UserLog, because there is no need for a complex test environment, the cost of testing UserLog is very low. In the J2EE core mode, a refactoring idea that hides a specific representation layer detail to the business layer:
Although the starting idea of this reconstruction method is to avoid the details of the interface level to expose to the business layer, but from another perspective, it also improves the testability of the business layer assembly. After all, build a user information, more easily than building an HTTPSerVeltrequest.
Therefore, the most reasonable introduction test is in the demand phase. The focus of the test work is how to define the test plan, how to define the acceptance test and obtain the customer's recognition, when the demand phase is completed, it must ensure that all the needs can be tested, all have test cases, the demand stage is another Important test tasks are preparing to build a test sandbox, build a test environment, and test data needed by this software project; in the design phase, the focus of testing work is how to define detailed test content of each module, the best way Implement the test code and build a test framework, and some test tools are needed for some complicated projects. In practice, we found that an extension of a test framework is a simple but practical approach. XUnit's focus is for automated testing provides a universal framework, capturing exceptions, logging errors, and failure, and manages Test Case and Test Suite using combined mode. In fact, there are still many jobs that can continue to be carried out on the XUnit framework, for example, is there a more common test case in software development? This way, you can define some abstract test cases and use this as the foundation of the test framework. For example, we hope that when we integrate daily every night, the test results can be sent directly to the person in charge through SMS, then we can embed this part of the function in the framework. These are accumulated on the test framework. For a software organization, it is necessary to spend time to accumulate the test framework. This simplifies the test workload and enhances the quality of the software.
Testing process
We have said that there is a process of testing itself. Although XP does not spend too much pen ink to describe your testing process, but after careful observation, we can find that there is also a test process in XP:
This process starts from the user story (or the use case recommended in the previous chapter), not only provides a demand for the version plan, but also provides test scenarios for accepting tests. For the acceptance test of customers, it provides feedback for each iteration, including BUG feedback and feedback of the next iterative information. Only the customer recognizes the acceptance test, the software can publish a small version. This is the highest level of testing in the XP process.
In the above, we mention that the best time to introduce tests is in the demand analysis phase. Because of the origin of the test life cycle - test plan and test cases require support. Let's refer to the process of RUP:
We see that RUP recommends starting testing activities in the first phase. Test activities in the early stage of the development process, the purpose is to improve the testability of software. Software Design If you have not been able to consider the testability of the software, the cost of the test will rise, and the software quality will drop. Sometimes, the unit test or component test is difficult. Therefore, we need to test testability for class or components. For example, for a component that implements a business process, there is a large number of status, events, branch selection and so on. The cost of component testing for such components is very high. If the testability can be considered in the component design, for example, the components are split into a sub-assembly having a smaller particle size, or the method of being used in the component is inserted in the assembly, the state of the component can be directly manipulated. It is the key to reducing test costs when designing. The source of design and testing is an analysis of demand in the first phase. The basis for the process of process component is exactly from the demand for the project. Some practices for testing strictly follow the first maintenance test, and then maintain the order of the code to achieve changes. In practice, a problem that the priority often happens is that when design changes affect test code, developers tend to bypass test code and directly modify the code.
When I just contacted the test priority ideas, I was strictly written in accordance with the premiere of the test, but when the code needs to be modified, sometimes some very small changes, this time I still maintain the original habits, directly on the code After completing the modification of the code, I suddenly realized that the test code needs to be modified, so I have modified the code, because it is just a small modification, I think there is no need to run test. This thing is soon being forgotten by me, but the hidden danger is buried. When two days after integrated test, the test program captured the error of this code. After debugging, it was found that simply modifications were neglected to ignore an extreme situation. Location errors, debug code, and through testing time far exceeds the time that is currently saving. Fortunately, the code is discovered in the next checkpoint (integrated test). Improve the test network. When I learned and practiced the test priority, the team I was in the middle of the project, and there was a lot of code that did not implement the test, and I took the idea that the newly written code must follow new tests. Method, the old code remains status. Doing so can save a certain amount of cost, but soon we discovered that the put incentives were absolutely worth mentioning existing code. Plus the test code can quickly respond to changes, just this, it is worth rebuilding the test network. In addition, since the test is required, we have also found some interface definitions in the original code unreasonable or irregular. In other projects, in additional starting projects, the problem that is often encountered is that with the progress of the project, the late test code is getting better and better. At this time, do we need to improve the original test code? The answer is yes, you will benefit from it. For automated testing, modify the test code and re-run the test, there is no bigger you think.
Perfect tests do not exist, but testing can be more and more perfect. In the beginning of the article, we mentioned the idea of comprehensive quality management (TQM). TQM believes that each process of product production will affect the final product quality, everyone needs to be responsible for quality. For software development, any step of the development process will affect the software quality, to improve software quality, not to enhance the test power, it is necessary to ensure the quality of the software throughout the process. Building testing and continuously improving the testing behavior runs through the entire development process, providing a basic guarantee for quality.
automated test
Automation test is another excellent idea of XP test activities. When we discuss iteration, it was a brief discussion of regression and automation testing. Only the test is automated, the regression test can be achieved, and the reconstruction can be implemented, and iteration can also be performed. Therefore, XP has always emphasized that its practice is like a puzzle, only all implementations can fully show their charm. From this perspective, we can understand the meaning of this sentence.
For an automated test system, several parts are particularly important:
Data Preparation: For a simple TestCase, data preparation works in Setup (see junit), but the test data during real-world development is usually more complex, so it is necessary to prepare a separate data to provide classes. For a complete enterprise application system, often contain thousands of test cases, and the corresponding test data is also extremely large. At this time, we also need to have special mechanisms to generate and manage test data.
Test data and specific items are related to therefore there is no standard for establishing test data. So we see in the XUnit framework, the framework is just the activity of the establishment of data to abstraction and does not do additional processing. But for automated testing, it is necessary to establish independent test data for each unit. The independence of the test data is the premise of testing independence. Most of the test data is established in the form of scripts, including input data and output data. For example, for a business entity, you can use a script to assign a value for it. The script file has a lot of forms, such as configuration files, database data scripts, and more.
Verification: Verify that comparing the result values returned to the method to be tested and the predetermined result value to determine if the method is successful. The result value is always matched with the input value, so we often put the result value and the input value in the same script. The relatively universal verification method is to use the assertion mechanism, and in addition, it includes error records, browsing test results, generating test reports.
Pile: Stub is a technique that is commonly used in automated testing. In OO design, class and classes often have a relationship, how do we test a separate test of a class that relies on other classes? There are many phenomena that are difficult to simulate errors in many software design. For example, an error is wrong, the network protocol error is difficult to simulate. The idea of testing the pile is to solve these problems, a pile is not a real object, but it is possible to provide data or status of the object to be tested, so that the object to be tested can be able to use the dependence object, or analog events.
