1.背景

1.1困境

團隊內一位測試者對接多位開發者，開發者的需求提測速度遠大于測試者的測試速度，導致開發者提測的需求堆積待測試，無法及時上線，團隊測試資源匱乏的問題愈加凸顯，直接影響團隊的需求交付速度。

圖1-開發工作流

測試資源匱乏的問題在支付組中尤為嚴重，且支付項目業務復雜、上手周期長，要求開發者與測試者盡可能的穩定，短期內引進新人也很難解決問題。因此團隊的目標是在現有資源供給下，不進行人員變動，而通過優化團隊內部的質量保證工作量的分配，既保證團隊穩定與研發質量，又提升需求交付速率。

1.2剖析

?1.2.1 概念

在解構團隊困境之前，首先定義若干概念，建立一個簡單的數學模型進行分析。

(1) 開發側

?  開發資源：團隊內部的開發者人數，例如10人；

?  單位提測速率：每個開發者平均每天提測的需求數，例如2個/人天；

?  提測速率：團隊平均每天提測的需求數，顯然有：提測速率=單位提測速率×開發資源=2×10=20個/天。

圖2-提測速率公式

(2) 測試側

?  測試資源：團隊內部的測試者人數，例如2人；

?  單位測試速率：每個測試者平均每天測試完成的需求數，例如4個/人天；

?  測試速率：團隊平均每天測試完成的需求數，顯然有：測試速率=單位測試速率×測試資源=4×2=8個/天。

圖3-測試速率公式

(3) 上線

?  需求交付速率：指團隊平均每天上線交付的需求數，由于需求通過測試后基本就能上線了,顯然有：需求交付速率≈測試速率=8個/天。

圖4-需求交付速率

圖5-提測速率>測試速率，需求堆積，需求交付速率受限

?1.2.2 提測速率與測試速率的大小關系

下面分析一下提測速率與測試速率的三種大小關系：

(1) 提測速率>測試速率

存在的問題：我們團隊中目前存在這種大小關系，雖然資源都被充分利用，但資源分配不合理，導致開發者提測的需求堆積待測試，需求無法及時交付，需求交付速率與團隊分配到的資源不匹配。

解決方案一：重新分配資源，減少開發資源，增加測試資源；

解決方案二：重新分配質量保證工作量，將一部分工作量由測試者轉移至開發者。

(2) 提測速率<測試速率

存在的問題：資源未被充分利用，開發資源被充分利用，但測試資源出現閑置。

解決方案一：重新分配資源，增加開發資源，減少測試資源；

解決方案二：重新分配質量保證工作量，將一部分工作量由開發者轉移至測試者。

(3) 提測速率≈測試速率

這是一種理想情況，資源都被充分利用，且資源分配合理，需求交付速率與團隊分配到的資源匹配。

?1.2.3 提測速率與測試速率的動態平衡

很顯然，我們團隊的現狀是：提測速率>測試速率，目標是：提測速率≈測試速率，解決方案是：提升測試速率和/或降低提測速率。

圖6-現狀、方案與目標

(1) 測試側

由于測試資源固定，因此要提升測試速率，只能提升單位測試速率，即提升每個測試者平均每天測試完成的需求數，例如從4個/人天提升至6個/人天。

圖7-提升測試速率

問題：如何提升單位測試速率？

這里再引入幾個概念“交付能力”與“測試復雜度”：

?  測試復雜度：指平均每個需求需要消耗多少測試資源才能測試完成，例如2人天/個表示平均每個需求需要2個測試者花1天時間才能測試完成；

?  交付能力：指測試者平均每天交付工作成果的能力，交付能力與測試者的“工作能力”、“工作時長”有關，因此有如下關系：

圖8-交付能力

交付能力是一個沒有單位的系數，該系數越大，表示測試者的交付能力越強。

因此單位測試速率與交付能力、測試復雜度有如下關系：

圖9-單位測試速率

目前測試資源都被充分利用，工作都已飽和，工作時長無法提高；工作能力的提升也不是一蹴而就的，短期內工作能力也是一個常數，因此要提升單位測試速率只能降低測試復雜度。

圖10-提升單位測試速率

問題：如何降低測試復雜度？

最直觀的方式就是“減少測試者測試完成每個需求的工作量”，把測試承擔的一部分質量保證工作量轉移出去，例如之前測試者平均需要為每個需求創建并測試10個用例，轉移出去后僅需7.5個用例，這樣測試復雜度就降低了25%。

那么應該把這部分質量保證工作量轉移給誰，由于目前提測速率>測試速率，很顯然把這部分質量保證工作量轉移至開發者，下面來看一下轉移之后對開發者的影響。

(2) 開發側

對于開發者，也有交付能力這一概念，同時引入“提測復雜度”這一概念：

?  提測復雜度：指平均每個需求需要消耗多少開發資源才能開發完成并提測，例如2人天/個表示平均每個需求需要2個開發者花1天時間才能開發完成并提測。

開發者在開發過程中以及提測之前肯定會進行自測與基本的冒煙測試，因此開發者在完成一個需求時，除了編寫代碼的工作量外，還需要一定的測試工作量，因此提測復雜度由開發復雜度和測試復雜度構成，有如下關系：

圖11-單位提測速率

由于把一部分質量保證工作量由測試者轉移至開發者，因此開發者的測試復雜度升高了，這樣就導致提測復雜度升高了，最終導致單位提測速率降低了。

圖12-降低單位提測速率

隨著單位提測速率的降低，開發的提測速率也就降低了。

圖13-降低提測速率

在質量保證工作量轉移之后，測試者的測試速率升高了，開發者的提測速率降低了，因此只要把握好轉移的量，就能實現提測速率與測試速率的動態平衡。

圖14-結果

1.3結論

經過分析發現，可以通過優化團隊內部質量保證工作量的分配，動態地將一部分質量保證工作量由測試者轉移至開發者，就能實現提測速率與測試速率的動態平衡，最終實現團隊需求交付速率的最大化。

這種工作量的分配優化，其實就是團隊內部資源的分配優化，即使用開發資源換取測試資源，由開發者承擔更多的質量保證工作，減少對測試資源的依賴，這樣就在不進行人員變動的情況下，解決了開發資源與測試資源分配不合理的問題。

1.4團隊動員

在當前行業寒冬之下，看到“由開發者承擔更多的測試工作，減少對測試資源的依賴”相關字眼，大家可能會心生疑慮，彈性研發是否意味著“壓榨開發者并實行去測試化”？其實不然，下面分別從開發和測試的角度進行闡述以消除疑慮。

對于開發，根據上面的分析，彈性研發確實增加了開發者的工作量，但并未要求開發者增加工作時長，最終單位提測速率也降低了，這意味著彈性研發在增加開發者工作量的同時，也相應地拉長了開發者的開發周期，并不存在壓榨開發者。只不過要求開發者采取一定措施保證研發質量，這樣才有信心幫助降低測試者的測試復雜度。

測試者經歷過完整的軟件測試理論學習與技能培訓，是軟件工程中保證質量不可或缺的一環，測試者以第三者的視角審視開發者的產出，并使用其專業技能揪出隱藏的缺陷。在我們團隊中，測試者正經歷長時間的高強度加班，彈性研發正是為測試者減負，絕不是使用開發者取代測試者。

2.質量保證是系統性的工程

2.1概述

開發者的疑問：明明我已經做得很好了，為什么項目上線后還是出現了bug或不滿足用戶訴求的情況？

質量保證是系統性的工程，產品和測試分別是開發的上游和下游，從產品、到開發、再到測試，每一環缺一不可。

2.2產品

對于產品，在需求分析階段，要求產品準確理解用戶訴求，并針對用戶訴求執行縝密的需求分析；在產品設計階段，要求產品產出清晰的產品原型與完善的產品需求文檔等，這些都是開發與測試在工作時的重要參考資料；尤其需要強調產品架構，它是技術架構的基礎，因此要求產品在設計產品架構時具備一定的前瞻性與抽象性。

2.3開發

對于開發，必須準確理解產品需求，并根據產品架構設計科學合理的技術架構；深刻理解項目中使用的各種中間件與框架；編寫的代碼易于維護與閱讀、符合編碼規范、可測試；在提測前至少進行冒煙測試以及一定程度的正向自測。

2.4測試

對于測試，要求準確理解產品需求，根據產品需求文檔對業務場景進行分析，編寫科學且場景覆蓋全面的測試用例，以第三者的視角審視開發者的產出并揪出隱藏的bug。

3.彈性研發團隊

3.1概述

彈性研發團隊主要包含兩部分，彈性和右移：

?  右移：就是讓開發者在開發工作流中盡早介入測試，這樣才能盡早發現并解決問題，大大降低解決軟件缺陷的成本；

?  彈性：是指可以根據團隊內開發資源與測試資源的配比與實際交付能力動態調整轉移的質量保證工作量，使提測速率與測試速率保持動態平衡，實現需求交付速率的最大化。

3.2越早發現問題，解決問題的成本就越低

谷歌經過多年實踐發現，在開發工作流中，越早發現問題，解決問題的成本就越低。如下圖所示，通過測試者發現問題再由開發者在測試環境中檢查并解決問題就已經導致解決問題的成本一定程度上的增加；一旦在軟件投產后遇到問題，解決問題的成本更是呈指數上升。

圖片

橫坐標從左到右是開發工作流中從早到晚的各個階段，縱坐標是解決軟件缺陷的成本

在人工測試階段發現并解決缺陷的工作流大致如下圖所示，很明顯整個流程相比開發者自測更為復雜且涉及測試者與開發者之間的溝通，這些都會帶來額外的成本。

圖16-測試開發交互流程

3.3右移動態化

右移動態化可一定程度上自適應團隊內開發資源與測試資源的配比與實際交付能力，使團隊的提測速率與測試速率保持動態平衡，最終實現需求交付速率的最大化。

3.4測試即代碼

彈性研發提倡測試即代碼，指通過代碼來表達測試，例如編寫單元測試，使測試行為形成代碼資產。傳統的開發者自測行為，例如在IDE中進行debug、在HTML頁面點擊按鈕調用接口，無法形成資產、無法復用、無法共享。

測試即代碼要求代碼是可測試的，代碼難以測試說明代碼職責太多、依賴關系混亂、低內聚高耦合，因此測試即代碼能夠促使代碼模塊化、高內聚低耦合、單一職責化。

使用代碼表達測試后，就可以反復運行這些測試代碼，每次更新代碼后都可以運行這些測試代碼，避免更新代碼引入bug，因此測試即代碼使開發者對更新代碼更有信心，更利于快速迭代軟件，以適應不斷變化的市場環境與用戶需求。

在更新代碼后，一旦無法通過舊有的測試用例，就說明更新代碼改變了業務邏輯，

這也就發出了提醒，是否需要更新相關的文檔，促使文檔與代碼保持同步。

3.5測試自動化

在踐行測試即代碼后，就可以持續自動運行這些代碼化的測試用例，例如在把代碼合并至master分支時。自動化運行測試成本低、效率高，因此可頻繁運行，持續對系統進行測試。

3.6建立質量文化

彈性研發提倡開發者更多地盡早地參與質量保證，提升開發者的質量意識，增強開發者的質量保證參與感，強調代碼寫完并不意味著開發完成。

彈性研發促使開發者編寫模塊化的、可測試的代碼，可推動開發者使用更合理更科學的設計方案，對于建立團隊的質量文化有重要意義。

3.7與測試左移的比較

傳統測試左移的工作流是，測試者創建一定數量的基礎測試用例，開發者開發完成后必須進行自測且通過這些測試用例之后方可提測，基本思想也是讓開發者盡早參與質量保證，盡早發現并解決問題以降低解決問題的成本。

傳統測試左移的模式相對固定，通過測試用例來驅動開發，有相對固定的流程，一定程度上限制了開發者的主觀能動性。而彈性研發提倡開發者通過實踐來發掘任何能保證研發質量的手段，堅信成功的思想或手段是會傳播開的，并最終被廣泛接受。

4.如何彈性右移

4.1概述

彈性研發提倡開發者更多地盡早地參與質量保證，降低測試復雜度，幫助建立質量文化，因此彈性右移不拘泥于固定的形式，只要開發者在實踐彈性右移后有信心保證研發質量即可。

為了避免“當局者迷”與“思維定式”，建議由代碼作者以外的第三者參與進來保證質量，機器或人工皆可，以下著重描述若干可供參考的實踐方向。

4.2靜態代碼掃描

靜態代碼掃描是指使用程序分析源代碼以發現潛在的問題，如bug、反模式及其他不需要運行代碼就能發現的問題，例如大家熟知的SonarQube以及IDEA插件Alibaba Java Coding Guidelines。在AI大行其道的當下，也可考慮使用相關AI工具進行靜態代碼掃描。

4.3組內代碼評審

組內代碼評審是由與代碼作者同組的另一名成員負責代碼審核，同組成員意味著平時負責開發的業務與項目完全相同或相似，這有助于降低代碼評審的門檻，同時有助于提升巴士因子。

巴士因子是軟件開發中的一個術語，用于衡量軟件項目的相關知識在團隊成員中的共享程度。一個項目一旦有超過閾值的關鍵成員無法參與（例如被巴士撞傷了）就會導致項目無法推進甚至失敗，這個閾值就是巴士因子。巴士因子強調項目的有關知識不應該僅被極少數人所掌握。組內代碼評審促使同組至少有2名成員掌握所有業務需求與代碼。

程序員由于崗位的特殊性，要求其把主要時間和精力花在編寫好代碼上，而不是整天與人溝通，因此組內代碼評審也是一種促進組內同事學習和溝通的渠道。

目前我們團隊定期進行團隊范圍的代碼走查，這也是一種形式的代碼評審，有助于形成團隊的統一編碼規范與風格。

4.4開發者驅動的自動化測試

?4.4.1 編寫測試代碼

彈性研發團隊提倡測試即代碼與測試自動化，因此如何編寫測試代碼非常關鍵。

好的測試代碼是不變的、健壯的、明確的：

?  不變的測試：除非被測代碼的需求改變了，否則測試代碼一旦編寫完成后就不再修改；

?  健壯的測試：在被測代碼所實現的需求沒變的情況下，測試代碼總是能夠運行通過；

?  清晰的測試：在測試代碼運行失敗的情況下，能夠明確知道是哪出問題了。

(1) 編寫不變且健壯的測試代碼

在實踐中，可以把開發者對代碼的修改分為四類：

第一類是對代碼進行重構：由于被測代碼的需求沒變，因此對代碼進行重構不應該使測試代碼運行失敗。若測試代碼運行失敗，則說明重構影響了系統的行為，或測試代碼的被測代碼太過底層。

第二類是修復bug而修改代碼：bug的存在說明現有的測試代碼覆蓋的用例不夠全，在修復bug后，應該新增測試用例對應的測試代碼，但不需要修改已有測試代碼。

第三類是添加新需求而新增代碼：在編寫完新需求代碼后，應該新增針對這部分代碼的測試代碼，但不需要修改已有測試代碼。

第四類是因需求改變而修改代碼：由于需求改變了，因此現有的測試代碼肯定會運行失敗，此時必須針對變更后的需求修改測試代碼。

綜上所述，理想情況下，只有在現有需求改變了，測試代碼才會運行失敗，才需要修改測試代碼，這樣一來維護測試代碼的成本就大大降低了。

編寫不變且健壯的測試代碼的目標是：只要需求沒有變，測試代碼就始終能夠運行通過，這樣也就不需要修改測試代碼。達到這一目標最簡單最直接的測試方法就是按照用戶調用系統的方式來測試系統，也就是說，針對系統的公共API進行測試，而不是系統的實現細節。

那么哪些代碼才能稱得上公共API呢？

僅供一個類內部使用的private輔助方法不是公共API，應該通過測試那些使用該private輔助方法的代碼來測試它，這是因為private輔助方法過于底層，可能被修改的概率很大。

項目中的Service方法與通用工具類都可視為公共API，由于它對整個項目甚至所有其他項目公開，因此具備一定的抽象性與穩定性，即使內部的實現細節可能被修改，但對外呈現的行為應該是相對穩定的。

項目對外暴露的接口是公共API，由于它直接對外公開，因此具備很高的抽象性與穩定性。

(2) 編寫清晰的測試代碼

清晰的測試是指測試代碼存在的目的以及運行失敗的原因都很明確，這樣在遇到測試代碼運行失敗時才能高效地進行修復。

下面以測試轉賬Service方法為例來描述何謂清晰的測試，轉賬Service方法有如下簽名：

// code=0表示轉賬成功，code!=0表示轉賬失敗及其原因  
public R<?> transfer(Account from, Account to, double amount);

清晰的測試應該是完整且簡潔的，完整是指測試代碼包含讀者理解測試的所有相關信息，簡潔是指除此之外測試代碼不包含其他信息，更不能包含任何邏輯，例如字符串拼接或流程控制等。

清晰的測試應該測試方法的行為而不是方法本身，應該為方法的每一種行為分別編寫測試方法，這樣測試方法就不會隨著被測方法行為的膨脹而膨脹，也不需要修改能夠運行通過的測試代碼。以轉賬方法為例，其行為包括轉賬成功、因出款戶余額不足導致的轉賬失敗、因出款戶不存在導致的轉賬失敗等，因此要分別為這些行為編寫測試方法。

面向行為的測試代碼由三部分組成，“given”定義預設的系統環境，“when”定義對系統執行的操作，“then”驗證結果。測試方法也應該由測試行為命名。

下面展示一個測試轉賬成功的測試方法：

@Test  
public void testTransferSuccess() {  
 // given  
 Account from = new Account("account1", 50.00);  
 Account to = new Account("account2", 40.00);  
   
 // when  
 R<?> r = transfer(from, to, 20.00);  
   
 // then  
 Assert.assertEquals(0, r.getCode());  
 Assert.assertEquals(30, from.getBalance());  
 Assert.assertEquals(60, to.getBalance());  
}

最后聲明一點，一旦你覺得需要額外編寫測試來驗證測試代碼，就表明測試遠遠不夠清晰。

?4.4.2 自動運行測試代碼

可在把代碼push到遠程倉庫時，在本地執行maven的test命令即可自動運行測試代碼，也可在A-One編譯構建項目時自動運行測試代碼。

4.5AI自動化測試

目前我們團隊有使用IDEA插件GitHub Copilot，它由OpenAI提供支持，基于數十億行開源代碼構建的模型，可實現根據代碼注釋編寫代碼、創建單元測試與靜態代碼掃描。這里也推薦大家使用這款插件，利用AI進行自動化測試肯定是未來的趨勢，這里也提倡大家多多實踐多多分享。

作者簡介

張超

■服務端研發部-服務端買用技術團隊-交易平臺組

■ 2021年加入汽車之家，目前主要負責權益中臺的建設與后端開發工作，熱衷探索與分享。