Write test requirements and test cases

There's not much difference in the template of the test case, and I always wanted to find a good test case template when I first came into contact with the test. Typically, the test case template includes the main three items: operating instructions, expected results, and no pass. With these three items, the other is based on your needs to embellish, my blog has a I now use the test requirements and use case template, can refer to.

The question is how to fill in the template, that is, how to write test requirements and use cases. Some people write test requirements and test cases separately. Test requirements as a document, a test case as another document, as I began to write test cases, there was always a question: test requirements and test cases write only one not OK. It is true that the test requirements and the test cases themselves do not have too obvious boundaries, and the test requirements are not much different from the test cases. I do not doubt that testing can be performed according to the detailed testing requirements. In fact, I always hold a view, if the time is not enough, you can write test requirements, because after all, the test is basically the tester himself to perform their own test requirements and test cases, if the test requirements are listed in the function points, the operation process is known. However, I still write the test requirements and test cases together, and the time seems to be quite adequate.
Here is an example of a simple test requirement and test case:
Test requirements: You can only enter any number in the 1~4 in the edit box
Test cases: 1. Consider entering a non-numeric case
(not complete 2. Consider non-input situations
Test case format) 3. Consider the case that the input is not in 1~4
4 ............
The above is a test requirements and test case comparison, you can see that the above test cases than the test requirements described in more detail, generally speaking, I write in the way above, test requirements only describe a overall requirements, test cases consider a variety of situations.

As for the test requirements and the writing of test cases, there is an easy question to be confused about: granularity.    In short, it is the degree of refinement. Write the granularity is too large, not conducive to writing clear test object and operation process. If you are doing the test yourself to write a test case is a little better, know what you write, under what preconditions can execute the test case, if someone else executes the test case you write, especially to the system is not familiar with people, it is difficult to say no trouble, It may not be possible to find the first step in the operating instructions where to operate, or to be confused about the test results, the results are the same as those written on the test case. I think such a test case is not a good test case. Write the granularity is too small, I will not stand, you will complain about the things to write is too much, more importantly, write test cases more time, you can use to execute test cases less time, I have a similar experience. Granularity of the trade-offs, is a troublesome thing, but for the first time to write test cases of the people, the proposal began or write a little bit, write more, will slowly realize which places can be secretly lazy, hehe.

Test case coverage, this is a relatively large problem, I am here just a brief mention, many books are introduced, I learned a little fur. The simplest, test case, the first must be guaranteed to contain all the functional points of the object you want to test; second, there must be at least two test items with a positive and negative. Another equivalent division, this method I think, this is the most basic requirements, but also used the most, the most important. Other such methods, can also learn to learn, when necessary, may be used, such as the object to test the relationship is very complicated, causality diagram method can be tried. Frankly speaking, those methods I have not used, because basically do not use them, it is simply a waste of brain power, hehe.

The test case of the fall generation, an unavoidable process. I've also written one or two test case documents so far, and not once was done. One is because the initial understanding of requirements and detailed design documents is not deep, neglecting some of the more covert but important test points, and the second is that there may be some minor changes in software requirements during the writing of test cases. I remember one time when I finished the test case, I thought it was almost finished, I was happy, I found only more than 20 pages, but by the end of the day I really felt I could finish, the number of pages doubled, more than 50 pages, and I really wrote so many words for the first time.

Last one, skeptical. Theoretically, the test should start from the demand, participate in the needs of the review, the detailed design also to test, but at present we do not do so much, or do not complete. Depending on the status quo, sometimes I can only rely on detailed design to write test cases, so it must be assumed that the detailed design is written in the right. Then we began to understand the detailed design, skeptical, after we have a certain understanding of the detailed design (at first it is best not to doubt). At this time there will be several situations, one, not very clear, the second, as if there is a missing place, the third, it seems wrong (just the wrong word, because we do not have the requirements of the specification can be consulted). To continue writing the test case you have to deal with these three questions, for the first, no way to consult the programmer who wrote this document; for the second kind, the programmer who wrote the document; to the third, tell him it's wrong. Of course, you can also choose another way, temporarily skip, but sooner or later to solve. In the absence of the requirements of the document, there is a certain risk, do not know whether the detailed design and requirements are consistent, before the requirements of the document, ask for their doubts about the needs of personnel, after the requirements of the document, and detailed design documents against, the general detailed design documents are not wrong to where, hehe.

It seems that these, their own slowly experience will come out, but must first bite the bullet to write the use case, written written on the good.