The evolution of software testing from experience to actual operation

System version 2.0 2012-09-12~2012-09-17 time period of the test.

This test is mainly for the System version 2.0 due to the record and monitoring of the two systems unified common use of the basic database changes. The original system in the record and monitoring shared with the same main frame, now separates the two, but the common data such as user information, unit information needs to be unified, these changes will involve the database data structure changes, and data structure changes must cause changes in the system code and some data optimization changes. So for testers, the whole system has to be tested thoroughly.

Then, describe the whole test idea and the test process in detail.

Because I have seen a detailed online test report, which describes the idea of a specific and effective version control, so at the beginning of the organization of testing, there is a sense of testing into various stages to mimic version control.

The test began in the morning of Wednesday, requiring the release of an external version at the end of the week, which meant that there was a full three days to test.

1 hrs
BVT	major issues found	verify bugs and small functional tests	verify bug
2012-09-12 (Wednesday)	2012-09-13 (Thursday)		2012-09-14 (Friday)

The test process is divided into four stages: the first stage, the version acceptance test, mainly see whether the system can be run, the core function of the module can be implemented under normal circumstances, the second stage, is also the most important test phase, at this stage to focus on the main business logic, requirements, detailed testing, In short, all the major defects of the discovery should be carried out at this stage, the third stage, this stage is more cumbersome and scattered, in this phase of the main stage of the validation of the bug and some of the remaining small functional points of testing, mainly should be the above phase of the verification of the bug, at this stage of the work priority of the GRASP, Do a good job of recursion, the fourth stage, the remainder of the Friday afternoon to carry out the remaining bug verification, at this stage, as far as possible to ensure that serious or troublesome bugs are almost nonexistent, so as to ensure that the task is completed properly.

In this process, the work of each stage of the grasp and control needs to have a certain comb. The following four stages are reviewed in the actual test process.

The actual test work for this project is at 10 points, according to the previous plan, the time of the BVT test to be controlled within 1 hours. Because of a database problem that caused the updated version to be inaccessible, each module clicked unresponsive. After an XL change, the existing list of stations can not be displayed and so on, and began to formally test from 10 points. In this round of operation, should be the fastest speed to find out whether the system has the main function of direct error, such as click on the main function of the system to see if the error, the main module of the new function can be carried out smoothly, the page shows whether there is a clear flaw, the main should be from the above three aspects of the fastest test. Although the whole system, but the functional modules are really just a few, to ensure that in one hours to complete the implementation of these tests and to describe the problem to the developer, time is still relatively adequate. In the actual test, the time is slightly exceeded. In the implementation of the BVT process, careless on the Construction unit module in the detailed testing and some query operations, when the remaining time to test the remaining module is a little tense, it is inevitable a little rush. Finally, after about 10 minutes, the test of this phase has been completed. During the testing of the whole system, there should be a spectrum for the important functional modules, and then the BVT test of these modules should be maintained equally, should not be added because of some new features (in this case, the other two units are added to this module in the Construction Unit management).

Because of the time, so the first version of the serious impact of the test to further the bug is more, but on the other hand, the more serious the problem to solve the faster, so the second phase of the test can be very smooth deployment.

In this phase should focus on the monitoring registration module and the real-time monitoring module and other users see the system, monitoring registration module in the Project sub-module and Construction unit module to pay attention to the sub-project logical relationship is relatively complex and will affect the other aspects of the system a little more, There are many differences in the construction unit module than in the original system. Construction Unit Management This module is 11:20~14:10 (about 50 minutes) intermediate test, the angle of view is mainly located in the original system and the current system between the construction module of the difference between the point of view to test, this piece of the problem is indeed more, but also in the planned time to complete. Project Sub-module test, originally expected in 14:15~14:45, but the problem is still more, only a push and push, until 16:00, about two hours, this period a bit chaotic, there are a lot of blocking continue to test the bug, and then and development of communication, It was a bit of a fuss and a bit hectic to wait for the development of code to be developed, since there were no parallel test lines that were previously considered for a thorough alternative. Although there is about a week before this version with the developers to complete the project sub-project function, this time is due to the base library and then make a change, but the development of the submitted version is still a lot of problems, it may indeed be in most parts of the system is based on engineering: monitoring registration, real-time monitoring, Statistical report, it is a full body. Real-time monitoring module Here is not a lot of problems, there are also engineering that block of changes caused by the problem here. The rest of the time is basically a matter of verifying some bugs. The next day, which is Friday four, focuses on the test of other users ' landing systems. In this piece of the problem is particularly many, although in addition to safety supervision Station user Login system after the module is very few, but due to less development considerations, so serious problems more, watching the time is so urgent, after consulting the manager, was informed that the supervision unit users and property Rights Unit users can temporarily not consider the situation, the workload suddenly reduced. The second phase is complete.

In the afternoon of Thursday, a third phase of the test was launched. Verify the previous bug, as well as the test of the small function point. Including monitoring registration, alarm information disposal, safety supervision station management. Now think of their own real-time monitoring of the operation of data, hanging weight data, run time test is not in place, it should be covered in this stage. These sub-modules are either logically simpler or are not affected by the underlying database's problems, so they are tested at this stage. The bug that was verified at this stage is basically a problem with the logic function in the last phase of the test. In the morning of Friday, it was mainly the validation of bugs in the Engineering management module.

Friday afternoon, the fourth stage, the residual test work is very few, so it is relatively idle, basically a simple verification bug. Now think at this stage should be in the beginning, serious analysis of the system where the number of bugs, where more important, user-use rate, so as to conduct a structured exploratory testing, scattered and not messy. It was really uncomfortable at the time, the lack of discipline in the test, the whole person was the bug of the verification of the domination. For the aimless test is powerless, at 5 o ' Day, and development and communication of some notes under the change of the bug, just stay in Chang xx next to see him to 2.0 version of the remaining bug, observe the process of changing the bug.

During and after the test there are some ideas about the test here to explain the main.

The first stage should pay attention to not many things, high-efficiency testing of the system to affect the operation of the defects.

The second phase of testing requires a good design in advance. The main business logic of the main module should be tested centrally, and the emphasis should be placed here. If this business logic is done entirely by the whim of the test execution, it is easy to miss out. The problems found here should be some of the requirements, logic, for the development of the more troublesome to modify, if in the early leak test, in the later stage only remembered, will affect the progress of the whole project. At this stage, after discovering the problem, most will cause the test of this module can not be carried out, so in the design of testing ideas, but also to consider and its important level similar to the module, when it must wait for the development of modified to expand the test of this module, you can timely the same level of another module test on the schedule, In case you're going to get too flustered. Also, for developers who are prone to problems with the development of modules, because they generally change a module will be more troublesome, so at this stage as early as possible to test, give him more time.

The third phase involves the validation of the pre-bug and the testing of the remaining small-function modules, always remembering to put the bug's validation to a higher priority, and consciously discovering whether there are other business logic beyond the business logic covered in the second phase during the bug verification process.

The fourth stage is the end of the test, should be based on the whole system, on the characteristics of the system to analyze the system problems more points, the list out, followed by exploratory testing.

The evolution of software testing from experience to actual operation