在大集成环境的全网回归环境下，回归验证必然会有发布窗口限制，没办法快速交付。会暴露出很多问题，例如：功能的交付与大应用相比并无改观；手工部署的应用更多，更复杂；自动化排查问题效率低；痛苦的回滚，剔除问题代码提交。
为了实现持续交付，该怎么做呢？单个应用实现快速交付，没有全网自动化回归，面对复杂的服务化依赖较大质量风险，给了质量保证部很大压力。既要快速交付，还要集成质量。质量向前，把一切能自动化的自动化起来，提升项目组成员的工作效能。完成这一系列过程，这其中的核心就是实现自动化。
分层自动化看上去就是一个金字塔，基本上分为两部分，业务逻辑自动化测试，和代码级别自动化测试。而这里面重点是UI自动化存在很多痛点，用下面这个公式可以说明：
- 自动化收益=有效迭代次数×手工测试成本
- 自动化成本=脚本创建成本+维护次数×维护调试成本+脚本失败次数×脚本排错成本
其次就是在服务化接口测试上做了很多改进，包括：无需编码，自动解析接口及所需参数，页面创建接口自动化测试用例；页面直接填写调用参数，支撑多种参数类型；直接指定IP进行服务调用。
在线性能压测方面，实行了在线编辑性能压测脚本；分布式集群压测执行调度，执行结果实时统计；Linux服务器资源在线监控。
通过一系列的改进，给 质量保证团队带来的变化很明显，比如：开发测试比逐年提升，更多的开发资源投入在产品研发上，支撑业务快速发展；测试资源通过高效的自动化工具产品，提供分层自动化测试套件进行自动集成；业务技术团队判断是否需要测试人员接手人工测试；可以有不经过手工测试的需求发布上线，但是不能没有质量数据监控的需求发布上线。
阿里巴巴CI/CD之分层自动化
一佛是阿里巴巴B2B事业群高级产品经理。从事多年互联网系统的研发和测试工作，目前主要负责云效分层自动化测试的产品设计。因为自动化测试在实践过程中，总是碰到各种各样的问题，导致进入自动化测试盲区。所以，一佛就根据当下环境并结合解决案例，来讲解了如何把握分层自动化的分层策略，如何将分层自动化融入到项目流程中，如何做好自动化测试等现实问题。
自动化诞生的背景，一佛说，手工测试的效率低下，尤其是发布频繁的情况下，回归量大，成本高，重复劳动，枯燥多。而自动化之后，就可以替代重复劳动，N次测试，只需要投入一次就够了。
但是自动化也是有烦恼的，问题就在于成本高（代码能力、自动化框架、IDE 准备、调度、多环境），效果差（浏览器影响、执行机影响、依赖环境影响、脚本健壮性不强），覆盖率低（框架不万能、上下层难全、接口参数排列多），及时性低（代码变更频繁、遗漏的变更、项目结束才发现）等等。
所以说，为了降低成本，提高准确性，就要考虑降低人员成本、制作成本、运维成本、运行成本，同时扩大覆盖率、数据独立、提供好的方法和脚本。当然，就需要实行分层自动化。
在阿里实践分层自动化就需要很多分层工具，包括配置管理Aton、UI测试的AUI、单元测试的Amon、环境管理的Aenv、接口测试SAT、性能测试Perf、集成自动化Pre等。这里来介绍几个革命性工具：
UI自动化—AUI
- 创新型web-ui自动化测试框架，无需安装复杂底层环境和 IDE
- 创建和维护脚本，都无需接触代码，全部为 Web 页面可视化使用
- 支持本地回放，支持云端执行，解放机器，释放双手
- 支持项目持续集成，线上监控等各种复杂场景
接口自动化—SAT
- 可视化的接口测试，无需编写代码
- 支持普通接口调试和复杂后台交互的接口测试的用例沉淀
- 支持主干，项目用例的沉淀与回归
- 支持项目持续集成
性能压测—Perf
- 基于 Jmeter 的性能压测平台
- 集脚本，场景，压测，监控和报表为一体，可快速施压的平台
- 支持多种协议，适合 http，service 接口等测试
- 比 LoadRunner 易上手，更轻量
单元测试—Amon