最近幾年，微服務架構越來越火爆，逐漸被企業(yè)所采用。隨著軟件架構的變化，對應的軟件測試策略需要作何調(diào)整呢?本文將介紹微服務架構下的測試策略，并結合分享在業(yè)務和架構演變過程中，一個歷經(jīng)九年的項目測試策略的演進。

關于微服務

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，每個服務運行在其獨立的進程中，服務間采用輕量級通信機制互相溝通(通常是基于HTTP協(xié)議的RESTful API)。每個服務都圍繞著具體的業(yè)務進行構建，并且能夠被獨立部署到生產(chǎn)環(huán)境、預生產(chǎn)環(huán)境。

從微服務的概念可以看出它有如下好處：

• 每個服務可以獨立開發(fā)
• 處理的單元粒度更細
• 單個服務支持獨立部署和發(fā)布
• 更有利于業(yè)務的擴展

同時，獨立開發(fā)導致技術上的分離，HTTP通信加上Queue的機制增加了問題診斷的復雜度，對系統(tǒng)的功能、性能和安全方面的質(zhì)量保障帶來了很大的挑戰(zhàn)。另外，服務間的復雜依賴關系帶來了很多的不確定性，要實現(xiàn)獨立部署，對運維也提出了更高的要求。微服務架構的系統(tǒng)要特別關注這幾個方面：

• 服務間的依賴、連通性
• 服務的容錯、可用性
• 數(shù)據(jù)的最終一致性
• 獨立部署
• 不確定性

測試策略的選擇

談到微服務的測試策略，很容易就想到了老馬推薦的文章《Microservices Testing》，該文推薦的微服務框架下的測試策略是這樣的：

經(jīng)典策略模型

這個策略模型強調(diào)測試分層以及每一層的恰當覆蓋，整體符合金字塔結構。它是最優(yōu)的嗎?

有人對此提出了質(zhì)疑...認為策略模型應該是蜂巢形狀的：

蜂巢模型

這個模型重點關注服務間的集成測試，兩端的單元測試和UI層E2E測試較少。

也有同事提出微服務下的測試結構應該是鉆石形狀的，服務間的集成依然是重點，單元測試較少，而頂層增加了安全和性能等非功能測試。

鉆石模型

好像都有道理，到底選擇什么樣的策略模型好呢?不禁陷入了困境…...怎么辦?不妨先來聽聽我們項目的故事吧!

項目的故事

1. 測試策略的演進

還是那個藍鯨項目，不知不覺進入了第九個年頭。在這九年里，隨著業(yè)務的不斷發(fā)展，系統(tǒng)架構也進行了多次演進和調(diào)整。相應的，測試策略也發(fā)生了有意思的演進變化。

測試策略的演進

最初單一用戶系統(tǒng)、單體架構的時候，嚴格按照測試金字塔來組織各層的自動化測試。隨著功能的擴展，大量mock的單元測試給重構帶來了很大的不便。

企業(yè)系統(tǒng)開始開發(fā)的時候，我們調(diào)整了策略，減少單元測試的編寫，增加UI層E2E測試的覆蓋，測試結構由原來的金字塔演變成上面梯形下面倒三角的形式。

后來，架構調(diào)整，開始服務化。此時，大量的E2E測試漸漸暴露出問題：

• CI上的測試執(zhí)行時間越來越長，而且定位問題的能力很弱，測試一旦失敗需要很長時間修復，測試人員好幾天也拿不到可以測試的版本，反饋周期過長;
• 由于服務化帶來的不穩(wěn)定因素增加，E2E測試沒法很好的覆蓋到需要的場景，測試人員就算拿到可測的版本也總有各種缺陷發(fā)生。

因此，項目引入契約測試，停止編寫新的E2E測試，將測試下移，分別用API測試和契約測試取代。

隨著功能的不斷增加，雖然E2E測試的量并不增加，但是其不穩(wěn)定性、維護難、定位難的問題有增無減，此時已經(jīng)很難由自動化測試來保證產(chǎn)品的質(zhì)量。為了平衡成本和收益，項目考慮去掉大部分E2E測試，只保留少量的Smoke測試，將更多的測試下移。

同時，技術雷達上新的技術“生產(chǎn)環(huán)境下的QA”出現(xiàn)，項目也開始關心生產(chǎn)環(huán)境，并且在QA測試階段結合微服務的特點進行對應的探索式測試。

2. 應對微服務的挑戰(zhàn)

前文提到過微服務帶來的挑戰(zhàn)，下面來看項目是如何應對這些挑戰(zhàn)的。

(1) 服務間的依賴、連通性

微服務架構下，獨立開發(fā)的服務要整合起來最具挑戰(zhàn)，如何保證服務間的依賴關系和連通性非常關鍵。前面已經(jīng)講過E2E集成測試有很大的挑戰(zhàn)，并不適合，而消費端驅(qū)動的契約測試是個不錯的選擇。項目正是利用契約測試去保證服務間的連通性，取代一部分E2E集成測試。

(2) 服務的容錯、可用性

在系統(tǒng)負荷達到一定程度或者某個服務出現(xiàn)故障的時候，微服務架構有兩種技術來確保系統(tǒng)的可用性：服務的熔斷和降級。服務的熔斷是指當某個服務出現(xiàn)故障時，為了保證系統(tǒng)整體的可用性，會關閉掉出現(xiàn)故障的服務;服務的降級則是當系統(tǒng)整體負荷過載的時候，考慮關閉某些外圍服務來保證系統(tǒng)的整體可用性。

對應的測試包括：

• 熔斷：從性能角度，當系統(tǒng)負載達到某個熔斷狀態(tài)的時候，服務是否能正確熔斷;同時，從功能角度驗證熔斷后系統(tǒng)的行為是否跟預期相符;
• 降級：從業(yè)務的角度，要能區(qū)分出核心業(yè)務和外圍業(yè)務，在需要降級的時候不能影響核心業(yè)務;當某個服務降級后，從功能角度驗證系統(tǒng)行為是否跟預期相符。

(3) 數(shù)據(jù)的最終一致性

數(shù)據(jù)一致性

數(shù)據(jù)一致性是微服務特別需要關注的。舉個例子，電商平臺某個訂單支付成功以后，需要更新積分和訂單狀態(tài)，當訂單服務或者積分服務其中有一個出現(xiàn)故障的時候，就會導致最終的數(shù)據(jù)不一致性。

測試這種情況，從業(yè)務的角度分析哪些服務會導致數(shù)據(jù)不一致性，制造對應的異常情況去測試數(shù)據(jù)的最終一致性。

(4) 獨立部署

微服務的獨立部署需要有CI、CD的支持，跟DevOps實踐分不開。同時，更為關鍵的是需要契約測試來驗證獨立部署后服務行為的正確性。項目在這方面的工作，請參考王健的文章：你的微服務敢獨立交付嗎?

(5) 不確定性

微服務架構使得系統(tǒng)復雜度增加不少，很多的事情發(fā)生都是不可預測的，只能在其發(fā)生以后找到產(chǎn)生的原因。因此，也就沒法在預生產(chǎn)環(huán)境通過測試去發(fā)現(xiàn)在真實生產(chǎn)環(huán)境才會發(fā)生的issue，我們需要把目光轉(zhuǎn)移到生產(chǎn)環(huán)境，利用生產(chǎn)環(huán)境的不確定性、微服務的不可預測性來構建反脆弱的系統(tǒng)。

項目在這方面主要采用的技術是生產(chǎn)環(huán)境下的QA。

3. 項目測試策略

從前面介紹的演進過程可以看到，項目測試策略在不同階段結合參考了不同的策略模型：金字塔->近似鉆石(除非功能測試外，類似于鉆石模型)->蜂巢。后期全面服務化的時候，我們認為蜂巢模型是比較適合的。

當然，光有符合這個策略模型的自動化測試是遠遠不夠的，我們項目還采用了針對微服務特點的探索式測試，保持持續(xù)交付節(jié)奏，踐行DevOps實踐，結合生產(chǎn)環(huán)境下的QA等技術把關注點右移到生產(chǎn)環(huán)境。

現(xiàn)在，項目整體測試策略演變成下圖的形式：

項目測試策略

• 項目采用的是敏捷迭代開發(fā)和持續(xù)交付的模式，每四周一個發(fā)布周期。
• 在開發(fā)過程中實現(xiàn)的自動化測試是分層實現(xiàn)的：底層少量的單元測試，中間量最多的是API測試(類似于老馬策略模型里的組件測試)，上面有一部分契約測試和少量的Smoke測試來保證服務間的契約和集成。除此之外，QA有手動的探索式測試，其中包括針對微服務特點進行的一些測試。整個測試結構是類似于蜂巢模型的。
• 采用生產(chǎn)環(huán)境下的QA技術，利用生產(chǎn)環(huán)境，進行error監(jiān)控、用戶行為分析、用戶反饋收集，從而來影響和指導預生產(chǎn)環(huán)境的開發(fā)和測試工作。
• 利用DevOps實踐，做到高效的部署和監(jiān)控，跟生產(chǎn)環(huán)境下的QA結合，形成良性的環(huán)路，保證項目的正常交付。

測試策略再思考

項目上多次測試策略的調(diào)整，看似很簡單，其實每次調(diào)整并不是一個輕松的過程，都是平衡利弊、綜合考慮多個因素才做出的決定。

分析整個調(diào)整過程，最后突然發(fā)現(xiàn)：當我們面對多個策略模型不知道如何選擇的時候，其實我們陷入了一個太過于關注測試結構的誤區(qū)，忘記了最初的目標是什么。

1. 影響測試策略的因素

跳出誤區(qū)，回到原點，重新思考測試策略的目標。影響策略的最關鍵因素是業(yè)務價值、質(zhì)量要求、痛點。

影響測試策略的因素

(1) 業(yè)務價值

帶來更大的業(yè)務價值、幫企業(yè)贏得更多的利潤，是軟件系統(tǒng)的目標;軟件測試是軟件系統(tǒng)成功的保障之一，業(yè)務價值也是測試策略的終極目標。所有測試活動都要圍繞這個目標開展，考慮業(yè)務優(yōu)先級，有效規(guī)避業(yè)務風險。

(2) 質(zhì)量要求

不同的系統(tǒng)、同一系統(tǒng)的不同利益干系人(參與的不同角色)對于質(zhì)量的定義和要求都可能是不同的，這毫無疑問是影響測試策略的一個關鍵因素。

對于僅有內(nèi)部用戶的系統(tǒng)，關注的重心可能是系統(tǒng)的功能;而對外發(fā)布的產(chǎn)品，則要求更高，一個按鈕位置的不恰當都可能帶來大量用戶的流失。

(3) 痛點

真正的痛點往往也是優(yōu)先級最高，迫切需要解決的。那些可以通過測試策略的調(diào)整來解決的痛點，自然成為了關鍵的影響因素之一。比如，CI Pipeline出包太慢，為了提高出包的效率，一方面在Pipeline本身想辦法，另一方面調(diào)整自動化測試的比例、執(zhí)行頻率等也是解決方案之一。

演進式測試策略

處在不同階段的項目，在業(yè)務價值這個大目標下，其他影響因素也是會不一樣的，跟技術架構的演進一樣，測試策略也應該是演進式的。

從目標出發(fā)，綜合所處階段各個方面的影響因素，制定出適合當時的測試策略。隨著時間的推移，對策略進行評估和度量，并進一步改進、提高，以更好的滿足需求。這就是目標驅(qū)動的演進式測試策略。

演進式測試策略

總結

微服務架構下多個服務的整合是最具有挑戰(zhàn)的，對此最重要的是契約測試。契約測試有效保證服務間的契約關系不被破壞，確保服務的連通性，有助于實現(xiàn)真正的獨立部署和獨立交付。

微服務架構引入的不確定性并不是壞事，可以利用這些不確定性，采用生產(chǎn)環(huán)境下的QA等技術，增強系統(tǒng)的反脆弱性，從中獲益。

測試策略的影響因素不是唯一的，技術架構并不是最關鍵的因素。微服務架構下的測試策略跟其他架構下的并不會有本質(zhì)的區(qū)別。

業(yè)務價值始終是我們的終極目標。在這個終極目標的驅(qū)動下，測試策略不是制定完了就可以束之高閣的，需要在整個軟件系統(tǒng)構建過程中不斷的度量和改進，是演進式的。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文