The software testing process is an abstract model that defines the processes and methods of software testing. The software development process is critical because the quality of the development process determines the overall quality of the software, and the testing process is also very important, because the quality of the testing process directly affects the accuracy and validity of the test results. Both the software testing process and the software development process must follow the principles of software engineering and management.
With the progress of test process management, many excellent test process models have been summarized by software testing experts through countless practices. These excellent models abstract test activities and combine them with development activities, which is an important reference for test process management.
In the long history of software development, developers and researchers have summarized many kinds of development models, such as waterfall model, spiral model, incremental model, prototype model, iteration model, rapid prototyping model and Rational unified process, etc., these models have a good guiding effect on the software development process, but these process methods do not fully emphasize the value of testing, nor do they pay enough attention to testing work, so the use of these models can not better guide testing practice.
Software testing and software development are closely related to planned systematic activities, and it is clear that software testing also requires test models to guide practice. It is gratifying that software testing experts have also summarized many excellent test models through countless testing practices. Of course, because the combination of testing and development is very close, these test models also make a good summary of the development process, reflecting the integration of testing and development. Several of the main test models are described below.
The V model is the most representative test model, first proposed by Paul Rook in the late 1980s and published in the national computing centre literature in the United Kingdom, mainly to improve the effectiveness and efficiency of software development.
In traditional development models (such as the waterfall model), the testing process is often seen as a stage in the completion of requirements analysis, profiling, detailed design, and coding, and although testing may take up half of the entire project cycle, there are still those who think that testing is only a finishing work, not a major project. The V model is a variant of the software development waterfall model that reflects the relationship between testing activity and analysis, analysis and design. The V model describes the basic process and test behavior of development from left to right, indicates the different levels that exist in the test project, and clearly describes the correspondence between the test phase and the development process.
The V model is shown in Figure 1. The arrows in the model diagram represent the direction of time, and on the left are the stages of the development process, corresponding to the stages of the testing process on the right.
Figure 1 Software test V model
The V model adopts a software testing strategy that includes low-level testing and high-level testing, low-level testing is to ensure the correctness of the source code, and high-level testing is to make the entire system meet user needs.
The V model has certain limitations, it only takes the testing process as the last stage of software development, which will indirectly make people think that the test can be done at the end, so that the hidden problems in the early work of the development such as requirements analysis can only be found at the time of later acceptance, which will not only affect the entire development work, but also may cause serious losses.
The V model does not embody the principle of "early and continuous software testing". Adding tests to the V model that should be carried out simultaneously at each stage of software development evolves into a W model. It is not difficult to see in the model that development is "V" and testing is a "V" in parallel with it. Based on the principle of "early and continuous software testing", testing activities during the requirements and design phases of software should follow the IEEE 829-1998 standard. The W model is shown in Figure 2.
Figure 2 Software testing the W model
The W model was proposed by Evolutif and is more scientific than the V model. It can be said that the W model is an upgraded version of the V model, and its main emphasis is that the testing work accompanies the entire software development cycle, and the object of testing is not only the program, but also the requirements, functions and designs. Testing and development go hand in hand to identify problems as early as possible.
The W model also has limitations. Both the W model and the V model treat software development as a series of serial activities such as requirements, design, and coding, and cannot support iteration, spontaneity, and change adjustment.
Neither of the previous two test process models provides a good indication of the integrity of the test process. The H model was proposed to solve the above problems. The H model completely separates the test activities, forms an independent process, and clearly reflects the test preparation activities and test execution activities. The H model is shown in Figure 11.3.
Figure 3 Software test H model
Figure 3 is a test "microcirculation" at some level throughout the production cycle. The "other processes" can be any development process, such as the design process, the coding process, or other non-development processes, such as the quality assurance process or even the testing process itself. Test execution activities can be carried out as long as the testing conditions are ripe and the test preparation activities are complete.
The H model specifically reveals the following.
(1) Software testing is an independent process that runs through the entire life cycle of the product and runs parallel to other processes.
(2) Software testing should be prepared as early as possible and executed as soon as possible.
(3) Software testing is carried out in different levels according to the different objects to be tested. Different levels of testing activities can be carried out in a certain order, but it may also be repeated.
(4) Software testing does not only refer to the execution of tests, but also includes many other activities.
The basic idea of the X model was proposed by Marick, but Marick did not intend to build an alternative model at first. Robin F. Goldsmith cites some of Marick's ideas and reorganizes them to build the X model. The name "X Model" was chosen because X generally stands for unknown, and Marick believes that his views are not enough to support a complete model, but already contain some of the main elements needed for a model, including some highlights in the model, such as Exploratory Testing. The X model is shown in Figure 4.
Figure 4 Software test X model
Marick believes that the biggest drawback of the V model is that it cannot guide the entire process of the project. He also believes that a model must be able to handle all the problems of development, including handoffs, frequently repeated integrations, and lack of requirements documentation.
Marick argues that a model should not prescribe behavior that is inconsistent with currently accepted practice. The left side of the X model depicts separate coding and testing for individual program fragments, after which the two will undergo frequent handovers to finally synthesize the executable program by integrating (figure 11.4 upper right part), where the executable program needs further testing. Finished products that have passed the integration test can be can be canonized (the last action on the top right of Figure 11.4) and submitted to the user, or as part of a larger and broader integration. Multiple parallel curves indicate that changes can occur in various parts.
As can be seen in Figure 11.4, the X model also positions the exploratory test (lower right of Figure 11.4). Exploratory testing is a special type of test that is not planned in advance.
The X model contains as many test design steps as the tool configuration steps, while the V model does not. But in this sense, the X model is also not realistic enough, in fact, it should allow the test design step to be adopted at any time.
Marick also questions the V model because it is based on a set of development steps that must be strictly arranged in a certain order, which does not reflect the actual development process very well.
Although many projects lack adequate requirements analysis, the V-model still starts from the requirements. The V model prompts testers to test what has already been obtained at each stage of development, but does not specify the amount of content that needs to be obtained. Without any requirements documentation, developers may not have a clear idea of what they need to do. The X model ignores the requirements. An effective model facilitates the adoption of many good practice methods, so one of the advantages of the V model is its confirmation of the role of the requirements, while the X model does not do so, which may be a disadvantage of the X model.
The X model fills in the gaps of the V model and the W model and can bring very obvious help to testers and developers.
Four typical test models have been introduced earlier, which are of great significance in guiding the conduct of testing work. But no model is perfect, and you should apply the parts of the model that are of practical value to the project as much as possible, and you must not use the model for the sake of using the model, which has no practical significance.
In the above model, the V model emphasizes several test levels that need to be experienced throughout the development of a software project, and each test level corresponds to a development level. But it ignores that the object of testing is not just the program, or that it does not explicitly indicate that the software requirements and designs should be tested, which are complemented in the W model.
The W model emphasizes work-first and testing of system requirements and system design, but neither the W model nor the V model is specifically addressed for the process of software testing.
In fact, as software quality becomes more and more important, software testing has gradually developed into an activity independent of software development, and each software test detail has an independent operating process. For example, the most common third-party testing today includes the whole process from test planning and writing test cases, to test implementation and test report writing, which is reflected in the H model.
In the H model, testing is a separate part, and testing can begin as long as you prepare the test in advance.
Of course, the X model adds a lot of uncertainties to this, because in real projects, there are often unexpected situations, such as changes in requirements.
In practical work, if you want to flexibly use the advantages of each model, you can use the idea of H model to test under the framework of the W model, and at the same time closely combine testing and development, find the appropriate ready point to start testing and iterative testing, and finally ensure that the predetermined goal is completed on schedule.