软件测试用例编写

软件测试用例编写

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

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

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

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

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

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

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

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

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

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

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