一、背景 & 現(xiàn)狀

二、意義何在

三、方案詳情

    1. 技術(shù)方案

    2. 推廣方案

    3. 運(yùn)營方案

四、現(xiàn)階段成果

    1. 基礎(chǔ)能力

    2. 應(yīng)用接入情況

    3. 覆蓋率運(yùn)營

    4. 研發(fā)自測

五、未來規(guī)劃

    1. 構(gòu)建質(zhì)量保障矩陣

    2. 覆蓋率數(shù)據(jù)精細(xì)化運(yùn)營

    3. 常態(tài)化運(yùn)營

六、結(jié)語

一、背景 & 現(xiàn)狀

在得物技術(shù)團(tuán)隊(duì)雙周迭代模式下，前端自動(dòng)化測試體系的建設(shè)已成為提升研發(fā)效能的關(guān)鍵突破口。當(dāng)前技術(shù)部門推行研發(fā)自測的核心訴求，其核心訴求在于通過建立可信的質(zhì)量保障機(jī)制釋放測試資源，以此承接更多的業(yè)務(wù)需求，提升需求吞吐率。

雙周迭代的機(jī)制對研發(fā)流程提出了雙重挑戰(zhàn)：既要保障兩周內(nèi)完成需求開發(fā)、測試驗(yàn)證到交付上線的完整閉環(huán)，又需保障研發(fā)交付的代碼質(zhì)量穩(wěn)定可靠且經(jīng)過充分的測試驗(yàn)證。

服務(wù)端已通過流量回放、代碼覆蓋率檢測等成熟方案構(gòu)建質(zhì)量護(hù)城河。我們統(tǒng)計(jì)了各個(gè)前端業(yè)務(wù)域在2025 年Q1中的自測率，服務(wù)端實(shí)際自測率為：24.45%，而前端的實(shí)際自測率僅有：15.35% 。因此，在完成技術(shù)部研發(fā)自測率25% 的目標(biāo)的情況下，前端是一個(gè)較大的短板。而制約前端實(shí)際自測率提升的一個(gè)重要的因素就是缺乏像服務(wù)端流量回放和代碼覆蓋率檢測技術(shù)這樣的自動(dòng)化代碼質(zhì)量保障技術(shù)，導(dǎo)致測試同學(xué)對于前端自測質(zhì)量的置信度存疑，無法檢測和衡量負(fù)責(zé)該需求的前端是否已經(jīng)完成了足夠詳盡的自測。

因此，如果需要提升前端的研發(fā)自測率，我們首先需要從這些質(zhì)量保障技術(shù)出發(fā)，夯實(shí)地基，構(gòu)建屬于前端的質(zhì)量保障護(hù)城河。

二、意義何在

上面我們說了，目前得物的前端領(lǐng)域缺乏自動(dòng)化代碼的質(zhì)量保障技術(shù)，我們想知道這些技術(shù)是否真的具有必要性呢？如果有了這些技術(shù)，真的能夠帶來研發(fā)效能的提升嗎？要回答這個(gè)問題，首先需要分析一下各種質(zhì)量保障方式的優(yōu)劣：

圖片

從上表的分析中，我們可以看到，不同的質(zhì)量保障方式各有優(yōu)劣，每種方式都有各自適合的場景，而研發(fā)自測場景和前端代碼覆蓋率相互結(jié)合，便可以解決前端研發(fā)自測置信度低的問題，再加上E2E自動(dòng)化測試，就可以補(bǔ)充全量用例自動(dòng)化回歸的缺口。

因此，補(bǔ)齊前端自動(dòng)化測試能力對于提升研發(fā)自測比例有著相當(dāng)大的正向作用。

三、方案詳情

正如上文所述，我們是通過補(bǔ)齊前端場景缺失的質(zhì)量保障工具的方法作為支點(diǎn)撬動(dòng)技術(shù)部研發(fā)自測比例的天平，讓更多符合研發(fā)自測標(biāo)準(zhǔn)的需求既能進(jìn)行研發(fā)自測釋放測試資源，又能有一定的質(zhì)量保障機(jī)制，確保前端交付代碼的質(zhì)量，穩(wěn)定生產(chǎn)。

為了方便大家更加理解這個(gè)項(xiàng)目，我們將會(huì)從技術(shù)實(shí)現(xiàn)方向、運(yùn)營方向、各域推廣這幾個(gè)方面具體聊一下在這個(gè)項(xiàng)目的具體操作原因和過程。

技術(shù)方案

圖片

圖片

前端代碼運(yùn)行時(shí)覆蓋率

※  插樁技術(shù)

圖片

前端代碼覆蓋率檢測最核心的點(diǎn)，就是需要想辦法檢測出我們修改的每一行代碼（JS代碼）在運(yùn)行時(shí)是否被執(zhí)行過，只要想辦法拿到這個(gè)數(shù)據(jù)，我們就可以在這個(gè)數(shù)據(jù)的系統(tǒng)上進(jìn)行一定的清洗、整理、合并，來得到我們想要的前端代碼運(yùn)行時(shí)覆蓋率的報(bào)告了。

經(jīng)過調(diào)研，想要知道某一行JS是否被運(yùn)行過，其實(shí)市面上已經(jīng)有比較成熟的方案了，例如：著名的JS前端測試框架 Jest 就是基于 istanbul 對需要檢測的代碼進(jìn)行插樁并收集代碼的運(yùn)行數(shù)據(jù)。

代碼插樁

代碼編譯過程中，在代碼的抽象語法樹（AST）每個(gè)語句節(jié)點(diǎn)中插入特定代碼，從而改變最終生成產(chǎn)物的一種非侵入性代碼修正方案。

圖片

// 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和測試代碼段，通過左側(cè)插樁邏輯處理右側(cè)的代碼后，我們就可以得到以下代碼：

圖片

接下來我們在頁面中進(jìn)行測試，沒有執(zhí)行到的代碼就可以被檢測出來。

圖片

圖片

當(dāng)然，上述只是一個(gè)簡易版的插樁代碼，僅用于演示，如果要在實(shí)際項(xiàng)目中使用，可以考慮使用： babel-plugin-istanbul 。

有了插樁能力之后，SDK剩下的邏輯就簡單了，只需要按照一定規(guī)則收集相關(guān)的覆蓋率報(bào)告并上報(bào)到指定服務(wù)器即可實(shí)現(xiàn)。

※  覆蓋率服務(wù)

覆蓋率服務(wù)數(shù)據(jù)處理流程

覆蓋率服務(wù)協(xié)作時(shí)序圖

覆蓋率服務(wù)是整個(gè)前端代碼覆蓋率體系的核心，起到「承上啟下」的作用。

• 上則與接入了覆蓋率SDK的業(yè)務(wù)系統(tǒng)相通，接收各個(gè)業(yè)務(wù)系統(tǒng)的原始覆蓋率數(shù)據(jù)，并進(jìn)行清洗、整理、合并、存儲(chǔ)的操作。
• 下則與其他關(guān)聯(lián)系統(tǒng)（覆蓋率報(bào)告展示平臺(tái)、覆蓋率平臺(tái)、發(fā)布平臺(tái)、流水線等）連通，為各個(gè)關(guān)聯(lián)系統(tǒng)提供核心覆蓋能力。

覆蓋率服務(wù)核心能力

• 收集處理報(bào)告： 收集瀏覽器上報(bào)的測試覆蓋率數(shù)據(jù)，按「應(yīng)用」、「分支」、「Color」、「時(shí)間段」做數(shù)據(jù)合并和存儲(chǔ)。
• 版本發(fā)布處理：版本發(fā)布后僅刪除「當(dāng)前應(yīng)用 + 當(dāng)前環(huán)境 + 當(dāng)前分支」，改動(dòng)文件的報(bào)告數(shù)據(jù)。
• 覆蓋率報(bào)告： 覆蓋率數(shù)據(jù)展示數(shù)據(jù)支持和備份能力。
• 橋接覆蓋率平臺(tái)：提供必要的接口，比如權(quán)限對接、報(bào)告管理、任務(wù)調(diào)度、流水線編排（發(fā)布攔截讀取覆蓋率平臺(tái)指標(biāo)）等交互。
• 報(bào)告機(jī)器人：通過報(bào)告機(jī)器人在特定時(shí)機(jī)通過飛書消息形式向特定群組發(fā)送覆蓋率報(bào)告。

覆蓋率服務(wù)旨在實(shí)現(xiàn)「應(yīng)用維度」，未來會(huì)支持「需求維度」、「人員維度」、「頁面維度」的覆蓋率：

應(yīng)用維度覆蓋率

圖片

※  報(bào)告展示

覆蓋率報(bào)告展示流程

覆蓋率報(bào)告列表

覆蓋率報(bào)告展示示例

為了讓開發(fā)同學(xué)能夠更加清晰且實(shí)時(shí)的知道哪一行代碼沒有被覆蓋，我們提供了兩種報(bào)告形式：

• 實(shí)時(shí)覆蓋率報(bào)告：與Master分支對比，得到測試分支與主干分支的差異，并過濾出增量變動(dòng)代碼的覆蓋率情況，且報(bào)告是實(shí)時(shí)更新的，無需反復(fù)生成報(bào)告，測試完刷新即可查看最新覆蓋情況。
• 覆蓋率報(bào)告快照：每個(gè)版本準(zhǔn)入和準(zhǔn)出階段，我們會(huì)保存一份覆蓋率報(bào)告的快照，這個(gè)快照會(huì)固定與生成快照時(shí)的commit進(jìn)行對比，生成之后不會(huì)改變，方便我們查看不同版本各個(gè)應(yīng)用的覆蓋率情況。

此外，我們也支持目錄維度的覆蓋率情況，方便開發(fā)同學(xué)快速查看未覆蓋代碼的定位。

目前，我們也支持「需求維度覆蓋率報(bào)告」、「人員維度覆蓋率報(bào)告」，將每行代碼的改動(dòng)與具體的需求和人員關(guān)聯(lián)上，支持這個(gè)功能以后，我們可以更好地衡量某個(gè)需求的的代碼測試質(zhì)量，開發(fā)同學(xué)也可以利用人員維度的覆蓋率報(bào)告更加高效地處理各自負(fù)責(zé)代碼的未覆蓋問題，提升自測和測試效率。

※  覆蓋率平臺(tái) & 協(xié)同流水線

圖片

圖片

有了針對指定應(yīng)用和環(huán)境生成覆蓋率報(bào)告的基礎(chǔ)能力后，我們就可以將我們的能力對接到覆蓋率平臺(tái)，這樣可以借助覆蓋率平臺(tái)現(xiàn)有的管理能力：

• 應(yīng)用注冊
• 環(huán)境管理
• 報(bào)告管理
• 任務(wù)管理

除此之外，我們還可以復(fù)用覆蓋率平臺(tái)與協(xié)同流水線之間現(xiàn)成的通信協(xié)議和能力，快速對接到協(xié)同流水線當(dāng)中，實(shí)現(xiàn)需求、應(yīng)用的「準(zhǔn)入」和「準(zhǔn)出」卡口，讓覆蓋率不達(dá)標(biāo)的應(yīng)用無法操作提測和上線，以此筑起質(zhì)量保障的長城，為穩(wěn)定生產(chǎn)保駕護(hù)航。

E2E 自動(dòng)化測試

上面我們簡單聊了整個(gè)前端代碼覆蓋率的各個(gè)模塊，細(xì)心的同學(xué)應(yīng)該發(fā)現(xiàn)了，我們一直說的都是「增量代碼覆蓋率」，但沒有提到「全量代碼覆蓋率」。難道全量代碼覆蓋率對我們來說可有可無嗎？其實(shí)不然！

上文我們主要聊的都是增量代碼的場景，其原因是我們之前還不具備全量代碼覆蓋率收集的能力。很多同學(xué)可能會(huì)問了，代碼覆蓋率不是就是代碼插樁收集嗎？那全量和增量似乎也沒區(qū)別呀，為什么增量可以實(shí)現(xiàn)，全量不行呢？

其實(shí)，這并不是我們技術(shù)能力上達(dá)不到，而是我們不可能要求測試或開發(fā)同學(xué)每次測試都把這個(gè)系統(tǒng)回歸一邊，要知道，一個(gè)成熟的業(yè)務(wù)系統(tǒng)，動(dòng)輒就是幾十萬行代碼級(jí)別的，我們不可能依靠人工進(jìn)行全量回歸。

所以，就到了另一個(gè)前端質(zhì)量保障的主角登場了，那就是 「E2E自動(dòng)化測試」，只要有了自動(dòng)化測試的能力，只要錄制（自動(dòng)分析）一次，下次需求開發(fā)之后，就可以直接全量自動(dòng)化回歸了。

關(guān)于E2E自動(dòng)化測試是前端平臺(tái)增長域的同學(xué)負(fù)責(zé)推進(jìn)的，在這里就不過多展開E2E的技術(shù)細(xì)節(jié)了。

推廣方案

至此，我們已經(jīng)大概地過了一遍整個(gè)前端自動(dòng)化測試體系的技術(shù)方案了。但光是把東西做出來，如果沒人用或者用戶基數(shù)低，那么這些工具的ROI也是非常有限的。因此，我們借助技術(shù)部推行研發(fā)自測的契機(jī)，也制定了前端代碼覆蓋率體系的推廣計(jì)劃。

應(yīng)用接入

2025年Q1在實(shí)驗(yàn)域的應(yīng)用內(nèi)試點(diǎn)運(yùn)行幾個(gè)版本后，覆蓋率相關(guān)功能已相對比較穩(wěn)定，因此Q2正式開始在前端平臺(tái)內(nèi)部的其他業(yè)務(wù)域中推廣，各個(gè)業(yè)務(wù)域根據(jù)各自應(yīng)用的情況，按照以下標(biāo)準(zhǔn)對應(yīng)用設(shè)定接入優(yōu)先級(jí)。

※  接入優(yōu)先級(jí)

• P0 應(yīng)用：應(yīng)用可接入且優(yōu)先級(jí)高（中后臺(tái)類應(yīng)用）。
• P1 應(yīng)用：應(yīng)用可接入但是相對優(yōu)先級(jí)較低，或改動(dòng)頻率較低，對于收集覆蓋率訴求不高。
• P2 應(yīng)用：應(yīng)用不可接入或者暫不支持接入，未來考慮實(shí)現(xiàn)支持收集覆蓋率功能。

為確保應(yīng)用接入順利，我們保證絕大部分應(yīng)用可以開箱即用地接入SDK，除了少數(shù)RsPack和MF架構(gòu)的應(yīng)用需要特殊接入外，其他應(yīng)用的接入成本均相當(dāng)?shù)土?/p>

統(tǒng)一標(biāo)準(zhǔn)

應(yīng)用接入完成之后，各域的已接入應(yīng)用就可以通過代碼覆蓋率來衡量研發(fā)自測的質(zhì)量了，那么接下來就要正式對我們的終極目標(biāo)“研發(fā)自測率”發(fā)起進(jìn)攻了。

各個(gè)域?qū)τ凇缚裳邪l(fā)自測需求」的顆粒度標(biāo)準(zhǔn)是參差不齊的，但如果要在技術(shù)部范圍內(nèi)將研發(fā)自測順利的推行起來，方便后期統(tǒng)一出具相關(guān)報(bào)告，并根據(jù)情況調(diào)整科研發(fā)自測標(biāo)準(zhǔn)，那么，擺在我們面前的一個(gè)最大的難題就是：統(tǒng)一研發(fā)自測顆粒度標(biāo)準(zhǔn)。

在進(jìn)行標(biāo)準(zhǔn)統(tǒng)一的討論的過程中，我們也遇到了很多問題，其中反饋?zhàn)疃嗟膯栴}就是：

• 有些業(yè)務(wù)域一旦按照統(tǒng)一標(biāo)準(zhǔn)判定可自測需求的話，可自測需求池子就會(huì)比原先多出很多可自測需求，雖然可自測需求不代表必須自測，但也需要相關(guān)的研發(fā)同學(xué)和測試同學(xué)進(jìn)行一定的溝通，確認(rèn)該需求是否能夠?qū)嶋H自測并打標(biāo)，這會(huì)增加溝通成本。如果需要反復(fù)去 “需求管理平臺(tái)” 篩選確認(rèn)，效率太低。

針對這種問題，我們前期通過腳本，按照最新標(biāo)準(zhǔn)將各業(yè)務(wù)域每個(gè)版本的應(yīng)自測需求都導(dǎo)出到多維表格，并將可以輔助判斷需求是否可以自測的一些信息（如當(dāng)前需求名稱、鏈接、預(yù)計(jì)是否可自測、實(shí)際是否自測、需求總估時(shí)[含測試]、需求總估時(shí)[不含測試]等）都一同導(dǎo)出，方便各域負(fù)責(zé)人快速確認(rèn)（后期研發(fā)效能同學(xué)會(huì)統(tǒng)一開發(fā)相關(guān)研發(fā)自測的數(shù)據(jù)統(tǒng)計(jì)報(bào)表和需求明細(xì)，方便各域進(jìn)行分析和確認(rèn)）：

此外，我們還確定下來，由于各域的實(shí)操標(biāo)準(zhǔn)目前參差不齊，可自測需求可以統(tǒng)一標(biāo)準(zhǔn)。但各域?qū)嵅贂r(shí)，還是按照各域現(xiàn)行標(biāo)準(zhǔn)實(shí)行，即目前這個(gè)階段，我們僅擴(kuò)大可自測需求的池子，但最終是否自測，還是按照各域?qū)嵅贅?biāo)準(zhǔn)來，后續(xù)再根據(jù)運(yùn)營情況調(diào)整策略，逐步逼近目標(biāo)。

目標(biāo)制定

我們通過對前端平臺(tái)各域Q1的自測數(shù)據(jù)進(jìn)行分析，得到了當(dāng)前各域的現(xiàn)狀：

• 實(shí)際自測率：15.29%
• 可自測完成率：42.22%

可見，無論是實(shí)際自測率還是自測完成率都是較低的。

基于這種現(xiàn)狀，如果想要一蹴而就直接打到25%是不太可能的，因此，我們將戰(zhàn)線拉長，分兩個(gè)季度來逐步完成目標(biāo)：

• Q2：統(tǒng)一可自測標(biāo)準(zhǔn)、提升可自測完成率，通過自測完成率的提升帶動(dòng)實(shí)際自測率的提升，因此確定下來：

Q2 自測率：21%

Q2 完成率：65%

• Q3：加強(qiáng)自測能力，提高可自測標(biāo)準(zhǔn)，通過擴(kuò)大池子來整體提升自測率，因此確定下來：

Q3 自測率：25%

Q3 完成率：80%

以上為前端平臺(tái)整體的目標(biāo)，上面也說了，各域由于業(yè)務(wù)特性，存在不同的情況，如果一概而論，對于某些域來說難度堪比登天，對于某些域來說又是輕而易舉。因此我們還針對各域Q2的現(xiàn)狀，為各域量身定制的一套差異化目標(biāo)：

• 實(shí)際自測率：

在高位，持續(xù)保持（30%）

在中低位，但是空間大 （25%）

在低位，空間有限的，取可自測率為目標(biāo)

• 自測完成率：
• 原本處于低位（9.52%）：設(shè)定特殊目標(biāo)25%
• 原本處于中位（27%～41%）：設(shè)定最低目標(biāo)65%
• 原本處于高位，在原基礎(chǔ)上提升一定比例即可

需求研發(fā)自測影響因素分析

在標(biāo)準(zhǔn)完成統(tǒng)一以及目標(biāo)完成制定之后，我們進(jìn)一步下鉆數(shù)據(jù)，想要通過各版本的自測數(shù)據(jù)分析，找出可能影響研發(fā)自測率的因素。首先，我們先預(yù)設(shè)了幾個(gè)可能影響研發(fā)自測的因素：

• 需求全棧率：由于全棧開發(fā)的目標(biāo)需求也是簡單的小顆粒度需求，跟研發(fā)自測的目標(biāo)需求有一定重合，而如果一個(gè)需求是完全全棧的話，就不需要前端參與了，會(huì)導(dǎo)致需要前端參與的小顆粒度簡單需求數(shù)量減少。

全棧

即通過可視化配置的頁面來替代人工源碼開發(fā)的一種解決方案，若某個(gè)需求完全推行全棧策略，則無需前端參與，由服務(wù)端同學(xué)直接配置即可。

圖片

• 大顆粒度需求占比：由于前端總體資源是相對固定的，一個(gè)版本中，如果大顆粒度需求比較多，那么前端能夠承接的小顆粒度需求自然就會(huì)變少，從而導(dǎo)致前端整體可自測需求比較少，直接影響自測率。

圖片

• 小顆粒度需求占比：有些版本，即使大顆粒度的版本不多，小顆粒度的需求也不見得會(huì)變多，需求有可能集中在不大不小的區(qū)間內(nèi)，因此小顆粒度需求的多少也會(huì)影響到自測率。

圖片

• 版本平均顆粒度：除了大顆粒度需求和小顆粒度需求外，整個(gè)版本的平均顆粒度的高低也會(huì)一定程度上影響到可自測需求的多少，通常來說，平均顆粒度越高，可自測需求就會(huì)相對越少，反之亦然。當(dāng)然版本平均顆粒度并不會(huì)直接影響「實(shí)際自測率」，而是通過「可自測率」影響可自測需求池的大小，從而最終影響「實(shí)際自測率」。但由于是間接影響，中間可能受到「自測完成率」以及「額外自測需求數(shù)」等其他因素的影響，「版本平均顆粒度」和「實(shí)際自測率」之間，并不總是成負(fù)相關(guān)的關(guān)系，因此需要進(jìn)一步下鉆分析。

版本平均顆粒度走勢

版本需求自測率走勢

圖片

圖片

【平均顆粒度】【應(yīng)自測率】：通常成反比關(guān)系

【自測完成率】【實(shí)際自測率】：通常成正比關(guān)系

• 純前端需求占比：根據(jù)過往數(shù)據(jù)分析，純前端需求自測占比相較于非純前端需求自測占比會(huì)高很多，因此，一個(gè)迭代當(dāng)中，純前端需求的多少也會(huì)影響自測率。

圖片

• 版本周期：受到各種節(jié)假日的影響，得物每個(gè)迭代周期可能都不太一樣，如 567由于有五一假期，因此該迭代周期為13天，而569由于有端午假期，版本周期只有9天。版本周期不一樣，能夠承接的需求數(shù)量、難易程度、顆粒度也都會(huì)有差異，也會(huì)影響自測率。
• 獨(dú)立項(xiàng)目占比：目前很多域都有不斷提升獨(dú)立項(xiàng)目在迭代需求中的占比的趨勢，由于項(xiàng)目管理相對獨(dú)立，且存在需求龐大，時(shí)間周期長，基本不可能自測的特點(diǎn)，如果一個(gè)版本中獨(dú)立項(xiàng)目的占比提升了，那么勢必會(huì)擠占正常迭代需求的時(shí)間，導(dǎo)致可承接的需求數(shù)量變小，可研發(fā)自測的需求也會(huì)變小，影響自測率。

圖片

基于上述的集中可能影響研發(fā)自測的因素，我們拉取了560～568的9個(gè)版本的迭代數(shù)據(jù)進(jìn)行了細(xì)致分析。

從數(shù)據(jù)分析中我們發(fā)現(xiàn)，版本周期和獨(dú)立項(xiàng)目占比對需求自測率占比的影響是比較明顯的，通常版本周期變長，自測率會(huì)提升，反之則降低。而獨(dú)立項(xiàng)目占比提升通常會(huì)導(dǎo)致自測率降低，反之提升。其他條件沒有太明顯的有規(guī)律變化，但不代表他們不會(huì)對自測率造成影響，應(yīng)該是還有一些其他未知因素暗中影響導(dǎo)致的。

因此，我們后續(xù)推進(jìn)時(shí)，可以重點(diǎn)關(guān)注一下版本周期和獨(dú)立項(xiàng)目兩個(gè)影響因素，其他因素也可以看情況加強(qiáng)關(guān)注。

運(yùn)營方案

工具開發(fā)好了不代表就完事了，如果不用心去運(yùn)營的話，肯定也是無法達(dá)到技術(shù)部 25%的需求研發(fā)自測目標(biāo)的，我們需要一個(gè)詳盡的運(yùn)營策略持續(xù)跟進(jìn)覆蓋率的運(yùn)營。當(dāng)覆蓋率有保障了，才能夠提升前端自測置信度，讓測試放心將更多的小顆粒度需求給研發(fā)測試。

簡單來說我們會(huì)在每個(gè)版本需求提測之前，要求負(fù)責(zé)需求開發(fā)的研發(fā)在指定環(huán)境完成自測，如果未自測或自測不達(dá)標(biāo)，可以直接通過「前端代碼覆蓋率」工具監(jiān)控出來并實(shí)時(shí)提醒。在需求上線之前，我們也會(huì)觀察待上線應(yīng)用的準(zhǔn)出代碼覆蓋率情況，用來衡量或輔助判定測試是否充分，是否存在漏測場景，以此保證生產(chǎn)質(zhì)量和穩(wěn)定。

四、現(xiàn)階段成果

圖片

基礎(chǔ)能力

完成了包括應(yīng)用維度覆蓋率、實(shí)時(shí)覆蓋率報(bào)告、覆蓋率報(bào)告快照、覆蓋率準(zhǔn)出卡口等基礎(chǔ)能力的建設(shè)，初步搭建起了前端代碼覆蓋率體系。Q2預(yù)計(jì)完成需求維度覆蓋率報(bào)告、人員維度覆蓋率報(bào)告、自動(dòng)化報(bào)告推送機(jī)器人等能力。

應(yīng)用接入情況

我們在Q2進(jìn)行了一次集中的各域應(yīng)用接入，接入完成率達(dá)126.67%，遠(yuǎn)超預(yù)期。雖然后續(xù)不會(huì)再集中接入了，但還會(huì)逐漸單獨(dú)接入其他支持應(yīng)用。

接入應(yīng)用數(shù)和生成報(bào)告情況

覆蓋率運(yùn)營

我們對接入的部分應(yīng)用代碼覆蓋率進(jìn)行了抽樣統(tǒng)計(jì)和分析：

圖片

從覆蓋率數(shù)據(jù)上來看，統(tǒng)計(jì)的應(yīng)用在正式啟動(dòng)運(yùn)營之后，相較于566有較大幅度的提升，無論是準(zhǔn)入覆蓋率還是準(zhǔn)出覆蓋率都遠(yuǎn)遠(yuǎn)超出了目標(biāo)標(biāo)準(zhǔn)，其中平均準(zhǔn)入覆蓋率為：78.58%，準(zhǔn)出覆蓋率為：87.06%（準(zhǔn)入目標(biāo)：60%，準(zhǔn)出：80%）。可見只要我們運(yùn)營得當(dāng)，主動(dòng)推進(jìn)，是能夠得到直接的正向反饋的。但從代碼覆蓋率來說，先不說覆蓋率的提升對于研發(fā)自測率的影響，就單是對于前端代碼交付質(zhì)量的提升的收益而言，已經(jīng)比較喜人了。

研發(fā)自測

我們抽樣查看了實(shí)驗(yàn)業(yè)務(wù)域的研發(fā)自測情況，我們可以看到，實(shí)驗(yàn)域?qū)嶋H自測率已經(jīng)超出了Q1的目標(biāo)（21%）3個(gè)百分點(diǎn)，可見實(shí)際投入運(yùn)營后給研發(fā)自測率帶來的正向效果。（當(dāng)然，每個(gè)版本受限于一些不可控因素，如：需求特性、版本周期、獨(dú)立項(xiàng)目占比等影響，數(shù)據(jù)會(huì)有一定程度的波動(dòng)，我們每個(gè)版本需要通過數(shù)據(jù)下鉆分析原因，保證順利向目標(biāo)進(jìn)發(fā)）。

圖片

五、未來規(guī)劃

圖片

我們在Q1和Q2分別完成了「基礎(chǔ)能力建設(shè)」「研發(fā)自測標(biāo)準(zhǔn)化&全域項(xiàng)目試點(diǎn)運(yùn)營」，基礎(chǔ)能力和標(biāo)準(zhǔn)都已經(jīng)確定下來了，那么后續(xù)我們就要從以下兩個(gè)方向努力了：

構(gòu)建質(zhì)量保障矩陣

圖片

我們當(dāng)前已經(jīng)支持了中后臺(tái)應(yīng)用的代碼覆蓋率檢測了，已經(jīng)支持了公司內(nèi)部很大一部分的前端應(yīng)用，但C端應(yīng)用和NodeJs應(yīng)用也占了不小的比重，后續(xù)需要補(bǔ)齊這一部分能力，讓代碼覆蓋率將這一部分應(yīng)用都囊括進(jìn)來，整體提升前端項(xiàng)目的交付質(zhì)量。

圖片

除此之外，我們也會(huì)進(jìn)一步聯(lián)動(dòng)E2E自動(dòng)化工具和影響面評(píng)估工具，進(jìn)一步提升測試完整度。

此外，我們還可以通過支持覆蓋率評(píng)論、頁面維度覆蓋率報(bào)告、AI智能推薦最佳測試路徑、以及影響面評(píng)估工具等，提升研發(fā)和測試快速精準(zhǔn)地找到漏測頁面和潛在風(fēng)險(xiǎn)點(diǎn)，提升自測和測試效率。

在測試質(zhì)量方面，我們打算利用AI能力，分析PRD并生成核心自測用例，補(bǔ)齊研發(fā)自測沒有測試用例這一短板，提升研發(fā)自測的測試質(zhì)量。

覆蓋率數(shù)據(jù)精細(xì)化運(yùn)營

通過搭建前端代碼覆蓋率大盤，觀測各域各應(yīng)用以及前端平臺(tái)全域的覆蓋率變化曲線，針對覆蓋率較低的業(yè)務(wù)域和應(yīng)用，進(jìn)行專項(xiàng)推進(jìn)與提升，整體提升前端平臺(tái)接入應(yīng)用的交付質(zhì)量。并通過機(jī)器人告警等方式實(shí)時(shí)通知未達(dá)覆蓋率最低標(biāo)準(zhǔn)應(yīng)用的覆蓋率情況，針對性分析需求、人員因素的影響。

通過對各域覆蓋率、自測率等核心指標(biāo)的精確分析，不斷的優(yōu)化推行策略和運(yùn)營策略，可以更早地發(fā)現(xiàn)我們在推進(jìn)的過程中遇到的阻礙和瓶頸，提前制定合適的備案，保障完成最終目標(biāo)。

常態(tài)化運(yùn)營

在完成了所有的能力建設(shè)后，我們就需要針對每個(gè)版本的需求進(jìn)行精細(xì)化運(yùn)營了。每個(gè)版本迭代結(jié)束，及時(shí)對上個(gè)版本的數(shù)據(jù)進(jìn)行復(fù)盤和分析，看一下有哪些地方?jīng)]做好，導(dǎo)致原本可以研發(fā)自測的需求，最終沒有自測。并根據(jù)上一個(gè)Q的運(yùn)營情況，實(shí)時(shí)調(diào)整研發(fā)自測的標(biāo)準(zhǔn)和各域的差異化目標(biāo)，確保研發(fā)自測的正常健康推進(jìn)。

六、結(jié)語

在數(shù)字化進(jìn)程加速的產(chǎn)業(yè)背景下，前端工程的質(zhì)量保障已從單一功能驗(yàn)證演進(jìn)為體系化工程實(shí)踐。上文通過技術(shù)架構(gòu)、運(yùn)營機(jī)制、推廣策略三個(gè)維度，系統(tǒng)解構(gòu)了我們在推進(jìn)前端自動(dòng)化測試體系的建設(shè)路徑與研發(fā)自測的實(shí)踐價(jià)值，為前端構(gòu)建起質(zhì)量護(hù)城河，提升前端代碼交付質(zhì)量，并以此撬動(dòng)研發(fā)自測的杠桿，向著整體提升需求吞吐率的目標(biāo)發(fā)起沖鋒。

作為現(xiàn)代前端工程師，質(zhì)量保障責(zé)任不能完全委托于測試團(tuán)隊(duì)。有研究表明，經(jīng)過嚴(yán)格自測的代碼提測后無論是缺陷密度還是代碼回滾率都會(huì)有較大幅度的下降。前端開發(fā)者通過瀏覽器中對于功能的詳盡自測，能夠深度理解業(yè)務(wù)邏輯邊界條件；在覆蓋率報(bào)告分析過程中，可常發(fā)現(xiàn)未覆蓋的異常分支或冗余代碼，這對代碼可維護(hù)性提升具有顯著價(jià)值。

通過覆蓋率報(bào)告建立個(gè)人/需求質(zhì)量檔案，持續(xù)跟蹤自測覆蓋率、缺陷引入率等指標(biāo)，遇到問題時(shí)能夠精準(zhǔn)快速溯源，快速判斷Bug逃逸原因是否是因?yàn)楣δ茳c(diǎn)漏測導(dǎo)致的。之前曾看過這樣一句話："優(yōu)秀的代碼不僅是能運(yùn)行的代碼，更是經(jīng)得起反復(fù)驗(yàn)證的代碼"，這種嚴(yán)謹(jǐn)?shù)墓こ虘B(tài)度正是專業(yè)開發(fā)者的核心素養(yǎng)。

通過上述體系建設(shè)，可使前端質(zhì)量保障從被動(dòng)發(fā)現(xiàn)轉(zhuǎn)向主動(dòng)檢測&防御，從個(gè)體實(shí)踐升級(jí)為團(tuán)隊(duì)能力，最終實(shí)現(xiàn)研發(fā)效能與產(chǎn)品質(zhì)量的雙重提升。這既是應(yīng)對復(fù)雜前端工程的必然選擇，也是項(xiàng)目在高速迭代過程中保障交付代碼質(zhì)量，穩(wěn)定生產(chǎn)的關(guān)鍵路徑。