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