Software test case effectiveness Analysis and evaluation method _ software Testing

Test case design is one of the basic skills that testers must master, and it is also one of the difficulties. So how does a written test case evaluate effectiveness? Recently has been thinking about this issue, originally wanted to come to an article, but has been lazy, until now, the information on the Internet a lot, here on the combination of their own thinking to simply talk about their own views it.

1, from the test case form analysis

First, each company has a test case template for each company, including modules, sub modules, priorities, preconditions, steps, operational data, expected results, use case status, severity of defects, probability, actual test results, comments, font formatting, and font size Whether the test case is designed according to the previous agreed process or according to the module design; where the test case is placed and the order of execution, the test cases performed above can be used as input data for the following test cases, that is to say, whether the test data is consistent and so on, This is the first condition that we judge the validity of a test case.

Again, see if the individual columns that correspond to each use case are written effectively, if the operation steps are concise, the priority setting is reasonable (of course, the priority setting and the actual project version of the test strategy also have a lot of relationship), the expected results are clear, the previous review of many test cases of the expected results are very vague, If you click "Save" After you modify the settings and the expected result is "saved successfully", I feel that the expected result is the same as not written; we can optimize for: Database data Update and modify settings consistent and page display and database data consistency. This gives the test case a clear standard of judgment when it is completed and handed over to another person for testing.

Use case Format Evaluation method: The use of peer-use case review methods.

2, from the test case coverage Analysis

1 The total number of test cases and particle size

Many theoretical books write the principle of designing test cases: The maximum coverage is achieved with minimal test cases. I have always doubted this principle, and personally think that the coverage of test cases is related to the test time, the total number of tests and the granularity of the test, and if you have enough time you can design a high coverage test case, but the total number of use cases and the granularity will change accordingly. Particle size is fine, no matter how you design, the total number of test cases will certainly rise, and coverage will be increased accordingly. Now think about what the author might want to say: Use the appropriate test case design method to achieve coverage, while the total number of use cases is relatively small, then what we need to do is to find a way to grasp this balance.

Use case review of our standards can be from the following aspects to grasp: whether the granularity is properly, use case redundancy, the corresponding module used test case design method is appropriate (this is not right and wrong, only good and better difference) and so on

2. Coverage and omission rate of test cases

(a) Coverage

Personal sensory coverage is the most important part of test case design, especially the coverage of main functions, no matter how granular you are, the total number of test cases, and what test case design method is used, only the function that must be covered is covered by the whole test case. So how to judge if there is no coverage to it.

First, compare the requirements specification to cover all demand points on demand (both explicit and implicit, of course this is related to test objectives and test strategies, such as major functional testing or validation testing or detailed testing, etc.)

Again, let other test peers and development help review to see if the function detection point is covered.

Finally, analyze the bugs found (pay attention to bug quality rather than quantity)

(b) Here is a simple next omission defect (omission defect is also a side reflection of coverage) method of collection (the following is mainly to enter the implementation phase)

a> User Site feedback;

b> when multiple build tests are performed on a project, the later discovered bug analysis is whether the test case is not covered or if the test case has but not been executed by the tester before;

C> Cross testing, different testers perform test cases or conduct related module tests in a different way of thinking, you may find hidden functionality before the test cases are not covered.

The above is the test Case effectiveness analysis method which oneself thought, the test case validity analysis should be a synthesis each aspect balance one process and the activity. Some peers also use defect rates to reflect the effectiveness of test cases, if the total bug found is divided by the total number of test cases, the number of bugs found by a test case, personal feeling that this is unscientific and not practical, the number of bugs does not really reflect the validity of test cases, the quality of bugs, The coverage of major functions and the testing strategies used should be the cornerstone of our analysis.

Copyright notice: This article from the Flying Fish without Wings 51Testing Software Test Blog: http://www.51testing.com/?363907

Original works, reprint, please be sure to hyperlink form to indicate the original source, author information and this statement, otherwise it will be held accountable.