自动化测试是软件测试技术上的一大进步，我们都知道自动化测试可以给工作提效，减少重复劳动，但在实践过程中，却总是碰到各种各样的问题，导致进入自动化测试盲区。如何做好自动化测试，是很多企业迫切想要解决的问题。
近日，阿里巴巴产品专家金桐从自动化的烦恼，到分层自动化单元测试、业务服务层测试和UI测试的优劣势分析，再到阿里巴巴分层自动化的实践之路，为大家提供了一套分层自动化实施解决方案。
自动化
为什么要做自动化？
手工测试效率低下，发布频繁，回归量大、成本高，重复劳动很枯燥。自动化测试，就是用机器执行替代测试手工操作的一种测试方法，能够帮助测试人员从重复、枯燥的手工测试中解放出来，从而节省人力、时间或硬件资源。
节约劳力为（N-1）M，M为此项工作单次需要投入的资源，N为此项工作需要重复工作的次数。
自动化的烦恼
如果自动化这么好，为什么大家没有全部做自动化呢？特别是对于初创公司，自动化测试非常少，原因大致如图。
上图不难看出，阿里该部门这一周的自动化失败次数不仅没有与发现bug数成正比，还浪费了测试人员41次自动化失败的排查时间，而这些时间对于做自动化查bug的初衷，都是无意义之举。
为什么外部环境、业务变更、应用环境问题、执行机问题、数据问题、框架问题这些都能引起这么多失败呢？而单单真正查出bug的概率这么低呢？
结合我们的多年自动化实践与总结，自动化存在如下这些缺点：
成本高
人员成本高：基本要懂某种自动化框架的代码语言，要有一定的编码能力，同时代码逻辑要清晰，否则如何能保证合理性、逻辑性、业务性与健壮性这些大大影响自动化成功率的因素？如何能保证自动化测试脚本本身没有bug？
环境成本高：开发环境、运行环境、调度环境等等，接触过代码的同学都知道，一次环境的安装，没有大半天甚至一天是完不成的。同时要让自动化对接到项目自动化流程中，或定时监控等，还需要再开发调度平台，这些成本对于从0到有的测试组，甚至是一家公司，将会是多大？需要投入多少人日的工作量可以完成这些？
效果差
从上图分析就知道效果如何，图中还只是阿里某部门单周的一个采样，就已经浪费了41次排查时间，这样的自动化测试，若运行一年，那效果又会如何？能确保后面没有这些干扰的失败吗？失败次数可以和bug数成正比吗？
覆盖率低
经常有同学抱怨自动化的覆盖率低，很多分支和逻辑无法覆盖，这大部分原因是这些同学的理解偏差，很多人都将UI自动化作为自动化测试的全部。然而没有一种自动化测试框架可以覆盖一个系统的所有功能点的测试，所以出现“自动化”覆盖率低的观点。那该如何提高自动化的覆盖率呢？
及时性低
其实从图中10次业务变更引起的自动化失败，就是这一缺点的佐证。所谓业务变更，是指正常的项目变更，但脚本未及时更新引起的自动化失败。这种失败恰恰又证明自动化测试是有用的，只要测试覆盖到的内容，一旦有变，自动化就能测试出来。那如何提高我们的脚本及时性呢？
面对上述那些问题，我们不禁自问：做自动化测试真的有必要吗？如果有必要，那如何降低这些成本，如何提高测试效果呢？经过不断的实践，我们引入了分层自动化测试的策略。
分层自动化
提到分层自动化，就会想到自动化经典的金字塔，第一层UI层针对页面系统，第二层服务层针对于业务集成，最后底层单元测试针对底层服务等。
分层自动化的特点比较如下：
Unit（单元/底层服务）：
它可以通过mock框架，模拟各种异常场景，外部依赖最少，且可以做到测试粒度到最小的一种测试方法。也因为依赖少，可方便随时随地执行，也让问题排查很简单。这是一切测试的地基。优点是可到最小可测单元、其功能明确，特定条件、特定场景均可测，测试性价比很高，缺点是基本依赖开发同学去做，开源工具多、测试代码多，要想全覆盖，需要投入较多时间。
Service（接口/集成服务）：
它是单元组装、功能组装、条件组装、场景组装的集合，要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景。因此，我们需要测试人员的场景设计、构造测试数据、应用环境部署、同时也依赖接口单元的质量。同时，这一层由于含有一些业务逻辑和多接口的一个集成，所以相对单元测试来说，多了一些外界依赖，导致问题定位不会有单元测试层那么准确。因此，维护和问题排查上的投入会比单元测试多一些。
UI（系统/页面）：
它是最常见的黑盒自动化测试场景，能覆盖的场景全面、条件全面、环境全面，最接近用户。但也因为测试范围全面，对测试人员、自动化脚本的健壮性等要求也会相对全面，需要考量场景设计能力、全面测试能力、框架选型成功、相关环境部署、业务逻辑清晰、功能测试边界、依赖底层质量。因此，只要有一环薄弱，就会大大增加自动化的失败率，而排查成本也因为环境太多太复杂而成倍增加。
以上就是分层自动化的主体三层，由此可见，分层自动化测试倡导的就是，将系统分层，根据层次特点用合适的自动化方法进行测试的一种测试策略。某个项目如何用自动化覆盖，根据项目技术特点与项目属性，设定合理的自动化测试补充，与整个产品的自动化测试体系结合保障。
除了分层方法与建议外，还有分层投入比，究竟花了多少时间做单测、多少时间作接口和UI？我们清楚知道，根据（N-1）M的劳力节约公式，不是所有项目都需要做自动化测试，主干核心、业务稳定、项目周期长和重复工作多的项目是需要做项目自动化测试的，图中展示了Google产品分层自动化投入比，它是比较完美的，当我们底层建设很完善的时候，上层建筑的确可以花费较少时间，维护成本也会相对降低。我们目前达不到，但可向这个比例去发展。
阿里巴巴分层自动化的实践
阿里巴巴分层自动化在经过策略的沉淀调整后，又经历了长期的工具与流程实践，并从自动化成本和效果这两个重要缺点上突破，进行分层自动化工具和项目流程的双重革命，最终达到业内领先的研发测试比。
首先，分层自动化工具革命
自动化测试框架，无论UI，接口还是单元，外部开源框架、收费软件等很多，各有利弊。阿里测试综合多种框架的实践，对其进行改良与创新，突破了传统自动化框架的众多难题，大大降低了自动化的成本、提升了自动化效果。如下图所示的四款重要工具，AUI主攻UI自动化，SAT主攻接口自动化，Amon主攻单元测试，以及Perf主攻性能，在传统测试框架基础的弱点上进行全面攻克与改造，最终实现鸟枪换大炮，全面提升测试工作效率。
UI自动化—AUI：
接口自动化—SAT：
单测—Amon：
不仅如此，阿里云效还从需求-开发-测试-发布整个项目流程中可工具化、平台化的手工工作，全面进行工具化、平台化的改造，如图所示。
开发环节：从拉分支开始，到自测的部署环境与单元测试，全部平台工具化。一键拉分支、一键部署、一键触发单测集成，不到喝杯咖啡的时间，即可查看环境部署结果和findbugs、PMD、Sonar等代码扫描结果。
测试环节：手工测试中有用例和缺陷两款主打产品，平台沉淀，无需再做一些文件传输，加上前面介绍的分层自动化相关测试平台与工具，在自动化测试工作上的效率提升，最终实现整体测试工作的平台与工具化。
其次，项目流程革命
除了单个工具的成本减少与效果提升，云效还优化了项目流程。如下图是我们常见的项目流程，其中自动化测试工作经常只有单一自动化测试框架进行测试。
这样的流程，经过长期实践发现，研发测试比最多提升到3:1，是否还有改进空间呢？
我们再看这些流程，可以看到测试工作，尤其是自动化测试工作，独立于开发项目流程。这种流程带来最直接的问题就是自动化发现问题不及时，对于开发自测项目也没有很好的介入保障，同时全手工触发，人为因素影响非常大，这是限制开发测试比大幅提升的重要原因。
假设我们的项目在合理运用分层自动化的测试策略后，并将其触发-问题排查-结果反馈都平台化地纳入到整个需求-开发-测试-发布这个项目流程中，会产生什么样的效果呢？
图为阿里项目分层自动化持续集成完整示意图，我们多了集成自动化平台，该平台可以把分层自动化工具串联在一起，去做整个持续集成、持续交付操作，让工具具备了平台能力。不仅如此，我们还将分层自动化测试纳入到了拟发布流程中，开发同学提交环境部署后，会自动提交自动化测试，不需要测试同学介入，如果失败了才会通知测试人员排查，完全做到了CI／CD的理想效果。
项目集成可以使用，那么日常的产品回归也可以用，图为阿里产品分层自动化持续集成完整示意图，集成自动化给日常回归产品做了赋能，将分层自动化工具平台和集成自动化串联，去保证日常产品质量的回归。
通过流程优化，在各个方面都得到了很大益处：
- 阿里内部：大幅提高研发测试比，减少重复劳动带来的加班，更多高效工具的诞生，使用这套体系，B2B研发测试配比达到了8:1，部分产品线13：1，却全年无故障。
- 研发：单测成本降低，覆盖率可视化，自测有保障，故障降低。
- 测试：测试要求降低，重复工作减少，增加工作成就感，各种工具诞生。
- 云效客户：企业快速赋能，提高研发测试效率，快速掌握阿里内部高效测试流程。
关于云效(http://yunxiao.aliyun.com)：
云效，是阿里巴巴互联网业务催生下的新型研发效能平台，历经阿里集团众多业务打磨，覆盖研发测试全流程，通过研发效能综合管理和专项自动化提效工具，将流式实时交付、自动化验证、柔性化管理等互联网研发模式，引入银行、证券、保险、微金融、民航、新零售等各个行业的传统企业，同时也根据这些行业特性不断丰富发展，使传统企业与互联网结合，加强诸多新业务的快速迭代和质量提升，使技术赋予业务无限可能。
