建站
咨詢
售后
建站咨詢
新聞中心
1.背景
創(chuàng)新互聯(lián)歡迎咨詢：18982081108，為您提供成都網(wǎng)站建設(shè)網(wǎng)頁(yè)設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù)，創(chuàng)新互聯(lián)網(wǎng)頁(yè)制作領(lǐng)域十余年，包括成都發(fā)電機(jī)租賃等多個(gè)行業(yè)擁有豐富的網(wǎng)站營(yíng)銷(xiāo)經(jīng)驗(yàn)，選擇創(chuàng)新互聯(lián)，為網(wǎng)站錦上添花！
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è)試資源的依賴，這樣就在不進(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è)試資源的依賴”相關(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)出，并使用其專業(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或不滿足用戶訴求的情況？
質(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)確理解用戶訴求，并針對(duì)用戶訴求執(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é)太多、依賴關(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)境與用戶需求。
在更新代碼后，一旦無(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è)試方法就是按照用戶調(diào)用系統(tǒng)的方式來(lái)測(cè)試系統(tǒng)，也就是說(shuō)，針對(duì)系統(tǒng)的公共API進(jìn)行測(cè)試，而不是系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。
那么哪些代碼才能稱得上公共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)賬成功、因出款戶余額不足導(dǎo)致的轉(zhuǎn)賬失敗、因出款戶不存在導(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ā)工作，熱衷探索與分享。
當(dāng)前名稱：彈性研發(fā)團(tuán)隊(duì)的探索
新聞來(lái)源：http://m.fisionsoft.com.cn/article/dhijjod.html
