可重用的测试用例是需要设计的

实施GJB5000B三级的组织都知道需要进行测试用例重用。那么，是不是只要把测试用例保存下来，当遇到类似的需求进行测试时，就可以提取出这些测试用例进行重用呢？

没有那么简单。

如果是软件出现变更需要进行回归测试时，此时使用原测试用例（姑且将其也作为一种测试用例重用的方式）没有任何问题，即使不做任何处理完全重用都没有问题。但是，如果是不同项目的软件，即使完全相同的功能，其测试的操作步骤也不一定相同，有些可能还相差较大。

从这点出发，设计可重用的测试用例不应该包括详细的操作步骤。

对于一个测试用例来说，用例名称、操作步骤及预期输出是它的3个核心要素，而不同的操作步骤可能会产生不同的输出，如果测试不同项目软件，操作步骤可能不同，预期输出也会不同，那么岂不是就无法进行测试用例重用了？

当然不是。

虽然有些具体业务功能用例，特别是与UI界面密切相关的用例，很难做到完全重用，但这些用例的设计思路是完全可以重用的，而且测试代码也是可以完全复用或大部分复用。

另外，可重用的测试用例是需要设计的，使用合适的结构化的测试用例，更容易被重用。

例如，对于一个“用户登录”的功能，它的测试用例如果设计成下面这个样子，就不适合重用：

用例ID	用例名称	操作步骤	预期输出
DL-1	用户名正确	输入正确的用户名，密码为空，单击“登录”按钮	弹出“密码无效”提示
DL-2	密码正确	用户名为空，输入正确的密码，单击“登录”按钮	弹出“用户名无效”提示

因为这样的测试用例描述性的文字过多，很难提取出可供重用的公共的部分，所以不适合进行重用。

同样的测试用例，如果我们将其改为下面的结构形式，就很容易进行重用了：

用例ID	用例名称	用户名	密码	预期输出
DL-1	用户名与密码不匹配	John	空格	“密码无效”提示
DL-2		空格	0home	"用户名无效“提示

同样的需求，下面的测试用例设计只是改变了表现形式，它很简洁，而且将输入数据实例化，很明显它更容易提取出可重用的公共部分，它是更适合重用的。

不过这种形式的测试用例也有不足。那就是输入数据过于具体带来的局限性——如果这些测试数据不具有代表性或者不够全面，可能会造成漏测。一种改进的思路是扩展出专门的用例数据池，即使是同一等价类的数据，也可存储多组输入数据，由测试执行时选择。

总之，如果想要获得易于重用的测试用例，测试用例的结构或者表现形式是需要设计的。

这正是：

测试用例要重用，效果可能大不同
好的形式或结构，重用才能真用好

参考书目: 软件测试之魂：核心测试设计精解，作者：肖利琼，出版社：电子工业出版社