该文章为转载，如有侵权 请联系本人邮箱：bxf0321@qq.com
自动化测试是软件测试技术上的一大进步，我们都知道自动化测试可以给工作提效，减少重复劳动，但在实践过程中，却总是碰到各种各样的问题，导致进入自动化测试盲区。如何做好自动化测试，是很多企业迫切想要解决的问题。阿里巴巴旗下一站式研发提效平台——云效，将于12月8日16:00开启《阿里巴巴持续集成持续交付之分层自动化》直播分享，为企业提供自动化测试解决方案。今天我们先来看看阿里巴巴嘉宾的部分解读。
嘉宾介绍：金桐：阿里巴巴B2B事业群高级产品经理。从事多年互联网系统的研发和测试工作。现在主要负责云效分层自动化测试的产品设计。
自动化测试
所谓自动化测试，就是用程序模拟用户手工操作的一种测试方法，能够帮助测试人员从重复、枯燥的手工测试中解放出来。但在自动化实践过程中，测试人员往往发现理想和现实之间差距很大。
图1
上图不难看出，阿里该部门这一周的自动化失败次数不仅没有与发现bug数成正比，还浪费了测试人员41次自动化失败的排查时间，而这些时间对于做自动化查bug的初衷，都是无意义、不必要、也无技术含量之举。
为什么外部环境、业务变更、应用环境问题、执行机问题、数据问题、框架问题这些都能引起这么多失败呢？而单单真正查出bug的概率这么低呢？
结合我们的多年自动化实践与总结，自动化存在如下图这些缺点：
图2
成本：
人员成本高：基本要懂某种自动化框架的代码语言，要有一定的编码能力，同时代码逻辑要清晰，否则如何能保证合理性、逻辑性、业务性与健壮性这些大大影响自动化成功率的因素？如何能保证自动化测试脚本本身没有bug？
环境成本高：开发环境、运行环境、调度环境等等，接触过代码的同学都知道，一次环境的安装，没有大半天甚至一天是完不成的。同时要让自动化对接到项目自动化流程中，或定时监控等，都需要再开发调度平台，这些成本对于从0到有的测试组，甚至是一家公司，将会是多大？需要投入多少人日的工作量可以完成这些？
效果：
从图1分析就知道效果如何，然而图1还只是阿里某部门单周的一个采样，就已经浪费了41次排查时间，这样的自动化测试，若运行一年，那效果又会如何？能确保后面没有这些干扰的失败吗？失败次数可以和bug数成正比吗？
覆盖率：
经常有同学抱怨自动化的覆盖率低，很多分支和逻辑无法覆盖，这大部分原因是这些同学的理解偏差，很多人都将UI自动化作为自动化测试的全部。然而没有一种自动化测试框架可以覆盖一个系统的所有功能点的测试，所以出现“自动化”覆盖率低的观点。那该如何提高自动化的覆盖率呢？
及时性：
其实从图1中的10次业务变更引起的自动化失败，就是这一缺点的佐证。所谓业务变更，是指正常的项目变更，但脚本未及时更新引起的自动化失败。这种失败恰恰又证明自动化测试是有用的，只要测试覆盖到的内容，一旦有变，自动化就能测试出来。那如何提高我们的脚本及时性呢？
面对这些问题，我们不禁自问：做自动化测试真的有必要吗？如果有必要，那如何降低这些成本，如何提高测试效果呢？经过不断的实践，我们引入了分层自动化测试的策略。
分层自动化的理念是什么？
在理解分层自动化之前，我们先看自动化测试金字塔。自动化测试金字塔在测试领域耳熟能详，其中ui代表页面级系统测试，service代表服务业务测试（接口测试），unit代表单元测试。金字塔越高，表示需要投入的精力和工作量越大。
单元测试（unit）：它可以通过mock框架，模拟各种异常场景，外部依赖最少，且可以做到测试粒度到最小的一种测试方法。也因为依赖少，可方便随时随地执行，也让问题排查很简单。这是一切测试的地基。
接口测试（service）：这里要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景。这一层由于含有一些业务逻辑和多接口的一个集成，所以相对单元测试来说，多了一些外界依赖，导致问题定位不会有单元测试层那么准确。因此投入会比单元测试多一些。
页面测试（ui）：是常见的黑盒自动化测试场景。它最接近用户真实场景，也容易发现问题，但它的实现成本较高且太容易受外部依赖，影响脚本成功率，所以处在金字塔的顶端，但它不是金字塔的全部。自动化测试的劣势，其中80%都是因为ui自动化。
以上就是分层自动化的主体三层，由此可见，分层自动化测试倡导的就是，将系统分层，不同层次用合适的自动化方法进行测试的一种测试策略。某个项目是否都能用自动化覆盖，那就要看测试负责人的分层策略是否合理、全面。
通过实践发现，如果只是简单使用分层自动化测试，研发测试比最多提升到4:1，那么阿里巴巴研发测试比平均8:1，这是怎么实现的呢？
阿里巴巴分层自动化实践
阿里巴巴分层自动化在经过长期实践中，从自动化成本和效果这两个重要缺点
上突破，进行分层自动化工具和项目流程的双重革命，最终达到业内领先的研发测试比。
首先，分层自动化工具革命
自动化测试框架，无论ui，接口还是单元，外部开源框架、收费软件等很多，各有利弊。阿里测试综合多种框架的实践，对其进行改良与创新，突破了传统自动化框架的众多难题，大大降低了自动化的成本、提升了自动化效果。如下图所示的四款重要工具，AUI主攻UI自动化，SAT主攻接口自动化，Amon主攻单元测试，以及Perf主攻性能，在传统测试框架基础的弱点上进行全面攻克与改造，最终实现鸟枪换大炮，全面提升测试工作效率。
不仅如此，阿里云效还从需求-开发-测试-发布整个项目流程中可工具化、平台化的手工工作，全面进行工具化、平台化的改造，如图所示。
开发环节，从拉分支开始，到自测的部署环境与单元测试，全部平台工具化。一键拉分支、一键部署、一键触发单测集成，不到喝杯咖啡的时间，即可查看环境部署结果和findbugs、PMD、Sonar等代码扫描结果。
测试环节，手工测试中有用例和缺陷两款主打产品，平台沉淀，无需再做一些文件传输，加上前面介绍的分层自动化相关测试平台与工具，在自动化测试工作上的效率提升，最终实现整体测试工作的平台与工具化。
其次，项目流程革命
除了单个工具的成本减少与效果提升，云效还优化了项目流程。
如下图是我们常见的项目流程，其中自动化测试工作经常只有单一自动化测试框架进行测试。
通过前文的分析，分层自动化才能全面覆盖我们整个项目功能，因此，我们将流程改为如下图所示流程。
这样的流程，经过长期实践发现，研发测试比最多提升到3:1，是否还有改进空间呢？
我们再看这些流程，可以看到测试工作，尤其是自动化测试工作，独立于开发项目流程。这种流程带来最直接的问题就是自动化发现问题不及时，对于开发自测项目也没有很好的介入保障，同时全手工触发，人为因素影响非常大，这是限制开发测试比大幅提升的重要原因。
假设我们的项目在合理运用分层自动化的测试策略后，并将其触发-问题排查-结果反馈都平台化地纳入到整个需求-开发-测试-发布这个项目流程中，会产生什么样的效果呢？
将自动化的结果反馈变成了发布的必要环节，每一项自动化测试结果都变成发布环节的重要开发，又会产生什么样的效果？
我们的自动化测试，只能用于测试介入的项目测试么，只能用于测试介入的发布么？我们是否还能用做日常业务保障？是否可以在项目中的bug出现初期就发现问题呢？
无论是测试工具革命还是测试流程改进，都留给我们很多疑问，正是这些疑问，让自动化测试成为一把双刃剑，用的好可以大幅提升效率，降低成本投入，用的不好则可能成为鸡肋，阻碍效率提升。所以学习如何进行自动化测试，如何把握分层自动化的分层策略，如何将分层自动化融入到项目流程中，是企业必须掌握的测试技巧。
