隨著近年來(lái)DevOps的興起，軟件的迭代速度逐步加快，開(kāi)發(fā)架構(gòu)逐步微服務(wù)化，部署也逐步走向輕量級(jí)容器化。而測(cè)試作為銜接開(kāi)發(fā)與運(yùn)維的重要一環(huán)，承擔(dān)著保障軟件質(zhì)量的重責(zé)。因此在IT工作模式改革和信息技術(shù)革新的今天，軟件測(cè)試也正在掀起關(guān)于效能與質(zhì)量的改革浪潮。

早些年人們?cè)谲浖y(cè)試的改進(jìn)上，更多地可能只是在關(guān)注測(cè)試的技術(shù)發(fā)展，試圖通過(guò)買(mǎi)入或封裝自動(dòng)化測(cè)試工具來(lái)應(yīng)對(duì)DevOps的快節(jié)奏，卻忽略了思考如何讓測(cè)試真正地服務(wù)于軟件研發(fā)，即如何讓測(cè)試更好地適應(yīng)DevOps下軟件研發(fā)的工作模式和技術(shù)特點(diǎn)。

因此在今天的分享中，我們將通過(guò)分享DevOps下測(cè)試的“現(xiàn)狀分析”-“技術(shù)優(yōu)化” - “機(jī)制改革“三部曲，來(lái)帶大家逐步領(lǐng)略DevOps發(fā)展下軟件測(cè)試所遭遇的瓶頸，以及對(duì)應(yīng)改進(jìn)的“術(shù)”與“法”。

01. 復(fù)雜且瑣碎：DevOps下測(cè)試的現(xiàn)狀分析

過(guò)往，為了快速應(yīng)付DevOps轉(zhuǎn)型后的快速迭代節(jié)奏和復(fù)雜技術(shù)架構(gòu)，不少研發(fā)團(tuán)隊(duì)引入了大量自動(dòng)化測(cè)試工具，寄希望于技術(shù)為測(cè)試團(tuán)隊(duì)提效。

但過(guò)于追求短期的快，卻忽略了需要在企業(yè)整體上對(duì)測(cè)試進(jìn)行業(yè)務(wù)設(shè)計(jì)和技術(shù)管控，導(dǎo)致長(zhǎng)期運(yùn)行下來(lái)以后，大幅加劇了測(cè)試的管理復(fù)雜度。

那么回到“讓測(cè)試更好地適應(yīng)DevOps下軟件研發(fā)的工作模式和技術(shù)特點(diǎn)”的主題上，企業(yè)又該如何重新為測(cè)試設(shè)計(jì)業(yè)務(wù)和工藝呢？

這里需要我們先跳脫出手工測(cè)試和自動(dòng)化測(cè)試的二極管思維，來(lái)學(xué)習(xí)下自動(dòng)化測(cè)試的分層概念：

上圖左側(cè)的分層自動(dòng)化測(cè)試金字塔模型最早來(lái)自于Mike Cohn2009年出版的《Succeeding with Agile》。我們可以觀察到，在該模型中，自動(dòng)化測(cè)試被分為了單元層、接口/服務(wù)層以及UI層三個(gè)大類(lèi)。

這是由于不同類(lèi)型的測(cè)試，在自動(dòng)化測(cè)試上的投入產(chǎn)出比是不一樣的。越往復(fù)雜度高的維度走，自動(dòng)化測(cè)試的效率將越低，投入也越高。

因此，在綜合考慮測(cè)試工作量、測(cè)試頻率以及自動(dòng)化測(cè)試投入產(chǎn)出比等因素后，我們建議在整體測(cè)試工作的業(yè)務(wù)設(shè)計(jì)和技術(shù)使用上，企業(yè)應(yīng)當(dāng)：讓自動(dòng)化測(cè)試優(yōu)先覆蓋單元層和接口/服務(wù)層，UI層僅覆蓋主流程或者核心業(yè)務(wù)分支即可。

名詞解釋

UI（界面）測(cè)試：測(cè)試用戶界面的功能模塊的布局是否合理，整體風(fēng)格是否一致，是否符合客戶使用習(xí)慣等。

接口測(cè)試：檢測(cè)系統(tǒng)與外部系統(tǒng)之間以及內(nèi)部各個(gè)子系統(tǒng)之間的交互點(diǎn)，例如檢查數(shù)據(jù)的交換、傳遞和控制管理，以及系統(tǒng)之間的相互邏輯等。

單元測(cè)試：指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。最小可測(cè)試單元由人為界定，如C語(yǔ)言中單元指一個(gè)函數(shù)，Java里單元指一個(gè)類(lèi)，圖形化的軟件中則可以指一個(gè)窗口或菜單等。

當(dāng)然，隨著微服務(wù)和容器化的廣泛應(yīng)用，也有部分業(yè)界人士認(rèn)為，單元測(cè)試已經(jīng)不能很好地承擔(dān)現(xiàn)在主流軟件的測(cè)試重任，質(zhì)疑全面自動(dòng)化單元測(cè)試的業(yè)務(wù)價(jià)值，轉(zhuǎn)而將更多自動(dòng)化測(cè)試資源優(yōu)先投入到接口/服務(wù)層，整體分層自動(dòng)化測(cè)試結(jié)構(gòu)呈現(xiàn)橄欖型。

例如，部分團(tuán)隊(duì)會(huì)優(yōu)先選擇通過(guò)單接口測(cè)試向下覆蓋單元測(cè)試，以此保障微服務(wù)架構(gòu)下API接口的穩(wěn)定性。

這種做法更多是強(qiáng)調(diào)在微服務(wù)架構(gòu)下，自動(dòng)化接口測(cè)試中難度相對(duì)最低的最小邏輯單元接口測(cè)試，可能會(huì)比解耦了依賴關(guān)系的自動(dòng)化單元測(cè)試更具有業(yè)務(wù)價(jià)值。

這里的單接口測(cè)試，主要是指對(duì)單元測(cè)試之間的測(cè)試間隙（可以先簡(jiǎn)單理解為函數(shù)與函數(shù)之間的調(diào)用關(guān)系）進(jìn)行測(cè)試，以此覆蓋單元測(cè)試沒(méi)有覆蓋到的數(shù)據(jù)依賴和外部服務(wù)依賴等測(cè)試內(nèi)容。

但考慮到單元測(cè)試不僅具有測(cè)試復(fù)雜度低的優(yōu)點(diǎn)，更重要的是它還具備測(cè)試左移的最大先發(fā)優(yōu)勢(shì)。越早開(kāi)始測(cè)試，發(fā)現(xiàn)問(wèn)題和修復(fù)問(wèn)題的成本越低。

所以這也是為什么，雖然單元層和接口/服務(wù)層都可以根據(jù)業(yè)務(wù)需求全面地推進(jìn)自動(dòng)化測(cè)試，但我們?nèi)耘f建議，企業(yè)在推行自動(dòng)化測(cè)試時(shí)，應(yīng)當(dāng)優(yōu)先全面覆蓋單元測(cè)試，而接口測(cè)試次之。

以上也是近年來(lái)隨著DevOps討論度的增加，TDD的概念開(kāi)始被IT人所接受和推崇的原因之一。

作為敏捷開(kāi)發(fā)的其中一項(xiàng)核心實(shí)踐，TDD強(qiáng)調(diào)通過(guò)測(cè)試來(lái)推動(dòng)軟件開(kāi)發(fā)，重點(diǎn)關(guān)注代碼層的測(cè)試工作，來(lái)保障DevOps下測(cè)試工作的高效完成。

名詞解釋

TDD：Test-Driven Development，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)。具體可表現(xiàn)為在開(kāi)發(fā)功能代碼前，先編寫(xiě)單元測(cè)試用例的代碼，提升代碼的可測(cè)試性，以達(dá)到“測(cè)試左移”，從而提升軟件整體交付效率。

但由于單元測(cè)試具有測(cè)試左移的業(yè)務(wù)優(yōu)勢(shì)和代碼編寫(xiě)的能力要求，要么需要測(cè)試團(tuán)隊(duì)具備代碼編寫(xiě)能力且真正做到與開(kāi)發(fā)團(tuán)隊(duì)密切配合，要么就需要開(kāi)發(fā)團(tuán)隊(duì)除了開(kāi)發(fā)新功能以外，還需要自行承擔(dān)起單元測(cè)試的工作。

在考慮到普遍企業(yè)的開(kāi)發(fā)復(fù)雜度和測(cè)試性價(jià)比后，我們會(huì)更推薦企業(yè)選用由開(kāi)發(fā)主導(dǎo)的形式開(kāi)展單元測(cè)試，尤其是那些有不少外包開(kāi)發(fā)團(tuán)隊(duì)的傳統(tǒng)企業(yè)。

那么在這種情況下，我們?cè)趯?duì)單元測(cè)試領(lǐng)域應(yīng)用自動(dòng)化測(cè)試技術(shù)時(shí)，就需要更多地考慮到開(kāi)發(fā)團(tuán)隊(duì)的實(shí)際業(yè)務(wù)情況，降低單元測(cè)試給開(kāi)發(fā)人員的壓力。

02. 固測(cè)試根基：DevOps下測(cè)試的技術(shù)優(yōu)化

上文我們提到，自動(dòng)化測(cè)試可分為UI層、接口/服務(wù)層和單元層三大類(lèi)，而在DevOps研發(fā)模式下企業(yè)應(yīng)當(dāng)優(yōu)先考慮實(shí)現(xiàn)自動(dòng)化單元測(cè)試，而且自動(dòng)化單元測(cè)試工藝最好基于開(kāi)發(fā)團(tuán)隊(duì)主導(dǎo)的視角進(jìn)行打造。

那么基于以上考慮，我們接下來(lái)就聊聊自動(dòng)化單元測(cè)試這項(xiàng)負(fù)責(zé)打基礎(chǔ)的質(zhì)檢技術(shù)。

這里可能有讀者會(huì)發(fā)出疑問(wèn)，既然要做自動(dòng)化單元測(cè)試，那咱們直接在Jenkins里集成個(gè)Jacoco插件不就完事了嗎？做一般迭代的回歸測(cè)試都綽綽有余了，這塊還有什么技術(shù)難點(diǎn)值得關(guān)注嗎？

誠(chéng)然，前面提及過(guò)，相對(duì)其他類(lèi)別的測(cè)試而言，單元測(cè)試腳本的開(kāi)發(fā)和保鮮已經(jīng)是成本最低的了。

但對(duì)于開(kāi)發(fā)而言，只要單元測(cè)試仍然需要耗費(fèi)大量工時(shí)來(lái)手動(dòng)編寫(xiě)和執(zhí)行腳本，那想要在企業(yè)內(nèi)全面推行，尤其是在那些按人天計(jì)費(fèi)的外包團(tuán)隊(duì)內(nèi)推行，就難免會(huì)遇到一些“不可抗阻力”和“結(jié)果不盡如人意”。

為了解放單元測(cè)試的生產(chǎn)力和保證執(zhí)行質(zhì)量，我們列舉了當(dāng)前具有代表性的自動(dòng)化單元測(cè)試發(fā)展趨勢(shì)，各位可以參考看下自己的企業(yè)是否潛藏著相關(guān)技術(shù)需求：

• 無(wú)代碼改造、不依賴測(cè)試框架
• 全自動(dòng)生成單元測(cè)試代碼
• 不依賴被測(cè)系統(tǒng)技術(shù)和狀態(tài)
• 精確定位問(wèn)題代碼
• 圖形化配置、簡(jiǎn)單易用

我們不難看出，實(shí)現(xiàn)“測(cè)試自動(dòng)生成”，從而減輕單元測(cè)試可能給開(kāi)發(fā)造成的代碼改造、腳本編寫(xiě)和問(wèn)題定位等成本，提升代碼覆蓋率，是當(dāng)前自動(dòng)化單元測(cè)試技術(shù)優(yōu)化的重點(diǎn)。

目前市面上專(zhuān)業(yè)做自動(dòng)化單元測(cè)試的工具也是如同雨后春筍般冒出，多數(shù)都還在集中攻克Java語(yǔ)言，現(xiàn)在也不合適做工具能力的對(duì)比。

但總而言之，能有越來(lái)越多企業(yè)關(guān)注單元測(cè)試并產(chǎn)生市場(chǎng)需求，也有廠商愿意在這塊領(lǐng)域進(jìn)行投入是件好事。說(shuō)明在軟件研發(fā)領(lǐng)域，國(guó)內(nèi)也是越來(lái)越舍得在這軟件質(zhì)量這塊下功夫了。

如果有讀者對(duì)自動(dòng)化單元測(cè)試非常感興趣，可以結(jié)合上面的技術(shù)趨勢(shì)與自身的實(shí)際需求，去對(duì)工具作進(jìn)一步判斷和選擇，這里不作過(guò)多引導(dǎo)。

03. 服務(wù)于業(yè)務(wù)：DevOps下測(cè)試的機(jī)制改革

上文通過(guò)介紹自動(dòng)化單元測(cè)試的發(fā)展趨勢(shì)，從技術(shù)角度初步帶領(lǐng)大家看到了分層自動(dòng)化測(cè)試的“測(cè)試自動(dòng)生成”導(dǎo)向。

當(dāng)我們把目光再次聚焦到“讓測(cè)試更好地適應(yīng)DevOps下軟件研發(fā)的工作模式和技術(shù)特點(diǎn)”的主旨上，軟件測(cè)試的工作機(jī)制又該如何優(yōu)化呢？

為了應(yīng)對(duì)DevOps的快節(jié)拍與復(fù)雜度，我們無(wú)論是應(yīng)用手工還是自動(dòng)化的測(cè)試技術(shù)，無(wú)論是執(zhí)行單元層、接口/服務(wù)層和UI層的測(cè)試工作，無(wú)論是由開(kāi)發(fā)還是測(cè)試主導(dǎo)的測(cè)試任務(wù)，都需要以快速應(yīng)對(duì)需求變更為前提進(jìn)行布局，簡(jiǎn)單總結(jié)就是下述四個(gè)步驟：

1. 需求建模

確保所有研發(fā)需求都被測(cè)試驗(yàn)證范圍所覆蓋，其中優(yōu)先推薦通過(guò)自動(dòng)化測(cè)試覆蓋單元層和接口層，打牢軟件測(cè)試的根基，但如果目前系統(tǒng)并不具備可測(cè)試性，那么使用手工測(cè)試也是非常合理的選擇。

2. 測(cè)試建模

通過(guò)有限的狀態(tài)機(jī)去消除復(fù)雜的測(cè)試用例，將狀態(tài)機(jī)與需求進(jìn)行1：1綁定，自動(dòng)化生成測(cè)試用例/偽腳本，從而達(dá)到自動(dòng)化測(cè)試建模，以及測(cè)試數(shù)據(jù)自動(dòng)化生成和管理的效果。這一步主要是解決需求變更后，測(cè)試用例無(wú)法及時(shí)變更等問(wèn)題，影響精準(zhǔn)測(cè)試。

3. 場(chǎng)景建模

通過(guò)自動(dòng)化創(chuàng)建拓?fù)溆成洌審?fù)雜的測(cè)試場(chǎng)景自動(dòng)化生成。由于測(cè)試用例之間存在著錯(cuò)綜復(fù)雜的關(guān)聯(lián)拓?fù)洌绕涫窃谟美枰缦到y(tǒng)調(diào)用外部依賴的情況下，為了解決“牽一發(fā)卻不知道動(dòng)了全身”的問(wèn)題，就需要我們對(duì)測(cè)試場(chǎng)景也進(jìn)行建模，保障業(yè)務(wù)場(chǎng)景得到有效驗(yàn)證。

這里的測(cè)試場(chǎng)景自動(dòng)化生成，主要是針對(duì)測(cè)試用例場(chǎng)景法的應(yīng)用。在實(shí)際測(cè)試工作中，為了保障軟件的業(yè)務(wù)流程和業(yè)務(wù)邏輯，會(huì)讓測(cè)試通過(guò)模擬最終用戶分別進(jìn)行正確和錯(cuò)誤的操作，從而檢驗(yàn)軟件功能是否能夠正確實(shí)現(xiàn)，以及軟件是否有足夠的異常處理能力。

4. 工具規(guī)范化接入

為了能對(duì)測(cè)試業(yè)務(wù)和測(cè)試工藝進(jìn)行企業(yè)級(jí)管控，我們要將需求建模和場(chǎng)景拓?fù)溆成渥鳛闇y(cè)試平臺(tái)的核心設(shè)計(jì)原則，從而降低測(cè)試的保鮮（維護(hù)）成本，再通過(guò)有選擇性地集成測(cè)試工藝，避免企業(yè)被某些能力不足的測(cè)試工具所“綁架”或者“卡脖子”。