How to ensure the quality of the test cases are created? How to manage their life cycle? How to deliver them quickly and when developers need it ?
1. Template– need one and complete template for creating test cases. We can create it in a text editor, spreadsheet or buy or customize the tool. I have written about this in the context of the JIRA.
（使用测试用例模板）
2. Descriptive and specific– you need a short, concise title and description. Should clearly define the purpose and scope of their operations. We are writing to all testers, not only for yourself, use simple language, complicated language figures are not popular here. Use rather imperative, therefore “Write abc and press enter” not “I am writing abc, and pressing Enter.”
（测试用例描述要简明扼要、清晰明确）
3. Reusable– one and the same test case can be used in many scenarios. Let us remember that! Creating a new item, we must imagine a different kind of use case of our work. I also imagine that test step could be reused, so pay your attention at this level too.
（考虑测试用例的可重用性）
4. Atomic– the greatest tester nightmare struggled with the manual testing is a test case, which is too long and doing too much dependency checks. Person carrying out a process must have a sense of progress, otherwise is bored, reducing its vigilance, and motivation. Tester may have to perform 100 test cases and do them in one day, but it can also have their 10 and do it for a week. Let us create test case, which can be performed up to several minutes, and gain the favor of the other fellow testers, among the satisfied, we can also include those who write automation scripts.
（保持测试用例的“原子性”）
5. Positive and negative– the next important thing is the order of creation. What to do when the project manager requests a set of test cases on the day following approval of an implementation plan? Usually we do not say that he wanted only the beginning of positive tests, those which check whether the functionality exists and acts in accordance with the requirement. Give him as such set as soon as possible, then we can deal with the preparation of a negative description situation and the relationship between other requirements. To sum up: Positive -> Negative -> Relationships
（先写“正面”的测试用例，再写“负面”的以及其它类型的测试用例）
6. Refactor– if you already done your job we have to remember that applications are changing and the changes in the test cases should follow this process. We can version it, using clone and change method for a given version number. Head of the tests should determine how many past versions we support and we should care enough about our current collection of test cases.
（测试用例也需要“重构”）
7. Test data– there are moments in which along the correct execution of the test we have to provide some data, which usually (if they are too complex to be described in the text) are attached as binary files. We need to analyze whether it is easier to provide test data or may be easier to add the appropriate test steps.
（考虑在测试步骤中还是在附件中提供测试数据）
8. Setup and tear down– if the test case requires the initial configuration, call a particular component, we need to take this into account in the zero step. It is also important to cleanup in the last step like in unit testing or automation, but I believe that during the test manual is worth to preserve this good practice.
（测试用例执行前的初始化和执行后的“扫尾”）
