2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开。以“AI+未来”为主题，汇聚国内外测试领域知名专家学者、领先企业决策者、高级技术管理者、媒体从业者等，共同探讨高端云测试技术并帮助测试从业者了解最前沿的行业趋势，以及最新的行业实践。会上，网易传媒测试总监张涛做了主旨演讲《网易新闻DevOps实践及在AI测试中的应用》。张涛分享了网易新闻过去一年在DevOps方面的实践，并指出，“DevOps落地的过程也是测试价值提升的过程，从关注服务可用性到系统可测性和稳定性，发挥核心作用在测试和运维的全过程中。”以下为张涛演讲实录：与大家分享网易新闻这一年来在DevOps方面的实践与落地，希望能给大家一些好的思路。在正式分享之前，让我简单介绍一下自己。我目前在网易新闻负责整个测试的质量保证。来网易新闻之前，我在百度工作了七八年左右，主要负责手机的质量保证。在首白工作期间，我在CICD和DevOps上做了很多实践。近两年，一些大公司一直在做各种DevOps的尝试和落地，希望能够打通串联、研发、运维、测试等环节，更好地提升迭代效率。今天重点结合网易新闻的实践经验和移动100期间积累的经验与大家分享。首先是通过DevOps提高迭代效率的思路和方法。第二，在DevOps的范畴里，如何凸显测试的价值。前两部分是关于如何在落地实践过程中提升测试价值的。我会稍微谈谈价值的提升。第三，机器学习测试和DevOps。今年我们在这部分做了很多尝试，关于如何实现DevOps，尤其是机器学习相关的部分。上午还听了艾老师的分享。他谈到了AI测试的思路和方法。有些内容和我说的差不多，比如如何测试算法、模型和特征。当然，艾老师分享的重点还是在测试方法上。我们的重点是在测试的基础上提高DevOps和机器学习的测试效率。我们先来看第一部分，常规迭代效率的提升。常规的测试方式，大版本迭代有几种方式，先收集需求，然后排程，开发测试，最后发布最终版本，周期比较长。如何让这个迭代更有效率？最近一两年，我们的业务迭代速度越来越快，研发和测试的压力都越来越大。如何快速交付需求，快速上线，尤其是研发测试之后，到测试阶段其实是压力最大的阶段。如何在迭代过程中提高测试效率，尽量避免测试瓶颈，也是我们一直在探索的方向。提高迭代效率的基础任务有很多。我们在基础工作上做了大量的长期建设，比如基础的自动化工作，基础的CI工作。只有完成这些基础自动化能力的积累，才能提升整体的迭代效率。传统版本的迭代一般类似于train模型，集中需求收集、review、集中研发、集中测试，类似于我们平时讲的模型，这是整个版本迭代的模型。这里最大的问题就是整个需求特别集中。如果在迭代过程中有需求变更或插入，很难及时响应。此外，产品的交货期会特别长。另一个大问题是研发环节。长期以来，许多功能正在同步开发。最终环节非常容易出错，整个代码的最终值非常耗时。这是train模式中一个明显的问题。如何优化这种模式是我们一直在探索的问题。之前在汉百，一直在尝试从火车模式转为班车模式。穿梭模式改变了集中需求收集和集中研发测试的方式。可以随时提交、审查、开发和测试新的需求。当然，这并不是每天任何时候都在发生，而是有一个相对固定的周期，比如每周一次需求的收集和发布，每周对某些需求的测试和交付。这个需要根据业务的复杂程度来定。根据团队的构成来决定设置什么样的循环比较合理。我们在手百做了很多测试。通常，传统的方法是一个月到一个半月一个版本。当我们开始构建火车模式时，我们做得更加积极。我们想将其更改为两周。涉及的团队非常庞大。Zhou的模型，尤其是对于QA模型挑战非常大。因为每次发布都需要回归、灰度发布、验证过程，QA的消耗非常大。为了应对这种模式，专门成立了发布测试小组。该小组不会参与常规的功能测试，而是专注于每周发布测试的工作。这需要大量的人力，并且由一个独立的人来完成，成本非常高。后来做了一些调整，网易新闻也固定了三周迭代模式。评价时间-样本周期是否合理，我们通常会从几个维度看数据。一是整个研发交付周期，从需求发布到开发阶段。在这个固定的时间内，评估需要一个月。如果这个月有两个版本，或者1.5版本，那么评估一下固定时间内研发产出是多少，真正投入研发的人有哪些，因为研发是除了版本迭代投入。还有很多其他的工作，比如requirementreview，bug修复，requirementdevelopment工作中真正的R&D投入占多少。这是我们需要评估的一个维度。另一个维度是实际产出方面。当然，需要在固定时间内交货的数量不能只看数量，因为需求的大小不同，耗时也不同。一般来说，评估是耗时的。一个需求消耗研发人力和测试人力，来评估在固定的时间内能产出多少需求。在模式切换的过程中，我们通常会遇到很多问题，很多我们依赖的工具和环境都非常碎片化。碎片化会导致无法提高效率。这样的问题会让好的想法实施起来非常痛苦。这是我们以前的业务形式，分支管理也是一个独立的平台，在线配置通常是一套独立的运维管理。测试自动化平台和工具全部由测试团队负责。每个平台都是单独维护和管理的，很难在整个迭代过程中非常顺利的打通。这个问题极大地影响了整体效率的提升。我们如何做这项工作？该行业也有先进的经验。百度之前也搭建过类似的平台。在阿里和腾讯，几大厂商都有类似的平台来开发提高效率的平台，比如阿里的云效率平台和腾讯的TAP。平台。在网易，我们与项目管理团队一起构建了OverMind平台。它最大的作用就是把需求到研发、上线、测试各个环节中常用的一些平台和工具串联起来。.比如需求管理，研发用到的分支管理工具，测试工具，线上平台都是串联起来的。我们的测试还将iTestin提供的自动化功能集成到我们的整个过程中。我将重点介绍测试部分，包括客户端测试、后台测试和推荐测试。我们每个人都有几个平台来支持测试工作，提高效率。这里涉及到客户端的自动化部分，网易内部有一个易于测试的平台，现在也在使用iTestin来自动化客户端的UI功能。在后台自动化方面，网易打造了一个名为“GoAPI”的平台，统一管理后台所有界面自动化案例，实现统一运行。以前大家写接口和写case分别管理和维护，不统一，写case的规范也不统一。这个平台统一管理之后，包括后台在内的性能测试也是在一个统一的平台上进行的。测试环节通过多个平台串联，充分发挥自动化能力。这是在测试的每个阶段完成的工作。基于平台的能力，我们更好的实现和实现了TDD的效果，突破了以往测试开发的局限。TDD能不能做好，关键在于接口契约。借助GoAPI平台，接口契约可以统一标准化。现在研发每写一个接口，接口的所有参数，每个接口都要在平台上定义好。参数的取值范围。由于接口契约，可以在实际编写代码之前编写一个自动化案例。这是最根本的变化。如此一来，整个测试的效率也得到了显着提升。粗略估计一下，接口功能测试的环节大概可以节省三分之一的人力。还有一个环节在测试的时候遇到了很多问题，非常头疼，就是环境管理和建设。每个人在测试的时候都会搭建环境，搭建环境的脚本和方法也不一样，成本也比较高。每次更新代码都需要修改环境脚本，环境搭建比较耗时。而且整个准备工作非常繁琐。一个人只能用他自己的环境，别人要用你的环境会来找你，你帮他建环境。这是一个非常耗时且麻烦的过程。基于OverMind平台的管理环境，实现自动化环境构建，一键自动化实现环境创建全过程。当然这非常依赖研发的配合，因为很多环境的搭建，一些参数，尤其是环境中的准备工作，都和研发的代码有很大的关系。我们要配合研发做很多联动和修改。基本上每个业务模块都必须和研发一起修改配置，才能实现最终的自动化。这是实现环境自动化后的效果。当一个业务模块发生变化时，只需要更新该业务模块的环境即可。我们有一个集成的回归环境。在整个大环境中，如果有服务调用，我们可以调用回归环境依赖的其他服务。如果两个业务模块都发生了变化，需要对变化的模块进行调整，就需要通过回归环境同步另一个环境依赖环境的代码。我们在OverMind平台上实现了环境管理，各个模块环境的部署状态可以在这里直观的展示出来。最终，环境建设整体效率提升了240倍。以前搭建环境需要几个小时，通常情况下两三个小时。如果遇到非常复杂的业务，这个过程可能需要半天时间。现在我们在OverMind上有了这么一套环境管理的工具，基本上分分钟就可以搭建好环境了。此外，环境的数量也增加了很多。过去，您只能拥有自己的一套环境。现在你可以随时快速搭建任何你想使用的环境。另外，我们在OverMind平台打通了CI的全链路，通过它进行CI触发和函数调用，所有的自动化能力都集成在pipeline中。除了代码的CI，还有需求的CI，在我们的平台上可以很直观的展现出来。上面提到的部分仍然侧重于测试的可测试性。从DevOps这个大范畴来看，重点是测试的左移，也就是如何从测试本身的范围转向研发和需求。随着更多的扩展，更加关注可测试性和需求的合理性。除了刚才提到的自动化工具和平台工具，我们在日常工作中也会投入一些工作，比如单元测试和CodeReview，这需要我们跟研发、产品、有非常紧密的契合。上面讲的就是从需求的起源，到研发，再到测试，如何提高迭代效率。以下部分是关于产品或版本发布后如何做更多的质量保证。这部分更注重服务的稳定性。在服务稳定性方面，我们关注几个方面，一个是服务稳定性；二是全链路监控，更多的是将客户端、服务端、全监控串联起来；三、故障预防和一些演练工作，真正发现系统中的隐患。前面我们提到了如何提升测试的价值，如何在测试左方向从需求到研发再到测试提高效率。在测试向右移动的部分，更注重测试的稳定性和测试的风险防范。在这方面，QA也可以发挥很多作用。维修合作也比较多。下面分别谈谈这两方面的工作。一是全链路监控。我们已经这样做了一段时间。大家对于全链路监控的概念都有一个基本的了解。如何梳理服务的依赖关系，使链式路径跟踪串联起来整个请求的链接。另外还有链接调用的性能，每次请求的性能如何，一些性能上的瓶颈可以很快找到。这就是全链路监控的整体思路。核心是监控链路。最重要的是要有一个监控ID，比如在网易新闻里刷新一次，或者点击某个新闻，点击操作会有一个请求，在这个客户端上会发送到服务器。发送请求时，必须自动生成ID并带入服务端，服务端再将ID带入最终请求服务的最终节点。服务器端的调用涉及到很多调用层次，每个调用层次都有一个核心点，就是SpanID。可以记录一个服务和另一个服务请求的关系，最后整个链路的整个调用过程都会生成一个记录，这样在追溯问题的时候，可以快速的找出一个请求最终调用了哪些服务，而中间哪里出了问题，这就是全链路监控的思路。故障演练的核心重点是两个层面，一个是服务依赖，以及如何把强依赖变成弱依赖。二是将无损降级转化为有损降级。你可以看到右边的两张图片。比如网易新闻最常用的帖子和评论。我们曾经是第一个调用的方法。后来我们把依赖关系隔离出来，转化为右边调用的关系。强依赖变成弱依赖。比如后台服务和发帖排行榜出现问题，但不会影响发帖流程。故障演练比较关心的有几种故障类型。一是硬件层面的问题，二是更关注中间件，比如数据库问题、缓存问题、服务依赖，这些都有自己内部的服务依赖，调用第三方服务会有一定的依赖性。自己应用部分，着重介绍一些现成的情况，也就是常规关注的故障类型。故障演练的方法主要有几个方面。首先，要有数据积累。数据积累后如何定义故障规则和故障注入，相当于一个故障案例，和写常规案例差不多。最后怎么办查看结果，看是否有逾期告警。现在故障演练逐渐平台化。平台化需要大量的基础积累、数据和规则。如果没有平台化，就很难实现平台化。我研究了一段时间，发现了几个典型的问题。一是数据库。数据库和缓存都有很多问题。另一方面是服务依赖的问题，就是刚才说的对自己服务的依赖，还有对第三方服务的依赖，还有硬件的问题。第三部分讲了我们的一些测试方法，结合DevOps提高效率。机器学习测试实际上类似于传统的工程测试。在线工程类似于我们常规的后台测试方法，但是模型训练的一部分与常规测试方法不同。艾老师这部分也介绍了很多，关于考试基础的覆盖范围我就不多说了。我们在线服务的测试重点关注服务的稳定性，模型部分的测试重点关注特征模型的准确性。我们常规的测试类别，包括特性的一致性，是我们比较关注的。如何验证特征的一致性实际上是一个非常复杂和庞大的工作。我们在手百的时候在这方面做了很多投入，网易新闻也在这方面做了一段时间。另外，在模型训练的部分，最重要的是如何验证模型的有效性和合理性。评估模型的合理性。此外，估计部分取决于正确性和分布。下面简单介绍一下我们模型训练的全过程，从所有在线用户日志行为开始。我们拿到这些日志之后，我们做数据处理，特征计算，然后做模型训练，在线预估。这就是整个模型训练过程。在这个过程中，最核心的两个部分，当然就是日志采集和数据处理部分，还是照常做业务测试和后台服务，测试方式也差不多。主要区别在于功能和模型部分。如何验证特征的有效性和模型的有效性？这其实是核心。另外，如何配合研发，让这部分工作更有效率。我之前遇到了一个大问题。一个模型从训练上线到上线需要很长时间。很长一段时间需要一个星期。如果你去传统行业，新模式上线的时间会更长，半个月，甚至在一个月内，如何提高模型训练的效率，其实是我们与研发合作的一个机器学习服务平台。这里的核心工作是通过这个平台可视化展示很多研发日常的线下工作，比如需要的日志，素材，所有特征的结果，模型训练结果，以及在这个平台上查询日志的整体分布，有什么材料可用，模型更新都可以在这个平台上快速自动化。我们搭建这个平台的主要目的是让特征训练和模型训练的工作平台化、服务化，这也类似于之前提高迭代效率的方法。通过OverMind平台，整个客户端和服务后台的所有测试都是平台化、服务化的。当然机器学习涉及的研发测试和产品比较少，类似需求管理的部分不会涉及太多。这是我们的效果之一。在平台上，整个特征工程的训练结果，以及所有的配置修改，都是面向服务的。下面是目前正在使用的功能，以及这些功能的状态是否在线，什么时候上线的？如果有问题，需要在这里做一些准备和修改，然后再做线上操作。它可以一次自动完成。模型也是如此。该模型的实验和推出是相似的。我们展示了整个模型训练的效果，它所依赖的一些特征，以及特征之间的关系。您可以在平台上进行修改。并开始直播。协助研发，有效提升整个模型的训练效果和周期。今天就这些，谢谢。
