作者|刘道伟指导风险驱动交付是百度实用智能测试——感知智能阶段一个非常重要的研究方向。风险驱动的交付源于三种当前情况：1.并非所有项目都有风险。80%以上的项目没有相关的bug和线上问题。2.并不是所有的测试任务都能揭示错误，无效的质量行为（发现bug的质量行为/所有质量行为）的比例非常高。3、测试人员也有误判的可能，漏测总是存在的。通过以上三个现状可以看出，如果有一种方法可以接近：检测该检测的项目，做该做的质量行为，准确评估风险，将对检测有很大的帮助有效性和召回率。接下来，我们将继续发布三篇文章，揭秘百度在风险驱动交付实践中的冰山一角：1、百度搜索业务交付无人值守实践与探索：从具体业务实践的角度，引入风险评估无人值守交付领域的关键作用。2、AI技术在基于风险的测试模式变革中的应用：从整个测试流程的角度，介绍风险思维+AI技术在各个环节支持的各种应用场景。3.质量评估模型助力提升风险决策水平：从思路、解决方案、模型等角度介绍质量度模型的实现与挑战。本文先介绍第一篇：百度搜索业务投放无人值守实践与探索。01介绍中提到了无人值守配送的概念。大多数人应该不熟悉它。出现以下问题：什么是无人值守配送？如何实现无人值守配送？无人值守送货有什么好处？本文将从以上几个方面入手，详细介绍百度搜索业务在无人值守方面的一些探索和实践。02无人值守的由来在介绍无人值守之前，可以先了解一下交付模式的发展过程，如下图所示，随着工程能力的不断发展，交付过程中的测试逐渐从纯人工测试转变为半自动测试。自动化测试或自动化测试。同时，互联网行业的敏捷开发模式不断发展，持续集成也在进行。通过将自动化测试工具集成到流水线中，质量和效率工作逐渐左移。大部分需求研发人员可以通过流水线完成测试和上线工作。我们称这类研发人员不再需要通过测试人员的人工测试，而是使用流水线完成整个测试过程，称为研发独立测试。在搜索业务中，DevOps成为最重要的交付方式，部分业务需要独立测试。比例达到90%以上。理想情况下，既然大部分需求都已经独立测试过了，那么整个交付过程应该不需要测试人员花费人力，但理想很丰满，现实却很骨感。下图是测试人员在独立测试模式下的日常工作。可以看出，在整个过程中，测试人员的工作量还是比较大的：1）研发人员在流水线执行测试失败，需要测试人员排查和修复任务稳定性。问题及定位是否与代码相关，与研发反复沟通；2）R&Dpipeline完成后，需要测试人员确认R&D独立测试报告，分析需求风险，判断是否可访问；3）在交付过程中，有很多这个环节需要研发人员和测试人员进行沟通和手动操作，比如上报需求、拉分支、发布版本等。能否有技术手段，用机器代替测试人员在交付过程中的劳动密集型工作？这就是我们今天要介绍的无人值守起点。03无人值守解决方案在目前的交付过程中，主要有以下几个环节对测试人员的依赖程度比较高：决策靠人：哪些测试任务需要在CI代码静态配置或完全由人工决策决定后执行。流程靠人：交付每个环节的流程都依赖于研发或测试人员，沟通交互成本高。结论靠人：流水线没有风险分析能力，测试任务没有0/1结论，进出的风险判断靠个人经验。因此，要实现无人值守，就必须通过技术手段解决这三个依赖问题。一句话，“通过智能执行和风险评估能力，实现故障智能运维、流程自动化、风险智能揭示，整个交付过程无需测试，无需人工干预”。要真正实现这一目标，首先要具备三个必要条件：完备的测试能力、稳定的施工能力、精准的评估能力。在这些能力的基础上，构建数据采集、风险识别、风险控制、风险决策等智能化机制，最终实现全流程无人化操作。限于篇幅，本文首先重点介绍三个依赖的基本能力。3.1完备的测试能力完善的测试能力是实现无人值守的基础，要求流水线的测试任务全面有效。如何理解全面？不同类型的业务对测试任务有不同的要求。全面性是指具备相应业务类型所需的各种测试任务。以百度的工程能力地图服务器需求为例，综合测试能力需要下图所示的服务终端各环节的测试任务，可以根据业务实际需要做一些改动。在综合测试能力的基础上，更加有效。很多时候，虽然流水线有某类测试任务，但测试任务能否拦截问题，取决于测试任务的风险暴露能力，或者取决于测试人员对测试报告的理解。分析和解释能力。以搜索业务的DIFF测试类型为例。DIFF测试是对基线版本和测试版本发送相同的数据，比较返回数据的字段差异，判断测试版本是否符合预期。已经是现在的接口测试和大数据测试了。更常见的方式。但是，DIFF测试任务的有效性存在问题。测试任务产生差异结果，这些结果可能由于“噪音”、预期的代码更改或错误导致的意外结果而不稳定。这种风险判断完全依赖于研发和测试的人工分析。因此，为了提高DIFF测试的有效性，需要解决噪声干扰的随机diff问题和diff结果的0/1分析问题。通过后端mock、环境数据一致性、随机diff智能识别过滤策略等机制解决随机diff的消除。不详细讨论，我们将重点放在diff测试的拟人化分析能力上。拟人化分析是一种自动化过程，它转变了手动分析测试结果的能力。因此，要实现拟人化分析，首先要知道人们看到diff测试结果时是如何判断的。经过实际研究发现，研发和测试人员在分析diff测试结果时，首先检查修改的代码是否与输出的diff结果字段相关联，如果相关性比较大，则认为是代码导致的，然后分析这些字段的业务影响在需求中是否是预期的，以及影响面的大小，如果是预期的影响，风险可控，就可以认为是通过了。因此，拟人化分析也从以下两个方面进行判断：1）根据白盒数据+模型+业务逻辑分析字段，是否符合预期；2）根据数据分析结合业务，评估现场影响风险。最重要的一点是如何将白盒数据与结果关联起来。目前主要采用两种方法。一是相对常规的业务知识库沉淀。通过业务知识的梳理和沉淀，将开发测试个人经验转化为可以自动判断的规则。例如，某些功能的更改可能会导致某些类型的差异。优点是与业务密切相关，准确率较高。缺点是还是过于依赖各种业务人员的梳理，效率低下，所以我们探索了第二种方法。我们通过任务执行的历史数据，分析代码变更与字段变更的关系，离线构建代码与字段的关联模型，并利用该模型判断线上阶段字段是否发生变更。是代码造成的，结合领域的业务风险判断，最终给出了diff测试的结论。通过以上方法，可以大大提高DIFF测试的有效性，也可以降低DIFF测试人工分析的成本。在性能测试等其他场景也开展了类似的工作，即通过技术手段提高测试任务的风险揭示能力和结果。分析能力，从而提高测试任务的有效性。3.2稳定的构建能力如果说完备的测试能力是无人值守实施的基础，那么稳定的构建能力则是无人值守实施的保障。如果管线施工经常出现故障，会导致测试人员在独立测试过程中不断定位修复故障问题，并与研发人员反复沟通。因此，稳定的结构非常重要。如何打造稳定的施工能力？其实可以参考在线服务的稳定性建设。在线服务通常有各种稳定性和监控建设，用于研发、运维。稳定性能达到9以上，但线下服务的稳定性通常只有几百。百分之八九十，为什么不用线上稳定性建设标准来建设线下测试能力呢？因此，我们利用线上运维标准，全面提升线下构建的稳定性，主要包括以下主要工作：基础依赖治理：管道的稳定离不开基础依赖的稳定。这些依赖包括机器、实例、测试代码、测试数据、第三方服务等。因此，要提高稳定性，首先要对这些依赖进行管理。比如机器的统一管理，测试代码和数据在线代码的标准化管理，第三方服务的SLA保障，容灾措施等。全链路稳定保障：全链路，即预防、发现、定位、恢复、闭环，每个环节都有相应的稳定性能力。比如在预防环节，对施工所需的环境和数据进行监控。遗漏issue等问题会提前报告，避免在构建测试任务时才发现故障；定位环节对错误码进行了标准化处理，并建立了错误码自动定位机制。如果定位问题可以自动恢复，自愈策略会自动触发恢复方法，减少故障。人为干预。施工数字化：通过施工数据的数字化，实现施工的稳定性测量、描述和建议。3.1精准评估能力有完备的测试能力和稳定的构建能力，无人值守交付还有最后一个环节需要解决：如何判断准入和退出的风险？传统流程中，风险通常通过人工审核测试报告来控制，不仅耗费人力成本，而且判断的准确性完全取决于个人经验。刚接触研发和测试的同学，经常会出现判断失误，漏测的情况。如何实现自动风险评估能力？我们采用了基于质量度模型和规则组合的方法来构建评价能力。质量度模型是将可能影响风险的数据抽象成特征，利用人工标注的历史数据来训练模型。在进入和退出阶段，通过调用质量模型的结果给出风险评分，并结合基于业务的规则判断综合判断风险。如果风险低，可以自动接纳，无需人工分析。如果风险高，则引入人工。通常特征包括交付过程中的各种数据，如代码白盒数据、研发人员画像、研发过程数据、测试任务结果、覆盖率等，如下图所示，通过特征抽象的过程，模型训练和模型评估。实现准确的评价能力，评价能力的准确性取决于质量模型选择特征的丰富程度和人工标注数据的准确性。04无人值守的收益通过测试能力的持续建设，搜索业务90%以上的需求可以通过研发自主测试完成，大大提升了测试吞吐能力。在独立测试的基础上，通过上述无人值守工作，需求无人值守比例达到40%以上，让更多的测试人员从日常的交付工作中释放人力，投入到其他更高价值的工作中，交付成本单一需求进一步减少。--结尾--
