Treat every software test Case _ test case like your own child

Software test cases have been being collated recently due to project needs. A large number of software test cases and business is not easy to organize, although a considerable amount of practice, but also to harvest some ideas, hope that the future of software testing work can help.

In the process of collating test cases, you are thinking about a problem from beginning to end and why these use cases need to be sorted out. How to do so that the people in the back no longer need to organize these use cases, but very happy in accordance with a certain standard to do every day or project, in order to devote more time to the strength of the blade, do not omit bugs. As the title says, we should treat each use case as if we were our own children and write each use case carefully. Here are some of my daughter's humble opinion, put forward for you to discuss. :-）

A good interface/unit test case should do:

1. No reliance on the environment

2. Verification Point test complete (cannot be omitted or omitted because of the use case writing a regular copy)

3, use case classification is reasonable, the naming is easy to understand

4, the data is not dependent, the data is automatically created by the measured code. It is necessary to test the data in case the data is ready to be fully

5. Delete test data after each use case is completed

6, can be covered in a use case to the test point, as far as possible in a use case to complete, to reduce the subsequent test data and the use case itself maintenance costs.

7. Each test case is independent of each other and not dependent on each other

8, minimize and develop code coupling, can cover from the top of the situation as far as possible from the top cover

9, easy to understand, the annotation is complete, posterity easily understands the business according to the use case

10, use case structure is clear, test case can also learn to develop code, adopt some design pattern to optimize, improve the code quality of the use case itself, reduce the writing cost and maintenance cost of subsequent use case

In addition, annotate classes can be added to the root directory or portal of different businesses, or in the main process test class, depending on the different business categories. On the one hand can be used for reference, on the other hand, can also use as their own memo. Together with the code, it's also easy to navigate. Development is also accustomed to look at the comments in the code, the wrong place is easy to find in time, but also conducive to the development of communication. Of course, the point here is to annotate some of the more detailed code implementation aspects of the business points and summaries.

More importantly, if you can define a use-case specification, we can test it as well as develop review. The functional test will review the manually executed use cases, and the development team will review the code. Our interface test will review the use-case design, so it is also possible to review the use-case implementation. Although the different project business, the test case implementation framework may also be different, but I believe that a good test case standards must be the same.

I believe, under the supervision of so many pairs of eyes, if all of our test cases for each project are able to do all of these points, then we can make the maintenance of the use case an easy thing to do, and once the use case is running but it means a bug, the days are no longer far away from us. And one day when we leave our current project team, the use cases we have written with our hearts will not become a pile of worthless rubbish because of the high maintenance costs.

I wish this day would not be far away from us, and I believe it will come soon, amen. :-)

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