阿里巴巴CI:CD之分层自动化实践之路


阿里巴巴CI:CD之分层自动化实践之路

2018-05-30 摘自:阿里巴巴CI:CD之分层自动化实践之路

自动化
  1.1 为什么要做自动化?
  1.2 自动化的烦恼
  1.3 自动化的追求
2 分层自动化
3 阿里分层自动化的实践
  3.1 首先,分层自动化工具革命
  3.2 其次,项目流程革命

 

6月29日,由阿里云研发协同RDC、阿里云云效和云栖社区联合举办的“首届阿里巴巴研发效能嘉年华”上,阿里巴巴高级产品经理金桐带来“分层自动化实践之路”的演讲。本文从为什么要做自动化开始谈起,进而对分层自动化单元测试、业务服务层测试和UI测试进行优劣势分析,最后重点分享了阿里分层自动化的实践,包括工具分层和流程优化等。

随着云计算、大数据、AI智能等前沿科技的发展,传统的研发速度越来越难满足企业快速发展的需求,研发效能也成了继商业模式、技术突破之后的另一核心竞争力。分层自动化测试倡导的就是将系统分层,不同层次需要用合适的自动化方法进行测试的一种测试策略。本文从大家熟知的单元测试、业务服务层的测试及UI自动化测试,进行优势和劣势的分析,同时从执行速度、维护成本、测试方法、完成优先级、覆盖范围及实施团队等多个维度,为大家提供一套分层自动化实施解决方案,最后重点分享了阿里分层自动化的实践,包括工具分层和流程优化等。一起来了解下吧: 

返回

返回

8f2a67cd7dbe44b4a7850f1325ac4dfe8dbe5c5d

提到分层自动化,就会想到自动化经典的金字塔,第一层UI层针对页面系统,第二层服务层针对于业务集成,最后底层单元测试针对底层服务等。

分层自动化的特点比较如下:

  • Unit(单元/底层服务):

它可以通过mock框架,模拟各种异常场景,外部依赖最少,且可以做到测试粒度到最小的一种测试方法。也因为依赖少,可方便随时随地执行,也让问题排查很简单。这是一切测试的地基。优点是可到最小可测单元、其功能明确,特定条件、特定场景均可测,测试性价比很高,缺点是基本依赖开发同学去做,开源工具多、测试代码多,要想全覆盖,需要投入较多时间;

  • Service(接口/集成服务):

它是单元组装、功能组装、条件组装、场景组装的集合,要求测试人员对系统的结构和系统间的调度非常清楚,同时要了解接口逻辑关系,否则接口测试代码很容易遗漏一些异常场景。因此,我们需要测试人员的场景设计、构造测试数据、应用环境部署、同时也依赖接口单元的质量。同时,这一层由于含有一些业务逻辑和多接口的一个集成,所以相对单元测试来说,多了一些外界依赖,导致问题定位不会有单元测试层那么准确。因此,维护和问题排查上的投入会比单元测试多一些。

  • UI(系统/页面):

它是最常见的黑盒自动化测试场景,能覆盖的场景全面、条件全面、环境全面,最接近用户。但也因为测试范围全面,对测试人员、自动化脚本的健壮性等要求也会相对全面,需要考量场景设计能力、全面测试能力、框架选型成功、相关环境部署、业务逻辑清晰、功能测试边界、依赖底层质量。因此,只要有一环薄弱,就会大大增加自动化的失败率,而排查成本也因为环境太多太复杂而成倍增加。

以上就是分层自动化的主体三层,由此可见,分层自动化测试倡导的就是,将系统分层,根据层次特点用合适的自动化方法进行测试的一种测试策略。某个项目如何用自动化覆盖,根据项目技术特点与项目属性,设定合理的自动化测试补充与整个产品的自动化测试保障体系的结合保障。

fed22af88a5982a563511e5cf72e6368554f6620

除了分层方法与建议外,还有分层投入比,究竟花了多少时间作单测、多少时间作接口和UI?我们清楚知道,根据(N-1)M的劳力节约公式,不是所有项目都需要做自动化测试,主干核心、业务稳定、项目周期长和重复工作多的项目是需要做项目自动化测试的,图中展示了Google产品分层自动化投入比,它是比较完美的,当我们底层建设很完善的时候,上层建筑的确可以花费较少时间,维护成本也会相对降低。我们目前达不到,但可向这个比例去发展。 

返回

阿里巴巴分层自动化在经过策略的沉淀调整后,又经历了长期的工具与流程实践,并从自动化成本和效果这两个重要缺点上突破,进行分层自动化工具和项目流程的双重革命,最终达到业内领先的研发测试比。

3.1 首先,分层自动化工具革命

自动化测试框架,无论UI,接口还是单元,外部开源框架、收费软件等很多,各有利弊。阿里测试综合多种框架的实践,对其进行改良与创新,突破了传统自动化框架的众多难题,大大降低了自动化的成本、提升了自动化效果。如下图所示的四款重要工具,AUI主攻UI自动化,SAT主攻接口自动化,Amon主攻单元测试,以及Perf主攻性能,在传统测试框架基础的弱点上进行全面攻克与改造,最终实现鸟枪换大炮,全面提升测试工作效率。

4b1c961d0b18900ddf7d222e921441929adfe3be

1792420da37f13f65bef4b1591d96359373f5942

  • UI自动化—AUI:

4e9cfbc4f50df23867a3a2bfa192b84f2b6b369f

  • 接口自动化—SAT:

d74df6c542a4e3c1a873fa7e47559eb6600d0f71

  • 单测—Amon:

39ef89471276e798bf2bf4038735b4e2ce8edcf3

不仅如此,阿里云效还从需求-开发-测试-发布整个项目流程中可工具化、平台化的手工工作,全面进行工具化、平台化的改造,如图所示。 

9ba07736b25788fd2a2dc6b7e050ae588d53cc5f

开发环节:从拉分支开始,到自测的部署环境与单元测试,全部平台工具化。一键拉分支、一键部署、一键触发单测集成,不到喝杯咖啡的时间,即可查看环境部署结果和findbugs、PMD、Sonar等代码扫描结果。

测试环节:手工测试中有用例和缺陷两款主打产品,平台沉淀,无需再做一些文件传输,加上前面介绍的分层自动化相关测试平台与工具,在自动化测试工作上的效率提升,最终实现整体测试工作的平台与工具化。

3.2 其次,项目流程革命

除了单个工具的成本减少与效果提升,云效还优化了项目流程。如下图是我们常见的项目流程,其中自动化测试工作经常只有单一自动化测试框架进行测试。

ffb3336f73c50dd2631018acb2271990fc39b95e

这样的流程,经过长期实践发现,研发测试比最多提升到3:1,是否还有改进空间呢?

我们再看这些流程,可以看到测试工作,尤其是自动化测试工作,独立于开发项目流程。这种流程带来最直接的问题就是自动化发现问题不及时,对于开发自测项目也没有很好的介入保障,同时全手工触发,人为因素影响非常大,这是限制开发测试比大幅提升的重要原因。

假设我们的项目在合理运用分层自动化的测试策略后,并将其触发-问题排查-结果反馈都平台化地纳入到整个需求-开发-测试-发布这个项目流程中,会产生什么样的效果呢?

78889e73b6abef00d61a95f4f19a7a8a878aa0ba

图为阿里项目分层自动化持续集成完整示意图,我们多了集成自动化平台,该平台可以把分层自动化工具串联在一起,去做整个持续集成、持续交付操作,让工具具备了平台能力。不仅如此,我们还将分层自动化测试纳入到了拟发布流程中,开发同学提交环境部署后,会自动提交自动化测试,不需要测试同学介入,如果失败了才会通知测试人员排查,完全做到了CI/CD的理想效果。

bbbb45903b088de9aab3997d6546833436457eff

项目集成可以使用,那么日常的产品回归也可以用,图为阿里产品分层自动化持续集成完整示意图,集成自动化给日常回归产品做了赋能,将分层自动化工具平台和集成自动化串联,去保证日常产品质量的回归。

通过流程优化,在各个方面都得到了很大益处:

  • 阿里内部:大幅提高研发测试比,减少重复劳动带来的加班,更多高效工具的诞生
  • 研发:单测成本降低,覆盖率可视化,自测有保障,故障降低
  • 测试:测试要求降低,重复工作减少,增加工作成就感,各种工具诞生
  • 云效客户:企业快速赋能,提高研发测试效率,快速掌握阿里内部高效测试流程

使用这套体系,B2B研发测试配比达到了8:1,部分产品线13:1,却全年无故障。