Scenario Test Case Note summary

Recently in the writing of a module scene test case, from a scene more than 10 steps, basically did not follow the user logic, and there is no subject to the last scene of a few simple and clear steps and the subject explicitly through the external review, the process, encountered a lot of problems, constantly corrected, continuous summary, Finally, a good scenario test case is written. a good scenario use case must meet the following points:

Cover as many bvt as possible;
The execution steps of each scene are simple and clear;
Must be the user may use the scene (scene story), has certain logic;
Do not waste resources, achieve faster code execution, scenario test case format:

Preconditions: Some of the steps are not the focus of this scenario test, so don't focus on these steps, so you will need to set the direct to the preconditions, that is, the implementation of this test case, what is required. For example, when we need to test whether an object has an attribute, the object's creation is not the focus of the test case, so the precondition should be an object.
Execution steps: Follow the user's logic, step by step to complete
1.
2.
Forecast results: Avoid the general written above each step can be set normally, to write: Each step after the success of the set, we are how to test the success of this step, that is, how to write code.
1.
2.
Post condition: The destruction cleanup of resources. For example, this test case only focuses on the object creation process, so an object will eventually be created in the execution step, and then the objects created in the post-condition will be destroyed. points that the scenario test case should be aware of:

1. Pay attention to the theme, it is necessary to understand that the use case is to test what function, should not be the API test points in any combination of their own, where to write where;
in order to achieve the theme of the test point, we can put the test case before writing a user-used scene story, This is to ensure that the scene can be seen in the process of user use.
2. Note the context, the scenario use case itself is to impersonate the user, test the basic function (BVT) Link up whether there is a bug, must have the user's logic;
3. Be careful to test simple basic functions such as password legality, memory, Bandwidth out of bounds such a problem scenario does not need to appear, the API is already covered,
about the legality of passwords and other test points, there is no need to appear in the scene use case, that is, the scene only the main process (password error This belongs to the sub-process).
4. Note that the steps should be concise and clear, no ambiguity, the number to explain the unit;
because the test cases written out not to go to manual testing or to implement their own code, so that others can suddenly be able to understand the meaning of the implementation steps, no ambiguity.
5. It is not said that all BVT test points are tested in two ways, because sometimes a certain aspect is not BVT;
6. Try not to make different scenes cover the same test points;