作为软件测试人员（SQA/SQC），做的最频繁并且最主要的活动之一就是编写测试用例了。首先，请记住以下所有的讨论都是关于编写测试用例，而不是设计/定义/确认测试用例（TC）。

　　这项主要活动有几个重要的关键因素，让我们先来大概了解一下吧。

　　A、测试用例要易于定期修改和更新

　　我们生活在 一个不断变化的世界，软件也不能免于变化。需求也是如此，这就直接的影响到了测试用例。不论什么时候，一旦需求发生变化，测试用例就需要更新。然而，并不 是只有需求的变化才会引起测试用例的版本变化和更新。在测试用例执行过程中，脑海中会涌现出许多的想法，单个测试用例的许多子条件会引起更新甚至测试用例 的补充。除此而外，在回归测试中一些补丁和/或波纹都会需要修订或是新的测试用例。

　　B、测试用例要易于分配于执行用例的测试人员

　 　当然了，让单独一个测试员执行完所有的测试用例是几乎不太可能的。正常情况下，一个单独的应用程序会有几个测试员分别负责测试不同的模块，因此，根据他 们自己在应用程序中测试的部分测试用例也会相应的分配开。一些和应用程序集成相关的测试用例有可能会由多人执行而有的则只是由单独的个人执行。

　　C、测试用例要易于集群和批处理

　 　属于一个测试场景的测试用例通常都会要求以一些特定序列或小组格式来执行，这很正常，也是很常见的。可能会有一些测试用例是其他测试用例的先决条件，同 样的，根据AUT的业务逻辑，一个单独的测试用例会在几个测试条件中存在，而一个单独的测试条件也可能会由多个测试用例组成。

　　D、测试用例有相互依赖的趋势

　 　测试用例中一个有趣并且重要的行为就是他们彼此之间是相互依赖的。在具有复杂业务逻辑的中型到大型应用程序中，这种趋势则更为明显。任何应用程序中能明 确的观察到这个行为的最清晰的地方就是，相同甚至不同应用的不同模块之间的互操作性。简单的说就是，不管相异模块或应用程序是在哪里相互依赖的，相同的行 为都体现在了测试用例中。

　　E、测试用例要易于在开发者间分配（尤其是在测试用例驱动开发环境中）

　 　关于测试用例，重要的一点就是，它并不是只被测试人员使用的。在正常情况下，当开发人员修改bug的时候，他们间接的使用了测试用例来修改问题。同样 的，如果遵守的是测试用例驱动开发，那么开发员则直接使用了测试用例来构建他们代码的逻辑并覆盖测试用例中处理到的所有的场景。

　　所以，将以上的5点记住，这里给出一些编写测试用例的建议：

　　要简洁但是不能太简单；要复杂但是又不能太复杂。

　　这句话似乎是自相矛盾的，但是我发誓并不是如此。走完测试用例的每一步，正确序列和预期结果的正确映射都得要精确，这就是我所说的让测试用例保持简单。

　 　而，使其复杂一点实际上指的是测试用例得和测试计划以及其他测试用例相融合。当需要的时候，参照其他的测试用例，相关工件，GUI等。但是做此事的时候 得均衡一下，不能让测试人员为完成单个测试场景就来回的搬运大堆的文件。另一方面，不要让测试人员希望你会压缩这些测试用例文件。在编写测试用例的时候， 请时刻记住你或者别人不得不修改并且更新这些测试用例。

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

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

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

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

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

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

　　成为一个贡献者

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

　　不要忘记最终的用户

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

　　总结：

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

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

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/