Test and software life cycle
Tip: I need some knowledge of UML and RUP development model before watching this article.
Test introduction
What is the test is, is it wrong when the development is complete? In fact, it is like fishing, saying that the use of the season, sunshine, water flow, and even the size of the fish net hole directly affects the effect of fishing. The test is also the same, not just to find the wrong, but also need planning, but everyone knows that the sooner of finding software defects, the lower the cost of modification. So how can I accurately and timely discovery software defects, this first to sprout from the life cycle of the software.
Software life cycle
The software's life cycle divides software development into several phases, mainly demand, analyzes, design, encodes, and tests several major stages, while in addition to these major stages in the development of RUP, these stages are also Iterative development. But I have a few questions, is it necessary to test after the development? Perhaps in the early development process, the current software development has gradually developed into large-scale team development, and the early interventional test helps to discover problems early, and there is a big reduction in project risks. the benefits of. However, how to intervene in early intervention is a very worthless discussion. Below we describe how to intervene in software testing from the software life cycle.
Demand, combination of analysis phase test
First, we analyzed from various stages of the software life cycle. In demand, analysis, demand staff will analyze the needs of users, forming a product manual, if better detachable to the example, activity map. Maybe everyone is not very familiar with UML, I will make a simple explanation here. The use case is a process of using the system using the system using the system using the system using the system using the system to use the system. The use case is a set of cases of the system, the participant (role) of the use case, and the relationship between the use case and the participant. Below is an example of a simple shopping system.
Figure 1
From the figure we can find the functions of three systems, 1 purchase goods, 2 security verification, 3 return the goods. At this time, our tester can know that this system has three functional blocks, at which time the test target of the three function blocks can be described in detail in the test plan, thereby ensuring the coverage of the system without important function blocks. The following experienced case designers will test the function through the test plan to design a reasonable case. At this time, our testers can also play another role, reviewing the needs, such as whether the user is going to log in, everyone has a different view, at which time the demand personnel can further confirm whether the user needs to use the login function block. Different systems are always different, but in the eyes of our testers, it is used to determine if the product can meet the main criteria for users' needs, and a use case can correspond to one or multiple function points. I can clearly write the test function objective, I call the test plan. Here mainly describes the functions, performance requirements, stability requirements that the product needs to be achieved. That is to say, we can intervene test in the early demand analysis phase, determine the goal of later tests, if you need to make a higher demand test, demonstrating whether the demand can meet the requirements of the user, thereby reducing demand risk.
Combination of design phase and test
Enter the design phase, the design group members provide a detailed design document, which is mainly sequenced, collaborative drawings (state map), class diagrams, etc. The timing diagram shows us a partial participant that directly interacts directly in the process of useful events, and can be seen as a black box). At this time, you can extract which system is to test, you can clarify the goal of our black box test, rather than which the system is going to be tested. Collaborative diagrams can detail the changes in system status. Establishing a state diagram for a large software product is a hard thing. Since there is a lot of labor results we don't use? The test demand for the previous test is a static demand, but here we can clearly see the changes in the software status. At this time, we can analyze the status conversion and the main program process to test for various states. The case, the change in the status is sometimes the handover of the system interface. At this time, the design case is mainly for the principle of the interface, ensuring that the interface is effectively tested during the hook. Below is a state map: Figure 2
From the figure, we can see how the system operates from entering POST, making the system via messages, such as changes from purchase (Sale) to paying (payment) This state is made by Create's message. However, we don't need to care about this. This is concerned about the design person and developers. Test staff is concerned with the changes in the system, and our test case can measure these state changes. So our test case has a supplement. It has just been discovered from the example of the example. For example, the purchase of goods is purchased, and now you can see the process of implementing the status of the purchase function system, at this time The case is to supplement this state change, so that the case can cover dynamic changes, thereby ensuring the test of the important functional process of the system. At the same time, you see the change of the message is the change of the interface, which also guarantees full interface. test. The role of the class diagram is more apparent, and below is a class diagram.
image 3
From the class diagram, you can clearly understand which entity classes have this system, such as the POST entity class with the Sale entity class, there is a variable, function, and the level of the variable and function (public, private, private) and many more). This way you can effectively test the corresponding test cases for these design. Especially in China, it is impossible to meet such a white box test like Microsoft, and the test of the function will help the problem of earlier discovery, eliminate software defects in the early stage of development.
Coding phase implementation test
When reaching the coding phase, how to intervene in the early days, it is necessary to compile daily, in the possible case, the development of the developed function is compiled daily, forming the test-tested version, so that the test personnel test, At this time, the previous work did not do it in white. At this time, we already have test demand instructions, test plan and important cases, which can be assigned and tested, and at least important functions are guaranteed early in the early days. At the same time, as the system is constantly improving, the testers of each function module can increase the test case to ensure the completeness of the test. There is also a benefit of daily compilation, that is, the measured software defects can be handled on the same day, thereby ensuring the destruction of defects in the early stage. At this time, the test and development have been perfectly combined to test the synchronization of testing and development, and does not conflict with each other.
Later test
After development, it is test, saying that now you are easily, because testing is synchronous, so I think you think that you are the regression test of issues found during the development process. Even you can drink coffee J, because I found almost in the coding stage software defect, then the main energy is placed in some tests such as integrated test, performance test, compatibility test, and the standards of these tests are analyzed in demand. There is, such as performance testing, it requires the data we have paid attention to the demand, is we still doing these effective goals? to sum up
Test If combined with the software lifecycle, you can effectively guarantee the target and coverage of the test, and you can take advantage of the demand personnel, the strength of the designer to guide our test, but also bring some problems, it is the difficulty of implementation, essential The entire development team is required to use RUP or similar to RUP for its own development process, and the senior tester has a certain understanding of it. However, its benefits are still obvious, why don't we try to do it? J Finally, I wish you all good luck, more discovery, have discovered problems early, write high quality software.
