How to confirm the end of software testing?

Before the software dies, if there is no end point for testing, then the software test will never end. The end point of software testing, according to their own company specific circumstances to formulate, can not generalize! The individual considers that the test end point is determined by the following conditions:
　　 1. Based on the "testing phase" principle:
The testing of each software is generally through the stages of unit testing, integration testing, system testing, and we can develop detailed test end points for unit, integration, and system tests, respectively. After each test phase meets the end criteria, a subsequent phase of testing is performed. For example: unit testing, we require that the test end point must meet "core code 100% through code Review", "functional coverage of 100%", "code line coverage of not less than 80%", "No A, B-type defects", "all defects found at least 60% Are included in the defect tracking system and at all levels of defect recovery rates to the standard "etc. The end point for integration testing and system testing has the relevant end criteria, of course.
　 2. Based on the principle of "test case":
The Test designer designs the test case and invites the project team members to participate in the review, and once the test case is passed, the test can be used as a reference standard for the end of the test. For example, in the test process, if you find that the test case pass rate is too low, you can refuse to continue testing, until the developer repair before continuing. When the function test case pass rate reaches 100%, the non-functional test case reaches more than 95%, allowing the normal end of the test. However, when using this principle as the test end point, it is very important to grasp the quality of the test case.
　　 3. Based on the principle of "defect convergence trend":
In the software testing life cycle, as the test time passes, the defect graph that is found in the test is gradually rising and then tested to a certain stage, and the defect becomes a downward trend until the defect is almost zero or it is difficult to find the defect. We can decide whether the test can be finished by the trend of the defect, which is also a criterion.
　　 4. Based on the principle of "defect recovery rate":
Software defects in the test life cycle we divide into several severity levels, namely: Critical error, primary error, minor error, general error, minor error, and test recommendation 6. When we determine the end point of the test, the defect repair rate of the critical error and the primary error must be 100%, no functional errors are allowed, minor errors and general errors must have a defect repair rate of more than 85%, a small number of functional defects are allowed, and a later version is resolved; the defect repair rate for minor errors is best 60 %~70% above. For test recommendations, you can temporarily leave the changes.
　　 5. Based on the principle of "acceptance test":
Many companies are doing project software, if this to determine the test end point, it is best to test to a certain stage, to meet or close to the standards specified by the test Department, the submission of users to do the acceptance test. If through the user's test acceptance, you can immediately terminate the test department test, if the customer acceptance testing, found a partial defect, can be targeted to modify the defect, after verification passed the customer, the corresponding test can also be completed.
　　 6. Based on the principle of "coverage":
For testing the "coverage" principle, the individual feels as long as the test case "coverage" covers all the software requirements of the customer, including the industry's hidden needs, functional requirements and performance requirements, as long as the test case execution coverage reaches 100%, basically the test can end. such as "the minimum statement coverage in a unit test cannot be less than 80%", "test case execution coverage should reach 100%" and "test demand coverage should reach 100%" can be used as the end point. If you are not at ease, you have to look at the performance of test cases, check if there are cases where the use case is missing, you can "sample test" and "random test" of the commonly used functions. For coverage in unit tests, integration tests, and system tests, each stage cannot be ignored.

　　 7. Based on the principle of "project plan":
In most cases, each project will be written from the beginning of the development and testing of the schedule, corresponding to each milestone in the test plan, the test progress and test end point to make a limit, generally with the project team members (development, management, testing, marketing, sales staff) to reach a consensus, The team agreed to set a standard end point. If a link in the project is delayed, the test time is shortened accordingly. In most cases, all of the required test content and regression tests have been completed and can be used as an end point. Many non-standard software companies are the project plan as a test end point, but if it as an end point, testing the risk is large, software quality is difficult to be guaranteed.
　　 8. Based on the principle of "defect measurement":
This principle may not be used by many people, the understanding is relatively small. We can use the commonly used defect analysis techniques and defect analysis tools to analyze the defects that have been found, and to make the data easy to consult and measure the defects in time period. I remember ZHUZX in this forum on the issue of defect analysis technology, I will not repeat the story. We can also use "test period defect density" and "run-time defect density" as an end point. Of course, the most appropriate test end criterion should be "defect number control within an acceptable range".
For example: 10,000 lines of code to allow a maximum number of what severity level of error, this is better quantified, better implementation, as a test of the mainstream of the flaw measurement.
　　 9. Based on the principle of "quality cost":
A software often has to be balanced from "quality/cost/schedule" and then stop. As to which of the three aspects of the main position, it depends on what software. For example: Human life Aerospace software, that quality is important, even if you spend more money, postpone the progress, but also to test to ensure high quality after the end of testing, release version. If the general common software, because of the interests and market reasons, even if there are bugs, you must first launch products, no way ah. In general, the most important reference is: "To find the cost of defects and this flaw can result in a balance of the loss." Specific operation, you can according to the actual situation of the company to define what kind of situation is "the cost of testing costs the most cost-effective, most reasonable", while ensuring that the company's interests to maximize. If the cost of the bug is found to be higher than the cost of the bug, the test can also be terminated.
　　 10. Based on the principle of "test industry experience":
In many cases, the experience of the testing industry can also be a reference for our testing. For example, the tester's familiarity with the industry, the ability of testers, the efficiency of testing, etc. all affect the execution of the entire test plan. If a test team, everyone does not have the project industry experience data accumulation, to get a new project, Nature is confused, do not know where to start, the test quality will not be very high. Therefore, through the experience of the tester, it will also play a key role in confirming the test execution and the end point.

How to confirm the end of software testing?