敏捷测试的最佳实践,第 4 部分 自动化测试的 ROI.docxVIP

测试中为什么要规划好自动化测试 狂热的追逐自动化的比率提高，自动化框架的复杂度提升，工具，脚本的开发量增大似乎已经让很多人感到不适。有人开始质疑自动化测试的投入产出比，和自动化的成效，而无论在敏捷开发还是传统开发论坛中我们听到更多的问题仍集中于如何自动化测试，采用什么行之有效的工具和方法才是最好的，似乎重点仍然是工具和技术。因为很少人认真考虑投入自动化开发占整个项目测试投入的比例的科学性，而更少有人曾经清晰的分析何时，花费多少人力的自动化开发与维护才是颇为合理的规划，而仍然用经验和教训在维持似是而非的自动化测试体系。 对自动化工具的研究（基于 2008 年对 IBM 中国软件开发实验室自动化测试工具的研究），我们不经感到自动化工具的本身的效率固然非常重要，以致一度让我们相信自动化测试工具的选择是自动化测试成功的关键。而渐入敏捷开发、敏捷测试的围城后，我们渐渐认识到，人的活动力，工作效率的提升更能影响到工作绩效。仅仅拥有最好的自动化工具还远不能实现最有效的自动化测试。而我们既然相信一支能自律，自我管理的行为模式下的敏捷团队能够更大化的提升敏捷项目的进入市场的速度，增加产品价值，降低投入。那么，为什么我们不从自动化测试者，和手动测试者的投入产出中，经验中分析自动化测试的成功关键呢。于是，我们开始探寻到底自动化测试应该越大程度越好呢，还是应该科学的规划才更有价值，而又如何规划才是合理的呢。 经过在多个自动化测试的项目环境中调研，我们认为成功的自动化测试很大程度决定于合理的投入规划。相反不计成本的规划，或者疏于成本规划的自动化测试只能带来负担而不是效率的提高，尽管有些人为了满足对其自动化技术的一味崇尚而调整了各种报告结果，并且已经满足了某些人对自动化投入的愚昧狂热后，他们仍然欢欣于一个价值公式，一些精确的指导来调整或者提高他们自动化测试收益。那么如何做好自动化测试的成本规划呢？ HYPERLINK /developerworks/cn/rational/r-cn-agiletesting4/index.html \l ibm-pcon 运用 ROI 指标判断是否需要自动化测试，以及多少自动化测试 Wikipedia 对 ROI 的解释为，在金融学中， ROI 被理解为投入产出比（Return on Investment），指投融资的回报率或者有时就指投资回报。它表示相对于投资额的金钱获得或者损失的比例。金钱的获得或者损失可以理解为利益，利润或者损失，浪费。投资额可以理解为资产、本金。 ROI 的最简单的计算公式是： 是指产出、收益。指初始投资，指最终的价值。 测试的价值是通过找到更多质量缺陷（Defects）使得产品后期投入（Cost）减少而实现的。因此，自动化测试和手动测试一样，?最终的价值决定于多少质量缺陷的暴露。 自动化测试 ROI 如何计算的 综上所述，自动化测试的取决于最终发现的质量缺陷数量多少，而自动化测试的初始投资由自动化工具开发、部署，自动化脚本、程序的开发和维护，以及执行自动化测试所需的成本决定。 因此，?越大，越小，我们的 ROI 比例将越大，也就证明自动化测试越成功。 而为了证明自动化测试的优势，我们喜欢将它和手动测试的 ROI 进行对比，我们希望得到公式 1，从而证明自动化测试比手动测试更有效。 公式 1： 如果无论自动化测试和手动测试达到的最终价值都是等量的质量缺陷的暴露，也就是： 公式 2： 也就推得： 公式 3： 进而推得： 公式 4： 经过以上推算，我们可以得到结论，如果要使得自动化测试优于手动测试的投入产出比，我们需要证明同样质量的测试结果前提下，自动化测试的投入成本要低于手动测试成本。 好了，为了进一步推断自动化规划的最优化，我们将从一次成功的测试的案例的分析开始，首先我们需要一些假设和前提，而这些假设不应影响结论： 假设 1：手动测试用例 / 自动化测试脚本的粒度是一个用例 / 脚本均足以且仅能发现一个质量缺陷。 假设 2：自动化测试不发现质量缺陷，只能发现日志错误，在人工检查日志错误时，需经过分析日志（约等同于 1 遍手动测试），人工再现场景以确认产品问题（等同于 1 遍手动测试）来定位和暴露真实质量缺陷。 假设 3：无论是否采用了自动化手段，在当前质量缺陷被修复后，仍然需要花费一遍手动执行测试用例的同等执行时间来验证此修复。 假设 4：自动化过的脚本仅执行所花费的时间和投入可以忽略。 如果我们将 100 个测试用例来测试一个隐藏了 20 个质量缺陷的产品，而且每个测试用例的执行时间约为 a 小时。 当这 100 个测试用例完全手动测试时，我们最少的测试时间是，80a，可以完全通过的测试用例的执行时间，加上 20 个需要平均 3a 小时的处理时间才能完全暴露质量问题（参考假设 2