《精通自动化测试框架设计》—第1章 1.6节再启航

本节书摘来自异步社区《精通自动化测试框架设计》一书中的第1章，第1.6节再启航，作者陈冬严 , 邵杰明 , 王东刚 , 蒋涛，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.6 再启航
尽管面临这样或者那样的问题，一些测试团队仍然成功获得了开发团队的信任，建立起了双方每周对话的机制，在周例会上沟通彼此遇到的技术问题，并决定自动化测试任务的优先级。也有些测试团队的成员，开始代替开发人员着手修复或者新建框架中的类，并提交代码进代码库而不再只作为缺陷描述中的补充。这样做所取得的直接效果就是降低了与自动化测试框架相关的缺陷的修复时间。

在测试组织内部，也通过这两年的锻炼，吸引了一些熟练掌握框架API并且熟悉产品知识的自动化测试人员，他们通过BCO牵头，成立了一个虚拟的自动化测试团队。

在这个背景下，终于有人喊出了测试组织需要拿回框架所有权的口号，并逐步运用上述团队的力量实施这一战略。而开发团队也终于越来越意识到加大投资自动化测试的必要性。于是整个工程部门召开了一次由相关方参与的自动化测试峰会。会议上基于自动化测试金字塔方针，提出了“做更有效的自动化测试”的策略。

1.6.1 自动化测试金字塔与冰淇淋
Lisa Crispin在其广为流传的《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中提到了自动化测试金字塔[4]。依据图1.8所示的金字塔，自动化测试的资源投入或者收益额度从大到小的分别是单元测试、API测试、UI测试。

随着敏捷这一软件工程实践日益成为主流，这一模式目前已经被行业遵守，甚至还演化出了其他不同的形式。例如，Alister Scott 提出了冰激凌模式[5]，这也是目前很多从UI开始自动化测试实践的测试团队的现状。

在这种自动化测试的反模式下，如图 1.9 所示，单元测试在冰激凌杯的底部，表示其数量或者投入很少，甚至有可能完全没有。接着中间部分是集成测试，其情况略好于下部的单元测试。冰激凌杯的最上部，也就是体积最大的杯口部分，则是 UI 自动化测试。而在这个冰激凌杯里面所盛放的，是一块超级大的冰淇淋，名字叫做手工测试。冰淇淋是一种让人产生愉悦感觉的食物，而这款自动化测试冰激凌，估计吃过的人很少会感觉好吃并且愿意推荐给其他人。

1.6.2 橄榄形的自动化测试
自动化测试金字塔看似美好却很难达到，而更多的自动化测试团队，则是吃着自动化测试冰激凌大餐并且难以下咽。为了解决这一挑战，An君从自身所经历的经验教训出发，认为自动化测试首先要达到橄榄形的自动化模式。如图1.10所示，接口测试位于中间，且占比最大，UI测试和单元测试位于橄榄的两端。建议在测试组织的自动化测试达到这个稳定的橄榄形之后，再另行考虑自动化金字塔的可达到性。

从面向业务的角度来说，接口测试同样可以覆盖业务逻辑的测试需求，并且相比于UI自动化测试其运行效率、稳定性和可靠性更高。从面向技术的角度来说，接口测试比单元测试进入的门槛更低，并且单个测试用例的覆盖范围更广，单位收益也更高。

从投资收益的角度考虑，也可以得出类似的结论。按照边际效用递减法则的原理，在进行自动化投资的初期，边际效用会增加，自动化投资的总收益也随之增加。随着自动化投资的持续，其边际效用会逐渐减少。而当边际效用递减至0时，表示总收益达到最大。如果此后再进行投资，反而会因为负的边际效益而使总收益降低。

显而易见，UI 自动化测试虽然覆盖范围最广，却因为后期的高维护成本，UI 自动化测试投资的边际效用是最早递减至0的。单元测试却因为前期的高投入，以及关注代码自身，而不是业务的缘故，限制了其后期的总收益。因此，在各类型的自动化测试中，接口测试的综合收益最高。

综合来说，建议测试组织在自动化测试的发展路径图的初期，最大限度集中可投入的有限资源，首先实施接口测试或者集成测试，而后再涉及部分的UI/端到端自动化测试。而单元测试则可以交由开发人员自行完成，并交由集成团队收集并执行，成为版本集成的前置测试的方式纳入测试组织的用例库。

这也是本书取名《自动化测试框架设计再入门》的缘由。读者在读完本书之后，会发现这里假借Webdriver自动化之名，却是将读者带入到了统一自动化测试框架这扇门之前。由反式脂肪酸造出的自动化测试冰激凌即使好吃也不健康，是时候出来运动运动，打一场自动化测试橄榄球了。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。