一、背景 & 現狀

在得物技術團隊雙週迭代模式下，前端自動化測試體系的建設已成為提升研發效能的關鍵突破口。當前技術部門推行研發自測的核心訴求，其核心訴求在於通過建立可信的質量保障機制釋放測試資源，以此承接更多的業務需求，提升需求吞吐率。

雙週迭代的機制對研發流程提出了雙重挑戰：既要保障兩週內完成需求開發、測試驗證到交付上線的完整閉環，又需保障研發交付的代碼質量穩定可靠且經過充分的測試驗證。

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

因此，如果需要提升前端的研發自測率，我們首先需要從這些質量保障技術出發，夯實地基，構建屬於前端的質量保障護城河。

二、意義何在

上面我們説了，目前得物的前端領域缺乏自動化代碼的質量保障技術，我們想知道這些技術是否真的具有必要性呢？如果有了這些技術，真的能夠帶來研發效能的提升嗎？要回答這個問題，首先需要分析一下各種質量保障方式的優劣：

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

因此，補齊前端自動化測試能力對於提升研發自測比例有着相當大的正向作用。

三、方案詳情

正如上文所述，我們是通過補齊前端場景缺失的質量保障工具的方法作為支點撬動技術部研發自測比例的天平，讓更多符合研發自測標準的需求既能進行研發自測釋放測試資源，又能有一定的質量保障機制，確保前端交付代碼的質量，穩定生產。

為了方便大家更加理解這個項目，我們將會從技術實現方向、運營方向、各域推廣這幾個方面具體聊一下在這個項目的具體操作原因和過程。

技術方案

前端代碼運行時覆蓋率

※  插樁技術

前端代碼覆蓋率檢測最核心的點，就是需要想辦法檢測出我們修改的每一行代碼（JS代碼）在運行時是否被執行過，只要想辦法拿到這個數據，我們就可以在這個數據的系統上進行一定的清洗、整理、合併，來得到我們想要的前端代碼運行時覆蓋率的報告了。

經過調研，想要知道某一行JS是否被運行過，其實市面上已經有比較成熟的方案了，例如：著名的JS前端測試框架 Jest 就是基於 istanbul 對需要檢測的代碼進行插樁並收集代碼的運行數據。

代碼插樁

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

// code.jsvar 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剩下的邏輯就簡單了，只需要按照一定規則收集相關的覆蓋率報告並上報到指定服務器即可實現。

※  覆蓋率服務

覆蓋率服務是整個前端代碼覆蓋率體系的核心，起到「承上啓下」的作用。

• 上則與接入了覆蓋率SDK的業務系統相通，接收各個業務系統的原始覆蓋率數據，並進行清洗、整理、合併、存儲的操作。
• 下則與其他關聯繫統（覆蓋率報告展示平台、覆蓋率平台、發佈平台、流水線等）連通，為各個關聯繫統提供核心覆蓋能力。

覆蓋率服務核心能力

• 收集處理報告： 收集瀏覽器上報的測試覆蓋率數據，按「應用」、「分支」、「Color」、「時間段」做數據合併和存儲。
• 版本發佈處理：版本發佈後僅刪除「當前應用 + 當前環境 + 當前分支」，改動文件的報告數據。
• 覆蓋率報告： 覆蓋率數據展示數據支持和備份能力。
• 橋接覆蓋率平台：提供必要的接口，比如權限對接、報告管理、任務調度、流水線編排（發佈攔截讀取覆蓋率平台指標）等交互。
• 報告機器人：通過報告機器人在特定時機通過飛書消息形式向特定羣組發送覆蓋率報告。

覆蓋率服務旨在實現「應用維度」，未來會支持「需求維度」、「人員維度」、「頁面維度」的覆蓋率：

※  報告展示

為了讓開發同學能夠更加清晰且實時的知道哪一行代碼沒有被覆蓋，我們提供了兩種報告形式：

• 實時覆蓋率報告： 與Master分支對比，得到測試分支與主幹分支的差異，並過濾出增量變動代碼的覆蓋率情況，且報告是實時更新的，無需反覆生成報告，測試完刷新即可查看最新覆蓋情況。
• 覆蓋率報告快照： 每個版本准入和準出階段，我們會保存一份覆蓋率報告的快照，這個快照會固定與生成快照時的commit**進行對比，生成之後不會改變，方便我們查看不同版本各個應用的覆蓋率情況。

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

目前，我們也支持「需求維度覆蓋率報告」、「人員維度覆蓋率報告」，將每行代碼的改動與具體的需求和人員關聯上，支持這個功能以後，我們可以更好地衡量某個需求的的代碼測試質量，開發同學也可以利用人員維度的覆蓋率報告更加高效地處理各自負責代碼的未覆蓋問題，提升自測和測試效率。

※  覆蓋率平台 & 協同流水線

有了針對指定應用和環境生成覆蓋率報告的基礎能力後，我們就可以將我們的能力對接到覆蓋率平台，這樣可以藉助覆蓋率平台現有的管理能力：

• 應用註冊
• 環境管理
• 報告管理
• 任務管理

除此之外，我們還可以複用覆蓋率平台與協同流水線之間現成的通信協議和能力，快速對接到協同流水線當中，實現需求、應用的「准入」和「準出」卡口，讓覆蓋率不達標的應用無法操作提測和上線，以此築起質量保障的長城，為穩定生產保駕護航。

E2E 自動化測試

上面我們簡單聊了整個前端代碼覆蓋率的各個模塊，細心的同學應該發現了，我們一直説的都是「增量代碼覆蓋率」，但沒有提到「全量代碼覆蓋率」。難道全量代碼覆蓋率對我們來説可有可無嗎？其實不然！

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

其實，這並不是我們技術能力上達不到，而是我們不可能要求測試或開發同學每次測試都把這個系統迴歸一邊，要知道，一個成熟的業務系統，動輒就是幾十萬行代碼級別的，我們不可能依靠人工進行全量回歸。

所以，就到了另一個前端質量保障的主角登場了，那就是 「E2E自動化測試」，只要有了自動化測試的能力，只要錄製（自動分析）一次，下次需求開發之後，就可以直接全量自動化迴歸了。

關於E2E自動化測試是前端平台增長域的同學負責推進的，在這裏就不過多展開E2E的技術細節了。

推廣方案

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

應用接入

2025年Q1在實驗域的應用內試點運行幾個版本後，覆蓋率相關功能已相對比較穩定，因此Q2正式開始在前端平台內部的其他業務域中推廣，各個業務域根據各自應用的情況，按照以下標準對應用設定接入優先級。

※  接入優先級

• P0 應用：應用可接入且優先級高（中後台類應用）。
• P1 應用：應用可接入但是相對優先級較低，或改動頻率較低，對於收集覆蓋率訴求不高。
• P2 應用：應用不可接入或者暫不支持接入，未來考慮實現支持收集覆蓋率功能。

為確保應用接入順利，我們保證絕大部分應用可以開箱即用地接入SDK，除了少數RsPack和MF架構的應用需要特殊接入外，其他應用的接入成本均相當低廉。

統一標準

應用接入完成之後，各域的已接入應用就可以通過代碼覆蓋率來衡量研發自測的質量了，那麼接下來就要正式對我們的終極目標“研發自測率”發起進攻了。

各個域對於「可研發自測需求」的顆粒度標準是參差不齊的，但如果要在技術部範圍內將研發自測順利的推行起來，方便後期統一出具相關報告，並根據情況調整科研發自測標準，那麼，擺在我們面前的一個最大的難題就是：統一研發自測顆粒度標準。

在進行標準統一的討論的過程中，我們也遇到了很多問題，其中反饋最多的問題就是：

• 有些業務域一旦按照統一標準判定可自測需求的話，可自測需求池子就會比原先多出很多可自測需求，雖然可自測需求不代表必須自測，但也需要相關的研發同學和測試同學進行一定的溝通，確認該需求是否能夠實際自測並打標，這會增加溝通成本。如果需要反覆去 “需求管理平台” 篩選確認，效率太低。

針對這種問題，我們前期通過腳本，按照最新標準將各業務域每個版本的應自測需求都導出到多維表格，並將可以輔助判斷需求是否可以自測的一些信息（如當前需求名稱、鏈接、預計是否可自測、實際是否自測、需求總估時[含測試]、需求總估時[不含測試]等）都一同導出，方便各域負責人快速確認（後期研發效能同學會統一開發相關研發自測的數據統計報表和需求明細，方便各域進行分析和確認）：

此外，我們還確定下來，由於各域的實操標準目前參差不齊，可自測需求可以統一標準。但各域實操時，還是按照各域現行標準實行，即目前這個階段，我們僅擴大可自測需求的池子，但最終是否自測，還是按照各域實操標準來，後續再根據運營情況調整策略，逐步逼近目標。

目標制定

我們通過對前端平台各域Q1的自測數據進行分析，得到了當前各域的現狀：

• 實際自測率：15.29%
• 可自測完成率：42.22%

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

基於這種現狀，如果想要一蹴而就直接打到25%是不太可能的，因此，我們將戰線拉長，分兩個季度來逐步完成目標：

• Q2：統一可自測標準、提升可自測完成率，通過自測完成率的提升帶動實際自測率的提升，因此確定下來：
• • Q2 自測率：21%
  • Q2 完成率：65%
• Q3：加強自測能力，提高可自測標準，通過擴大池子來整體提升自測率，因此確定下來：
• • Q3 自測率：25%
  • Q3 完成率：80%

以上為前端平台整體的目標，上面也説了，各域由於業務特性，存在不同的情況，如果一概而論，對於某些域來説難度堪比登天，對於某些域來説又是輕而易舉。因此我們還針對各域Q2的現狀，為各域量身定製的一套差異化目標：

• 實際自測率：
• • 在高位，持續保持（30%）
  • 在中低位，但是空間大 （25%）
  • 在低位，空間有限的，取可自測率為目標
• 自測完成率：
• • 原本處於低位（9.52%）：設定特殊目標25%
  • 原本處於中位（27%～41%）：設定最低目標65%
  • 原本處於高位，在原基礎上提升一定比例即可

需求研發自測影響因素分析

在標準完成統一以及目標完成制定之後，我們進一步下鑽數據，想要通過各版本的自測數據分析，找出可能影響研發自測率的因素。首先，我們先預設了幾個可能影響研發自測的因素：

• 需求全棧率： 由於全棧開發的目標需求也是簡單的小顆粒度需求，跟研發自測的目標需求有一定重合，而如果一個需求是完全全棧的話，就不需要前端參與了，會導致需要前端參與的小顆粒度簡單需求數量減少。

全棧

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

• 大顆粒度需求佔比：由於前端總體資源是相對固定的，一個版本中，如果大顆粒度需求比較多，那麼前端能夠承接的小顆粒度需求自然就會變少，從而導致前端整體可自測需求比較少，直接影響自測率。

• 小顆粒度需求佔比：有些版本，即使大顆粒度的版本不多，小顆粒度的需求也不見得會變多，需求有可能集中在不大不小的區間內，因此小顆粒度需求的多少也會影響到自測率。

• 版本平均顆粒度：除了大顆粒度需求和小顆粒度需求外，整個版本的平均顆粒度的高低也會一定程度上影響到可自測需求的多少，通常來説，平均顆粒度越高，可自測需求就會相對越少，反之亦然。當然版本平均顆粒度並不會直接影響「實際自測率」，而是通過「可自測率」影響可自測需求池的大小，從而最終影響「實際自測率」。

但由於是間接影響，中間可能受到「自測完成率」以及「額外自測需求數」等其他因素的影響，「版本平均顆粒度」和「實際自測率」之間，並不總是成負相關的關係，因此需要進一步下鑽分析。

【平均顆粒度】【應自測率】：通常成反比關係

【自測完成率】【實際自測率】：通常成正比關係

• 純前端需求佔比：根據過往數據分析，純前端需求自測佔比相較於非純前端需求自測佔比會高很多，因此，一個迭代當中，純前端需求的多少也會影響自測率。

• 版本週期：受到各種節假日的影響，得物每個迭代週期可能都不太一樣，如 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.從零實現模塊級代碼影響面分析方案｜得物技術

文 / 康輝

關注得物技術，每週更新技術乾貨

要是覺得文章對你有幫助的話，歡迎評論轉發點贊～

未經得物技術許可嚴禁轉載，否則依法追究法律責任。