敏捷测试的最佳实践（4）——自动化测试的 ROI
相关文章：
测试中为什么要规划好自动化测试
狂热的追逐自动化的比率提高，自动化框架的复杂度提升，工具，脚本的开发量增大似乎已经让很多人感到不适。有人开始质疑自动化测试的投入产出比，和自动化的成效，而无论在敏捷开发还是传统开发论坛中我们听到更多的问题仍集中于如何自动化测试，采用什么行之有效的工具和方法才是最好的，似乎重点仍然是工具和技术。因为很少人认真考虑投入自动化开发占整个项目测试投入的比例的科学性，而更少有人曾经清晰的分析何时，花费多少人力的自动化开发与维护才是颇为合理的规划，而仍然用经验和教训在维持似是而非的自动化测试体系。
对自动化工具的研究（基于 2008 年对 IBM 中国软件开发实验室自动化测试工具的研究），我们不经感到自动化工具的本身的效率固然非常重要，以致一度让我们相信自动化测试工具的选择是自动化测试成功的关键。而渐入敏捷开发、敏捷测试的围城后，我们渐渐认识到，人的活动力，工作效率的提升更能影响到工作绩效。仅仅拥有最好的自动化工具还远不能实现最有效的自动化测试。而我们既然相信一支能自律，自我管理的行为模式下的敏捷团队能够更大化的提升敏捷项目的进入市场的速度，增加产品价值，降低投入。那么，为什么我们不从自动化测试者，和手动测试者的投入产出中，经验中分析自动化测试的成功关键呢。于是，我们开始探寻到底自动化测试应该越大程度越好呢，还是应该科学的规划才更有价值，而又如何规划才是合理的呢。
经过在多个自动化测试的项目环境中调研，我们认为成功的自动化测试很大程度决定于合理的投入规划。相反不计成本的规划，或者疏于成本规划的自动化测试只能带来负担而不是效率的提高，尽管有些人为了满足对其自动化技术的一味崇尚而调整了各种报告结果，并且已经满足了某些人对自动化投入的愚昧狂热后，他们仍然欢欣于一个价值公式，一些精确的指导来调整或者提高他们自动化测试收益。那么如何做好自动化测试的成本规划呢？
运用 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，3）才能最终完成测试。因此，
小时
而经过这次测试，我们可以得到了 20 个质量点的提升
。
为达到同样的测试效果呢，我们仍然对同样的产品采用了自动化测试手段。那么基于前提假设，最优的自动化测试比例，也就是 80 个可以完全通过的测试用例我们都生成了自动化测试脚本，那么本次测试的
。
其中，x 为开发和维护 80 个自动化测试脚本的代价。
而同样的
。
根据公式 4 得到的结论，我们的最优自动化规划将满足以下不等式：
结论：
如果自动化后的测试脚本在项目中只运行一遍，那么自动化脚本本身开发的成本不应大于手动执行一遍对应测试用例的执行时间。即完全没必要自动化。
多少自动化投入才是合理的
真实的场景比以上案例要复杂，首先自动化测试脚本可能执行多次，产品中的质量缺陷无法确切得知，为了进一步得到更合理的场景下自动化测试规划的建设性分析，我们需要声明几个变量：
声明 1：d% 是平均出错率，也就是说一个产品的代码中如果有 d% 的出错率，对产品质量缺陷的修复仍然将带来 d% 的新质量缺陷。
声明 2：质量达标 95% 的测试通过率后，产品可以发布。
声明 3：n ，迭代次数，自动化脚本将被执行 n 次，或者叫做迭代测试 n 次（n>=1）。
声明 4：TotalEf，即完成一次完整的手动测试，测试用例完全通过的执行成本。
声明 5：x ，自动化的开发和维护成本的上限，
，也就是说实际的脚本开发维护成本应该大大低于 x，这样的自动化测试 ROI 才是合理的
引用公式 4 推导出来的结果：
即
推得：
因此推导出：
公式 5：
结论：
d% 的值越大，质量缺陷越多，我们依赖于手动测试的可靠性更大。
因为新测试用例开发出来很快投入了 FVT，之后测试员才投入开发自动化测试，因此，此阶段我们必然依赖于手动测试。只有在以后的回归测试阶段，两种测试手段，即自动化测试和回归测试才具备可比性。而真正的自动化收益也来自于测试的回归测试阶段。同时，以上公式表明，TotalEf 越大，我们越能够倚重于自动化测试。回归测试的用例重复性使用频率越高，自动化的投入必要性越大。下面就以回归测试作为背景来分析自动化测试的合理规划。
我们大胆假设，如果一个团队回归重复测试相同用例的出发点为了确保先前成功的功能不会失败那么。成熟的测试团队应该不断根据现有的产品质量缺陷报告对回归测试的覆盖范围和计划做出正确估计和调整。在开发团队修复代码的过程中依据 d% 错误率的平均工作有效性来估计，我们对每个迭代的质量缺陷数量将是上一迭代数量的 d%。那么 n 次迭代将总共产生的质量缺陷数量为：
公式 6：
结论：
回归测试产生的质量缺陷是产品出错率的等比数列之和。
回归测试的自动化测试规划方式
同理，科学规划了的回归测试的覆盖范围也是将是等比递减的，例如第一次迭代所花费的成本为：
；
第二次迭代所花费成本为：
；
第三次迭代花费的成本为：
；
以此继续推导，可以得到第 n 次迭代总共花费手动测试成本为：
公式 7：
而引入自动化测试，第一次迭代所花费自动化测试执行分析成本为
，第二次迭代所花费成本为
；
第三次迭代花费的成本为
所以 n 次迭代后总花费自动化测试执行分析成本为：
公式 8：
因此，根据公式 7 和公式 8 以及声明 5，我们得到自动化开发和维护的成本上限 x：
公式 9：
图示为公式 9 所呈现出来的各单元之间的关系：
图 1. 自动化测试脚本开发与维护成本规划图例 1
结论：
当考虑自动化测试成本收益时，我们应该先考虑那些可能迭代次数更多，运行次数更多的测试用例进行自动化脚本开发。而对于产品的质量缺陷，当质量缺陷越少，质量越好的产品，自动化开发成本收益也会比较大。反之，则致使自动化开发并不合算。例如，当当前测试用例很可能最多就执行 2 次，单产品中的遗留问题可能使得 60% 测试用例不能通过，这时考虑自动化测试简直没有必要。
而且，即使产品中质量缺陷很少，但是测试用例可能被使用的次数非常少，少于 3 次，那么自动化测试的开发成本也只允许极少量投入，或许并不可行。
调换 n 和 d 的关系，我们再来看看 x 的曲线：
图 2. 自动化测试脚本开发与维护成本规划图例 2
结论：
继续对自动化测试脚本开发与维护成本规划的分析，从图表 2，我们还能得到另一个信息，那就是当迭代次数，也就是测试重复性基本与可允许投入的自动化开发成本成线性关系。也就是说当测试需要迭代的次数是 n=k 时，允许投入的自动化开发、维护成本可以是当 n=2 时候的 k 倍。
基于 Scrum 的敏捷测试应该如何考虑自动化测试
敏捷测试仍然需要自动化测试
自动化测试规划的复杂性已窥见一斑，敏捷测试、Scrum 开发模式下的敏捷测试隐约比我们分析过的情形要更加扑朔迷离。因为总所周知，Scrum 模式下的开发、测试遵循了独特的规则。
首先，迭代模式使得代码逐步累加起来，每个迭代周期又是如此短暂，似乎没有来验证最后几个质量缺陷，突然需求变化了。一半以上的测试用例和测试脚本不再有用。
每个迭代的新功能、新需求的测试和研究紧迫感并不容得我们考虑诸如测试代码复用，或者来计算多少基于上一迭代的测试用例和脚本需要再度测试。
简单的说，就是测试节奏一下子加快了，在这样的压力下，更加对迭代价值的追逐，以致使得每个开发、测试、研究的活动一定能够服务于当前迭代即将诞生的代码和产品。更多的人开始谨慎选择自动化策略，缩减自动化投入。也因而，更多的问题指向敏捷开发专家，我们是不是需要自动化测试，何时开始自动化测试，多少投入自动化测试工具和脚本的开发是值得的。
首先，关于要不要自动化测试，我们的回答是肯定的。迭代模式使得代码量逐步累加的同时，靠后的迭代我们所面临的整合测试压力、测试任务就越大。而且敏捷测试需要测试人员能够随时启动自动化的回归测试对马上发布的迭代代码进行快速验证。
接着我们借鉴传统测试的中自动化测试规划的细则，基于敏捷迭代的特点对自动化测试规划做进一步分析。
敏捷测试中的自动化测试与其在传统测试中的角度有什么不同
应该说迭代次数（n），测试覆盖次数越多，自动化测试带来的好处就应该越多，而产品开发中出错率（d%）越小，自动化测试效果越好。这是我们在之前章节分析出来的结论。
但是，自动化脚本也许因为迭代目标和对象的差异性需要大幅修改。而重新构造和改变测试脚本带来的代价和成本也非常大。
特别在敏捷测试中，产品变化之大给自动化测试带来难度也陡然增加。因此，敏捷测试中，我们要以更精细的单位来计算自动化测试的投入产出比。即，决策敏捷自动化测试的投入产出应该基于每个迭代自身的收益，而不是整个产品开发周期。
在每个迭代的 2 周到 4 周的时间内，我们将经历从测试策略的选择，测试脚本和用例的撰写到即刻的测试执行，和短暂的回归测试。我们不能保证回归测试完全可以自动化，是因为我们可能没有足够的时间投入自动化开发，而正是因为测试脚本和用例的生命短暂，我们开发的成本也如期望的一样缩减了。
因为敏捷的模式在不同项目中的实践存在较大的差异，在进一步分析敏捷测试下对自动化测试规划之前，我将描述一个笔者认为理想的敏捷测试模型。
在这个模型里，我们的迭代周期为 4 周，团队的总共有 7 名成员，其中只有 1 名是测试人员。在这四周的活动中，我们将讨论图表 3 所示的敏捷测试的自动化测试规划方案。
进入迭代的第一周的工作测试人员集中确定测试策略，制定可行的测试计划和划定充分的测试范围。
第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。
第三周的第三天，基于约定，第一个可以执行的产品代码已经能够发布了（这个约定的履行需要整个团队的配合）我们便可开始功能测试了。直到第三周周末，一部分功能测试已经完成，大部分关键的新功能得到验证。
第四周我们将要结束迭代的测试，在这一周中，不但要完成新功能和新非功能需求的测试，也要顾及持续性开发带来的老代码的质量风险。也就是说产品的回归测试将在这个周内开始并结束。同样，基于约定，我们将迭代最后的两天或者更少时间作为回归测试阶段。正如基于 Scrum 的拥有严格的周期制度一样，一旦进入了回归测试阶段，所有人都要配合、遵守例如 Code Freeze 的时间等约定。
图 3. 敏捷测试 Work Flow 最佳实践
Scrum 的自动化测试的 ROI 指标
我们对自动化的规划也将融入这个 4 周的计划。同样，为了更好分析，我们需要几个假设和声明：
声明 1：n，进入回归测试的后我们仍然需要对测试用例反复测试的次数。
声明 2：d%，这段时间内测试的平均出错率仍然是 d%。
声明 3：TotalEf, 即执行一次回归测试所花费的执行成本。
假设：
假设 1：产品迭代周期为 4 周。
假设 2：在此次迭代中，第一个可测的产品发布于第三周的第三天。
假设 3：回归测试于第四周的倒数第 1 或者第 2 天进入，在此之前测试人员将要完成新功能测试。
假设 4：一个迭代达到退出的标准是 (d%)n<5%，也就是说 95% 的测试都通过了，这样的迭代才能是的客户满意。
因此，迭代次数 n 就必须满足
公式 10：
而从图表 3 所示的的最佳实践中，我们假设测试人员将用迭代的最后 1 到 2 个工作日来完成回归测试测试。
因此，如果TotalEf 是执行一次回归测试用例所花费的代价的话，那么
公式 11：
（单位人天）
根据公式 10 和公式 11，我们可以确定的得出：
公式 12：
将公式 12 代入公式 9 得到公式 13（不是十分严谨，不过不影响分析）
公式 13：
（单位人天）
绘制其曲线是，n 作为横坐标取值为 1:1:10，x 为自动化工具、脚本开发维护的最大投入。
图 4. 迭代中自动化测试脚本开发与维护成本规划
基于图示，我们可以得到以下基于敏捷测试的自动化测试规划的规律：
结论：
一般产品的测试错误率高于 20%，也就说为了达到质量好到足够能够退出，回归测试至少需要 3 次，在这种情况下我们其允许投入到自动化开发的成本为不多于 3 人天。
而当产品质量非常好，错误率低于 20%，因为不需要经过多次测试以达到退出标准，我们也就可以省去自动化测试的步骤了。
最后关于本文的经验之谈，当我们从事着敏捷测试活动时，在四周为周期的迭代测试中，测试人员在第二周的开始进入自动化脚本开发。开发活动不易超过 3 天。
总结
不要指望自动化投入越多对产品和质量越好，也不要指望自动化测试可以取代手动测试。但是，自动化测试是需要测试人员合理、科学的使用来提高测试成效的途径之一。ROI 的自动化规划将是非常适合敏捷测试、传统测试的最佳原则。
而成功的自动化测试除了拥有良好的规划外，自动化成本越低，开发工具越简易，自动化维护和管理复杂度越小，自动化测试也越容易驾驭。因此，在同等自动化规划下，测试人员应当采用更成熟的自动化测试工具，积极参与自动化测试经验交流以不断提高测试自动化开发的生产率，以有限的投入获得更大测试收益。
