2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，帮助测试从业者了解最前沿行业趋势，及最新的行业实践。
会上，阿里巴巴测试开发专家潘家腾做《阿里妈妈在线下测试域的智能化建设》主题演讲。潘家腾分享了阿里妈妈在线下测试方面的实践，包括业务的现状与挑战，进入智能化的逻辑，以及如何实现线下测试的智能化。
以下为潘家腾演讲实录：
大家早上好！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的方式，让它无缝的嵌入到研发模式中。以上几种能力，共同组建了阿里妈妈极致左移的流程。
谢谢大家！
