严选精准测试实践（进阶篇）
精准测试领域经过一年多来在各个BU的探索和实践，也逐渐发现了在实际业务落地时遇到的各种问题和一些瓶颈。本文主要介绍下我们面向集团内开源共建的精准测试平台的一些能力，以及在严选内结合实际业务线落地实践所做出的一些效果和突破。
1 前言
继严选精准测试实践之后，我们经过了一年多来在各个BU的探索和实践，也逐渐发现了在实际业务落地时遇到的各种问题和一些瓶颈，例如：
覆盖率方向：已经明确知道了自动化或人工测试的覆盖情况，但是因为代码量大（特别对一些老旧服务来说，废弃冗余代码太多），较难下手进行逐一补充和精准的测试覆盖，落地难度大且效率低下，久而久之就慢慢腐化，丧失了其价值。
代码变更分析方向：虽然能够基于代码分析出了一些变更点，很多情况下会涉及大量的变更接口，但是因为数据太多且维度较单一，无法提供比较有价值和核心的信息，进而导致此功能比较鸡肋，无法发挥其应有的价值。
平台能力方向：之前在各BU的测试团队都有在自建平台或工具做一些覆盖率和精准测试分析的一些方向，重复造轮子且这个领域的技术难度较大、投入资源有限，做不深，收益效果也不明显。
2 天玑平台介绍
我们首要的目标是设计一套面向集团内部通用化的解决方案，实现可快速复制，低成本接入 ，整合资源减少重复的技术投入。天玑平台是由严选和传媒的质量技术团队在2021年一起共建上线的一个精准测试平台，上线近一年，已在严选、传媒、云信、有道、杭研urs等部门全面落地投入使用，目前已接入300+个应用，为各部门提供了4万次+的各类覆盖率计算和精准分析。
2.1 平台特点
打通集团各基建，提供精准测试依赖的各项基础数据的同步和可视化，提供一站式平台能力。
以公有化+私有化的方式来实现部署，尽可能的满足各BU对个性化、兼容性和安全性方面的要求。
2.2 平台架构
平台（公共化部署）：主要提供精准测试各项能力的访问入口、操作和可视化，背后会负责所有能力的驱动和调度执行、结果数据存储和各项基础数据的配置管理等，支持用户角色访问控制。
Agent（私有化部署）：主要负责精准测试各项能力的执行。之所以考虑私有化部署，是因为精准测试领域的一些特殊性，是需要基于工程代码、部署环境、版本管理等方面的基建来执行。各个BU的基建都不同，个性化的东西较多，且存在一些代码安全方面的考虑，所以采用私有化部署的方式，Agent内会提供一份标准和规范，各个BU接入可以根据自己的实际情况去实现其中需要定制化的部分即可。
SDK（开源方向）：我们抽象并封装了精准测试的各类原子操作，重写了原生Jacoco、java-callgraph中底层的算法和逻辑，为适配各类复杂的业务场景，形成通用化的能力输出，如果不接入天玑平台，也可以用这些通用的能力接入自己的工具平台，目前SDK也是由严选、传媒、智企的一些测试和开发同学在一起共建维护。
2.3 平台能力
服务端覆盖率收集、计算和报告输出（支持Java、Golang）
服务端增量代码覆盖率计算（包括分支增量/版本增量）
服务端增量代码变更中测试未覆盖率部分计算和结果输出
服务端覆盖率结果对比能力（计算出差异未覆盖部分）
工程内或多工程间差异化代码Diff计算
工程差异化代码变更链路计算和结果分析
工程差异化代码自动化用例关联和筛选
工程差异化代码变更影响接口分析（上下游链路接口影响分析、线上调用次数关联、接口链路拓扑和链路覆盖率）
TOP接口GoApi用例筛选和覆盖情况分析
客户端覆盖率（建设中...）
3 严选落地实践
基于我们开场提出的这些实际碰到的问题和痛点，我们该如何去改进和突破呢？以下会介绍一下在严选的一些落地效果和最佳实践：
做减法：我们基于已有的全量覆盖率数据，不断的去提炼和精简，在有限的测试资源下尽可能的去覆盖我们最核心、最真实、最应该去覆盖的点，少走弯路减少不必要的投入。
做加法：我们基于比较基础的代码变更分析能力，我们希望集成更多的关联信息，整合成一套可分析、可追溯、可决策的数据来提供给开发和测试同学，通过智能化的一些手段来辅助或指引原有人工分析的工作，提升分析的准确性和可靠性。
3.1 覆盖率（我测得怎么样）
我们如何来做减法，该减去什么呢？
结合严选实际的研发流程、质量准入准出和自动化基础等方面，在“覆盖率”这个广义的概念上，我们做了很多深入的能力扩展和业务落地，总结下来我们希望把覆盖率更多的聚焦在每次版本变更的影响的代码块（变更的）和线上热点代码块（真实的）这两个方面：
3.1.1 增量覆盖率
我们希望在全量覆盖率达到一定的基础的前提下，QA同学能够更多的去关注和覆盖每次版本变更带来的影响点。
增量覆盖率目前在严选主要会以当前部署的版本和master来进行对比计算出代码差异，然后将测试覆盖情况体现在变更行覆盖率和变更方法的行覆盖率这两个维度：
变更行覆盖率：只针对变更的代码行做覆盖率统计（统计以下标记+号的行）
变更方法行覆盖率：方法中存在变更代码，我们认为变更方法是需要整体回归的，所以也会统计该变更方法的行覆盖率情况（未变更的方法不会然和参与计算，会剔除掉）
3.1.2 有效覆盖率
如何能够让我们的测试覆盖有本质上的提效呢？
我们决定用线上真实流量来帮助我们可以更加精准高效的去补充和提升我们的自动化覆盖，以及对人工测试去做一个引导和辅助。同时通过线上流量的覆盖情况我们也能帮助开发同学在废弃冗余代码的治理方面提供数据支撑。
目前严选已经在主站、交易、促销、供应链、渠道分销等业务线的核心服务，将Jacoco部署到了线上，在线上灰度的机器中常态化的对线上流量覆盖率做采集和分析。同时在天玑平台也提供了覆盖率报告对比计算的能力，可以将线上的覆盖率报告和线下的覆盖率报告做对比计算，计算出线上覆盖的代码行中在线下哪些是未覆盖的，如以下的一个代码片段：
其中颜色说明：
有颜色的代码行：代表线上流量覆盖率走过
无颜色的代码行：代表线上流量覆盖率未走过（不参与整体覆盖率统计，即分母不纳入）
绿色：代表线上流量覆盖率走过，线下自动化流量也覆盖（参与统计）
红色：代表线上流量覆盖率走过，线下自动化流量未覆盖（参与统计）
黄色：为判断分支点（部分分支流程覆盖），代表线上流量覆盖率走过，线下自动化流量也覆盖（参与统计）
那我们有了这份数据后，开发在分析代码细节、测试评估测试充分度等方面，都有了一份非常具有说服力和价值的数据来做为目标来参考。
3.1.3 TOP接口覆盖率
我们会统计每个应用线上日均调用次数TOP的接口，然后在每次发布质量卡点中，通过自动化的结果来验证用例是否均已覆盖TOP接口（那目前只针对执行集中是否覆盖到了这些接口来做计算，还是比较粗的粒度，后续会对覆盖的准确性和用例的质量情况做评估）。
3.1.4 准出卡点
我们已经将GoApi用例通过率、全量覆盖率、变更行覆盖率、有效行覆盖率、Top30接口覆盖率、等指标作为发布卡点的准出标准来落地执行，达不到阈值(用例通过率100%、全量行覆盖50%、增量行覆盖70%，有效行覆盖60%、TOP30接口覆盖90%)，无法进行后续的发布流程。
3.2 代码变更分析（我要测什么）
针对版本代码变更分析方向，我们希望是做加法，希望整合变更所带来的一系列的有用信息（比如变更接口重要性、接口上下游、接口的用例覆盖度、用例情况等），来辅助开发和测试同学更好更高效的来做一些技术评估和决策。
3.2.1 影响接口分析
平台能够支持对两个版本的代码做差异化Diff计算，然后通过字节码层面的静态分析，计算出每个变更方法它影响到的最上层的Controller或RPC接口（即测试入口），以及本次新增的接口，能够帮助开发和测试同学快速缩小本次版本影响的接口范围，有助于测试分析，提升回归效率。
3.2.2 上下游链路影响分析
通过以上计算出的变更影响接口，平台再通过哨兵或严选的APM帮助分析出本次变更影响接口的服务间上下游链路的接口依赖关系是怎么样的，这些依赖接口的线上调用次数是怎么样的（接口重要性），为接口变更带来的上下游依赖影响分析提供数据支撑。
3.2.3 影响接口重要性评估
我们通过每个变更接口的线上调用次数、变更影响的方法数来综合评定该接口的重要程度，在开发和测试同学评估版本影响范围时提供一些辅助。
3.2.4 影响接口链路覆盖率
我们在计算变更影响接口的同时，还做了覆盖率的收集，计算了变更链路上每个方法的覆盖率和接口链路的覆盖率，以拓扑图的形式来展现，也能看到每个节点的覆盖代码行染色情况：
3.2.5 影响接口用例推荐
我们目前将变更接口的GoApi用例/场景/执行集进行了关联和筛选（目前做的相对比较粗，只精确到了接口url的粒度）：
如果接口线上调用量较大，但是又没有任何用例覆盖，我们是会暴露风险的，后续也会加入质量准出卡点；同时在测试分析阶段，如果接口的用例缺失，也可以更加有针对性的去补充用例。
同时也能将筛选出这些覆盖的用例进行执行，生成该变更接口的链路覆盖率，直观的可以看到每个变更接口的用例覆盖情况，方便更加精准的补充用例。
3.3 整体收益情况
经过一年多来的持续探索和建设，在严选的精准测试领域已经从1.0版本（基础能力探索）全面迈向了2.0版本（数据驱动决策），通过各项能力和指标的不断迭代完善，已为严选的研发团队赋能和提效。
赋能开发：
在严选库存，交易，前台等多个技改项目中应用（库存缓存服务化，交易db切分，前台应用拆分），分别从两个场景帮助提升研发效率和精确度：
分析修改点对上游链路影响，帮助精确评估影响点和回归范围。
从前台服务接口拆分，分析完整代码调用链路，一次迁移属于该前台服务的代码资产。（严选app 项目代码行数已经超过149w行），将以前几乎无法人工分析的事情实现了工具化。
平台能力和SDK已经在严选一些研发团队落地并形成最佳实践：
赋能测试：
在质量准入和准出层面都有了数据指标来量化和决策，冒烟通过率和测试逃逸率相比去年都有不同程度的提升。
通过“有效覆盖率”来精准驱动自动化的建设，据各业务线的反馈，在用例的分析和设计过程中，相比之前有20~30%左右的测试提效。
精准测试输出的各类自动化覆盖率的指标，已纳入严选的服务自动化能力分体系考核指标。其中严选130个+核心服务的自动化测试全量行覆盖平均水平已达到55%+，有效覆盖率的平均水平达到70%+，各应用TOP30核心接口的覆盖率达到90%+。
提升了团队同学的测试深度，提供了较好的白盒测试的切入口。
4 未来规划
4.1 智能化方向
我们计划会和云音乐的引流平台、杭研的GoAPI以及Devops体系结合，向精准测试3.0版本探索：
目标：积累和沉淀日常各类流量，建立流量和代码的映射关系，基于版本变更来生成用例。同时结合CI流程，通过机器来执行一轮版本变更测试，输出测试报告，再交付给测试人员来介入做决策。
我们希望编写各类用例不再完全依赖人工经验或者需要一行行的去啃代码（效率低下而且容易遗漏），而是基于日常各类流量来辅助我们自动生成用例，同时能够通过机器来自动化的帮我们执行一轮冒烟测试或回归测试，这样能够更加高效快速的来应对各类业务的高速迭代或者敏捷模式的质量保障。
那要支持各种场景的用例生成，前提就需要我们来收集各类流量数据来计算每个请求流量走过的代码块，建立起映射关系。那我们会改造Jacoco-agent，同时结合引流平台的回放能力，通过基于探针的实现方式来记录下来每个流量走过的类和方法信息，为后续的用例生成提供数据来源。
4.2 开源化方向
目前我们底层已抽象和封装了精准测试需要用到的各项原子能力，具有较强的业界通用性，目前也在集团内形成了各部门的开源共建（严选、传媒、智企的同学都有在参与共建维护），今年计划会把开源范围继续扩大，不仅局限在精准测试领域，能够让更多有兴趣的同学一起加入进来，来一起创新和探索，为我们的研发过程来创造价值。
本文由作者授权严选技术团队发布