developerWorks：敏捷测试系列文章

最近，IBM中国软件开发中心高级工程师谢明志在developerWorks上发表了《敏捷测试的最佳实践》系列文章的第四篇——《自动化测试的ROI》。

在这一系列的文章中，谢明志以IBM测试工程师的身份和视角，总结并分享了IBM在采纳推广敏捷开发策略过程中，尤其自己亲身参与的产品开发测试过程中对敏捷开发和测试的思考。

我们在敏捷项目开发的过程中使用了定制的测试流程，我们有两部分测试，即 Confirmative 和 Investigative 两部分。我们将这两部分测试都放在当前迭代的计划内完成。原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。

 

以笔者所在团队为例，历时 1 年，经历 12 个迭代后，我们逐渐形成了一套可以遵循测试活动时间表。这张表包含了敏捷测试团队的各项活动安排和必要的前提与进入条件。在这张表中，测试团队较早的涉 入，较早的开展测试，以及各项相关工作，并与设计和开发人员紧密的合作，它确保了测试团队乃至整个敏捷团队的工作的按期完成，是值得向大家推荐一种最佳实 践。

“如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能 够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现 并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。

系列文章的第四篇是对自动化测试的思考：

无论在敏捷开发还是传统开发论坛中我们听到更多的问题仍集中于如何自动化测试，采用什么行之有效的工具和方法才是最好的，似乎重点仍然是工具和 技术。因为很少人认真考虑投入自动化开发占整个项目测试投入的比例的科学性，而更少有人曾经清晰的分析何时，花费多少人力的自动化开发与维护才是颇为合理 的规划，而仍然用经验和教训在维持似是而非的自动化测试体系。

经过在多个自动化测试的项目环境中调研，我们认为成功的自动化测试很大程度决定于合理的投入规划。相反不计成本的规划，或者疏于成本规划的自动化测 试只能带来负担而不是效率的提高，尽管有些人为了满足对其自动化技术的一味崇尚而调整了各种报告结果，并且已经满足了某些人对自动化投入的愚昧狂热后，他 们仍然欢欣于一个价值公式，一些精确的指导来调整或者提高他们自动化测试收益。那么如何做好自动化测试的成本规划呢？

作者试图用ROI公式来计算自动化测试的投资回报率，并利用假设和前提来推导出结论，这样的结论包括：

如果自动化后的测试脚本在项目中只运行一遍，那么自动化脚本本身开发的成本不应大于手动执行一遍对应测试用例的执行时间。即完全没必要自动化。

d%（平均出错率，也就是说一个产品的代码中如果有 d% 的出错率，对产品质量缺陷的修复仍然将带来 d% 的新质量缺陷）的值越大，质量缺陷越多，我们依赖于手动测试的可靠性更大。

回归测试产生的质量缺陷是产品出错率的等比数列之和。

当考虑自动化测试成本收益时，我们应该先考虑那些可能迭代次数更多，运行次数更多的测试用例进行自动化脚本开发。而对于产品的质量缺陷，当质量缺陷越少，质量越好的产品，自动化开发成本收益也会比较大。反之，则致使自动化开发并不合算。

而针对在Scrum迭代开发过程中的自动化测试成本分析，作者提出：

应该说迭代次数（n），测试覆盖次数越多，自动化测试带来的好处就应该越多，而产品开发中出错率（d%）越小，自动化测试效果越好。但是，自动 化脚本也许因为迭代目标和对象的差异性需要大幅修改。而重新构造和改变测试脚本带来的代价和成本也非常大。特别在敏捷测试中，产品变化之大给自动化测试带 来难度也陡然增加。因此，敏捷测试中，我们要以更精细的单位来计算自动化测试的投入产出比。即，决策敏捷自动化测试的投入产出应该基于每个迭代自身的收 益，而不是整个产品开发周期。

结论是，一般产品的测试错误率高于 20%，也就说为了达到质量好到足够能够退出，回归测试至少需要 3 次，在这种情况下我们其允许投入到自动化开发的成本为不多于 3 人天。而当产品质量非常好，错误率低于 20%，因为不需要经过多次测试以达到退出标准，我们也就可以省去自动化测试的步骤了。最后关于本文的经验之谈，当我们从事着敏捷测试活动时，在四周为周 期的迭代测试中，测试人员在第二周的开始进入自动化脚本开发。开发活动不易超过 3 天。

总之，

不要指望自动化投入越多对产品和质量越好，也不要指望自动化测试可以取代手动测试。但是，自动化测试是需要测试人员合理、科学的使用来提高测试成效的途径之一。ROI 的自动化规划将是非常适合敏捷测试、传统测试的最佳原则。