利用流量保障搜索质量的实践

见贤思齐

这是第359篇不掺水的，想要了解更多，请戳下方卡片关注我们吧～一 背景政采云的搜索服务是基于 Elasticsearch 的在线分布式搜索，为内部业务提供结构化和非结构化数据的多条件检索，支撑政采云PC端、APP端、小程序端的搜索能力。搜索以中间件形式提供服务，由于无法感知外部业务在哪用、怎么用，导致搜索测试一直沿用人工梳理场景，接口测试覆盖场景的方式。可通过人工去做，一是效率不高，二是场景覆盖不全。所以搜索的质量工作一直被如下问题所困扰：搜索对外提供了 171 个检索条件，不同条件的组合，会流转到不同代码分支。一旦改动公共层代码，不确定回归场景是否全面？若回归场景覆盖不全，如何自动识别未覆盖的场景？识别到未覆盖场景，如何自动转化成场景用例？转成场景用例，如何快速实现自动化？基于上述问题，实践了一套基于流量的质量保障方案。二 搜索质量保障方案2.1 整体保障方案目标：借助流量区分活跃和非活跃代码，针对活跃代码，使用场景计算，自动识别和构建场景用例。针对非活跃代码，通过人工覆盖，补齐场景用例。接下来分别介绍：活跃代码保障策略，非活跃代码保障策略，自动回归策略。2.2 活跃代码保障2.2.1 保障策略核心思想：借鉴流量录制回放的思路，通过采集 Dubbo 调用日志，清洗出场景数据，针对场景数据进行计算，生成场景用例。策略包含 3 个节点：日志采集节点外部应用通过 Dubbo 调用搜索，搜索会输出一条日志，日志内容包含入参等信息。数据清洗节点此节点会根据指定格式清洗 Dubbo 日志，生成场景数据。场景计算节点此节点是整个策略中最核心的节点，主要包含 3 块功能：1）入参模板化；2）生成模板指纹；3）根据指纹对流量去重。接下来详解实现方式。2.2.2 场景计算入参模板化外部应用传给搜索的入参是一个 JSON（图1到图2），搜索会把 JSON 转化成 ES 的查询语句（图2到图3），只要捕获业务传入多少种入参（图2），就能统计出有多少种搜索场景。入参模板化方式有2种 ：按字段方式生成模板//仅供说明，非真实业务字段搜索条件：{"bussinessScope":"浙江","status":true,"keywords":"打印机"}生成的模板：{"bussinessScope":"@","status","keywords":"@"}上述示例对 bussinessScope、status、keywords 三个字段进行限定查询，类似 MySQL 的 where bussinessScope='浙江' and status=true and keywords='打印机'。只要查询字段相同，无论值怎么变，对搜索来说都是一类查询。按字段方式生成模板，只需替换掉 value，保留 JSON 骨架即可。按字段和值的方式生成模板//仅供说明，非真实业务字段如上图所示：查询已上架的黑色数据线，搜索条件：{"attribute":"颜色:黑色","status":true,"keywords":"数据线"}生成的模板：{"attribute":"颜色:黑色","status","keywords":"@"}上述示例对 attribute、status、keywords 字段进行限定查询，还需根据 attribute 的值进行数据匹配。针对有业务含义的搜索条件，需要保留对应的 value 值。生成具有业务含义的 JSON 骨架。生成模板指纹模板生成后，会根据模板算 MD5，生成唯一指纹。为什么要生成唯一指纹？因为搜索日均调用百万+，里面包含了大量重复查询。为了快速识别出重复查询，本方案会对每一个模板生成指纹，只要指纹相同，就属于一类查询。//仅供说明，非真实业务字段描述：查询已上架的打印机搜索条件：{"status":true,"keywords":"打印机"}生成的模板：{"status","keywords":"@"}模板指纹：D8AD32393C65D62C8658A9D699A8C190去重采集到新流量，生成新指纹，新指纹与已有指纹进行匹配，若相同则跳过。通过指纹匹配，相同指纹的搜索会被归为一类（如下图示例）。这样既能快速发现新场景，又能识别出重复流量。//仅供说明，非真实业务字段描述：查询已上架的打印机搜索条件1：{"status":true,"keywords":"打印机"}生成的模板1：{"status","keywords":"@"}模板指纹1：D8AD32393C65D62C8658A9D699A8C190////////////////////////////////////////////描述：查询已上架的三星手机搜索条件2：{"status":true,"keywords":"三星手机"}生成的模板2：{"status","keywords":"@"}模板指纹2：D8AD32393C65D62C8658A9D699A8C190模板1和模板2生成的指纹是一致的，通过对每一个模板的指纹进行对比，就能识别出相同搜索条件。流量计算产出的结果基于搜索现有流量，通过场景计算，自动生成线上P1场景用例 618 条，P2场景用例 516 条，P3场景用例 58 条，P4场景用例 161 条，总计 1353 条。2.3 非活跃代码保障2.3.1 保障策略流量覆盖不到的代码是非活跃代码，保障策略采用人工覆盖。搜索的非活跃代码主要有：1）开关；2）异常场景；3）未使用的方法。分别通过如下方式保障：开关，打开和关闭开关，人工调用接口，形成用例。异常场景，通过阅读代码，人工构造参数，形成用例。2.4 自动回归通过流量和人工方式构建了场景用例，就得让用例产生价值。产生价值的方式是让用例自动“活”起来。搜索自动回归的流程如下，重点在：「预期结果池」和「校验规则」的建设。2.4.1 预期结果池目的：同一查询条件，一定命中相同预期结果优化前：固定关键字即时搜索。优化后：测试用例首次执行的结果，自动复制到预期结果池，非首次执行将查询预期结果池。为什么要建立预期结果池？原因1：线上同一个搜索条件，间隔一段时间后再次搜索，存在返回结果不相同的情况。造成该情况的原因：用户操作或定时任务导致状态变更。如：A条件，第一次搜索返回 3 个商品 A、B、C，一段时间后，商品 B 下架。相同条件二次搜索返回 A、C、D。动态的预期结果不能很好的做校验，为了消除变动带来的影响，所以建立预期结果池。原因2：线上索引数据 1亿+，若每条用例执行都扫 1亿+的数据，易产生慢SQL。预期结果池是独立索引，数据量几十万，相比查线上索引，速度快且不易产生慢SQL。预期结果池里数据的新增和失效新增数据：用例库新增一条场景用例，首次执行会查询线上索引，同时把搜索结果复制到预期结果池。当用例第二次查询，自动路由到预期结果池。失效数据：逻辑变更测试通过，删除原有数据，重新走新增数据流程。2.4.2 校验规则目的：根据使用场景，建立不同的校验规则。优化前：自动化脚本里硬编码校验点。优化后：脚本与用例、校验规则解耦，根据使用场景，建立不同的校验规则。当前自动化落地在2个场景：接口测试、重构测试，分别建立了2套校验规则。接口测试规则校验重点：准确性。分为：总数准确和字段准确。总数准确：结合预期结果池，对比预期总数与实际总数。用例库新增一条场景用例，首次执行会查询线上索引，记录搜索结果总数（预期结果），同时把搜索结果复制到预期结果池。当用例第二次执行，自动路由到预期结果池。若二次搜索结果总数不一致，说明代码逻辑存在问题。字段准确：按字段维度进行校验。比如：校验区域字段，校验内容：「区域=浙江」。会校验每一个返回结果的区域字段是否等于浙江，或者包含浙江。重构测试规则校验重点：全量对比返回结果和结果顺序。即同一搜索条件，新老接口返回值和返回顺序必须强一致。结果：沉淀2套场景校验规则，总计 37 个。其中接口测试规则 36 个（8个P1场景规则，19个P2场景规则，8个P3场景规则，1个P4场景规则），重构测试规则1个。三 保障方案在项目中的落地23年搜索代码将整体重构，要求测试人员对全场景进行保障。上半年分别进行了2次重构工作，内容如下：改动点以业务Id 作为分表键，数据分表存储。4个P2服务重构。风险点路由逻辑。路由出错，将导致搜索结果为空。业务逻辑。场景覆盖不全，将导致搜索结果不准确。质量保障的挑战全场景覆盖，人工回归成本高。服务重构前后，同一搜索条件，返回结果和结果顺序必须强一致，采用人工对比既痛苦又容易漏测。保障方案场景覆盖：采集 Dubbo 调用日志，清洗出场景数据，针对场景数据进行场景计算，最终生成场景用例。用例执行：自动执行用例，自动校验返回结果。结果预发环境，自动构建基础服务测试用例 4128 条，协议服务测试用例 6322 条，全量服务测试用例 4174条。自动化发现Bug：7例。剖析其中 1 例Bug，阐述人工测试，会产生的漏测点。该Bug发现于搜索重构项目，使用重构校验规则（全量对比返回结果，以及结果顺序）。Bug描述：搜索结果顺序不一致，导致对比失败Bug根因：老索引的id字段是 long 类型（左图），新索引的id字段是 keyword 类型（右图），字段类型变更，引发字段排序变化易漏测点：在海量数据对比时，容易忽视顺序变化引发的问题，继而发生漏测。因为新老接口都返回相同数据，仅商品位置发生了变化。业务影响：上游业务搜索出商品，并按商品id排序，然后放到定时任务里执行。当商品位置变化，会造成已执行过的商品被重复执行，导致任务报错。四 未来规划线下环境使用流量录制回放系统。探索录制回放（mock形式）与本方案（真实调用）的相互结合。探索基于代码覆盖率的场景覆盖。看完两件事如果你觉得这篇内容对你挺有启发，我想邀请你帮我两件小事1.点个「在看」，让更多人也能看到这篇内容（点了「在看」，bug -1 ）2.关注公众号「政采云技术」，持续为你推送精选好文招贤纳士政采云技术团队（Zero），Base 杭州，一个富有激情和技术匠心精神的成长型团队。规模 500 人左右，在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com