导语
自动化测试是一种测试手段，自动化测试ROI的高低，引领我们优先投入精力做ROI最高的单元测试，再做ROI中的接口测试，最后完成UI测试。
寻找最优 ROI 自动化测试策略
实际落地会出现的问题：一批人做 UI 测试自动化，另外一批人去做接口测试，然后开发人员做单元测试。三路人马忙得不亦乐乎，都说自己贡献大，等到 bug 发生了泄漏到生产环境，又开始甩锅。
很明显，这是一个内卷的场景，让我们结合例子具体看看内卷发生在哪里？
以一个web登录功能为例：
- UI测试层：编写Selenium UI 自动化测试脚本；
- 接口测试层：编写API requests自动化测试脚本；
- 单元测试层：编写Login 函数的单元测试脚本。
可以看到，一个请求，从浏览器页面发起，进入 API 网关，再传递到服务里的 Login 函数，经过了 UI 测试、API 测试和单元测试三个测试截面。
三个测试截面测的是一个请求在不同层面上的形态，那么每一个截面都可以测试全部的案例，也可以测试部分的案例。就像 3 个人负责 1 个项目一样，如果没有经过事先的协调和安排，3 个人可能做了重复的事情，造成浪费，也可能存在一件事 3 个人都没干，形成测试盲区。
需求 / 策略矩阵
咱们先看看测试需求是什么，用 FURPS 模型来理一下需求。FURPS 是用 5 个维度来描述一个软件的功能需求，FURPS 这个单词对应着每个需求的英文首字母：
- F=Function 功能
- U=Usability 易用性
- R=Reliability 可靠性
- P=Performance 性能
- S=Supportability
可支持性把测试需求和测试类型组合在一起，就整合了后面这个矩阵表格：
结合表格，可以看到 UI 测试、接口测试和单元测试每个截面的测试能力。
3KU 整体策略
好，有了需求 / 策略矩阵后，结合测试分层ROI金字塔，我们可以得出整体最优 ROI 策略。什么是整体最优 ROI 呢？
有 3 个 Key（关键因素）：
- Useful: 每个测试需求都是有效的；
- Ultimate: 每个测试需求的验证都在优先寻找自动化 ROI 高的层面去实现，如果不可行，按照 ROI 高到低回退，直到 UI 层；
- Unique: 每个层面上验证的测试需求都和别的层面都不是重复的。
这样分配的工作，既不重复，又没遗漏，还遵循了 ROI 的原则。简称3KU 原则。
3KU 策略该怎么执行呢? 按照 3KU 策略，我们把表格里的测试需求，对照下面这三个问题，按顺序检查一遍：
- 能在单元测试验证么？
- 能在接口测试验证么？
- 能在 UI 测试验证么？
这样检查以后，就能得出各个需求的自动化实现截面了。UI 测试关注功能场景测试，易用性测试和可执行性测试；而接口测试关注不同数据的循环，接口的性能和错误恢复能力；单元测试关注算法的正确性和性能。
在 3KU 测试金字塔下，每一个测试需求都会选择最大的 ROI 测试截面，通过这样的安排，实现了整体最优 ROI 的目标。
微服务架构下 ROI 自动化测试策略
微服务架构诞生后，一个系统拆分成多个独立开发和运行的服务，这个服务不管大小，业界都管它叫微服务。它们也有一套服务治理的技术规范，用来保证部署和运行的可靠性和扩展性。微服务集群的开发方式确实方便了用户需求快速实现和交付，但今天我们的关注点是，从测试角度看，微服务相比单体应用有什么不一样？有没有新的测试点？
单体应用的 FoodCome 是这样的：
随着业务规模的扩大，开发人手增加，FoodCome 被拆分成 5 个微服务，具体如下：
- 订单服务：处理用户下的订单；
- 物流服务：Foodcome 内部的物流管理，
- 与外部物流对接；
- 餐馆服务：管理餐馆的信息，参与订单的工作流；
- 账户服务：管理订单里的顾客信息，和外部的支付系统对接。
- 通知服务：产生消息通知用户，和外部的邮件系统对接。
由此组成的 FoodCome 的微服务架构如下图：
在这个架构下，原先单体应用的对外接口保持不变，但是单体应用内部被 5 个独立的微服务取代。用户的订单请求先通过 API 网关到达订单服务，完成支付后，餐馆接单，再通过物流系统交付订单。
每个微服务实现自治，独立开发和发布部署，加快发布速度。而且增加新功能也很方便，比如登录鉴权，在这个图中再增加一个认证服务就可以，这是给客户带来的好处。
现在的问题是，这给测试带来哪些变化呢？分拆后，FoodCome 系统变成了微服务集群，就像一部巨大机器，由多个零件组成，互相咬合，一起工作。作为测试人员，不但要验证每个零件是合格的，还要有办法预测它们组装起来的机器也能正常工作。
这里的测试难点是，微服务的数量增加，服务间的交互量也会剧增，相比单体系统，集成测试在微服务集群架构下更加关键。
所以在微服务架构下 ROI 自动化测试策略，调整为如图所示：
小结
我们从 ROI 角度分析了一下分层测试的原理和在实践中的应用。分层理论上的分层测试的特性，必然会造成重叠和错失。我们遵循回归到效益的原则，思考怎么用最少的资源干最多的事，能达到这个效果，就是好的实践。因此，我们进行分层但协调实现整体最优 ROI 的解决方案，3KU 测试矩阵和 3KU 测试金字塔。
沿着这个思路，各层做好自己具有优势能力的测试需求，比起全部需求系于端到端的测试上，更有效率和效益，分层是追求整体 ROI 的结果。
