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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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