一、背景 & 现状
在得物技术团队双周迭代模式下，前端自动化测试体系的建设已成为提升研发效能的关键突破口。当前技术部门推行研发自测的核心诉求，其核心诉求在于通过建立可信的质量保障机制释放测试资源，以此承接更多的业务需求，提升需求吞吐率。
双周迭代的机制对研发流程提出了双重挑战：既要保障两周内完成需求开发、测试验证到交付上线的完整闭环，又需保障研发交付的代码质量稳定可靠且经过充分的测试验证。
服务端已通过流量回放、代码覆盖率检测等成熟方案构建质量护城河。我们统计了各个前端业务域在2025 年Q1中的自测率，服务端实际自测率为：24.45%，而前端的实际自测率仅有：15.35% 。因此，在完成技术部研发自测率25% 的目标的情况下，前端是一个较大的短板。而制约前端实际自测率提升的一个重要的因素就是缺乏像服务端流量回放和代码覆盖率检测技术这样的自动化代码质量保障技术，导致测试同学对于前端自测质量的置信度存疑，无法检测和衡量负责该需求的前端是否已经完成了足够详尽的自测。
因此，如果需要提升前端的研发自测率，我们首先需要从这些质量保障技术出发，夯实地基，构建属于前端的质量保障护城河。
二、意义何在
上面我们说了，目前得物的前端领域缺乏自动化代码的质量保障技术，我们想知道这些技术是否真的具有必要性呢？如果有了这些技术，真的能够带来研发效能的提升吗？要回答这个问题，首先需要分析一下各种质量保障方式的优劣：
![]()
从上表的分析中，我们可以看到，不同的质量保障方式各有优劣，每种方式都有各自适合的场景，而研发自测场景和前端代码覆盖率相互结合，便可以解决前端研发自测置信度低的问题，再加上E2E自动化测试，就可以补充全量用例自动化回归的缺口。
因此，补齐前端自动化测试能力对于提升研发自测比例有着相当大的正向作用。
三、方案详情
正如上文所述，我们是通过补齐前端场景缺失的质量保障工具的方法作为支点撬动技术部研发自测比例的天平，让更多符合研发自测标准的需求既能进行研发自测释放测试资源，又能有一定的质量保障机制，确保前端交付代码的质量，稳定生产。
为了方便大家更加理解这个项目，我们将会从技术实现方向、运营方向、各域推广这几个方面具体聊一下在这个项目的具体操作原因和过程。
技术方案
![]()
![]()
前端代码运行时覆盖率
※ 插桩技术
![]()
前端代码覆盖率检测最核心的点，就是需要想办法检测出我们修改的每一行代码（JS代码）在运行时是否被执行过，只要想办法拿到这个数据，我们就可以在这个数据的系统上进行一定的清洗、整理、合并，来得到我们想要的前端代码运行时覆盖率的报告了。
经过调研，想要知道某一行JS是否被运行过，其实市面上已经有比较成熟的方案了，例如：著名的JS前端测试框架 Jest 就是基于 istanbul 对需要检测的代码进行插桩并收集代码的运行数据。
代码插桩
代码编译过程中，在代码的抽象语法树（AST）每个语句节点中插入特定代码，从而改变最终生成产物的一种非侵入性代码修正方案。
![]()
// code.js
var a = 1;
var b = 2;
var c = a + b;
var d = a < b ? a : b;
function test() {
return a + b;
}
if (Math.random() > 0.5) {
test();
} else {
console.log("done");
}
上述代码是一份简易版本的插桩 SDK和测试代码段，通过左侧插桩逻辑处理右侧的代码后，我们就可以得到以下代码：
![]()
接下来我们在页面中进行测试，没有执行到的代码就可以被检测出来。
![]()
![]()
当然，上述只是一个简易版的插桩代码，仅用于演示，如果要在实际项目中使用，可以考虑使用： babel-plugin-istanbul 。
有了插桩能力之后，SDK剩下的逻辑就简单了，只需要按照一定规则收集相关的覆盖率报告并上报到指定服务器即可实现。
※ 覆盖率服务
![]()
![]()
覆盖率服务是整个前端代码覆盖率体系的核心，起到「承上启下」的作用。
覆盖率服务核心能力
-
收集处理报告： 收集浏览器上报的测试覆盖率数据，按「应用」、「分支」、「Color」、「时间段」做数据合并和存储。
-
版本发布处理：版本发布后仅删除「当前应用 + 当前环境 + 当前分支」，改动文件的报告数据。
-
覆盖率报告： 覆盖率数据展示数据支持和备份能力。
-
桥接覆盖率平台：提供必要的接口，比如权限对接、报告管理、任务调度、流水线编排（发布拦截读取覆盖率平台指标）等交互。
-
报告机器人：通过报告机器人在特定时机通过飞书消息形式向特定群组发送覆盖率报告。
覆盖率服务旨在实现「应用维度」，未来会支持「需求维度」、「人员维度」、「页面维度」的覆盖率：
![]()
![]()
![]()
![]()
※ 报告展示
![]()
![]()
![]()
为了让开发同学能够更加清晰且实时的知道哪一行代码没有被覆盖，我们提供了两种报告形式：
此外，我们也支持目录维度的覆盖率情况，方便开发同学快速查看未覆盖代码的定位。
目前，我们也支持「需求维度覆盖率报告」、「人员维度覆盖率报告」，将每行代码的改动与具体的需求和人员关联上，支持这个功能以后，我们可以更好地衡量某个需求的的代码测试质量，开发同学也可以利用人员维度的覆盖率报告更加高效地处理各自负责代码的未覆盖问题，提升自测和测试效率。
※ 覆盖率平台 & 协同流水线
![]()
![]()
有了针对指定应用和环境生成覆盖率报告的基础能力后，我们就可以将我们的能力对接到覆盖率平台，这样可以借助覆盖率平台现有的管理能力：
除此之外，我们还可以复用覆盖率平台与协同流水线之间现成的通信协议和能力，快速对接到协同流水线当中，实现需求、应用的「准入」和「准出」卡口，让覆盖率不达标的应用无法操作提测和上线，以此筑起质量保障的长城，为稳定生产保驾护航。
E2E 自动化测试
上面我们简单聊了整个前端代码覆盖率的各个模块，细心的同学应该发现了，我们一直说的都是「增量代码覆盖率」，但没有提到「全量代码覆盖率」。难道全量代码覆盖率对我们来说可有可无吗？其实不然！
上文我们主要聊的都是增量代码的场景，其原因是我们之前还不具备全量代码覆盖率收集的能力。很多同学可能会问了，代码覆盖率不是就是代码插桩收集吗？那全量和增量似乎也没区别呀，为什么增量可以实现，全量不行呢？
其实，这并不是我们技术能力上达不到，而是我们不可能要求测试或开发同学每次测试都把这个系统回归一边，要知道，一个成熟的业务系统，动辄就是几十万行代码级别的，我们不可能依靠人工进行全量回归。
所以，就到了另一个前端质量保障的主角登场了，那就是 「E2E自动化测试」，只要有了自动化测试的能力，只要录制（自动分析）一次，下次需求开发之后，就可以直接全量自动化回归了。
关于E2E自动化测试是前端平台增长域的同学负责推进的，在这里就不过多展开E2E的技术细节了。
推广方案
至此，我们已经大概地过了一遍整个前端自动化测试体系的技术方案了。但光是把东西做出来，如果没人用或者用户基数低，那么这些工具的ROI也是非常有限的。因此，我们借助技术部推行研发自测的契机，也制定了前端代码覆盖率体系的推广计划。
应用接入
2025年Q1在实验域的应用内试点运行几个版本后，覆盖率相关功能已相对比较稳定，因此Q2正式开始在前端平台内部的其他业务域中推广，各个业务域根据各自应用的情况，按照以下标准对应用设定接入优先级。
※ 接入优先级
-
P0 应用：应用可接入且优先级高（中后台类应用）。
-
P1 应用：应用可接入但是相对优先级较低，或改动频率较低，对于收集覆盖率诉求不高。
-
P2 应用：应用不可接入或者暂不支持接入，未来考虑实现支持收集覆盖率功能。
为确保应用接入顺利，我们保证绝大部分应用可以开箱即用地接入SDK，除了少数RsPack和MF架构的应用需要特殊接入外，其他应用的接入成本均相当低廉。
统一标准
应用接入完成之后，各域的已接入应用就可以通过代码覆盖率来衡量研发自测的质量了，那么接下来就要正式对我们的终极目标“研发自测率”发起进攻了。
各个域对于「可研发自测需求」的颗粒度标准是参差不齐的，但如果要在技术部范围内将研发自测顺利的推行起来，方便后期统一出具相关报告，并根据情况调整科研发自测标准，那么，摆在我们面前的一个最大的难题就是：统一研发自测颗粒度标准。
在进行标准统一的讨论的过程中，我们也遇到了很多问题，其中反馈最多的问题就是：
针对这种问题，我们前期通过脚本，按照最新标准将各业务域每个版本的应自测需求都导出到多维表格，并将可以辅助判断需求是否可以自测的一些信息（如当前需求名称、链接、预计是否可自测、实际是否自测、需求总估时[含测试]、需求总估时[不含测试]等）都一同导出，方便各域负责人快速确认（后期研发效能同学会统一开发相关研发自测的数据统计报表和需求明细，方便各域进行分析和确认）：
![]()
自测需求确认表
此外，我们还确定下来，由于各域的实操标准目前参差不齐，可自测需求可以统一标准。但各域实操时，还是按照各域现行标准实行，即目前这个阶段，我们仅扩大可自测需求的池子，但最终是否自测，还是按照各域实操标准来，后续再根据运营情况调整策略，逐步逼近目标。
目标制定
![]()
我们通过对前端平台各域Q1的自测数据进行分析，得到了当前各域的现状：
-
实际自测率：15.29%
-
可自测完成率：42.22%
可见，无论是实际自测率还是自测完成率都是较低的。
基于这种现状，如果想要一蹴而就直接打到25%是不太可能的，因此，我们将战线拉长，分两个季度来逐步完成目标：
以上为前端平台整体的目标，上面也说了，各域由于业务特性，存在不同的情况，如果一概而论，对于某些域来说难度堪比登天，对于某些域来说又是轻而易举。因此我们还针对各域Q2的现状，为各域量身定制的一套差异化目标：
需求研发自测影响因素分析
在标准完成统一以及目标完成制定之后，我们进一步下钻数据，想要通过各版本的自测数据分析，找出可能影响研发自测率的因素。首先，我们先预设了几个可能影响研发自测的因素：
全栈
即通过可视化配置的页面来替代人工源码开发的一种解决方案，若某个需求完全推行全栈策略，则无需前端参与，由服务端同学直接配置即可。
![]()
![]()
![]()
-
版本平均颗粒度：除了大颗粒度需求和小颗粒度需求外，整个版本的平均颗粒度的高低也会一定程度上影响到可自测需求的多少，通常来说，平均颗粒度越高，可自测需求就会相对越少，反之亦然。当然版本平均颗粒度并不会直接影响「实际自测率」，而是通过「可自测率」影响可自测需求池的大小，从而最终影响「实际自测率」。
-
但由于是间接影响，中间可能受到「自测完成率」以及「额外自测需求数」等其他因素的影响，「版本平均颗粒度」和「实际自测率」之间，并不总是成负相关的关系，因此需要进一步下钻分析。
![]()
![]()
![]()
![]()
【平均颗粒度】【应自测率】：通常成反比关系
【自测完成率】【实际自测率】：通常成正比关系
![]()
-
版本周期：受到各种节假日的影响，得物每个迭代周期可能都不太一样，如 567由于有五一假期，因此该迭代周期为13天，而569由于有端午假期，版本周期只有9天。版本周期不一样，能够承接的需求数量、难易程度、颗粒度也都会有差异，也会影响自测率。
-
独立项目占比：目前很多域都有不断提升独立项目在迭代需求中的占比的趋势，由于项目管理相对独立，且存在需求庞大，时间周期长，基本不可能自测的特点，如果一个版本中独立项目的占比提升了，那么势必会挤占正常迭代需求的时间，导致可承接的需求数量变小，可研发自测的需求也会变小，影响自测率。
![]()
基于上述的集中可能影响研发自测的因素，我们拉取了560～568的9个版本的迭代数据进行了细致分析。
从数据分析中我们发现，版本周期和独立项目占比对需求自测率占比的影响是比较明显的，通常版本周期变长，自测率会提升，反之则降低。而独立项目占比提升通常会导致自测率降低，反之提升。其他条件没有太明显的有规律变化，但不代表他们不会对自测率造成影响，应该是还有一些其他未知因素暗中影响导致的。
因此，我们后续推进时，可以重点关注一下版本周期和独立项目两个影响因素，其他因素也可以看情况加强关注。
运营方案
工具开发好了不代表就完事了，如果不用心去运营的话，肯定也是无法达到技术部 25%的需求研发自测目标的，我们需要一个详尽的运营策略持续跟进覆盖率的运营。当覆盖率有保障了，才能够提升前端自测置信度，让测试放心将更多的小颗粒度需求给研发测试。
简单来说我们会在每个版本需求提测之前，要求负责需求开发的研发在指定环境完成自测，如果未自测或自测不达标，可以直接通过「前端代码覆盖率」工具监控出来并实时提醒。在需求上线之前，我们也会观察待上线应用的准出代码覆盖率情况，用来衡量或辅助判定测试是否充分，是否存在漏测场景，以此保证生产质量和稳定。
四、现阶段成果
![]()
基础能力
完成了包括应用维度覆盖率、实时覆盖率报告、覆盖率报告快照、覆盖率准出卡口等基础能力的建设，初步搭建起了前端代码覆盖率体系。Q2预计完成需求维度覆盖率报告、人员维度覆盖率报告、自动化报告推送机器人等能力。
应用接入情况
我们在Q2进行了一次集中的各域应用接入，接入完成率达126.67%，远超预期。虽然后续不会再集中接入了，但还会逐渐单独接入其他支持应用。
![]()
接入应用数和生成报告情况
覆盖率运营
我们对接入的部分应用代码覆盖率进行了抽样统计和分析：
![]()
从覆盖率数据上来看，统计的应用在正式启动运营之后，相较于566有较大幅度的提升，无论是准入覆盖率还是准出覆盖率都远远超出了目标标准，其中平均准入覆盖率为：78.58%，准出覆盖率为：87.06%（准入目标：60%，准出：80%）。可见只要我们运营得当，主动推进，是能够得到直接的正向反馈的。但从代码覆盖率来说，先不说覆盖率的提升对于研发自测率的影响，就单是对于前端代码交付质量的提升的收益而言，已经比较喜人了。
研发自测
我们抽样查看了实验业务域的研发自测情况，我们可以看到，实验域实际自测率已经超出了Q1的目标（21%）3个百分点，可见实际投入运营后给研发自测率带来的正向效果。（当然，每个版本受限于一些不可控因素，如：需求特性、版本周期、独立项目占比等影响，数据会有一定程度的波动，我们每个版本需要通过数据下钻分析原因，保证顺利向目标进发）。
![]()
五、未来规划
![]()
我们在Q1和Q2分别完成了「基础能力建设」「研发自测标准化&全域项目试点运营」，基础能力和标准都已经确定下来了，那么后续我们就要从以下两个方向努力了：
构建质量保障矩阵
![]()
我们当前已经支持了中后台应用的代码覆盖率检测了，已经支持了公司内部很大一部分的前端应用，但C端应用和NodeJs应用也占了不小的比重，后续需要补齐这一部分能力，让代码覆盖率将这一部分应用都囊括进来，整体提升前端项目的交付质量。
![]()
除此之外，我们也会进一步联动E2E自动化工具和影响面评估工具，进一步提升测试完整度。
此外，我们还可以通过支持覆盖率评论、页面维度覆盖率报告、AI智能推荐最佳测试路径、以及影响面评估工具等，提升研发和测试快速精准地找到漏测页面和潜在风险点，提升自测和测试效率。
在测试质量方面，我们打算利用AI能力，分析PRD并生成核心自测用例，补齐研发自测没有测试用例这一短板，提升研发自测的测试质量。
覆盖率数据精细化运营
通过搭建前端代码覆盖率大盘，观测各域各应用以及前端平台全域的覆盖率变化曲线，针对覆盖率较低的业务域和应用，进行专项推进与提升，整体提升前端平台接入应用的交付质量。并通过机器人告警等方式实时通知未达覆盖率最低标准应用的覆盖率情况，针对性分析需求、人员因素的影响。
通过对各域覆盖率、自测率等核心指标的精确分析，不断的优化推行策略和运营策略，可以更早地发现我们在推进的过程中遇到的阻碍和瓶颈，提前制定合适的备案，保障完成最终目标。
常态化运营
在完成了所有的能力建设后，我们就需要针对每个版本的需求进行精细化运营了。每个版本迭代结束，及时对上个版本的数据进行复盘和分析，看一下有哪些地方没做好，导致原本可以研发自测的需求，最终没有自测。并根据上一个Q的运营情况，实时调整研发自测的标准和各域的差异化目标，确保研发自测的正常健康推进。
六、结语
在数字化进程加速的产业背景下，前端工程的质量保障已从单一功能验证演进为体系化工程实践。上文通过技术架构、运营机制、推广策略三个维度，系统解构了我们在推进前端自动化测试体系的建设路径与研发自测的实践价值，为前端构建起质量护城河，提升前端代码交付质量，并以此撬动研发自测的杠杆，向着整体提升需求吞吐率的目标发起冲锋。
作为现代前端工程师，质量保障责任不能完全委托于测试团队。有研究表明，经过严格自测的代码提测后无论是缺陷密度还是代码回滚率都会有较大幅度的下降。前端开发者通过浏览器中对于功能的详尽自测，能够深度理解业务逻辑边界条件；在覆盖率报告分析过程中，可常发现未覆盖的异常分支或冗余代码，这对代码可维护性提升具有显著价值。
通过覆盖率报告建立个人/需求质量档案，持续跟踪自测覆盖率、缺陷引入率等指标，遇到问题时能够精准快速溯源，快速判断Bug逃逸原因是否是因为功能点漏测导致的。之前曾看过这样一句话："优秀的代码不仅是能运行的代码，更是经得起反复验证的代码"，这种严谨的工程态度正是专业开发者的核心素养。
通过上述体系建设，可使前端质量保障从被动发现转向主动检测&防御，从个体实践升级为团队能力，最终实现研发效能与产品质量的双重提升。这既是应对复杂前端工程的必然选择，也是项目在高速迭代过程中保障交付代码质量，稳定生产的关键路径。
往期回顾
1.从CPU冒烟到丝滑体验：算法SRE性能优化实战全揭秘｜得物技术
2.得物自研DScript2.0脚本能力从0到1演进
3.社区造数服务接入MCP｜得物技术
4.CSS闯关指南：从手写地狱到“类”积木之旅｜得物技术
5.从零实现模块级代码影响面分析方案｜得物技术
文 / 康辉
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
