关于测试:全栈代码测试覆盖率及用例发现系统的建设和实践

本文首发于微信公众号“Shopee 技术团队”。

作者：Hao、Qianguang，来自 Shopee Digital Purchase 团队。

1. 背景

随着我的项目不断深入迭代，业务逻辑以及用户场景日渐简单，补充和保护单元测试保护的老本也变得越来越高。测试笼罩品质通过测试用例评审或者人工 Code Review 的形式费时费力，单凭多方沟通和教训累积的办法，往往不够精确，也难以避免开发人员存在在代码上线前“夹带私货”的场景，并且没有量化的、直观的主观数据来撑持。

为了在无限的工夫及人力老本内保障我的项目品质，实现对我的项目品质的精细化治理，咱们研发了 Finder —— 全栈代码测试覆盖率及用例发现零碎（下文简称 Finder），通过精确化的数据量化代码品质，从而实现精准化测试。本文将介绍 Finder 的总体架构，以及它作为品质保障体系中的重要一环，如何在我的项目中实现精确化测试。

2. Finder 我的项目介绍

Finder 次要分为两个模块，一个是 测试过程中对代码测试覆盖率进行收集与统计 ，一个是 剖析代码和用例的映射关系，精准确定回归测试范畴。

代码测试覆盖率统计模块，可能满足多环境、多需要、多服务的简单测试场景，实时收集测试过程中的覆盖率信息，并生成覆盖率统计报告；其反对多端语言接入（Web、React Native、Golang），实现前后端我的项目全笼罩，买通整体研发流程。

相干用例发现模块，针对变动的代码剖析函数调用关系，追溯残缺的调用关系链路，标记出所影响的 API 接口及相干用例，确定测试回归范畴。

3. 架构设计

Finder 分为代理层、应用层、外围服务层三个模块：

• 代理层 Finder Agent，负责后期数据采集的工作，包含编译阶段的代码插桩、覆盖率数据的采集、解析源码函数调用关系信息等；
• 应用层 Finder Platform，蕴含需要信息管理、分支信息管理、单文件覆盖率染色图展现、API 信息展现、测试用例关联、函数调用链展现等页面模块；

• 外围服务层 Finder Server，其中，覆盖率剖析和服务调用剖析是最次要的两个模块：

  • 覆盖率剖析，对收集到的覆盖率数据进行数据聚合、差别增量剖析、数据修改等操作；
  • 服务调用剖析，将源码解析工具传输来的数据进行数据结构转换后，实现调用拓扑图生成、API 信息关联、测试用例发现等操作。

在后期实现数据采集的接入工作后，测试人员无需额定操作，失常进行业务测试，测试实现后能够在可视化平台中查看覆盖率数据、相干测试用例等信息。

4. 实现计划

4.1 代码测试覆盖率模块

代码覆盖率模块次要分为两个步骤，第一步是通过对我的项目源码插桩，采集覆盖率信息；第二步是对覆盖率信息进行剖析，通过可视化平台展现统计报告。

步骤一：插桩与数据采集

代码插桩，意为在程序中插入一些代码，用于跟踪被测程序的某些信息。对于覆盖率测试而言，插桩的目标是检测程序中可执行语句被执行（即被笼罩）的状况。

Finder 反对 JS 和 Golang 两种程序语言的代码覆盖率统计，接入成本低，对业务需要无侵入性。

• 对于 JS 程序，咱们在 babel 编译阶段进行插桩操作，注入到全局对象 window 中。咱们提供了上报覆盖率数据的 npm 包 —— coverage-report，前端利用接入后会被动上报数据到 Finder Server；
• Golang 程序的覆盖率接入对业务我的项目零侵入，只须要引入 Finder Agent —— 覆盖率收集工具：它在编译阶段对源码插桩，包含 Git 信息和覆盖率信息注入；插桩实现后的服务会启动一个统计覆盖率的 Http Server，Finder Server 通过该 Http Server 提供的接口定时申请覆盖率数据。

步骤二：差别覆盖率统计

比起全量代码的覆盖率，实际上咱们更关怀改变代码局部的覆盖率状况。能够通过 Git 指令比照性能分支与 master 分支的代码差别，过滤无关代码，只针对改变代码局部进行覆盖率统计。

为实现差别覆盖率的计算，咱们约定以行（line）作为维度的构造示意 Git 代码差别和覆盖率信息，满足两者一一对应的关系。

首先将 Git 分支比照失去的 Diff 数据转换成以代码行作为索引的数组格局，元素的值有空值和 + 两种枚举值：

• 空值代表没有改变；
• + 代表有改变。

覆盖率数组也转换成以代码行作为索引的数组格局，元素的值有 -1、0、1 三种枚举值：

• -1 代表无需统计覆盖率的代码（例如空格，正文等）；
• 0 代表未笼罩的代码（尚未执行）；
• 1 代表已笼罩的代码（已被执行）。

将 Diff 数据与覆盖率数组进行合并，将非改变代码的覆盖率值置为 -1。失去最终的差别覆盖率数据。

关键问题一：数据源标准化

因为不同程序语言上报的覆盖率数据结构都不统一，咱们须要将数据源标准化，对立转化以行（line）为维度的数组构造。

首先，前端利用上报的覆盖率数据蕴含三种维度的覆盖率数据：

• Statement Coverage：语句维度的覆盖率数据；
• Branch Coverage：条件维度的覆盖率数据，例如 if/else、switch、三元运算符等；
• Function Coverage：函数维度的覆盖率数据。

对于这三类覆盖率，咱们做出以下数据转换：

咱们 采纳与操作 将三类覆盖率数据合并为行覆盖率，即一行代码满足三类覆盖率才算被执行过。

而后端 Golang 服务采集的覆盖率数据，如下图。

同样，咱们也须要将其转换为行维度的数组构造。

关键问题二：确保代码变更后的覆盖率正确性

在集成测试的过程中，开发人员不可避免地会进行代码更新。当代码更新后，咱们心愿可能记录新代码改变覆盖率的同时，仍然放弃原有代码的覆盖率数据。所以咱们须要获取新旧提交之间的代码差别，对原有覆盖率数据进行“修改”操作：

对原有的覆盖率数据，先删除 diff 后果中被移除的代码对应的覆盖率数据，再插入 diff 后果中新增的代码对应的覆盖率数据。

举个例子：

比照首次提交 commit 1 和 master 分支，失去首次改变：新增三行代码。

标记这三行代码的行索引 3、4、8，并统计它们的覆盖率。

比照 commit 1 和 commit 2，失去两次提交之间的改变：删除之前两行代码，新增一行代码。

移除原数据中第 3、4 行数据，而后插入新改变代码的行索引 7（删除后的索引地位）并统计新改变的覆盖率。

修改后的后果和 commit 2 与 master 分支比照的后果统一，既保留了首次改变的覆盖率数据，也记录了新改变的覆盖率数据。

关键问题三：单环境的代码覆盖率采集

在理论开发流程中，研发环境只有一套，咱们往往不能独占它，所有周版本需要都在 staging 环境开发，在 test 环境测试。这样会呈现一个问题：因为这种繁多环境的测试流程，导致统计进去的覆盖率无奈辨别来自哪个具体性能分支，进而影响对各性能需要的测试范畴判断。

为了解决这个问题，咱们提出两个计划：

第一个计划是搭建多泳道研发环境，通过 PFB（Per Feature Branch）的模式对各需要开发环境进行隔离。PFB 是一个能够疾速搭建虚拟环境的工具。它反对将多个性能分支版本同时部署在同一个测试环境中，且每个性能分支可领有独自的流量拜访，从而实现不同的性能分支可领有绝对隔离的虚拟环境。

然而因为这个架构改变较大，间隔落地到我的项目中还需一段时间，因而第二个计划应运而生：咱们 对繁多的集成分支进行性能追溯，判断出变动代码是属于合并进来的哪一个性能分支，并进行分类展现。

• 通过 Git Blame 命令从集成分支中判断出到各行代码对应的 commit hash；
• 通过 Git Branch 命令查找 commit hash 来自哪一个性能分支。

通过以上两步寻找到每行代码与性能分支的对应关系，与覆盖率后果进行映射后可得出对繁多集成分支的性能追溯成果，解决单环境的代码覆盖率采集问题。

4.2 相干用例发现模块

相干用例发现模块的要害是通过追溯变动代码的调用关系链，确定测试回归范畴。这个过程次要分为两个阶段：源码解析阶段 和数据分析阶段。

步骤一：源码解析

咱们在 Gitlab CI 接入源码解析工具，当有新代码提交时，触发源码解析。

通过对形象语法树 AST 和两头转换代码 SSA 进行解析，失去以下数据：

• 我的项目 Git 信息
• 函数根本信息
• 函数调用关系
• RPC 调用信息
• API 信息

最初将这些数据都打包对立发送到 Finder 服务端。

步骤二：数据分析

Finder 服务端接管到解析数据后，进行差别增量代码的函数调用关系全链路追溯，最初标记出相干的 API 信息及测试用例。具体追溯流程如下：

1. Git Diff 失去性能分支与 Master 分支比照的代码改变；
2. 通过差别增量代码的所在行数，确定所属函数体，进入步骤 3；
3. 追溯指定函数的调用关系，直到寻找到 API 触发函数；
4. 若遇到 RPC 调用的状况，进行 RPC 调用关系追溯，找到 RPC 调用方函数，持续回到步骤 3 的操作；
5. 追溯工作实现，失去从变动函数到 API 触发函数的调用关系全链路；
6. 通过以上失去的 API 触发函数，标记相干的 API 信息及测试用例。

每次代码变更都会触发上述流程，失去最新的函数调用链路信息，在可视化前台中展现该性能分支的变动函数调用关系链，以及相干测试用例。

关键问题：后端微服务架构串联，全链路笼罩

目前咱们后端服务采纳了分布式的微服务架构，例如一个购买商品的流程，当用户进入 APP 浏览商品时，会发动申请通过网关层，转发到商品服务，而后在创立订单时会调起订单服务，订单服务再调用用户信息服务和促销服务，整个过程还会调用多个根底服务共同完成一次操作流程。

咱们心愿除了解析服务内的调用关系外，也须要服务间的调用关系串联起来，失去残缺的调用链路。

为了解决这个问题，咱们针对我的项目中的 RPC 调用关系进行动态解析，通过寻找调用方函数——RPC Command——被调用方函数三者的关联关系，对调用方函数和被调用方函数进行标记，当函数调用关系链追溯到被调用方函数时，匹配到其对应的调用方函数，持续向上追溯，从而失去服务间的残缺调用关系链路。

5. 实际利用

Finder 通过接入团队中的我的项目流程管理系统，在整个需要生命周期的各个环节施展着不同的作用。

5.1 提测阶段

5.1.1 覆盖率提测达标

开发人员必须达到规定的覆盖率规范能力提测，对于覆盖率未达标的状况，开发人员须要反推代码逻辑是否存在问题，进一步剖析后期技术方案设计不够正当，还是对技术计划的实现有误，或者是在实现过程中造成的策略性放弃等。

5.1.2 覆盖率定制化

针对不同我的项目会有定制化的覆盖率要求，反对配置须要疏忽统计覆盖率的文件类型以及目录。

对于挪动端利用，提供 iOS 和 Android 双平台的覆盖率数据统计，这样可能提前裸露挪动端的兼容性问题，保障提测交付品质。

5.2 测试阶段

5.2.1 覆盖率实时剖析

测试人员染指测试后能够在 Finder 平台上实时查看覆盖率剖析后果，理解该测试版本变更代码的测试笼罩状况。

5.2.2 覆盖率染色图

通过代码覆盖率染色图辅助整个测试过程，不便测试人员对测试用例进行查漏补缺，尽可能保障所有要害场景都能笼罩到；同时能够驱动测试人员增强对代码的了解，充沛把控代码品质。

5.2.3 需要维度覆盖率统计

通过关联我的项目管理系统，从需要级别的角度，提供该需要下各模块的覆盖率数据，包含不同的后端服务和前端利用，辅助测试人员做决策，掂量品质危险。

5.3 回归阶段

标记变更范畴

依据 代码变更范畴 推断出 函数变更范畴，进一步标记出相干测试用例，从而实现用例和代码的关联关系。

用例发现剖析报告中会标记出该需要变更局部的相干信息，包含 变更的函数调用关系链路和受影响的 API 接口，测试人员从中能够疾速确定回归测试范畴，通过更小的维度更精准地度量测试品质，针对性进行自动化 / 手工测试，极大缩小回归阶段的工作量，以较小的回归老本保障较高的测试品质。

6. 将来瞻望

Finder 作为我的项目中品质保障体系中的一环，目前还处于初级阶段。在将来咱们会继续寻找 Finder 在研测协同体系中的更优实际。

1）反对更多维度的覆盖率数据统计

咱们心愿在统计方面能够提供更产品化更精细化的数据，包含关键字覆盖率、相干代码覆盖率、高风险覆盖率等，可能更好地辅助测试人员做决策。

2）精准记录 Bug 轨迹

后续咱们打算反对通过以增加标记的模式独自统计覆盖率，通过记录 bug 的残缺代码轨迹，还原问题的复现门路，精确定位问题所在。

3）建设用例知识库

构建用例与代码映射关系，造成用例知识库，反对对代码和用例进行关联治理，准确举荐改变代码关联的用例，提供测试用例优化倡议。