从 ROI 出发探究自动化测试

最近在极客时间上学习自动化测试课程，看到作者从投入回报率比 ROI（Return On Investment）的角度去讨论自动化测试的价值以及定位最优自动化实施截面。总结下来，我们在实践中也能通过 ROI 去判断当前项目是否适合自动化测试、根据 ROI 制定自动化测试的策略、优化自动化测试，提高效益等。

场景：产品要上线了，QA 人手紧，能不能搞一下测试自动化，减少点人手?

自动化测试项目的最终交付价值是它产生的效益，也就是 ROI。一个成功的自动化测试项目必然是获得了高 ROI 的收益。由此我们可以从 ROI 角度来分析是否需要安排自动化。

一个自动化测试案例 ROI=（单次运行时间*运行次数）/（开发时间+维护成本）

根据公式可以推出结论：

1. ROI 大于 1 就是赚了，小于 1 就是亏了。那么，给定一个测试案例，要不要对它做自动化，判断的依据是（自动化测试）预期 ROI 至少要大于 1。

2. 自动化测试是一个长收益模式。在理想情况下，是一次性投入（投入为开发成本），之后每运行一次，就会增加一份产出。所以，时间越长，次数越多，收到的回报就会越大。

3. 关于开发成本（包括开发成本和维护成本），类似估算软件开发工作量，代码行法、功能点法，我们也可以引入到估算开发工作量里，比较好掌握。但维护成本就有点模糊了，这里包含了多种可变因素，是自动化测试项目风险的主要来源。

那么当我们遇到场景“产品要上线了，QA 人手紧，能不能搞一下测试自动化，减少点人手?”这个时候就不能盲目的上自动化测试，ROI 是一个自动化测试项目的隐式命脉。首先，我们需要考虑此时时间成本，临近上线时间节点和投入自动化开发时间是否符合，如果不符合抛开 ROI 不谈也是不能搞自动化的。其次，此次上线的功能是否稳定，自动化测试多用来做回归测试，如果产品不稳定，自动化测试执行起来也是相当痛苦，相应的也会增加大量的维护成本。最后，对比自动化测试与手工测试需要消耗的人力、时间，ROI 能否大于 1，自动化测试能否产生效益。

自动化测试的测试策略如何做？

在实际工作中，自动化测试一旦做起来，带来的变化是：测试执行时间变快，软件发布周期缩短，又反过来增加回归次数 n，自动化测试的收益也在增加。想要搞出成功的自动化测试，测试策略也必不可少。

在测试设计领域，经常提到的方法是分层。具体就是给定一个系统，结构上划分三个层级，单元在最小圈；服务包含多个单元，在中圈；而系统又包含多个服务，是外部的最大圈。结构图如下：

相应地，我们的测试结构是在代码层做单元测试，服务层做接口测试，系统层做 UI 功能测试。同时，单元测试案例的数目应该多于接口测试案例数目，接口测试案例数目应该多于 UI 测试自动化测试案例数目。但是为什么这么分配？利用 ROI 思维，分析测试金字塔规律，可以得出 3 种类型自动化测试的 ROI 排序，如下表：

对照测试金字塔不难发现，实际上三类自动化测试的 ROI 是自底向上由高到低的。

所以在一个自动化测试项目中优先投入精力做 ROI 最高的单元测试，再做 ROI 中的接口测试，最后完成 UI 测试。

单元测试、接口测试、UI 测试，这三个测试截面测的是一个请求在不同层面上的形态，那么每一个截面都可以测试全部的案例，也可以测试部分的案例。就像 3 个人负责 1 个项目一样，如果没有经过事先的协调和安排，3 个人可能做了重复的事情，造成浪费，也可能存在一件事 3 个人都没干，形成测试盲区。

在资源有限的条件下，我们需要在整体上看待分层测试的最优 ROI。整合测试需求和测试类型组合，得出各个需求的自动化实现截面。

UI 测试关注功能场景测试，易用性测试和可执行性测试；而接口测试关注不同数据的循环，接口的性能和错误恢复能力；单元测试关注算法的正确性和性能。

如何优化自动化测试，提高效益？

一个案例转化成自动化测试后，我们的目标是它的投资回报率越高越好。从代码的角度，提高代码的复用率，增加运行次数 n 就可以在一定程度上提高 ROI，增加自动化测试效益。

例如一段登录脚本：

这段脚本实现的功能很简单，启动 chrome 浏览器，打开一个登录链接，在页面上输入用户名 test@example.com，密码 123456，点击“登录”按钮，完成登录。相应的脚本每运行一次，对应的 n 就为 1。

正常来说，我们测试不可能只是测试一个浏览器，会考虑支持市面上主流浏览器，多组测试数据，不同环境下运行以及业务要求可能需要支持多种语言等。相应的需要修改代码，减少 Hard code 来提高代码的复用率，增加 ROI。修改后代码如下：

总的来说，上面的例子在提高代码 ROI 方面给到了四种思路，一份代码，多浏览器运行，多数据运行，多环境运行，多语言运行，同时提高 ROI 的过程，也是消除代码 Hard code，优化代码结构的过程。

也许之前我对自动化测试的认知就是利用工具、代码来减少手工测试，节约人力。却没有真正思考过什么样的项目更适合自动化测试，如何做自动化？读到这里，不知道屏幕前的大家是否已经有了答案，欢迎大家一起交流学习～