02｜3KU法则：如何找出最优自动化实施截面？
测试 ROI 金字塔
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何通过3KU法则找出最优自动化实施截面。作者首先提到了测试ROI金字塔的概念，即单元测试在底部，接口测试在中部，UI测试在顶部。根据迈克·科恩的金字塔模型，作者分析了各层自动化测试的ROI，并指出了按照ROI高到低的顺序进行自动化测试的重要性。接着，文章讨论了分层测试中可能存在的“内卷”问题，以及如何在资源有限的情况下整体上看待分层测试的最优ROI。最后，作者提出了需求/策略矩阵，结合测试需求和测试类型，整合了UI测试、接口测试和单元测试每个截面的测试能力。通过分析测试金字塔的ROI规律和需求/策略矩阵，为读者提供了寻找最优ROI策略的思路和方法。文章还提出了3KU策略，即确保每个测试需求有效、优先寻找自动化ROI高的验证层面、确保各层验证的测试需求不重复。最后，通过3KU测试金字塔，实现了整体最优ROI的目标。整体而言，本文通过分析测试金字塔的ROI规律和需求/策略矩阵，为读者提供了寻找最优ROI策略的思路和方法。
《自动化测试高手课》，新⼈⾸单¥59
全部留言(22)
- 最新
- 精选
- lisa微服务本身基于RPC调用，服务拆分的力度比较小，所有从ROI的模型来讲，微服务的代码每次commit以及merge/pull request会进行API测试，这样API测试的运行次数n会加大，分子变大。而相对于单元测试来讲，API测试的建设成本d和维护成本m相对于单元测试会变小很多，导致分母变小。所以在微服务架构下，投资API测试的ROI明显更高，所以就会出现棱形更由于金字塔的情况出现。 但是说实话，我觉得说到底还是模块拆分力度变小带来的变化，拆分的越小，单元测试和API测试的界限就会变得模糊。实际上API测试的运行的成本还是比较高的，他需要初始化数据以及初始化泳道环境，并且稳定性远远低于单元测试，带来的维护成本其实还挺高的。所以我个人还是比较赞成金字塔模型，即便是在微服务的架构下。
作者回复: 很有思想！也很有经验！
2022-03-2615 - lisa最近重新思考了一下这个问题，其实我们没有必要去选择是采用金字塔模型还是菱形，而是更多的是基于测试需求去进行ROI分析，放在哪一层ROI最高就选择在哪一层（可能不同的产品形态会不一样）,不用太关注最后会形成什么模型。考虑到目前越往底层的运行成本最低，运行次数最多且最稳定，也就是D和M的时间比较少，大量的测试点会下沉，但是我们同时也要考虑到自动化测试是面向风险，而不是面向代码覆盖率。所以基于风险来看，哪些测试点应该要被设计也存在一个设计评估的过程。最后测试基础设施的完善性以及团队的实际情况也是其中一个重要的考虑因素。总之，最终是一个什么模型是测试点落地的结果，而不是前期的决策依据。
作者回复: 赞👍👍👍！
2022-05-3027 
D_w一点浅见： 问题1：在微服务架构下，测试层级会扩充，新增契约测试，组件测试，端到端的测试等等，并且在实际测试任务中一般开发负责的单元测试占比不高，最终成纺锤形。 问题2：如果团队成员能力都比较强，我偏向全栈，如果能力不均衡还是得考虑精细分工。我觉得全栈的测试效果能更好作者回复: 我在甲骨文和其他公司经历过几轮调整，每一轮过后，专职系统测试人员就会减少一部分，这个背后的逻辑就是测试下沉，单元测试和API测试做强，有了这个基础后，端到端测试做轻巧。被变化，不如准备好，拥抱变化！
2022-03-236
太匆匆我们很多人都喜欢引用金字塔模型，但是似乎没有多少人认真思考过金字塔的模型是怎么来的，有无理论依据。这点得向老师学习，拒绝拿来主义作者回复: 你有这个问号，已经很有悟性了！
2022-03-235- lisa我希望是最重视全栈的模式，因为对技术的理解成本远远小于对业务的理解成本，也就是一个人把它培训成全栈可能花上一个月就行，但是让这个人充分理解业务以及业务的架构是一件比较长期的事情
作者回复: 你能从成本的角度看待问题了，大大的👍！我是用了好几年才悟到这些！
2022-03-2623 
萧瑟我是这么理解的：在微服务架构的系统中，一个请求进入系统，可能会经过多个服务获取数据，最后整合输出。也就是说一个 UI 测试 会对应多个接口测试，而一个接口测试可能会对应多个不同服务之间的接口调用，单元测试更注重的是单个服务的逻辑、算法。因此接口测试因为运行次数 N 而变得比单元测试的 ROI 更高，测试金字塔也就变成了中间凸出两头小的棒槌形状。作者回复: 很好的思考！
2022-05-042
一默老师请教一下，单元测试无法手动测试，但是因为单元测试应该会到方法级别，所以是不是应该测试用例数也会最多，开发时间和维护时间应该也是比较多的吧。相应的ROI成本也会变低吧。 谢谢老师指教。作者回复: 理论上会是这样。但在实践中 1. 单元测试只会关注部分领域逻辑强的代码的测试 2. 我看到很多单元测试，都是追求代码覆盖率，并不会一个方法一个测试案例。在需要测试的地方测得不够，在不需要测的地方又花费了精力。 从测试整体来看，单元测试捕捉到Bug，比起在生产环境捕捉到Bug，节省了至少10倍左右的成本。它的ROI还是最高的。当然单元测试也要聪明地做，这些我都在第二模块，第四模块都会讲到！欢迎关注！
2022-05-271
IT蜗壳-Tango
思考题： 我选择全栈，因为对于特定模块来说，我可以从单元测试，API，UI三个层面去验证这个模块的性能以及可用性。 问题： 目前的自动化测试感觉很少会接触到单元测试层面，尤其是黑合测试的场景。是不是主要将UI, API的ROI考虑的全面一些就可以了啊。作者回复: 是的！ 国内不重视单元测试，可以先把ROI思维用在UI和API测试上，逐步推动单元测试。最终一定会行得通，因为没有哪个老板不喜欢ROI。
2022-03-231
随片answer： 1、微服务时代，每个系统都是单独的应用，整体性相对是减弱的，独立性提高后，也许该应用在UI层是不体现测试点的。所以金字塔是不符合微服务时代的。 2、要考虑团队规模和项目复杂程度。规模小，那么一人单挑吧，反之，多人负责。项目负责程度与规模类似。一人：优势--编程、维护代码，个人思路更清晰；劣势--时间成本，交接成本，代码模块粘性。多人：时间短，分工明确；劣势--人工成本，测试功能点重叠？作者回复: 谢谢分享！
2022-06-28
志杰我目前所参与的微服务，偏向于接口方面，从ROI的模型来讲，接口运行的次数会增加，相对于开发而言，成本会变得小很多；目前项目中没有单元测试，投资接口测试的ROI明显会变高，纺锤型更贴近目前的测试方向。微服务框架下的接口测试，我个人感觉：基于数据，性能，可靠性的要求更贴近目前一个主流趋势。把握当下主流，并剖析测试未来方向，眼界还是不能缺少，学以致用为主，老师所讲的内容让我少走了一些弯路，再此十分感谢；最后，做好一件事情，精力是有限的，对一个事物的理解和打磨需要持续化的时间。作者回复: 看出来你很有经验！谢谢分享！在微服务体系下，单体应用被切分成很多块，接口测试和单元测试的界限也有靠近的趋势。
2022-05-26
