测试怎么做，成本来说话

什么样的测试策略是有效的？

比如，测试要投入多少人力和资源？ 要进行哪些类型的测试？ 要进行哪些级别的测试？ ……

无法决择的一个原因就是没有一个量化的测试成本数据。

如果能够清楚地知道不同的测试策略所需的测试成本，那么上述这些问题都将会得到很好地解答。

在《软件测试的有效方法》中给出了通过对改正缺陷的成本进行限定来度量测试成本的方法。

通常软件缺陷产生的原因有以下几种：

• 需求说明不当

• 用户指定了不正确的需求

• 需求记录有误

• 设计规范不正确

• 程序规范不正确

• 程序编码错误

• 程序结构或指令错误

• 数据输入有误

• 测试错误

• 纠错错误

• 纠错导致新的缺陷

这些缺陷的范围很容易界定。 但对这些范围内的缺陷发现和纠正成本的评估是却很困难的。

可以通过以下两种方法来获得对测试成本更有现实意义的评估。

第一种方法是度量上述缺陷产生以及纠正时项目成员投入的时间和工作量。

这种方法在理论上是可行的，但在实际操作过程中，很难将从引入缺陷到最终发现缺陷的这段时间和工作量记录下来。 因为缺陷被引入后，可能要过几个星期其至几个月才会被发现，要追溯并恢复这些成本可能比较困难。

第二种方法更具有操作性，它通过记录发现的缺陷数目、纠正缺陷所用的成本、发现缺陷所处的阶段这些信息来计算测试成本。

纠正缺陷的成本包括重新编译代码或修改文档的成本。 在软件生命周期的不同阶段，这个成本要乘以不同的系数。

• 设计需求阶段纠正的缺陷： 这个系数为1，纠正成本是与纠正缺陷相关的总成本。

• 在软件编码实现时纠正的缺陷： 这个系数为10，因为额外的纠正成本与删除软件中有缺陷的组件有关。

• 系统投入使用后纠正的缺陷： 这个系数是100，纠正缺陷的成本大约是在系统投入使用前纠正同一缺陷所需成本的100倍。

如果我们能够使用简单易操作的方法得出了类似项目不同的测试策略所需的纠正成本，就很容易地回答小软件要不要做单元测试和产品集成这样的问题了。

毕竟，想要科学地决策，首先就要有数据支持！

这正是：

测试成本要度量，有了数据不慌张

单元集成做不做，成本回答当不当

作者简介： 王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。 现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。