共计 6649 个字符，预计需要花费 17 分钟才能阅读完成。
一分钟精髓速览
去哪儿公布的数据显示，在过来一年中，其公布故障率始终保持在 4‰ 以下并一直升高。作为一家出行游览服务平台，去哪儿网如何在简单的业务场景下，仍能放弃如此低的故障率？其中功能测试左移功不可没。
本文介绍了去哪儿网通过自动化测试、智能举荐、本地化等平台的建设，在低成本、低故障率、高效率方面的显著功效，并具体介绍了各阶段的实际重难点。
作者介绍
去哪儿网测试开发专家——鲁国宁
TakinTalks 社区专家团成员。2019 年退出去哪儿网，负责测试流程的治理和测试工具建设。主导 / 参加建设的平台有自动化测试、全链路压测、代码覆盖率、Mock 平台、智能举荐等。曾先后就任于京东商城、海尔集团等，善于性能压测平台建设，并实现近亿级 QPS 压测，曾多次为 618、双 11 等重要流动保驾护航；
舒适揭示：本文约 4500 字，预计破费 8 分钟浏览。
后盾回复“交换”进入读者交换群；回复“5132”获取课件材料；
背景
作为一家出行游览服务平台，去哪儿网的搜寻页面性能十分多且简单。以机票搜寻场景为例，用户的搜寻场景包含伺机人、起降地、仓储等信息。此外，还会关注航司信息、起降地点是否须要直达、落地工夫和后续出行安顿等。搜寻后果进去后，用户还会进行后续操作，比方搜寻航班价格，抉择退改服务、出行保障、接机服务和住宿服务等等。
如上图，QA 须要筹备的 Checklist 高达 1 万多条，每条 Checklist 对应至多 1 条测试用例，还需确保用例的时效性。随着业务的一直扩大，返回后果数据出现一直收缩的趋势，测试同学还须要确保各种数据的准确性，包含渠道、价格、伺机人和服务包等多个维度的数据。
因而测试同学每天须要忍耐大量沉重且单调乏味的工作，这对于他们的精力和膂力来说都是一种折磨，随同而来的就是公布故障居高不下。
（整体公布故障偏多，性能故障占比 50%)
秉持着用技术改善业务痛点的理念，去哪儿网不断完善工具平台的建设。依据公司公布的数据显示，去哪儿网过来一年中，公布故障数和故障率都一直升高，并始终保持在 4‰ 以下。开发和测试的比例也一直变动，从之前的 1:1 降至测试占开发的 1/3。因而，本次分享的功能测试左移，心愿可能在降低成本、升高故障率、进步研发效率等多个方面为大家带来肯定的帮忙。
（近一年公布故障数、开发测试比例一直升高 )
一、如何通过自动化测试降低成本？
1.1 整体思路
在工作中，测试同学负责承前启后的重要角色。在我的项目周期中，测试工作占据了近一半的老本，所以升高人工测试老本是一个重要的指标。咱们通过数据分析，发现测试同学在验证外围性能时，人力老本次要分为三个局部：用例筹备、环境筹备和后果断言。其中，Checklist 和用例筹备占据了 50% 的比例，须要特地解决。环境筹备须要确保公布代码的一致性，而后果剖析须要关注每个细节差别，确保后果的正确性。为了解决这些问题，咱们决定采纳自动化测试平台来代替繁琐的手工工作。
通过自动化平台实现用例保护、部署以及剖析断言后果。让测试人员可能专一于差别测试，不被回归测试搅扰。
1.2 自动化平台建设
1.2.1 计划选型
在计划选型中，最具挑战性的是用例的运维。为了达到全面笼罩和充沛测试的指标，咱们须要思考两种计划：一种是基于覆盖率，另一种是本人保护 Checklist。
1）覆盖率的原理
代码覆盖率原理是在每一行代码前面插入探针 Flag，默认值为 False；用例申请路过代码时 Flag 的标识会标识为 True，这些 Flag 值就是代码覆盖率的数据，依据 Flag 的状态判断代码是否执行。
自动化平台应用代码覆盖率计划时，要做到笼罩全面的业务，需进行大量的用例回归验证；每执行一次用例申请后收集一次覆盖率数据；此时通过判断覆盖率数据是否减少来断定是否走到了新的代码。
此计划在执行大量用例与覆盖率收集过程会耗费较多工夫，因而具体落地是须要在每天凌晨执行昨天的数据，计算并保留无效用例，供明天的自动化测试应用；随同的一个运维痛点是，当凌晨业务异样时，不易及时定位修复，因而影响第二天的自动化景象会偶然产生。
2）Checklist 的原理
Checklist 的原理是用户只配置用例维度（如：航班类型、伺机人类型等），维度的值不须要配置，在业务日志中主动拉取取得，而后多个维度主动叉乘出 Checklist。例如，9 个航班类型、5 个伺机人类型、120 个服务项目会主动生成 95120=5400 个 Checklist。有 Checklist 就须要找对应的用例，基础架构的 TC 同学，实现标准化接口日志，所有的业务利用均可打印申请参数、返回后果等信息，自动化平台在此日志中根本满足用例生成需要。
3）计划比照及论断
比照这两种计划，咱们能够发现，第一种计划是业务维度的展现，覆盖率的形式只能看到代码是否走到，无奈晓得每条 Checklist 的维度值，因而无奈展现或查看每一条 Checklist 的覆盖度状况；同时，此计划对覆盖率平台有依赖，在实际过程中会导致覆盖率平台 Load 偏高，甚至零碎异样的可能性。此外，用户对数据时效性会有所吐槽，因为它是在当天凌晨执行，不满足互联网企业谋求时效性的诉求。
相比之下，第二种计划会依据用户配置、线上日志实时更新 Checklist，在以后数据以及历史数据中捞取对应的用例。当找不到时，会有历史用例的补充策略来填充。因而，Checklist 计划能够满足观测性高且无提早的需要的。
最终，通过业务线和技术委员会的评审，咱们抉择了第二种计划。
1.2.2 实际过程
实际过程能够分为三个阶段：触发、执行和报告。
第一阶段，即 Step 1，是触发过程。以前，QA 同学和开发须要进行肯定沟通后再点击提测。当初只需监听开发 Push 的代码或我的项目状态的变动（比方点击了提测），就会主动触发部署。第二阶段是执行阶段，Step2 会筹备环境和用例信息；Step3 将用例别离在基准环境（线上代码）和测试环境（本次开发代码）上执行。Step4 次要性能是后果断言，这里将基准环境作为参照物，与测试环境执行的后果进行 DIFF。最初将后果（胜利、失败）以邮件和通信工具形式周知到对应人。
1.2.3 实际难点 / 要点分享
难点 1：生成 Checklist 和用例
在业务自动化平台实际中，生成 Checklist 和用例是最艰难的模块。这里有一个维度名的概念，能够了解为测试传入的参数 Key，比方航班类型、伺机人类型、成人 / 儿童数量等。
用户须要初始化维度名字段，字段值能够在线上主动补充（当然用户能够写成固定值）。有了测试维度，就能够叉乘出 Checklist，例如航班类型、伺机人类型、起降地点就会叉乘出指数级的 Checklist。有了 Checklist，就能够展现每个 Checklist 的覆盖度状况，并提醒有效的 Checklist（如图所示）。
这样，咱们就实现了只须要配置维度名称就能主动生成 Checklist，再依据线上规范日志数据生成用例信息，至此实现了最根本的 Checklist 与用例诉求。
要点 2：业务变动时 Checklist 如何主动调整
尽管咱们曾经可能主动生成 Checklist，然而 Checklist 会一直变动，因为服务始终在变动，例如航班类型会一直新增、缩减等。
所以，当遇到新增状况时，咱们会从 TC 的规范日志中解析对应的字段，当发现新的值呈现时，平台就从新生成新的 Checklist 和用例。当航班或航线隐没时，平台会判断该 Checklist 的用例最初一次生成工夫，如果在设置的 2 周内没有生成该 Checklist 的用例，咱们就默认该条用例是有效的。当超过一个月时，平台会主动删除该条用例，当然也能够手动一键删除。这样，从维度名、Checklist 主动调整，再到用例主动欠缺，就造成了一个主动运维的闭环。
要点 3：部署与触发中的高效率
在部署阶段，次要波及基准环境和测试环境的部署。
环境代码介绍：基准环境作为参照物，须要实时与线上环境同步，实现此能力只需监听线上利用公布的音讯，主动公布即可实现，达到用户不再关注基准环境的要求。对于指定的测试环境，平台检测开发 Push 的代码是否与环境代码统一，即环境公布代码 与 Git 分支 Commit 的 SHA 值是否匹配。若不统一，则触发部署，反之跳过部署。
并行开发难点解决：多我的项目并行开发时，应用一个测试环境就会呈现串行公布与测试期待的问题，因而去哪儿建设了软路由环境（也称泳道环境）。在基准环境（部署线上代码），一个我的项目需要创立一个软路由环境，软件环境上的利用部署我的项目对应分支代码。测试申请携带软路由标识，申请路过批改利用时，走到软路由环境，反之路过非批改利用时走基准环境，这样就解决了同一个利用并发我的项目开发的难题。联调场景也是一样，多个利用应用雷同代码分支默认应用同一个软路由环境，联调过程更加不便，倡议流程图如下。
如图所示，在软路由环境 01 中，咱们拉取了 B1 和 D1 分支，这样就能够在软路由环境中测试它们的分支，缩小了等待时间。
要点 4：断言后果要多、剖析维度也要多
后果断言与报告展现是自动化平台建设的最初一公里，容易被开发同学漠视，然而用户会依据最初的后果来评判平台的好坏。在此，咱们次要思考两点：一是测试的判断维度要多，二是返回内容的断言要精确。咱们的测试维度包含覆盖率、数据增量和全量数据。此外，咱们还有一个剖析的维度，例如，咱们能够依照航班类型对后果进行分类，以便疾速定位问题。
还有一个维度是后果剖析，咱们会对每个 Case 执行并查看后果是否合乎预期。底层应用的原理是权重类似度匹配，即每个叶子节点作为一个权重，档次越深，权重越小。咱们做了大量的工作，反对了简单的主动判断和用户自定义的断言逻辑，包含减少、缺失、变更以及正则表达式等非凡条件的断言。
1.3 实际成果
自动化测试平台落地后，咱们回归测试工夫从原来的至多 0.5 天降到均匀不超过 5 分钟，且不依赖于人工干预，齐全后盾主动运行。总我的项目中 QA 的排期占比，也已从近 45% 降至 15%。
二、如何通过智能举荐升高故障率？
2.1 反对的性能
自动化测试落地尽管升高了故障数量，但回归测试仍不能齐全满足公司要求的低故障率。通过一个季度的数据分析发现，代码变更和配置变更是故障的次要起源。针对代码变更，测试未笼罩或未发现异常是导致上线呈现故障的重要因素。针对配置变更，线上动静配置通常是先配置再察看，因而配置异样引发的故障时常产生。在应答配置变更引发线上故障问题时，咱们建设了自动化拦挡机制，通过将配置在仿真环境执行自动化测试形式，来校验配置是否存在危险，自动化测试通过后配置再主动同步到线上，从而大大降低了配置变更引发的故障。然而，应答代码变更引发的故障，咱们须要一个新的平台来解决。
这里，根底平台搭建实现精准测试和异样检测，统称为智能举荐平台。公司心愿测试后果既精确又高效。这就须要在依据变更代码进行测试用例举荐时，进行精准的匹配，应用起码的用例来申请变更方最全的分支门路。此外，当在线上出现异常时，须要及时发现并提醒用户，特地是当异样信息牵涉到变更办法时。
2.2 智能举荐平台建设
2.2.1 计划选型
在精准测试中，咱们须要找到申请参数与代码办法的关联关系，为此收集了三种计划，别离是 AOP、TC 同学开发的 Java-agent 以及代码覆盖率平台。最终，咱们抉择了覆盖率这种计划，因为它可能精准到行，并能辨别办法内的分支门路（if 条件门路），满足业务线要求的办法测试充沛的要求。计划比照如下
2.2.2 实际要点分享
1）整体架构
咱们的整体架构能够分为三个局部，其中两头局部是比拟重要的。整体可分为两个业务流程。第一个业务流程是保留用例和代码的关系，即入库的过程。咱们应用一个 Job 来定时从线上获取申请并收集覆盖率，而后进行去重剖析，最终将代码与对应的用例关系保留到数据库中。第二个业务流程是举荐。当开发同学 Push 代码时，咱们会辨认变更的办法，并将库里的代码用例推送给他，执行后将后果也推送给他。在执行过程中，如果出现异常或辨认异样，特地是与变更办法相干的异样，咱们会及时告诉用户。
联合以上架构，上面咱们将介绍一个实际过程。
2）精准测试
第一个要点是精准测试，这须要对非凡包进行过滤，咱们举例来说，去哪儿网只须要收集 com.qunar 包门路下的数据。此外，对于一些异样有效的变更，例如增加日志或监控，能够主动过滤掉。
第二个要点是测试全，次要是针对变更的办法，它的 if-else 条件要全面测试。咱们能够看一下覆盖率原理。在每一条指令下都插入了一个探针。例如，第一个申请达到并走了探针 1、3，第二个申请走了探针 1、4。然而第三个申请走了探针 1、3、4 之后，咱们依然会收集它，因为它的链路与后面的探针 1、3 和探针 1、4 不同，所以咱们会将其收集到数据中。当然，如果又呈现一个申请走了探针 1、3，就会呈现反复数据，咱们会过滤掉它。
当初来看一下精准测试页面，会将它的办法举荐的数据以及在两头增加的断点数据可视化并推送给用户。这样，咱们的精准测试触达率已达 90% 以上。
3）异样检测
除此之外，异样检测是咱们测试实现后发现问题的形式。咱们会检测异样栈以及变更办法，一旦匹配到问题，就会将异样信息推送给用户。咱们将所有的异样信息以及精准的异样信息展现在一个页面上，供用户查看。尽管目前异样检测驳回率仅达到 76%，然而咱们也一直地在致力，继续优化中。
2.3 实际成果
智能举荐的实际曾经继续了两年，通过不断改进，在升高故障率方面获得了继续的功效。人工测试阶段 3.8% 公布故障率，在自动化平台落地后，曾经升高到了 1% 以下。加之智能举荐平台的实际，咱们目前已实现故障率低于千分之 4，达到了公司所关注的低故障指标。
三、如何通过本地化进步研发效率？
3.1 整体思路
这部分次要是针对开发人员的需要，开发人员最苦楚的是须要公布到 Beta 环境能力进行测试用例等操作，本人筹备用例也比拟繁琐。因而，咱们的解决思路是测试左移，将测试过程提前到开发阶段进行，而不是在 Beta 环境中进行。
另外，开发人员可能不善于表白，甚至会对 QA 产生抵触情绪，为了升高沟通老本，咱们建设了开发工作流和我的项目工作台。在平台建设方面，咱们冀望做本地化测试和开发流水线，尽快收集开发人员的需要，让他们可能尽早实现开发和测试工作。
3.2 本地化平台建设
3.2.1 方案设计
在实践中，咱们借鉴了软路由的能力，将 Beta 环境的配置信息路由到本地，从而实现了本地调试和联调的性能。
3.2.2 IDEA 插件开发
基础架构 TC 同学开发了 IDEA 同步插件，使得利用能够一键启动，主动拉取测试环境配置并将软路由环境配到本地。此外，本地测试也要将它对应的数据上报到平台，开发对应 IDEA 组件实现覆盖率数据上报，如下图。
3.3 实际成果
本地化计划实现从 0 到 1 建设，使用率从 0% 达到 73%，最高时达到 80%；
自测自发的我的项目工作量从 22% 进步到 80% 以上；
我的项目实现工夫从 1.9 天 / 个升高到 1.2 天 / 个，耗时升高 36.8%；
通过自动化测试和测试后果推送，缩小研发与 QA 的沟通，进步工作效率。
四、总结与瞻望
4.1 总结回顾
在本次分享中总共三个局部，总结如下：
自动化测试：次要面向测试同学，实现了全自动的回归测试能力，并实现自主运维，无需人工染指，工作沉重的问题失去了解决。
低故障能力：面向公司诉求，实现了精准测试与异样检测能力，通过实现公布前测试到异样与线上异样后及时发现能力，大幅度降低公布故障。
高效率能力：面向开发同学，通过测试左移到开发侧思路，实现了本地化测试和本地化联调能力，简化了环境筹备，数据收集过程，从而进步了开发测试效率。
4.2 将来瞻望
瞻望局部是去哪儿网正在做或打算做的工作，包含云端开发、扩大能力、IDEA。云端开发的劣势在于性能更高，组件更标准化、更齐全，防止了本地化环境的问题。扩大能力则是心愿一种工具可能解决多个问题，例如 DIFF 能力能够在自动化测试和本地化测试中应用。咱们用 IDEA 在一直地开发，应用对立的 IDEA 组件提效开发过程。（全文完）
Q&A
1、测试的用例是不是能够用流量录制回放来做？
2、本地化测试，A-B-C 这样调用链路，本地服务如何接替 B 服务？
3、能够具体说说软路由吗？在本地服务接替环境服务的时候，如何保障申请到的是本地服务？革新网关负载策略吗？注册核心是什么？
4、压测报告个别怎么辨认服务瓶颈点，想问下压测完结之后怎么判断以后的瓶颈点是哪个？
更多具体内容，欢送点击“浏览全文”，观看完整版解答！
本文由博客一文多发平台 OpenWrite 公布！
