1.背景

1.1困境

團(tuán)隊(duì)內(nèi)一位測(cè)試者對(duì)接多位開(kāi)發(fā)者，開(kāi)發(fā)者的需求提測(cè)速度遠(yuǎn)大于測(cè)試者的測(cè)試速度，導(dǎo)致開(kāi)發(fā)者提測(cè)的需求堆積待測(cè)試，無(wú)法及時(shí)上線，團(tuán)隊(duì)測(cè)試資源匱乏的問(wèn)題愈加凸顯，直接影響團(tuán)隊(duì)的需求交付速度。

圖1-開(kāi)發(fā)工作流

測(cè)試資源匱乏的問(wèn)題在支付組中尤為嚴(yán)重，且支付項(xiàng)目業(yè)務(wù)復(fù)雜、上手周期長(zhǎng)，要求開(kāi)發(fā)者與測(cè)試者盡可能的穩(wěn)定，短期內(nèi)引進(jìn)新人也很難解決問(wèn)題。因此團(tuán)隊(duì)的目標(biāo)是在現(xiàn)有資源供給下，不進(jìn)行人員變動(dòng)，而通過(guò)優(yōu)化團(tuán)隊(duì)內(nèi)部的質(zhì)量保證工作量的分配，既保證團(tuán)隊(duì)穩(wěn)定與研發(fā)質(zhì)量，又提升需求交付速率。

1.2剖析

?1.2.1 概念

在解構(gòu)團(tuán)隊(duì)困境之前，首先定義若干概念，建立一個(gè)簡(jiǎn)單的數(shù)學(xué)模型進(jìn)行分析。

(1) 開(kāi)發(fā)側(cè)

?  開(kāi)發(fā)資源：團(tuán)隊(duì)內(nèi)部的開(kāi)發(fā)者人數(shù)，例如10人；

?  單位提測(cè)速率：每個(gè)開(kāi)發(fā)者平均每天提測(cè)的需求數(shù)，例如2個(gè)/人天；

?  提測(cè)速率：團(tuán)隊(duì)平均每天提測(cè)的需求數(shù)，顯然有：提測(cè)速率=單位提測(cè)速率×開(kāi)發(fā)資源=2×10=20個(gè)/天。

圖2-提測(cè)速率公式

(2) 測(cè)試側(cè)

?  測(cè)試資源：團(tuán)隊(duì)內(nèi)部的測(cè)試者人數(shù)，例如2人；

?  單位測(cè)試速率：每個(gè)測(cè)試者平均每天測(cè)試完成的需求數(shù)，例如4個(gè)/人天；

?  測(cè)試速率：團(tuán)隊(duì)平均每天測(cè)試完成的需求數(shù)，顯然有：測(cè)試速率=單位測(cè)試速率×測(cè)試資源=4×2=8個(gè)/天。

圖3-測(cè)試速率公式

(3) 上線

?  需求交付速率：指團(tuán)隊(duì)平均每天上線交付的需求數(shù)，由于需求通過(guò)測(cè)試后基本就能上線了,顯然有：需求交付速率≈測(cè)試速率=8個(gè)/天。

圖4-需求交付速率

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

?1.2.2 提測(cè)速率與測(cè)試速率的大小關(guān)系

下面分析一下提測(cè)速率與測(cè)試速率的三種大小關(guān)系：

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

存在的問(wèn)題：我們團(tuán)隊(duì)中目前存在這種大小關(guān)系，雖然資源都被充分利用，但資源分配不合理，導(dǎo)致開(kāi)發(fā)者提測(cè)的需求堆積待測(cè)試，需求無(wú)法及時(shí)交付，需求交付速率與團(tuán)隊(duì)分配到的資源不匹配。

解決方案一：重新分配資源，減少開(kāi)發(fā)資源，增加測(cè)試資源；

解決方案二：重新分配質(zhì)量保證工作量，將一部分工作量由測(cè)試者轉(zhuǎn)移至開(kāi)發(fā)者。

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

存在的問(wèn)題：資源未被充分利用，開(kāi)發(fā)資源被充分利用，但測(cè)試資源出現(xiàn)閑置。

解決方案一：重新分配資源，增加開(kāi)發(fā)資源，減少測(cè)試資源；

解決方案二：重新分配質(zhì)量保證工作量，將一部分工作量由開(kāi)發(fā)者轉(zhuǎn)移至測(cè)試者。

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

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

?1.2.3 提測(cè)速率與測(cè)試速率的動(dòng)態(tài)平衡

很顯然，我們團(tuán)隊(duì)的現(xiàn)狀是：提測(cè)速率>測(cè)試速率，目標(biāo)是：提測(cè)速率≈測(cè)試速率，解決方案是：提升測(cè)試速率和/或降低提測(cè)速率。

圖6-現(xiàn)狀、方案與目標(biāo)

(1) 測(cè)試側(cè)

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

圖7-提升測(cè)試速率

問(wèn)題：如何提升單位測(cè)試速率？

這里再引入幾個(gè)概念“交付能力”與“測(cè)試復(fù)雜度”：

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

?  交付能力：指測(cè)試者平均每天交付工作成果的能力，交付能力與測(cè)試者的“工作能力”、“工作時(shí)長(zhǎng)”有關(guān)，因此有如下關(guān)系：

圖8-交付能力

交付能力是一個(gè)沒(méi)有單位的系數(shù)，該系數(shù)越大，表示測(cè)試者的交付能力越強(qiáng)。

因此單位測(cè)試速率與交付能力、測(cè)試復(fù)雜度有如下關(guān)系：

圖9-單位測(cè)試速率

目前測(cè)試資源都被充分利用，工作都已飽和，工作時(shí)長(zhǎng)無(wú)法提高；工作能力的提升也不是一蹴而就的，短期內(nèi)工作能力也是一個(gè)常數(shù)，因此要提升單位測(cè)試速率只能降低測(cè)試復(fù)雜度。

圖10-提升單位測(cè)試速率

問(wèn)題：如何降低測(cè)試復(fù)雜度？

最直觀的方式就是“減少測(cè)試者測(cè)試完成每個(gè)需求的工作量”，把測(cè)試承擔(dān)的一部分質(zhì)量保證工作量轉(zhuǎn)移出去，例如之前測(cè)試者平均需要為每個(gè)需求創(chuàng)建并測(cè)試10個(gè)用例，轉(zhuǎn)移出去后僅需7.5個(gè)用例，這樣測(cè)試復(fù)雜度就降低了25%。

那么應(yīng)該把這部分質(zhì)量保證工作量轉(zhuǎn)移給誰(shuí)，由于目前提測(cè)速率>測(cè)試速率，很顯然把這部分質(zhì)量保證工作量轉(zhuǎn)移至開(kāi)發(fā)者，下面來(lái)看一下轉(zhuǎn)移之后對(duì)開(kāi)發(fā)者的影響。

(2) 開(kāi)發(fā)側(cè)

對(duì)于開(kāi)發(fā)者，也有交付能力這一概念，同時(shí)引入“提測(cè)復(fù)雜度”這一概念：

?  提測(cè)復(fù)雜度：指平均每個(gè)需求需要消耗多少開(kāi)發(fā)資源才能開(kāi)發(fā)完成并提測(cè)，例如2人天/個(gè)表示平均每個(gè)需求需要2個(gè)開(kāi)發(fā)者花1天時(shí)間才能開(kāi)發(fā)完成并提測(cè)。

開(kāi)發(fā)者在開(kāi)發(fā)過(guò)程中以及提測(cè)之前肯定會(huì)進(jìn)行自測(cè)與基本的冒煙測(cè)試，因此開(kāi)發(fā)者在完成一個(gè)需求時(shí)，除了編寫(xiě)代碼的工作量外，還需要一定的測(cè)試工作量，因此提測(cè)復(fù)雜度由開(kāi)發(fā)復(fù)雜度和測(cè)試復(fù)雜度構(gòu)成，有如下關(guān)系：

圖11-單位提測(cè)速率

由于把一部分質(zhì)量保證工作量由測(cè)試者轉(zhuǎn)移至開(kāi)發(fā)者，因此開(kāi)發(fā)者的測(cè)試復(fù)雜度升高了，這樣就導(dǎo)致提測(cè)復(fù)雜度升高了，最終導(dǎo)致單位提測(cè)速率降低了。

圖12-降低單位提測(cè)速率

隨著單位提測(cè)速率的降低，開(kāi)發(fā)的提測(cè)速率也就降低了。

圖13-降低提測(cè)速率

在質(zhì)量保證工作量轉(zhuǎn)移之后，測(cè)試者的測(cè)試速率升高了，開(kāi)發(fā)者的提測(cè)速率降低了，因此只要把握好轉(zhuǎn)移的量，就能實(shí)現(xiàn)提測(cè)速率與測(cè)試速率的動(dòng)態(tài)平衡。

圖14-結(jié)果

1.3結(jié)論

經(jīng)過(guò)分析發(fā)現(xiàn)，可以通過(guò)優(yōu)化團(tuán)隊(duì)內(nèi)部質(zhì)量保證工作量的分配，動(dòng)態(tài)地將一部分質(zhì)量保證工作量由測(cè)試者轉(zhuǎn)移至開(kāi)發(fā)者，就能實(shí)現(xiàn)提測(cè)速率與測(cè)試速率的動(dòng)態(tài)平衡，最終實(shí)現(xiàn)團(tuán)隊(duì)需求交付速率的最大化。

這種工作量的分配優(yōu)化，其實(shí)就是團(tuán)隊(duì)內(nèi)部資源的分配優(yōu)化，即使用開(kāi)發(fā)資源換取測(cè)試資源，由開(kāi)發(fā)者承擔(dān)更多的質(zhì)量保證工作，減少對(duì)測(cè)試資源的依賴(lài)，這樣就在不進(jìn)行人員變動(dòng)的情況下，解決了開(kāi)發(fā)資源與測(cè)試資源分配不合理的問(wèn)題。

1.4團(tuán)隊(duì)動(dòng)員

在當(dāng)前行業(yè)寒冬之下，看到“由開(kāi)發(fā)者承擔(dān)更多的測(cè)試工作，減少對(duì)測(cè)試資源的依賴(lài)”相關(guān)字眼，大家可能會(huì)心生疑慮，彈性研發(fā)是否意味著“壓榨開(kāi)發(fā)者并實(shí)行去測(cè)試化”？其實(shí)不然，下面分別從開(kāi)發(fā)和測(cè)試的角度進(jìn)行闡述以消除疑慮。

對(duì)于開(kāi)發(fā)，根據(jù)上面的分析，彈性研發(fā)確實(shí)增加了開(kāi)發(fā)者的工作量，但并未要求開(kāi)發(fā)者增加工作時(shí)長(zhǎng)，最終單位提測(cè)速率也降低了，這意味著彈性研發(fā)在增加開(kāi)發(fā)者工作量的同時(shí)，也相應(yīng)地拉長(zhǎng)了開(kāi)發(fā)者的開(kāi)發(fā)周期，并不存在壓榨開(kāi)發(fā)者。只不過(guò)要求開(kāi)發(fā)者采取一定措施保證研發(fā)質(zhì)量，這樣才有信心幫助降低測(cè)試者的測(cè)試復(fù)雜度。

測(cè)試者經(jīng)歷過(guò)完整的軟件測(cè)試?yán)碚搶W(xué)習(xí)與技能培訓(xùn)，是軟件工程中保證質(zhì)量不可或缺的一環(huán)，測(cè)試者以第三者的視角審視開(kāi)發(fā)者的產(chǎn)出，并使用其專(zhuān)業(yè)技能揪出隱藏的缺陷。在我們團(tuán)隊(duì)中，測(cè)試者正經(jīng)歷長(zhǎng)時(shí)間的高強(qiáng)度加班，彈性研發(fā)正是為測(cè)試者減負(fù)，絕不是使用開(kāi)發(fā)者取代測(cè)試者。

2.質(zhì)量保證是系統(tǒng)性的工程

2.1概述

開(kāi)發(fā)者的疑問(wèn)：明明我已經(jīng)做得很好了，為什么項(xiàng)目上線后還是出現(xiàn)了bug或不滿足用戶(hù)訴求的情況？

質(zhì)量保證是系統(tǒng)性的工程，產(chǎn)品和測(cè)試分別是開(kāi)發(fā)的上游和下游，從產(chǎn)品、到開(kāi)發(fā)、再到測(cè)試，每一環(huán)缺一不可。

2.2產(chǎn)品

對(duì)于產(chǎn)品，在需求分析階段，要求產(chǎn)品準(zhǔn)確理解用戶(hù)訴求，并針對(duì)用戶(hù)訴求執(zhí)行縝密的需求分析；在產(chǎn)品設(shè)計(jì)階段，要求產(chǎn)品產(chǎn)出清晰的產(chǎn)品原型與完善的產(chǎn)品需求文檔等，這些都是開(kāi)發(fā)與測(cè)試在工作時(shí)的重要參考資料；尤其需要強(qiáng)調(diào)產(chǎn)品架構(gòu)，它是技術(shù)架構(gòu)的基礎(chǔ)，因此要求產(chǎn)品在設(shè)計(jì)產(chǎn)品架構(gòu)時(shí)具備一定的前瞻性與抽象性。

2.3開(kāi)發(fā)

對(duì)于開(kāi)發(fā)，必須準(zhǔn)確理解產(chǎn)品需求，并根據(jù)產(chǎn)品架構(gòu)設(shè)計(jì)科學(xué)合理的技術(shù)架構(gòu)；深刻理解項(xiàng)目中使用的各種中間件與框架；編寫(xiě)的代碼易于維護(hù)與閱讀、符合編碼規(guī)范、可測(cè)試；在提測(cè)前至少進(jìn)行冒煙測(cè)試以及一定程度的正向自測(cè)。

2.4測(cè)試

對(duì)于測(cè)試，要求準(zhǔn)確理解產(chǎn)品需求，根據(jù)產(chǎn)品需求文檔對(duì)業(yè)務(wù)場(chǎng)景進(jìn)行分析，編寫(xiě)科學(xué)且場(chǎng)景覆蓋全面的測(cè)試用例，以第三者的視角審視開(kāi)發(fā)者的產(chǎn)出并揪出隱藏的bug。

3.彈性研發(fā)團(tuán)隊(duì)

3.1概述

彈性研發(fā)團(tuán)隊(duì)主要包含兩部分，彈性和右移：

?  右移：就是讓開(kāi)發(fā)者在開(kāi)發(fā)工作流中盡早介入測(cè)試，這樣才能盡早發(fā)現(xiàn)并解決問(wèn)題，大大降低解決軟件缺陷的成本；

?  彈性：是指可以根據(jù)團(tuán)隊(duì)內(nèi)開(kāi)發(fā)資源與測(cè)試資源的配比與實(shí)際交付能力動(dòng)態(tài)調(diào)整轉(zhuǎn)移的質(zhì)量保證工作量，使提測(cè)速率與測(cè)試速率保持動(dòng)態(tài)平衡，實(shí)現(xiàn)需求交付速率的最大化。

3.2越早發(fā)現(xiàn)問(wèn)題，解決問(wèn)題的成本就越低

谷歌經(jīng)過(guò)多年實(shí)踐發(fā)現(xiàn)，在開(kāi)發(fā)工作流中，越早發(fā)現(xiàn)問(wèn)題，解決問(wèn)題的成本就越低。如下圖所示，通過(guò)測(cè)試者發(fā)現(xiàn)問(wèn)題再由開(kāi)發(fā)者在測(cè)試環(huán)境中檢查并解決問(wèn)題就已經(jīng)導(dǎo)致解決問(wèn)題的成本一定程度上的增加；一旦在軟件投產(chǎn)后遇到問(wèn)題，解決問(wèn)題的成本更是呈指數(shù)上升。

圖片

橫坐標(biāo)從左到右是開(kāi)發(fā)工作流中從早到晚的各個(gè)階段，縱坐標(biāo)是解決軟件缺陷的成本

在人工測(cè)試階段發(fā)現(xiàn)并解決缺陷的工作流大致如下圖所示，很明顯整個(gè)流程相比開(kāi)發(fā)者自測(cè)更為復(fù)雜且涉及測(cè)試者與開(kāi)發(fā)者之間的溝通，這些都會(huì)帶來(lái)額外的成本。

圖16-測(cè)試開(kāi)發(fā)交互流程

3.3右移動(dòng)態(tài)化

右移動(dòng)態(tài)化可一定程度上自適應(yīng)團(tuán)隊(duì)內(nèi)開(kāi)發(fā)資源與測(cè)試資源的配比與實(shí)際交付能力，使團(tuán)隊(duì)的提測(cè)速率與測(cè)試速率保持動(dòng)態(tài)平衡，最終實(shí)現(xiàn)需求交付速率的最大化。

3.4測(cè)試即代碼

彈性研發(fā)提倡測(cè)試即代碼，指通過(guò)代碼來(lái)表達(dá)測(cè)試，例如編寫(xiě)單元測(cè)試，使測(cè)試行為形成代碼資產(chǎn)。傳統(tǒng)的開(kāi)發(fā)者自測(cè)行為，例如在IDE中進(jìn)行debug、在HTML頁(yè)面點(diǎn)擊按鈕調(diào)用接口，無(wú)法形成資產(chǎn)、無(wú)法復(fù)用、無(wú)法共享。

測(cè)試即代碼要求代碼是可測(cè)試的，代碼難以測(cè)試說(shuō)明代碼職責(zé)太多、依賴(lài)關(guān)系混亂、低內(nèi)聚高耦合，因此測(cè)試即代碼能夠促使代碼模塊化、高內(nèi)聚低耦合、單一職責(zé)化。

使用代碼表達(dá)測(cè)試后，就可以反復(fù)運(yùn)行這些測(cè)試代碼，每次更新代碼后都可以運(yùn)行這些測(cè)試代碼，避免更新代碼引入bug，因此測(cè)試即代碼使開(kāi)發(fā)者對(duì)更新代碼更有信心，更利于快速迭代軟件，以適應(yīng)不斷變化的市場(chǎng)環(huán)境與用戶(hù)需求。

在更新代碼后，一旦無(wú)法通過(guò)舊有的測(cè)試用例，就說(shuō)明更新代碼改變了業(yè)務(wù)邏輯，

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

3.5測(cè)試自動(dòng)化

在踐行測(cè)試即代碼后，就可以持續(xù)自動(dòng)運(yùn)行這些代碼化的測(cè)試用例，例如在把代碼合并至master分支時(shí)。自動(dòng)化運(yùn)行測(cè)試成本低、效率高，因此可頻繁運(yùn)行，持續(xù)對(duì)系統(tǒng)進(jìn)行測(cè)試。

3.6建立質(zhì)量文化

彈性研發(fā)提倡開(kāi)發(fā)者更多地盡早地參與質(zhì)量保證，提升開(kāi)發(fā)者的質(zhì)量意識(shí)，增強(qiáng)開(kāi)發(fā)者的質(zhì)量保證參與感，強(qiáng)調(diào)代碼寫(xiě)完并不意味著開(kāi)發(fā)完成。

彈性研發(fā)促使開(kāi)發(fā)者編寫(xiě)模塊化的、可測(cè)試的代碼，可推動(dòng)開(kāi)發(fā)者使用更合理更科學(xué)的設(shè)計(jì)方案，對(duì)于建立團(tuán)隊(duì)的質(zhì)量文化有重要意義。

3.7與測(cè)試左移的比較

傳統(tǒng)測(cè)試左移的工作流是，測(cè)試者創(chuàng)建一定數(shù)量的基礎(chǔ)測(cè)試用例，開(kāi)發(fā)者開(kāi)發(fā)完成后必須進(jìn)行自測(cè)且通過(guò)這些測(cè)試用例之后方可提測(cè)，基本思想也是讓開(kāi)發(fā)者盡早參與質(zhì)量保證，盡早發(fā)現(xiàn)并解決問(wèn)題以降低解決問(wèn)題的成本。

傳統(tǒng)測(cè)試左移的模式相對(duì)固定，通過(guò)測(cè)試用例來(lái)驅(qū)動(dòng)開(kāi)發(fā)，有相對(duì)固定的流程，一定程度上限制了開(kāi)發(fā)者的主觀能動(dòng)性。而彈性研發(fā)提倡開(kāi)發(fā)者通過(guò)實(shí)踐來(lái)發(fā)掘任何能保證研發(fā)質(zhì)量的手段，堅(jiān)信成功的思想或手段是會(huì)傳播開(kāi)的，并最終被廣泛接受。

4.如何彈性右移

4.1概述

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

為了避免“當(dāng)局者迷”與“思維定式”，建議由代碼作者以外的第三者參與進(jìn)來(lái)保證質(zhì)量，機(jī)器或人工皆可，以下著重描述若干可供參考的實(shí)踐方向。

4.2靜態(tài)代碼掃描

靜態(tài)代碼掃描是指使用程序分析源代碼以發(fā)現(xiàn)潛在的問(wèn)題，如bug、反模式及其他不需要運(yùn)行代碼就能發(fā)現(xiàn)的問(wèn)題，例如大家熟知的SonarQube以及IDEA插件Alibaba Java Coding Guidelines。在AI大行其道的當(dāng)下，也可考慮使用相關(guān)AI工具進(jìn)行靜態(tài)代碼掃描。

4.3組內(nèi)代碼評(píng)審

組內(nèi)代碼評(píng)審是由與代碼作者同組的另一名成員負(fù)責(zé)代碼審核，同組成員意味著平時(shí)負(fù)責(zé)開(kāi)發(fā)的業(yè)務(wù)與項(xiàng)目完全相同或相似，這有助于降低代碼評(píng)審的門(mén)檻，同時(shí)有助于提升巴士因子。

巴士因子是軟件開(kāi)發(fā)中的一個(gè)術(shù)語(yǔ)，用于衡量軟件項(xiàng)目的相關(guān)知識(shí)在團(tuán)隊(duì)成員中的共享程度。一個(gè)項(xiàng)目一旦有超過(guò)閾值的關(guān)鍵成員無(wú)法參與（例如被巴士撞傷了）就會(huì)導(dǎo)致項(xiàng)目無(wú)法推進(jìn)甚至失敗，這個(gè)閾值就是巴士因子。巴士因子強(qiáng)調(diào)項(xiàng)目的有關(guān)知識(shí)不應(yīng)該僅被極少數(shù)人所掌握。組內(nèi)代碼評(píng)審促使同組至少有2名成員掌握所有業(yè)務(wù)需求與代碼。

程序員由于崗位的特殊性，要求其把主要時(shí)間和精力花在編寫(xiě)好代碼上，而不是整天與人溝通，因此組內(nèi)代碼評(píng)審也是一種促進(jìn)組內(nèi)同事學(xué)習(xí)和溝通的渠道。

目前我們團(tuán)隊(duì)定期進(jìn)行團(tuán)隊(duì)范圍的代碼走查，這也是一種形式的代碼評(píng)審，有助于形成團(tuán)隊(duì)的統(tǒng)一編碼規(guī)范與風(fēng)格。

4.4開(kāi)發(fā)者驅(qū)動(dòng)的自動(dòng)化測(cè)試

?4.4.1 編寫(xiě)測(cè)試代碼

彈性研發(fā)團(tuán)隊(duì)提倡測(cè)試即代碼與測(cè)試自動(dòng)化，因此如何編寫(xiě)測(cè)試代碼非常關(guān)鍵。

好的測(cè)試代碼是不變的、健壯的、明確的：

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

?  健壯的測(cè)試：在被測(cè)代碼所實(shí)現(xiàn)的需求沒(méi)變的情況下，測(cè)試代碼總是能夠運(yùn)行通過(guò)；

?  清晰的測(cè)試：在測(cè)試代碼運(yùn)行失敗的情況下，能夠明確知道是哪出問(wèn)題了。

(1) 編寫(xiě)不變且健壯的測(cè)試代碼

在實(shí)踐中，可以把開(kāi)發(fā)者對(duì)代碼的修改分為四類(lèi)：

第一類(lèi)是對(duì)代碼進(jìn)行重構(gòu)：由于被測(cè)代碼的需求沒(méi)變，因此對(duì)代碼進(jìn)行重構(gòu)不應(yīng)該使測(cè)試代碼運(yùn)行失敗。若測(cè)試代碼運(yùn)行失敗，則說(shuō)明重構(gòu)影響了系統(tǒng)的行為，或測(cè)試代碼的被測(cè)代碼太過(guò)底層。

第二類(lèi)是修復(fù)bug而修改代碼：bug的存在說(shuō)明現(xiàn)有的測(cè)試代碼覆蓋的用例不夠全，在修復(fù)bug后，應(yīng)該新增測(cè)試用例對(duì)應(yīng)的測(cè)試代碼，但不需要修改已有測(cè)試代碼。

第三類(lèi)是添加新需求而新增代碼：在編寫(xiě)完新需求代碼后，應(yīng)該新增針對(duì)這部分代碼的測(cè)試代碼，但不需要修改已有測(cè)試代碼。

第四類(lèi)是因需求改變而修改代碼：由于需求改變了，因此現(xiàn)有的測(cè)試代碼肯定會(huì)運(yùn)行失敗，此時(shí)必須針對(duì)變更后的需求修改測(cè)試代碼。

綜上所述，理想情況下，只有在現(xiàn)有需求改變了，測(cè)試代碼才會(huì)運(yùn)行失敗，才需要修改測(cè)試代碼，這樣一來(lái)維護(hù)測(cè)試代碼的成本就大大降低了。

編寫(xiě)不變且健壯的測(cè)試代碼的目標(biāo)是：只要需求沒(méi)有變，測(cè)試代碼就始終能夠運(yùn)行通過(guò)，這樣也就不需要修改測(cè)試代碼。達(dá)到這一目標(biāo)最簡(jiǎn)單最直接的測(cè)試方法就是按照用戶(hù)調(diào)用系統(tǒng)的方式來(lái)測(cè)試系統(tǒng)，也就是說(shuō)，針對(duì)系統(tǒng)的公共API進(jìn)行測(cè)試，而不是系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。

那么哪些代碼才能稱(chēng)得上公共API呢？

僅供一個(gè)類(lèi)內(nèi)部使用的private輔助方法不是公共API，應(yīng)該通過(guò)測(cè)試那些使用該private輔助方法的代碼來(lái)測(cè)試它，這是因?yàn)閜rivate輔助方法過(guò)于底層，可能被修改的概率很大。

項(xiàng)目中的Service方法與通用工具類(lèi)都可視為公共API，由于它對(duì)整個(gè)項(xiàng)目甚至所有其他項(xiàng)目公開(kāi)，因此具備一定的抽象性與穩(wěn)定性，即使內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)可能被修改，但對(duì)外呈現(xiàn)的行為應(yīng)該是相對(duì)穩(wěn)定的。

項(xiàng)目對(duì)外暴露的接口是公共API，由于它直接對(duì)外公開(kāi)，因此具備很高的抽象性與穩(wěn)定性。

(2) 編寫(xiě)清晰的測(cè)試代碼

清晰的測(cè)試是指測(cè)試代碼存在的目的以及運(yùn)行失敗的原因都很明確，這樣在遇到測(cè)試代碼運(yùn)行失敗時(shí)才能高效地進(jìn)行修復(fù)。

下面以測(cè)試轉(zhuǎn)賬Service方法為例來(lái)描述何謂清晰的測(cè)試，轉(zhuǎn)賬Service方法有如下簽名：

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

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

清晰的測(cè)試應(yīng)該測(cè)試方法的行為而不是方法本身，應(yīng)該為方法的每一種行為分別編寫(xiě)測(cè)試方法，這樣測(cè)試方法就不會(huì)隨著被測(cè)方法行為的膨脹而膨脹，也不需要修改能夠運(yùn)行通過(guò)的測(cè)試代碼。以轉(zhuǎn)賬方法為例，其行為包括轉(zhuǎn)賬成功、因出款戶(hù)余額不足導(dǎo)致的轉(zhuǎn)賬失敗、因出款戶(hù)不存在導(dǎo)致的轉(zhuǎn)賬失敗等，因此要分別為這些行為編寫(xiě)測(cè)試方法。

面向行為的測(cè)試代碼由三部分組成，“given”定義預(yù)設(shè)的系統(tǒng)環(huán)境，“when”定義對(duì)系統(tǒng)執(zhí)行的操作，“then”驗(yàn)證結(jié)果。測(cè)試方法也應(yīng)該由測(cè)試行為命名。

下面展示一個(gè)測(cè)試轉(zhuǎn)賬成功的測(cè)試方法：

@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());  
}

最后聲明一點(diǎn)，一旦你覺(jué)得需要額外編寫(xiě)測(cè)試來(lái)驗(yàn)證測(cè)試代碼，就表明測(cè)試遠(yuǎn)遠(yuǎn)不夠清晰。

?4.4.2 自動(dòng)運(yùn)行測(cè)試代碼

可在把代碼push到遠(yuǎn)程倉(cāng)庫(kù)時(shí)，在本地執(zhí)行maven的test命令即可自動(dòng)運(yùn)行測(cè)試代碼，也可在A-One編譯構(gòu)建項(xiàng)目時(shí)自動(dòng)運(yùn)行測(cè)試代碼。

4.5AI自動(dòng)化測(cè)試

目前我們團(tuán)隊(duì)有使用IDEA插件GitHub Copilot，它由OpenAI提供支持，基于數(shù)十億行開(kāi)源代碼構(gòu)建的模型，可實(shí)現(xiàn)根據(jù)代碼注釋編寫(xiě)代碼、創(chuàng)建單元測(cè)試與靜態(tài)代碼掃描。這里也推薦大家使用這款插件，利用AI進(jìn)行自動(dòng)化測(cè)試肯定是未來(lái)的趨勢(shì)，這里也提倡大家多多實(shí)踐多多分享。

作者簡(jiǎn)介

張超

■服務(wù)端研發(fā)部-服務(wù)端買(mǎi)用技術(shù)團(tuán)隊(duì)-交易平臺(tái)組

■ 2021年加入汽車(chē)之家，目前主要負(fù)責(zé)權(quán)益中臺(tái)的建設(shè)與后端開(kāi)發(fā)工作，熱衷探索與分享。