2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在北京召开。以“AI+未来”为主题，汇聚国内外测试领域知名专家学者、领先企业决策者、高级技术管理者、媒体从业者等，共同探讨高端云测试技术并帮助测试从业者了解最前沿的行业趋势，以及最新的行业实践。会上，阿里巴巴测试开发专家潘家腾做了主题演讲《阿里妈妈在线下测试域的智能化建设》。潘嘉腾分享了阿里妈妈在线下测试的实践，包括业务现状与挑战、进入智能化的逻辑，以及如何实现线下测试的智能化。以下为潘家腾演讲实录：大家早上好！Testin所做的工作非常有趣，让我大开眼界。原来这样可以测试UI，而且通过智能应用让整个测试变得更简单。过去，我们的测试学生就是这样做的。以后非考级同学，开发，算法，运维都可以。普通人可以做，甚至让机器来做。没有问题。今天分享的是阿里妈妈在线下测试的实践，我们的业务现状和挑战，进入智能化的逻辑，以及线下测试的智能化。智能化是一项非常先进的技术，线下测试更是踏踏实实的工作。如何将先进的技术与脚踏实地的工作结合起来，是本期的重点。首先我们来看看阿里妈妈在测试过程中遇到的一些问题。离线功能测试的开发过程分为三个阶段。第一个是大航海时代，其特点是人工测试，自动化程度低；第二阶段是工业革命时代，自动化程度非常高。还有一个框架，和持续集成工具，比如阿里内部的一些平台，一起形成一个自动化程度非常高的方法。但由于测试技术门槛非常高，开发无法参与，大部分工作都是靠测试来完成的。在阿里内部，很多团队还处在高度自动化的时代，还没有进入智能化时代；第三阶段是智能化时代，以产品化、可视化、偏智能化为特征，极大地提高了效率。我们试图让整个测试工作变得更简单，通过降低门槛，让开发者、算法或其他同学都可以参与。这个阶段主要是向测试平台或测试平台演进。这就是阿里妈妈遇到的挑战。广告部是一个非常大的板块，包括超大规模的线上系统、链接数据，以及非常复杂和个性化的业务场景。千层级的在线发布，如果出现问题，反馈需要非常快，否则会造成非常大的损失，而且对性能有极高的要求，对测试同学来说是一个非常大的挑战。刚才的复杂场景，挑战一是测试开发的比例非常高，二是迭代频率已经是天级别，三是测试场景极其复杂，复杂性呈指数增长。我们重新审视了阿里妈妈原来的内部方法，以前是保姆式的测试方法，瓶颈集中在QA上。这么多人，这么多项目，不管我们怎么优化，瓶颈就在这里，逼着我们进入智能时代。解决方案是打造协同测试模式，在传统模式的基础上发展快速模式，以智能化的方式打造测试平台，主要面向低风险和算法类项目，高风险项目仍然以负责测试。该平台通过智能化、可视化、产品化的方式，让开发者和算法同学进行自动化测试，由系统决定准入和退出。如果系统通过，则可以随时启动。关于线下测试平台的思路，我们有几大诉求。第一大诉求就是这个平台可以随时测试，开发的同学可以随时随地快速测试。这就需要非常方便的用例编写，让测试思路快速映射到用例上，让系统高效管理用例和测试环境，实现极致的运行效率。整个平台共有三个方向。一是测试极左移，二是成为线下测试的基础设施，三是研发流程重构。基于这些方向，整个测试平台应该做什么？马尔可夫是我们打造的智能离线测试平台。作为一个非常强大的基础设施，本期将介绍它的一些智能技术，如智能回归、用例智能推荐、数据智能推荐、冒烟回归技术、用例扩展、智能排障闭环等。其他如docker基于-based的分布式容器管理、万级用例管理系统、分布式智能任务调度系统本次暂不讨论。智能技术很重要，但如何结合测试场景更重要。功能测试域主要分为三个部分。第一部分是如何写案例，也就是用例生成。二是用例回归，也就是写完用例后快速迭代这些用例。做智能侦查，这三块智能都有体现。先介绍一个概念，就是用例画像。对于测试，护城河和资产是什么？这就是用例。我们提炼、提炼、组合了阿里妈妈上万个用例，最终我们的每一个用例都形??成了自己的画像，包括用例名称、覆盖代码域、业务特征、用例失败归因、相似用例集，也就是说其他用例与它的相似度和相关性如何，以及异常用例的派生集，以及运行的稳定性等。基于整个用例画像，就可以看到全貌用例的概况一目了然，是用户全面感知用例的一种方式。同样，用例画像也是我们实现智能化的重要依据。用例智能推荐的目标很简单，就是希望将传统的标准化用例编写升级为极致体验的用例编写方式。以前最简单的是从测试名开始写，然后写依赖的测试数据，再写发送请求和期望。或者在用例库中复制一个用例数据。所以，传统的方式是直接手工编写，或者照搬之前的旧用例。马尔可夫智能用例推荐方法，我们提供一个智能盒子，用户可以描述自己需要什么样的用例，甚至可以直接复制设计文档，马尔可夫平台可以将你输入的描述一一提取到业务特征中。同样，在整个用例库中，如果有几千个用例库，则对每个用例进行训练，形成一个特征池。这时候可以使用自然语言处理，最后会提出业务特征。通过朴素贝叶斯算法，我们可以得到相似度为TopN的相关用例列表，最终确定选择，快速得到数千个用例中最相似的用例。这样就省去了搜索的过程，也方便了写用例的过程。右图是用例扩展。写完一个正常的用例，我们就需要写一个异常的用例。最基本的过程就是调整参数，改成最大值、边界值、异常值、乱码等。我们训练了一个N-wise特征模型，在整个用例库中训练了一个多因素模型。比如特征有1、2、3、4，我们可以得到这些数据的类型，根据类型得到异常值。我们把整个库中的特征都训练好之后，把所有的离群点和边界值都组合起来，就好办了，我们把一个刚通过智能推荐发现的用例组合变异。如果我们要扩展某个特征，我们从系统中推荐扩展后的组合值，通过最终的叉积，我们可以组合异常用例集，最终由用户选择和筛选。通过这种组合，会碰撞出很多用例，快速完成多个用例的生成。以下是数据智能推荐。在案例级推荐的基础上，可以更精准地推荐测试数据，进一步提升案例成文率。智能推荐提供了一种快速找到用例的方法，但是找到这个用例后，需要修改和编写。数据智能推荐就是做这个的。在写测试数据的时候，基于原来修改用例的方法，如果找不到某个测试数据，我们可能会找到其他用例的测试数据，然后复制修改。Markov平台做的是当你要写测试数据的时候，当你选择的时候，系统已经为你推荐了最合适的测试数据。我们有三种推荐方法。首先是模板推荐，这是一种用户可以自定义定制数据源模板的推荐方式。第二种是最长匹配法。我们对测试数据提出简单的建议。这个方法很简单。我们假设最长的测试数据中包含的信息是最完整的，也是您最可能需要的。第三个是相似用例距离的推荐，它是根据刚才用例的相似度来推荐的。如果这个用例与您当前正在编辑的用例非常相似，那么他们使用的数据很可能就是您所需要的。我们做完这个工作之后，修改测试数据就非常快了。三是智能烟感回流焊技术。这个技术很有意思，也是我们正在做的一个工作。我们希望以另一种方式生成用例。以此方式，我们基于生产流量烟雾进行测试，结合用例智能推荐技术，快速回流到线下用例，从而打通线上线下的闭环。这是什么意思？在传统的测试方式中，我们找到一个用例，开始修改它，然后进行测试。这个冒烟调试是另一种方式，借鉴了阿里妈妈内部算法同学的调试方式。他们会在网上抽烟，并使用在线数据、他们自己的数据和生产流量来监控。如果没有问题，他们将完成工作。我们想知道是否可以为他们提供解决方案。线上做的时候，可以一键回放线上过程，转成线下案例，在线调试后，线下库里自动有案例。向上。这怎么可能？它依赖于相对完整的基础设施。阿里妈妈有很好的内部基础设施，比如环境基础设施。我们可以快速一键获取与生产环境一致的环境。这是环境克隆。我们拿到这个环境之后，就可以根据我们数据工厂提供的流量修改算法，然后进行简单的在线抽烟。烟雾结束后，我们提供线下流量一键转化模式。这里会有两个问题，就是线上线下总是有差距的，数据肯定是不一样的。我们做了一些工作。首要任务是针对一些比较简单的模块，在smoke过程中从日志级别获取整个应用所依赖的测试数据。我们有输入数据，可以将其返回到离线。实际输出有了它，您可以以无间隙的方式转换离线流量。但是你发现这个方法了吗？整个开发代码侵入性很大，必须要依赖开发来嵌入。所以我们采用另一种方式，就是推荐技术和烟雾输入请求。我们会提取部分输入的请求特征，或者输出期望的特征，然后根据用例库中的用例特征，推荐可能需要的用例。推荐之后，修改用例，让系统自动做修改工作，那你一定会根据修改后的用例写用例。然后是智能回归技术。我们开发了用例动态编排算法，将回归效率提高了2-10倍，打破了回归时间随用例数量线性增长的曲线。回归测试就是把用例库中的用例批量运行，但是即使这么简单，它仍然是阻碍我们研发效率的一个重要环节。在传统模式下，由于多种原因，我们只能逐案执行，依赖的数据会出现重启和数据冲突。马尔可夫平台希望在整个用例编排过程中实现最高效的编排，从而使整个回归效率呈指数级增长，最终打破增长曲线。几十个用例返回一次还好，成百上千个用例怎么办？有的同学可能会进行精确的测试，只跑一些代码不影响的用例。另一种方法是并行运行多组环境。这实际上是一种牺牲资源换取时间的方式，因为资源总是有限的。马尔可夫希望通过编排的算法，只要增长曲线被打破，就结束了。如果我们在单环境回归中打破这条曲线，那么做整个多环境回归就会容易很多。多环境是指并行的多个环境。传统的方法非常简单。用例总数与环境数平均分配。马尔可夫方法，因为我们积累了用例时间对回归的影响，可以反向动态分配用例，通过估计回归方差达到全局最优，使各个环境的用例时间尽可能均匀，因为评估一次回归是否完成，回归过程是最后一个环境，如何让时间统一，使得每组回归的时间都差不多，可以达到全局最优。我们首先是在整个回归算法上解决它，其次是在环境上解决它。我们来看看动态编排算法。算法的核心在于测试数据。如果一次准备很多数据，整个过程会非常快，节省很多时间。如果用例没有任何数据依赖性，则它们可以并行运行。我们可以看右图，这是一条代表数据冗余率的曲线。我们可以看到，随着用例数量的增加，曲线的运行时间呈非指数增长。当冗余为零时，是非冗余的极端。在这种情况下，需要为每个用例准备一次数据，数据准备的时间消耗很大。我们这里采用的方法是根据最大的公共数据集递归创建二叉用例树。建好这棵树之后，第二步就是聚合这些测试数据。我们使用层次聚类的方法对不同的文本数据进行聚合，减少数据准备时间。第三步，建立一个基于深度优先的快速执行树，整个执行过程将成为串行中并行的高效方法。这是我们实验室的数据。我们将整个过程分为四个阶段。第一是数据准备阶段，第二是分层数据准备阶段，第三是快速执行阶段，第四是失败重试阶段。这里有600多条数据，冗余达到了500条，可以节省黑时间，因为数据准备好了，可以快速执行。实验室数据准备阶段效率提升500%以上。由于并行，节省了大约50%的时间。这是故障排除领域。用例失败后如何排查？这个调查很有意思。我们基于用例画像的记忆构建了这个调查系统。有两个目标。一是将故障排查的效率从分钟提高到秒，二是为下一次排查积累排查经验。.传统故障排查系统执行左半环，即重放失败的流量，然后整个系统在执行过程中收集链路数据。比如我们在执行过程中收集日志，trunk是什么状态，测试环境是否正常启动，或者一些基本的配置检查等等，我们就这样进行下去，最后系统给出了失败的原因，这是一种很正常的故障排除方式，即系统自检。在此之上，我们实现了另一个环，即右半环，它添加了一个用户反馈系统。这是什么意思？左半环是一种非常基本的自我检查方法。没有办法对复杂的场景进行故障排除。整个故障排除方法可以由用户手动检查，将排除故障的故障信息输入系统，系统进行检查。记录，最后提取整个检查的故障归因特征，并与历史故障原因进行比较。每次巡检时都会介绍系统自检的原因和历史上可能出现过的人工巡检的原因。我们把整个智能检测反馈和整个智能回归联系起来，形成一个回归反馈的闭环。简单来说就是可以快速进行一次回归，系统会自动触发自动调查，反馈给用户。运行一次，用户就能知道原因，达到最高效的反馈速度。再说说测试的左移。智能化的场景解决了一些高效率，或者是极简的方式让开发去做测试，但是提升效率还是其中一个环节。但是，要想提高整个研发流程的效率，就必须向左移动，从线和面解决研发效率的问题。首先是可编程流水线技术。这个过程原本需要5天。我们做过UT自动化一站式服务，功能测试，功能AB，性能AB。我们搭建了基础设施，在测试代码的时候，我们可以一键提交整个流程，整个流程可以改进到4小时以内。如果改动量不影响老功能，只要测试通过了四个环节，我们相信覆盖率可以接近100%。FunctionalA/BTest，相比线上环境，整个过程需要强大的基础设施。需要的核心能力包括环境克隆、基于数据工厂的流量精准抽取和转化、高发对比流量执行等。同样，性能A/BTest也是基于同样的思路。对性能的追求，比如这个版本上线后的稳定性，CPU的状态如何，内存如何？如果能追求最短的反馈时效，是可以做到的。这个版本的性能和测试报告都非常依赖强大的基础设施。三是CLI触发操作??，基于git的工作方式，使用命令行修改代码，可以使用马尔可夫git方式无缝嵌入到研发模式中。上述能力共同构成了阿里妈妈极左的过程。谢谢你们！
