图片由 Anastase Maragos 在 Unsplash 上拍摄
（TL; DR-在这里计算您的投资回报率！）
在敏捷软件开发时代，测试自动化已经从 “精打细算” 变成了快速交付高质量软件的关键组成部分。

商业决策者通常同意测试自动化是一个好主意，但可能会犹豫不决地投入适当的资源。有关构建和维护测试自动化框架的成本的不确定性，尤其是在预算和截止日期很紧的情况下，可能导致对其交付多少价值的疑问。

对于许多利益相关者而言，对每个 sprint 越来越多的手动回归测试最终如何最终束缚团队交付能力的定性解释足以证明对测试自动化进行投资的合理性。对于其他人，尤其是技术组织之外的人，量化证明可能会有助于接受。

在本文中，我将向您和您的团队演示一种将测试自动化的价值传达给精打细算的决策者的方法。

利益相关者将理解，尽管存在前期成本和持续成本，但长期替换人工回归测试所获得的价值将使该投资值得。

测试自动化的价值

测试自动化的大部分价值源于多次运行自动化测试¹。

如果测试仅运行几次，则手动运行所有测试可能会更快，更具成本效益，而不是支付购买测试自动化工具或从头开始并编写测试框架来支付前期费用。

但是，由于针对新版本反复进行自动化测试，因此达到了收支平衡点。从现在开始，所有未来运行都将代表正的 ROI 不断提高，并且通常会增加测试能力和覆盖范围（也就是说，以前无法执行测试的能力可能没有时间手动执行）。

在下面的示例中，经过 25 次测试自动化运行后达到了收支平衡，而到第 50 次运行时，其投资回报率约为 1.75，这意味着测试自动化所提供的价值比投入的投资高出 75％。

计算投资回报率

（如果您不喜欢数学，请随时跳到 “测试自动化 ROI 案例” 部分）

在这里，ROI 的计算方式是将手动回归测试替换为自动测试所节省的成本，再除以测试自动化的投资成本：

投资回报率=储蓄÷投资

由于 ROI 是一个无单位的数字，因此节省的资金和投资的金额以美元或时间为单位实际上并不重要。为了便于计算，将使用分钟，因为我们的大多数输入都是时间形式。

在我们的估算中包括货币值的一种方法是将美元转换为分钟，方法是将测试自动化工作人员的小时计费费率²除以然后将小时转换为分钟。

以类似的方式，可以通过从节省中减去投资成本（均以分钟为单位），将最终的分钟数转换为小时数，然后乘以小时计费费率³，来估算测试自动化成本的节省额。

节约成本

节省是在一段时间内手动运行一组测试与自动运行相同测试的成本之间的差额。

节省=（运行一个手动测试用例的时间⁴-运行一个自动化测试用例的时间）X 测试次数 X 运行次数

• 测试次数是该时间段内的平均值。如果测试套件从零个测试开始，到年底线性增长到 200 个，那么平均将是 100 个测试。

• 自动化测试运行得越快，他们越早可以达到正的 ROI。这样就可以在可能的情况下使用集成测试³代替端到端（e2e）UI 测试，因为它们通常运行速度快 5 或 10 倍，并且往往更可靠。

测试自动化投资

投资是测试自动化的固定成本和持续成本的总和，包括建立和配置测试自动化工具或框架所花费的时间，以及编码或维护自动化测试所花费的时间。

投资=构建框架的时间 +（编写一个自动化测试的时间 * 测试数量）+ 维护成本

• 如果存在购买或许可成本，则可以在将美元转换为分钟后，除以如上所述的帐单汇率，将其添加到此处。

  维护成本是调查和修复失败的测试的成本（误报和实际失败）。由于需要进行调查以确定功能或测试是否有故障，因此易碎的测试和开发错误同样会导致维护成本增加。测试失败的频率越高，ROI 收支平衡所需的时间就越长。

维护成本=维护时间⁴一个失败的测试用例每次运行中失败的测试用例的百分比测试用例的数量 * 运行的数量

• 我们假设所有测试的平均失败百分比

测试自动化 ROI 案例

上面的示例基于以下情形：

在这种情况下，运行 25 次后达到收支平衡，运行 50 次后的投资回报率约为 1.75。

让我们看一下其他情况，看看 ROI 和收支平衡时间如何受到影响：

案例 1：测试自动化仅运行 10 次

运行 10 次后，项目可能结束了，或者测试自动化框架被放弃了。无论哪种情况，都只能收回大约 45％（ROI = .45）的投资，而进行手动回归测试将更具成本效益。这里的假设是平均 150 个测试，但是如果套件仍在增加测试数量，则 ROI 可能会更低。

案例 2：构建测试框架所需的时间是原来的两倍

我们又有了原始方案，但是这次不是 2 星期，而是 4 星期使测试框架准备好开始对测试进行编码。乍看之下，多花两周的时间来支付某人的费用似乎很昂贵，但是在运行测试自动化框架 9 次之后（而不是 25 次，而不是 25 次），就弥补了赤字，并且 ROI 达到了收支平衡。运行 50 次后，ROI 约为 1.4。

案例 3：测试需要两倍的时间才能运行

在这种情况下，每个自动测试需要一分钟的时间，而不是 30 秒。尽管执行时间更长，但在 ROI 达到收支平衡之前，仅需要执行 4 次额外的运行（从 29 次而不是 25 次），而在运行 50 次之后，ROI 接近 1.6。

案例 4：测试失败的频率是两倍

测试自动化 ROI 中的另一个主要因素是测试的鲁棒性。如果测试失败，无论是实际失败还是误报，都需要时间来定位，诊断和纠正问题。如果大量测试经常间歇性地失败（由于计时问题等），则可能对 ROI 产生重大影响。在此模型中，需要额外运行 6 次才能达到收支平衡（31 次而不是 25 次），运行 50 次后的 ROI 为 1.35。

由于该模型的一个局限性在于，它不会在每次无法确认故障是真实的时都将花费在重新运行测试自动化上的时间考虑在内，因此实际的投资回报率可能会略低于上述水平。

案例 5：架构和测试花费的时间是原来的两倍，失败的频率是原来的两倍

在这种情况下，我们会遇到最坏的情况，其中情况 2-4 中的每个问题都会影响项目。我们的第一个倾向可能是将每种情况下的延迟加起来，以估计我们的收支平衡点。将这些加在一起，我们将获得 19 个额外的运行次数，因此可能需要 44 个运行才能达到收支平衡。

不幸的是，各种因素的融合对 ROI 的影响要大于对每种因素的总和，而我们在第 50 次试运行中勉强获得了正的 ROI。

案例 6：所有测试都已替换为服务级别/集成测试

根据项目类型，可能有可能将某些手动测试替换为自动服务或集成测试。在这种情况下，这些测试将不再通过 UI 运行，通常会产生更快的运行时间，更强大的测试和更少的维护时间。在这种情况下，我们的收支平衡点将左移至 19 个运行周期，而 50 个运行周期后的投资回报率则高达 2.4！

对于您的应用程序，可能无法用服务或集成测试替换所有手动测试，但是我们认为，按照 “测试自动化金字塔” 的一种良好做法是避免完全依赖 E2E UI 测试，并尽可能强调服务和集成测试尽可能。

该模型的局限性

我们的 ROI 模型特意简单地将输入的数量保持在较低水平，并使其尽可能普遍地适用。结果，还有其他一些因素可能会影响 ROI，但并未纳入计算中。

这些包括：

• 单元测试：单元测试是提高代码质量的宝贵开发活动。从本质上讲，它们的定义过于狭窄，无法替代手动测试，但是它们的值在模型中隐含，因为调查失败的可能性可能更低。它们未明确包含在 ROI 计算中。
• 测试覆盖率的提高：能够快速或在非工作时间运行自动化测试的能力可以带来更大的测试覆盖率或容量。可以运行没有足够时间手动运行的测试，或者可以在运行自动测试时运行其他手动测试。诸如此类的收益未计入 ROI 指标。
• 测试重新运行成本：当必须针对同一版本重复测试不稳定的测试时，这些重新运行不计入 ROI。
• 其他成本：未计入的其他基础设施和运营成本可以转换为分钟数，并添加到投资总额中。

• 将 ROI 转换为美元：如上所示，这是将 ROI 转换为美元的简单计算。这对于与业务决策者进行交流很有用，但由于模型非常简单，因此其准确性可能会受到限制。

  为了提高准确性，可以定制此模型以考虑与您的组织有关的这些或其他成本。

结论

测试自动化需要前期和持续的投资，使用后才能获得回报，通过将服务水平或集成测试作为整体测试自动化策略的一部分，可以取得显着收益。

随着产品的增长而依赖于手动回归测试，不仅不能实现这些收益，而且会使产品乃至整个组织面临风险。测试和错误修复的成本会随着每次迭代的增长而增加，最终会影响产品成本，质量和上市时间。

使用此 ROI 模型，业务决策者可以快速轻松地了解测试自动化随时间提供的价值，而技术团队成员则可以洞悉测试速度，健壮性和可维护性对其测试框架价值的影响。两者都可以使用它来推动正确的决策，从而在您的组织中实现高价值的测试自动化。

笔记：

[1] 由于在两次运行之间没有发现新的回归错误，因此针对同一内部版本反复运行测试自动化不会带来价值。如果由于测试的脆弱性而不得不重复运行测试，这会增加投资成本并降低总体 ROI。
[2] 如果有多个具有不同账单利率的人正在执行自动化测试，则可以根据他们的努力来使用账单利率的加权平均值。
[3] 可以使用此方法来评估可以有效替代手动回归测试的任何类型的自动化测试。
[4] 这里使用平均时间。一种获得平均测试时间的简单方法是使用三角三点估计，其中确定了简单，典型和复杂的测试，并对每个测试的时间进行了估计，相加并除以 3。

感谢凯尔西戴维斯（Kelsey Davis）。

原文链接：
https://medium.com/slalom-build/what-is-the-roi-of-my-test-automation-10ae7bf0d9ed