How to ensure the test coverage?
A first analysis needs to be fully tested
Specific testing requirements analysis in two steps:
1, access to testing needs
a source of demand:
the explicit requirements:
(1) the original requirements specification
(2) Product specification
(3) Software Requirements Document
(4) whether the inheritance documents
(5) experience base
(6) common protocol specification
implicit demand: the user's subjective feelings, the mainstream view of the market, evaluating professional analysis.
2, needs analysis, generate test requirements document
Needs of different sources into one demand point, each point were tested for analysis:
(1) define the measuring range
(2) using the various test methods designed to generate a test point
In terms of the test method, do note the following:
First, the analysis of an inlet. Analysis from the inlet, the possible combination of content classification environmental conditions, operation, and integration testing of people you according to the method, verified one by one. From the exit, the results will likely occur statistics, depending on the traced result, and then find the content as well as different operating conditions, statistics to document, verify them individually.
Second, learn and use a variety of testing techniques. It may be more concerned with test methods, but also the way the specific operating needs attention. After all, the test method is relatively easy to find, you reach people are familiar with. If a different person each way summed up the test and use them in your own test implementation, you may receive unexpected results.
In the testing process aspect, noted as follows:
First, the initial needs analysis to do well. The demand gradually refined to the point of small features, designed to test for each function point. For complete test design documents, after examining the review of project-related personnel, made the first draft of need.
Second, during the test, improve test design documentation in accordance with the Implementation process needs to change and specific test encountered.
Third, after the end of the test execution, to summarize the problems. Which contains the problem itself found, there may be issues raised by customers. Summed up the results of integration to the test designs to further improve the test design documentation.
For one test, it is impossible to have a comprehensive test coverage. Many times as needed to sum up the accumulation, will make the test more comprehensive.
In terms of the test flow thinking, we can make the following note:
First, the comprehensive test does not mean fully tested. Different stages have different requirements for software testing, such as in the previous version 0.8, for unimportant issues or small screen functionality issues do not need to be concerned about. But in the acceptance stage, the content may need more attention.
Second, life-long learning, and only continue to learn constantly to think, the ability to make their own tests stronger, more comprehensive test subjects complete.
Second, when the test requirements analysis is completed, and after the formation of the document, the assessment needs to be tested to ensure the accuracy and integrity requirements.
Third, after the completion of the test requirements, test cases can be designed according to test requirements.
To ensure full coverage of test cases to test requirements, to include all cases.
Dividing the single functional test designed to test the design and test scenarios, functional requirements single point in the coverage function test, test scenario covers the business logic requirements.
When designing test cases, test case design can use a variety of methods.
● firstly divided into equivalence classes, including input and output conditions of the equivalence class division, a reasonable set of valid and invalid equivalence class equivalence class, which is the test efficiency and reduce the workload of the most effective way to improve.
● You must use boundary value analysis, experience has shown that this approach to design use cases can find a lot of bugs.
● You can use the error reckoning additional test cases, which need to rely on your wisdom and experience.
● check program logic control logic devised coverage of test cases, if the cover does not reach the standard test should be replenished sufficiently.
● If the input conditions comprising combinations of the described functions of the program, beginning alternative cause determination table and driving method of FIG.
● For the software-based configuration parameters, use less orthogonal test selected combination to achieve the best results.
● clear system for traffic flow, the scene may be utilized throughout the test program process method, using a combination of test methods in the case.
After completion of the test case design, test case review should be organized, so you can learn from the opinions of others, reducing the omission, completion of test cases.
Fourth, after the completion of the preparation of test cases, test execution is,
● the implementation of 100% coverage of test cases.
● during test execution, we should continue to supplement and improve the test case, ensuring greater test coverage.
Fifth, the entire testing process, the same demand is impossible, so timely updates test requirements, test cases.
VI. To test requirements, test cases and bug found associated together, easy to manage and track, but also easy to see the coverage.
Finally, we can not do not miss, can only say that as far as possible and more comprehensive coverage. In addition, all the use cases, best products, development, testing, evaluation, together, can not test the final say, to prevent the limitations of thinking leads to omission.