【NCTS峰会回顾】阿里巴巴潘家腾:阿里妈妈在线下测试域的智能化建设

作者: 佚名 2019-11-26 17:41:59

 2019年10月26日,由Testin主办的第二届NCTS中国云测试行业峰会在京召开,此次峰会以“AI+未来”为主题,汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等,共同探讨高端云测试技术,帮助测试从业者了解最前沿行业趋势,及最新的行业实践。

pasted-image.jpeg

会上,阿里巴巴测试开发专家潘家腾做《阿里妈妈在线下测试域的智能化建设》主题演讲。潘家腾分享了阿里妈妈在线下测试方面的实践,包括业务的现状与挑战,进入智能化的逻辑,以及如何实现线下测试的智能化。

以下为潘家腾演讲实录:

大家早上好!Testin做的工作挺有意思,我挺大开眼界的。原来UI能这么测,通过智能化应用让整个测试更加简单。以前是我们测试的同学来做,以后能让非测试的同学,开发、算法、运营的都可以来做,普通人都可以来做,甚至让机器来做,都是没有问题的。

我今天分享的是阿里妈妈在线下测试方面的实践,我们的业务现状与挑战,进入智能化的逻辑,以及线下测试的智能化。智能化是非常高大上的技术,而线下测试更多的是比较脚踏实地的工作,如何将高大上的技术和脚踏实地的工作结合起来,这是我本期要讲的重点。

首先,让我们一起来看一下阿里妈妈在测试中遇到的一些问题。线下功能测试的发展历程,分为三个阶段,第一是大航海时代,特点是以人工测试为主,自动化程度不高;第二个阶段是工业革命时代,自动化程度非常高了,测试的框架也有了,加上持续集成的工具,比如阿里内部的一些平台,共同组成了很高的自动化方式。但是,由于测试技术的门槛非常高,开发无法参与进来,大部分工作都由测试来进行。在阿里内部,有不少团队还是处于高自动化的时代,但是还没有进入智能化的时代;第三阶段是智能化的时代,特点是产品化、可视化,以及部分的智能化,大大的提高效率。我们尝试着让整个测试工作更简单,通过降低门槛,让开发、算法或者其他同学都能够参与进来。这个阶段主要是向测试平台或者测试中台的演进。

这是阿里妈妈遇到的挑战,广告部门是非常大的一个盘子,包括超大规模的在线系统,链路数据化,以及非常复杂、个性化的商业场景。进行千级别的线上发布,有问题的话反馈需要非常快,否则会造成非常大的损失,还有性能的极致要求,这对测试同学的挑战是非常大的。在刚刚几大复杂的场景下,第一个挑战是测试开发比占的非常高,第二个是迭代频率已经是天级别了,第三是测试场景超复杂,复杂程度呈指数增高。我们复盘了原先在阿里妈妈内部的方式,之前是保姆式的测试方式,瓶颈都集中在QA上。人就那么多,项目更多之后,无论我们怎么做优化,瓶颈都在我们这里,不得不逼着我们进入智能化时代。

方案就是打造协同化的测试模式,在传统模式的基础上开辟一条快速模式,走智能化的方式,打造一个测试平台,主要是低风险和算法的项目,高风险项目仍由测试主要来负责。这个平台通过智能化、可视化、产品化的方式,让开发、算法的同学进行自动化的测试,由系统来判定准入,判定准出,如果系统通过了,可以随时上线。

关于线下测试平台的思考,我们有几大诉求。第一大诉求是这个平台随时可测,开发的同学无论何时何地都能快速的进行测试。这需要很方便的case编写,让测试想法能够快速的映射为case,使系统可以高效的做用例管理,测试环境管理,实现极致的运行效率。整个平台的方向有三个,第一是极致的测试左移,第二是成为线下测试的基础设施,第三是研发流程的重构。基于这些方向,整个测试平台该怎么做?Markov是我们打造的智能化线下测试平台,作为非常强大的基础设施,本期会介绍其中的部分智能化技术,如智能回归,用例智能推荐,数据智能推荐,冒烟回归技术,用例膨胀,智能排查闭环等,其他如基于docker的分布式容器管理,万级别用例管理系统,分布式智能任务调度系统,这次就不说了。

智能化技术非常重要,但是如何结合测试场景是更重要的事情。功能测试域主要分为三个部分,第一部分是怎么写case,就是用例生成,第二是用例回归,也就是说写完case之后快速的迭代这些case,第三是一旦case跑失败之后,怎么做智能排查,这三块智能化都有所体现。

首先介绍个概念,即用例画像,对测试而言,什么是护城河和资产?那就是用例。我们对阿里妈妈上万的用例做了精炼提取和组合,最终我们每个用例都形成了自己的画像,包括用例名称,覆盖的代码域,业务特征,用例失败归因,相似用例集,就是说其它用例跟它相似度、关联度是怎样的,还有衍生的异常用例集,以及运行稳定性等等。基于整个用例画像就可以一览用例的全貌,是一种让用户能够全面感知用例的方式。同样,用例画像也是我们实现智能化的重要基础。

用例智能推荐的目标很简单,那就是希望传统标准化的用例编写能够升级为极致体验的case编写方式。以前从测试名称开始写,再写依赖的测试数据,再写发送请求和期望,这是最简单的。或者在用例库中copy一个用例数据。因此,传统的方式就是直接手动写,或者是copy以前的老用例。Markov的智能用例推荐的方式,我们提供了一个智能框,用户可以随便描述一下需要什么样的用例,甚至把设计文档直接copy进去,Markov平台就可以把你输入的描述提取成一个一个业务特征。同样的,我们在整个用例库中,如果有上千个用例库,每个用例进行训练形成特征池。这个时候可以用自然语言处理,最后会提出业务特征。通过朴素贝叶斯算法,我们可以获取到相似度TopN的关联用例列表,最终确定选择,快速拿到上千个用例中最相近的用例。这样省去了搜索的过程,也方便了写用例的过程。右面这个图是用例膨胀,我们写完一个正常用例之后要写异常用例,最基本的过程是调整参数,改为极大值,边界值,异常值,乱码等等。我们训练了一个N-wise特征模型,在整个用例库中训练出了多因子模型,比如特征有1、2、3、4,我们可以拿到这些数据的类型,根据类型来得到异常值。当我们训练出整个库中的特征,所有的异常值、边界值组合之后,这样就好办了,将我们刚刚智能推荐找到的一个用例进行组合变异。我们想进行某一个特征的膨胀,就从系统里面推荐出膨胀的组合值,通过最终的叉乘就能组合出异常用例集,最终由用户进行挑选和筛选。通过这种组合,会碰撞出非常多的用例,就能快速的完成多个用例的生成。

下面是数据智能推荐,在case级别推荐的基础上,能更精准的进行测试数据的推荐,让case编写的速率进一步演进。智能推荐提供了一种解决了快速找到用例的方式,但是找到这个用例之后还要进行修改编写,数据智能推荐就是做这件事情的。在写测试数据的时候,基于原有的修改用例方式,如果找不到某个测试数据,我们可能是去其他case中找到测试数据,然后再copy过来修改。Markov平台做的事情就是当你想写测试数据的时候,当选中它时系统就已经给你推荐了最适合的一个测试数据。我们有三种推荐方式,第一种是模板推荐,就是用户可以自定义定制的数据源模板的推荐方式。第二种是最长匹配方式,我们将测试数据进行简单的推荐,这个方式很简单,我们假定了最长的测试数据所包含的信息是最全的,也是你最可能需要的。第三是相似用例距离的推荐,就是基于刚刚用例的相似度进行推荐,如果这个用例跟你当前编辑的用例是非常相似的,他们使用的数据大概率也是你需要的。我们做这个工作之后,再修改测试数据的时候就是非常快的事情。

第三个是智能冒烟回流技术,这个技术非常有意思,也是我们在做的一个工作,希望能够从另外一种方式来生成用例。这个方式是我们基于生产流量冒烟来进行测试,并结合用例智能推荐技术,快速回流为线下用例,从而打通线上线下的闭环。这是什么意思呢?传统测试的方式,我们找到一个用例,开始改,然后进行测试。这个冒烟调试是另外一种方式,借鉴了阿里妈妈内部算法同学的调试方式。他们会在线上来冒烟,用线上的数据和自己的数据和生产的流量来进行监测,如果没有问题了,他们就完成了这次工作。我们在想,能不能给他们提供一个方案,在线上做的时候,能够一键的将线上流程回放,转化成线下的case,这样线上调试完之后,线下库中就自动有case了。这是怎么实现的?它依赖于比较完善的一个基础设施,阿里妈妈内部有非常好的基础设施,比如环境的基础设施,我们能够快速的、一键的,拿到跟生产环境一致的环境,这就是环境克隆。我们拿到这个环境之后,算法能够基于我们的数据工厂给出的流量来进行改造,然后进行简单的线上冒烟,冒完之后我们提供一键转换线下流量的模式。这里会产生两个问题,那就是线上线下始终是有gap的,数据必然是不一样的。我们做了一些工作,第一个工作就是对一些比较简单的模块,在冒烟的过程,从日志级别获取整个应用依赖的测试数据,输入数据我们有了,能回流到线下了,实际输出的也有了,就能够以无gap的方式进行线下流量的转换。但是这种方式大家发现了吗,整个开发代码侵入性是非常大的,它必须要依赖开发进行埋点。于是我们采用另外一种方式,就是推荐技术,冒烟的输入请求。我们会抽取出部分的输入请求特征,或者是输出期望特征,然后根据用例库中的用例特征来推荐出可能想要的用例。推荐完之后,再将用例进行改造,让系统自动做改造的工作,就要就能够基于改造后的用例来写用例。

然后是智能回归技术,我们研发了一个用例动态编排算法,提升了2到10倍的回归效率,打破回归时长随着用例数线性增长的曲线。回归测试就是把用例库中的用例批量跑一遍,但是即使这么简单,它仍然是一个阻碍我们研发效率的重要环节。传统模式下,由于很多原因,我们只能进行case by case的执行,依赖的数据会有重启和数据冲突。Markov平台希望能在整个用例编排的过程中实现最高效的编排,让整个回归效率成倍的增长,最终打破增长曲线。我们有几十个用例的时候回归一次还好,但是有几百上千用例的时候怎么办呢?可能有些同学是进行精准测试,只跑一些代码不影响的用例,另外一种方式是多几套环境并行跑,这其实是牺牲资源来换时间的方式,因为资源总是有限的。Markov希望通过编排的算法,只要打破增长曲线就完了。我们在单环境的回归上,如果打破了这个曲线,整个多环境回归的情况下就好做很多。多环境指的是并行多套环境,传统的方式是非常简单的,用例总数跟环境数进行平分,Markov的方式,因为我们积累了用例时间对回归的影响,就能反作用来进行用例的动态分配,通过预估回归方差来实现全局最优,尽可能让每个环境的用例时间进行均匀化,因为评价一次回归是否完成了,最后一个环境跑完才是回归过程,怎么让时间均匀化,让每套回归的时间差不多,就能实现全局最优。

我们第一个是在整个回归算法上进行解决,第二是在环境上来进行解决。我们看一下动态编排算法,算法的核心在于测试数据,如果一次准备很多数据,整个过程就会非常快,节省的时间非常多。如果用例没有任何数据依赖,这些用例都能进行并行的运行。我们可以看一下右边的图,这是一个曲线,代表着数据冗余率,可以看到曲线随着用例数增多,运行时长是非指数的增长,当冗余度为零,即不冗余的极端情况下,每个用例都要准备一次数据,数据准备的时间是消耗非常多的。我们这边采用的方式,基于最大公共数据集递归创建二叉用例树,当建好这个树之后,第二步就是希望对这些测试数据进行聚合,我们采用了一个分层聚类的方式,对不同的文本数据,对数据进行聚合,减少数据准备的时间。第三步,基于深度优先建立快速执行树,整个执行过程都会变成串行中有并行的高效方式。

这是我们实验室的数据,在整个过程中我们分为四个阶段,第一是数据准备阶段,第二是分层数据准备阶段,第三是快速执行阶段,第四是失败重试阶段。这里有600多个数据,冗余度已经达到了500个,可以省掉黑色的时间,因为数据已经准备好了,能够快速的执行,实验室里面数据准备阶段效率提升了500%多,由于并行化,时间节约了50%左右。

这是排查领域,用例运行失败之后到底怎么排查呢?这个排查是非常有意思的,我们做这个是基于用例画像有记忆的排查系统,有两个目标,第一是失败排查效率从分钟级提升到秒级,第二是排查经验能够沉淀到下一次排查。传统排查系统实现的是左半环,即重放失败的流量,然后在执行的过程中由整个系统来进行链路数据的收集。比如我们收集执行过程中的日志,主干情况是怎样的,测试环境是不是正常启动的,或者是一些基础的配置检测之类的,我们通过这种方式来进行,最终由系统给出一个失败的原因,这是非常正常的一个排查思路,即系统自查。在此之上,我们实现的另外一环,就是右半环,增加了一个用户反馈体系,这是什么意思呢?左半环是自查非常初级的方式,没有办法对复杂场景进行排查,整个排查的方式就变成了可以由用户来进行人工的排查,把排查的失败信息输入到系统里面去,系统来进行记录,并最终将整个排查失败归因的特征抽出来,和历史的失败原因进行比对,每次进行排查的时候都会推出系统自查的原因,以及历史上可能出现的人工排查原因。

我们将整个智能排查反馈,以及整个智能回归,联动起来就变成了回归反馈闭环。简单来说,能够快速的执行一次回归,由系统自动的触发自动排查,反馈给用户原因,用户运行一次之后就可以知道是什么原因,可以达到最高效的反馈速度。

再说一下测试左移,智能化场景解决了一些高效性,或者是能够让开发做测试的极简方式,但提升效率仍然是其中一个环节。而我们想提升整个研发流程的效率势必要进行左移,才能从线和面上解决研发效率问题,第一个是可编排的pipeline技术,这个过程原先需要是5天时间,我们做了UT自动化一站式服务,功能测试,功能AB,性能AB。我们将基础设施打造好,提测代码的时候可以一键提交整个流程,将整个流程提升到4个小时之内。如果是改动量不影响老功能的情况下,只要提测通过了四个环节,我们认为覆盖率就能逼近百分之百。

功能A/B Test,跟线上的环境进行对比,整个过程都需要强大的基础设施。需要的核心能力包括环境克隆,基于数据工厂的流量精准抽取与改造,对比流量高发执行等等。同样,性能A/B Test也是这样的思路,追求性能,比如说这个版本上线之后稳定性到底怎么样,CPU的状态怎么样,内存到底怎么样,能够追求整个最短的反馈的时效,就能够做到这个版本性能跟测试报告到底怎么样,这些都非常依赖强大的基础设施。第三是CLI触发运行,是基于git的工作方式,用命令行的方式来进行代码的修改,能够用Markov git的方式,让它无缝的嵌入到研发模式中。以上几种能力,共同组建了阿里妈妈极致左移的流程。

谢谢大家!

AI 数据 人工智能
上一篇:【NCTS峰会回顾】Testin徐琨:AI引领下一代测试,iTestin改写测试未来 下一篇:【NCTS峰会回顾】李元春:强化学习在自动测试中的应用
评论
取消
暂无评论,快去成为第一个评论的人吧

更多资讯推荐

MIT提出Liquid机器学习系统,可像液体一样适应动态变化

麻省理工学院(MIT)的研究者开发出了一种新型的神经网络,其不仅能在训练阶段学习,而且还能持续不断地适应。

机器之心 ·  2021-02-21 15:47:47
规划智慧城市时,别忘了无障碍通行

要想成为一个智慧城市甚至一个智慧世界,虽然可能需要时间和有针对性的规划,但我们必须以人为本。

蒙光伟 ·  2021-02-21 10:26:41
2021关于人工智能的五大趋势

数字化变革,比过去10年更多,这主要是由于远程工作的规模,以及企业迅速部署了必要的技术,尤其是与网络安全相关的技术。那,2021关于人工智能的五大趋势会是如何的呢?

Lichu ·  2021-02-21 10:21:01
使数据中心更智能:人工智能如何发挥作用?

随着数据成为维持几乎所有业务运营以获取洞察力和业务成果的先决条件,数据中心正处于这种数字化转型的关键。

Cassie ·  2021-02-21 10:14:59
IBM拟出售Watson Health后,AI医疗还能不能碰

医疗服务仍然是一块商业上尚未被完全发掘的市场,看病难/看病贵、医疗资源紧缺、医疗资源不平均等痛点问题长期存在,对应的市场空间理应是巨大的。而Watson Health作为IBM曾寄予厚望的业务方向,为何要在此时萌生退意?它的故事给业界带来哪些启发?眼下的AI医疗市场,究竟是一副什么样的局面呢?

物联传媒 ·  2021-02-21 08:41:16
抛弃归一化,深度学习模型准确率却达到了前所未有的水平

我们知道,在传递给机器学习模型的数据中,我们需要对数据进行归一化(normalization)处理。

机器之心 ·  2021-02-20 21:09:12
华人博士生首次尝试用两个Transformer构建一个GAN

最近,CV 研究者对 transformer 产生了极大的兴趣并取得了不少突破。这表明,transformer 有可能成为计算机视觉任务(如分类、检测和分割)的强大通用模型。

Yifan Jiang ·  2021-02-20 21:04:53
无监督训练用堆叠自编码器是否落伍?ML博士对比了8个自编码器

柏林工业大学深度学习方向博士生 Tilman Krokotsch 在多项任务中对比了 8 种自编码器的性能。

Tilman Krokotsch ·  2021-02-20 20:57:16
Copyright©2005-2021 51CTO.COM 版权所有 未经许可 请勿转载