How to write a good test case _ test

The discussion of test cases has been nagging, and what test cases are good test cases, everyone has their own point of view. I don't want to say this. The properties of a test case, the definition of use cases and the characteristics of use cases, because these random search, is a piece, basically you cuff me, I handcuff your results, not a little innovation.

I have been thinking, as testers should use the head to test, that is, should be in the work of continuous experience, to apply their findings to the test, so you can have real improvement, you have the theory and ability to be competitive.

Back to the test case, I think it's a good test case to do the following three points.

First: The basis of clear

As we all know, a project first set up, and then after a series of action to the requirements analysis, last night after the requirements analysis, testing can do test requirements, and then can write test cases. So writing test cases is based on requirements. That's too general, give me an example. A system through the early requirements analysis, detailed design, module design, such as a series of actions, the final generation of detailed requirements and detailed design documents, etc., in these documents, has been very detailed description of all the requirements and function points, there are more detailed technical instructions, The next task is how to turn these function points and requirements point into a test point, which requires a good test requirements analysis and test plan work, to generate a test point can be tested. It is also a manifestation of the need to be measurable.

Assuming that after the last step, the system has 5 modules, 50 large function points, 500 specific demand points, and finally generated 5,000 test points. So OK, we're going to write 5,000 test cases. Still, a test case can only correspond to one test point, the test point and the use case are 1 to 1 relationships; a demand point can correspond to multiple use cases, and the demand point and use case are 1 pairs of relationships. The purpose of doing so is to say in statistics.

Second: The purpose is clear

Use cases have a test purpose, which is to be clear and can only have one purpose. No matter how many steps ahead, it is to find the way to this end. Features from the big to the small level of division, we do test cases are layered, otherwise you how to define the priority of use cases. Wait until the minimum functional point of the test is support this function point of the other upper function points, we are the default is correct, this is our expectation, so in the test steps do not have to the top of the function to consider the test data, only to him as a correct way to find the current function point of the line. In other words, the function point you want to test requires 10 connections to find, then the first 9 connections we should have designed the use case before, the default in the 10th connection is OK, the first 9 steps of the use case just tell you how to find the 10th step. That's it.

Third: Easy to statistics

Test cases are of great importance to the quality control and evaluation of the whole testing process.

One, you can do test requirements coverage analysis. So if a use case writes several test points, then the requirement coverage analysis cannot be completed, at least not in accordance with the rules.

Second, make use case success rate analysis. Having multiple test points in a use case will certainly result in a reduction in the number of use cases and a significant increase in use-case failure rates. So what's the point of success in your use cases?

You can also divide by module, to analyze which module exists more problems, there may be more problems (should be different for programmers, ability is different, defects like the distribution of clusters, this everyone knows), there are more modules need to do further testing or next time as a test focus. If your statistics are inaccurate, the results will be misleading.

Third, do defect analysis. When a use case fails, a flaw is generated. If you write multiple test points in a use case, when you return, these test pilots are back, and some of the testing points that may have nothing to do with the defects are returned to you.

This article is reproduced from the 51Testing Software test network, see more: http://www.51testing.com/html/news.html