Author: Robin F. Goldsmith, Dorothy Graham compile the Blueski article is selected from: CCID February 13, 2003 in the development of the model, testing often acts as a remedy the situation afterwards, but there are to test-centric development model of. In this article, let's investigate the V model and see if it is there? Decade of software development has proven that the practice of dividing the stage in the development of life cycle is very good. On the basis of a classic waterfall model, there is a spiral model and process iterative method, fast software development (RAD), and a newer Rational Uniform Process (RUP), but in these process methods, there is no fully emphasize the value of the test, No tests are given to you. Like development models, tests also have test models, although these methods are fresh. Part of the reason is that many testers have accumulated a lot of experience in their work, using these experiences to do their work. In general, tests often have to occupy the entire development cycle, but even in many regular universities, there is no software test course for those who are about to start the software career. Software experts are constantly providing new development models, which is also actually developing needs, at the same time, in the development process, it is constantly felt that these existing methods are inadequate, for example, not more than RUP, but There are also significant shortcomings in RUP, for example, RUP does not position the test plan.
V-model
The V model has only been blurred by the software industry. The V-model claims that the test is not an event to make up for behavior, but an important process as the development process. The V model is shown below:
Figure 1: Valvination of V model
The V-model was earliered by the late Paul Rook. In the 1980s, the V model was included in the British National Computing Center literature to improve the efficiency and effect of software development. The V model is accepted in Europe, especially the United Kingdom, and is considered an alternative to the waterfall model, and it is misunderstood in the United States is another waterfall model. During the traditional development process, only the test process acts as a stage after demand analysis, summary design, detailed design and encoding, in fact, the launch of the V model is also an improvement to this. In the waterfall model, there is indeed this adverse effect, that is, after many important development activities, the test is just a final work, not the main process, although the test will occupy a project cycle, many project supervisors Still still insisted so much.
Test is a significant job
The V model describes some different test levels and illustrates different phases in the life cycle of these levels. As shown in the model diagram, the left decline is the stage of development process, which corresponds to the right part of the right side, that is, various stages of each test process. Note that in different organizations, naming of the test phase may vary. On one side of the development phase in the model graph, first start from defining business requirements, then constantly converting these needs to the profile design and detailed design, and finally develop as program code. On the other side of the test execution phase, execute the start of the first test from the unit test, then the integration test, system test, and acceptance test. The value of the V model is that it clearly indicates different levels in the test process, and it is clearly described the corresponding relationship between these test phases and the development process: • The main purpose of unit testing is to exist for the coding process Various errors, such as the user input the boundary value of the verification process. • The main purpose of integration test is for the possible problems that may exist in detailed designs, especially those that may exist on interfaces between units and other program parts. · The system test is primarily designed to check whether the system is effective as an overall whether it is effective, such as whether the expected high performance is achieved in product settings. · Acceptance tests are usually performed by business experts or users to confirm that the product can actually meet the needs of user business. Different types of defects and errors will appear in different development phases, so different test techniques and methods are needed to discover these defects. Discovery art
Most testers are more likely to accept the view of the V model, that is, testing and development is equal during development. Even the developer also appreciates the test level and development process proposed by the V model, there are very few people to make full use of all the power of the V model. Many people think that the test will only happen after the coding or a part of the system is completed, and the test is incorrectly as "executed test". In this way, they knew that they really thought of testing when they were starting to perform tests. Test is not just testing. The test process also includes determining what (test range and conditions) to test, how to be tested (production test case), establish a test environment, execute test, finally evaluate test results, check whether the standard has been completed, and report progress Happening. Moreover, only these are not enough, according to the experience of many testers, when you think there is a problem, you can find problems there. If the test expert Boris Beizer said in his classic test book "Software Testing Techniques (Thomson Computer Press, 1990)", the test design can find defects and errors. Moreover, if you put the test design in the final stage, miss the timing of discovering the serious problems existing in the architecture and business logic design. In that time, it is inconvenient to repair these defects, because the defect has spread into the system. Go, so this error will be difficult to find and repair, and higher cost.
Flexible explanation, try to test early
The V model is easily interpreted at least in the UK, but it is difficult to accept in the United States. For example, although the V model does not express its early test design, Graham believes it is reflected in the process and considers that this is the powerful force of the V model. These other test behaviors that have not been explicitly illustrated in the V model are sometimes evolved as a W model, because it is actually "V", the test is also "V" overlinked with this. Regardless of whether the V model explicitly explains early test design behavior, the test design is indeed worth emphasizing. According to the requirements of the V model, once documentation is provided, test conditions should be determined in time, as well as writing test cases, which make sense to test. When the demand is submitted, it is necessary to determine the high-level test case to test these needs. When the summary is written, you need to determine the test condition to find design defects in this phase. If the test document can be submitted as soon as possible, there is more check and review time, which can also be used to evaluate the development document. There is also a great benefit that testers can face the challenge of specifications as early as possible (testing is a challenge). This means that testing is not just the quality of the software, but the test can also find the defects as early as possible, thereby helping to improve the quality of the project. Testers participating in the previous work can pre-estimate problems and difficulty, which will significantly reduce overall test time and speed up project progress. What-how-do
For traditional waterfall lifecycle models, V models are often mistakenly considered to require development and testing to maintain a linear front-rear relationship, requiring strict instructions to indicate that the previous phase is completely over, and can be officially started. This cannot support iteration, spontaneity, and change adjustment. For example, Brian Maricick ("The Craft Of Software, 1995)" Author) "Author) mentioned in the" New Model "test process", "The problem of V model is to divide the system development process into has The stages of strict borders have enabled people to hand over and exchange test information between these boundaries. "The situation is not the case, strictly regulating not effective developers and testers in the way in which various models are applied. In fact, various models simply remind us, it is necessary to define what must be done (demand) - what, then describe how to do (design) - how, then spend a lot of strength to achieve (encoding) - DO . The V model does emphasize that each development level has a test level associated with it, and the recommended test should be designed before the level. Each model does not specify the amount of work. Effective developers can always decompose projects into operable small stages, such as the entire project in an iterative development into many small pieces, and ignore the actual size of each fragment. At this point, the model's What-how-DO sequence is of great significance for payment on time, and is also important for the implementation of each phase target.
V model can't do
The V model applies to all types of development processes, but does not necessarily apply to all aspects of development and testing processes. Whether it is a GUI or a batch, the mainframe is still web, Java is also COBOL, which requires unit testing, integrated testing, system testing and acceptance testing. However, the V model itself does not tell you how to define the content of the unit test or integration test, how to work, how to perform specific test design, and how the input is the output result is correct. Some testers believe that: "Do you use a V model to see the application you apply. Some projects need to apply V models, and some projects are not needed. You can use it in projects that require V models." This practice actually The model is harmful. We should use the model aspects of the application model as much as possible, but it is not forced to use the model for the usage model, otherwise there is no practical meaning. For example, the V-model opponents often claim that the V model is only useful to be very clear, and the project has been documentated, as all developers and testers need to strictly define good demands and design to work. For many documents that need to be supplemented afterwards, or if there is no documentation, it has become a development culture), developers and testers are facing the same confusion. In this case, the concept of V model is still useful, but it is more difficult to apply in the case of unclear demand, because no matter what work to be carried out, what to test, first, you need to know what it has developed. The v-model opponents may claim that the V model does not apply to limit programming (XP), which advocates rapid development, pair programming, before encoding, has completed test cases before encoding. First, we advocate both methods simultaneously, in addition, it is also necessary to indicate that the XP method also emphasizes as much as possible before programming. The V model does not clearly describe how the requirements and design documents should be defined. It is necessary to define how much documentation, and the V model has not been described in the test stage how to test design. During the development of XP policies, the supporters of the V model believe that unit testing can be applied to the divided code snippet, but the V model does not define how each unit test should be matched. Integrated testing is only required when necessary, and the integration test in the final sense is the system test. Although some XP workers see these tests as "acceptance tests", their actual purpose is to reduce the need to reduce the user's testing, but also hoped to ensure that the system is functionally satisfying the needs of user business. V. Substitute for V Model --X Model?
Perhaps because the V-model has an existing time, it has brought about some extent, especially in the INTERNET era. Marick thinks: "Our need to be the need of V model is like fish." In his article, the new model of the test process is proposed. He believes that some tests are earlier than business behavior, while others have to do it later. Moreover, the V model makes it difficult to synthesize system descriptions of different stages. The V-model supporter believes that although there is no model in front of the display, it is impeccable, but in the practice process, some models are still more useful. In the next article, we will examine the X model advocated by Marick.
