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

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

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

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

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

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

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

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

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

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

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

名詞解釋

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

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

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

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

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

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

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

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

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

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

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

名詞解釋

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

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

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

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

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

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

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

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

誠然，前面提及過，相對其他類別的測試而言，單元測試腳本的開發(fā)和保鮮已經(jīng)是成本最低的了。

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

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

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

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

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

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

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

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

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

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

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

1. 需求建模

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

2. 測試建模

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

3. 場景建模

通過自動化創(chuàng)建拓?fù)溆成?，讓?fù)雜的測試場景自動化生成。由于測試用例之間存在著錯綜復(fù)雜的關(guān)聯(lián)拓?fù)?，尤其是在用例需要跨系統(tǒng)調(diào)用外部依賴的情況下，為了解決“牽一發(fā)卻不知道動了全身”的問題，就需要我們對測試場景也進(jìn)行建模，保障業(yè)務(wù)場景得到有效驗證。

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

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

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