测试用例编制完成之后，以一个测试人员的角度再审视一遍：

　　永远不要以为你写完测试场景的后一个测试用例后算完事了。回过头去从开始将所有的测试用例再看一遍，但是不要当自己是个测试用例的编写者或测试策划者，以测试人员的角度审视所有的测试用例。理性的思考并且干运行你的测试用例，评估一下你所提到的每一步都是清晰易懂的，并且预期的结果和这些步骤也是相协调的。

　　测试用例中规定的测试数据不仅要对实际的测试人员是可行的，而且也得是依据真实的实时环境的。要确保测试用例中没有依赖冲突，而且也要确认对于其他测试用例/工件/GUI的所有参考都是精确的，否则测试人员会陷入大麻烦中。

　　约束测试人员，但同时也让他们感到容易。

　　不要把测试数据都留给测试人员，给他们一个输入的范围，特别是当执行运算的时候或者是应用程序的行为是取决于输入的时候。也许你会把测试项目的值分给他们，但是永远不要让他们自己来选择测试数据项目，因为，有意无意的，他们会使用相同的测试数据因而在执行测试用例的时候一些重要的测试数据会被忽略掉。

　　根据测试类别和应用程序的相关领域对测试用例进行组织，这能让测试人员感到容易一些。清晰的指出哪些测试用例是相互依赖的/或是可批处理的。同样的，明确的指示出哪些测试用例是独立的，孤立的，因此，测试人员可以按照自己的意愿管理他/她的全部测试活动。

　　成为一个贡献者

　　从不接受FS或设计文档原来的样子，你的工作不仅仅是将FS浏览一遍然后明确测试场景。作为一个和质量相关的资源，你要毫不犹豫的去贡献。要给开发人员提建议，特别是在测试用例驱动开发环境中。建议一些下拉列表，日历控件，选择列表，单选按钮，更有意义的信息，警告，提示，可用性的改进等等。

　　不要忘记终的用户

　　重要的利益相关者是将会实际使用AUT的终的用户，所以，在编写测试用例的任何阶段都不要忘记他。事实上，在SDLC的任何阶段也都不能忽视终的用户，但是目前我只强调和我讨论的话题相关的。所以在识别测试场景的时候，不要忽视这些大多情况下被用户使用的用例，或者是那些甚至不太使用的业务关键用例。把你自己想象成终的用户，把所有的测试用例浏览一遍，判断一下你文档中测试用例执行的实际价值。

　　总结：

　　测试用例的编写是一项会对整个测试阶段产生重要影响的活动。这个事实使得测试用例文件编制这个任务变得非常的关键并且微妙。所以，编写测试用例得先适当的计划一下，还得非常的具有条理性。编制测试用例文件的人必须记住，这项活动不是为他/她自己而做的，而是为了整个团队，这个团队包括了其他测试人员和开发者，还有那些会被这项工作直接或间接影响到的客户。

　　所以，在这项活动进行的过程中必须给予适当的关注。对所有的使用者来说，测试用例文档必须是很好理解的，方式明确，维护简单。除此而外，测试用例文档必须介绍所有重要的特征，必须覆盖AUT所有重要的逻辑流，伴随着实时和实际可接受的输入。你编写测试用例的战略是什么？和我们的读者分享你的建议吧~也可把你的问题写在下面的评论中。