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

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

因此在今天的分享中，我們將通過分享DevOps下測試的“現狀分析”-“技術優化” - “機制改革“三部曲，來帶大家逐步領略DevOps發展下軟件測試所遭遇的瓶頸，以及對應改進的“術”與“法”。

01. 復雜且瑣碎：DevOps下測試的現狀分析

過往，為了快速應付DevOps轉型后的快速迭代節奏和復雜技術架構，不少研發團隊引入了大量自動化測試工具，寄希望于技術為測試團隊提效。

但過于追求短期的快，卻忽略了需要在企業整體上對測試進行業務設計和技術管控，導致長期運行下來以后，大幅加劇了測試的管理復雜度。

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

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

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

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

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

名詞解釋

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

接口測試：檢測系統與外部系統之間以及內部各個子系統之間的交互點，例如檢查數據的交換、傳遞和控制管理，以及系統之間的相互邏輯等。

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

當然，隨著微服務和容器化的廣泛應用，也有部分業界人士認為，單元測試已經不能很好地承擔現在主流軟件的測試重任，質疑全面自動化單元測試的業務價值，轉而將更多自動化測試資源優先投入到接口/服務層，整體分層自動化測試結構呈現橄欖型。

例如，部分團隊會優先選擇通過單接口測試向下覆蓋單元測試，以此保障微服務架構下API接口的穩定性。

這種做法更多是強調在微服務架構下，自動化接口測試中難度相對最低的最小邏輯單元接口測試，可能會比解耦了依賴關系的自動化單元測試更具有業務價值。

這里的單接口測試，主要是指對單元測試之間的測試間隙（可以先簡單理解為函數與函數之間的調用關系）進行測試，以此覆蓋單元測試沒有覆蓋到的數據依賴和外部服務依賴等測試內容。

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

所以這也是為什么，雖然單元層和接口/服務層都可以根據業務需求全面地推進自動化測試，但我們仍舊建議，企業在推行自動化測試時，應當優先全面覆蓋單元測試，而接口測試次之。

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

作為敏捷開發的其中一項核心實踐，TDD強調通過測試來推動軟件開發，重點關注代碼層的測試工作，來保障DevOps下測試工作的高效完成。

名詞解釋

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

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

在考慮到普遍企業的開發復雜度和測試性價比后，我們會更推薦企業選用由開發主導的形式開展單元測試，尤其是那些有不少外包開發團隊的傳統企業。

那么在這種情況下，我們在對單元測試領域應用自動化測試技術時，就需要更多地考慮到開發團隊的實際業務情況，降低單元測試給開發人員的壓力。

02. 固測試根基：DevOps下測試的技術優化

上文我們提到，自動化測試可分為UI層、接口/服務層和單元層三大類，而在DevOps研發模式下企業應當優先考慮實現自動化單元測試，而且自動化單元測試工藝最好基于開發團隊主導的視角進行打造。

那么基于以上考慮，我們接下來就聊聊自動化單元測試這項負責打基礎的質檢技術。

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

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

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

為了解放單元測試的生產力和保證執行質量，我們列舉了當前具有代表性的自動化單元測試發展趨勢，各位可以參考看下自己的企業是否潛藏著相關技術需求：

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

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

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

但總而言之，能有越來越多企業關注單元測試并產生市場需求，也有廠商愿意在這塊領域進行投入是件好事。說明在軟件研發領域，國內也是越來越舍得在這軟件質量這塊下功夫了。

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

03. 服務于業務：DevOps下測試的機制改革

上文通過介紹自動化單元測試的發展趨勢，從技術角度初步帶領大家看到了分層自動化測試的“測試自動生成”導向。

當我們把目光再次聚焦到“讓測試更好地適應DevOps下軟件研發的工作模式和技術特點”的主旨上，軟件測試的工作機制又該如何優化呢？

為了應對DevOps的快節拍與復雜度，我們無論是應用手工還是自動化的測試技術，無論是執行單元層、接口/服務層和UI層的測試工作，無論是由開發還是測試主導的測試任務，都需要以快速應對需求變更為前提進行布局，簡單總結就是下述四個步驟：

1. 需求建模

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

2. 測試建模

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

3. 場景建模

通過自動化創建拓撲映射，讓復雜的測試場景自動化生成。由于測試用例之間存在著錯綜復雜的關聯拓撲，尤其是在用例需要跨系統調用外部依賴的情況下，為了解決“牽一發卻不知道動了全身”的問題，就需要我們對測試場景也進行建模，保障業務場景得到有效驗證。

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

4. 工具規范化接入

為了能對測試業務和測試工藝進行企業級管控，我們要將需求建模和場景拓撲映射作為測試平臺的核心設計原則，從而降低測試的保鮮（維護）成本，再通過有選擇性地集成測試工藝，避免企業被某些能力不足的測試工具所“綁架”或者“卡脖子”。