微服務(wù)測試的思考與項目演進實踐
最近幾年,微服務(wù)架構(gòu)越來越火爆,逐漸被企業(yè)所采用。隨著軟件架構(gòu)的變化,對應(yīng)的軟件測試策略需要作何調(diào)整呢?本文將介紹微服務(wù)架構(gòu)下的測試策略,并結(jié)合分享在業(yè)務(wù)和架構(gòu)演變過程中,一個歷經(jīng)九年的項目測試策略的演進。
關(guān)于微服務(wù)
微服務(wù)架構(gòu)是一種架構(gòu)模式,它提倡將單一應(yīng)用程序劃分成一組小的服務(wù),每個服務(wù)運行在其獨立的進程中,服務(wù)間采用輕量級通信機制互相溝通(通常是基于HTTP協(xié)議的RESTful API)。每個服務(wù)都圍繞著具體的業(yè)務(wù)進行構(gòu)建,并且能夠被獨立部署到生產(chǎn)環(huán)境、預(yù)生產(chǎn)環(huán)境。
從微服務(wù)的概念可以看出它有如下好處:
- 每個服務(wù)可以獨立開發(fā)
- 處理的單元粒度更細
- 單個服務(wù)支持獨立部署和發(fā)布
- 更有利于業(yè)務(wù)的擴展
同時,獨立開發(fā)導(dǎo)致技術(shù)上的分離,HTTP通信加上Queue的機制增加了問題診斷的復(fù)雜度,對系統(tǒng)的功能、性能和安全方面的質(zhì)量保障帶來了很大的挑戰(zhàn)。另外,服務(wù)間的復(fù)雜依賴關(guān)系帶來了很多的不確定性,要實現(xiàn)獨立部署,對運維也提出了更高的要求。微服務(wù)架構(gòu)的系統(tǒng)要特別關(guān)注這幾個方面:
- 服務(wù)間的依賴、連通性
- 服務(wù)的容錯、可用性
- 數(shù)據(jù)的最終一致性
- 獨立部署
- 不確定性
測試策略的選擇
談到微服務(wù)的測試策略,很容易就想到了老馬推薦的文章《Microservices Testing》,該文推薦的微服務(wù)框架下的測試策略是這樣的:
經(jīng)典策略模型
這個策略模型強調(diào)測試分層以及每一層的恰當(dāng)覆蓋,整體符合金字塔結(jié)構(gòu)。它是最優(yōu)的嗎?
有人對此提出了質(zhì)疑...認為策略模型應(yīng)該是蜂巢形狀的:
蜂巢模型
這個模型重點關(guān)注服務(wù)間的集成測試,兩端的單元測試和UI層E2E測試較少。
也有同事提出微服務(wù)下的測試結(jié)構(gòu)應(yīng)該是鉆石形狀的,服務(wù)間的集成依然是重點,單元測試較少,而頂層增加了安全和性能等非功能測試。
鉆石模型
好像都有道理,到底選擇什么樣的策略模型好呢?不禁陷入了困境…...怎么辦?不妨先來聽聽我們項目的故事吧!
項目的故事
1. 測試策略的演進
還是那個藍鯨項目,不知不覺進入了第九個年頭。在這九年里,隨著業(yè)務(wù)的不斷發(fā)展,系統(tǒng)架構(gòu)也進行了多次演進和調(diào)整。相應(yīng)的,測試策略也發(fā)生了有意思的演進變化。
測試策略的演進
最初單一用戶系統(tǒng)、單體架構(gòu)的時候,嚴(yán)格按照測試金字塔來組織各層的自動化測試。隨著功能的擴展,大量mock的單元測試給重構(gòu)帶來了很大的不便。
企業(yè)系統(tǒng)開始開發(fā)的時候,我們調(diào)整了策略,減少單元測試的編寫,增加UI層E2E測試的覆蓋,測試結(jié)構(gòu)由原來的金字塔演變成上面梯形下面倒三角的形式。
后來,架構(gòu)調(diào)整,開始服務(wù)化。此時,大量的E2E測試漸漸暴露出問題:
- CI上的測試執(zhí)行時間越來越長,而且定位問題的能力很弱,測試一旦失敗需要很長時間修復(fù),測試人員好幾天也拿不到可以測試的版本,反饋周期過長;
- 由于服務(wù)化帶來的不穩(wěn)定因素增加,E2E測試沒法很好的覆蓋到需要的場景,測試人員就算拿到可測的版本也總有各種缺陷發(fā)生。
因此,項目引入契約測試,停止編寫新的E2E測試,將測試下移,分別用API測試和契約測試取代。
隨著功能的不斷增加,雖然E2E測試的量并不增加,但是其不穩(wěn)定性、維護難、定位難的問題有增無減,此時已經(jīng)很難由自動化測試來保證產(chǎn)品的質(zhì)量。為了平衡成本和收益,項目考慮去掉大部分E2E測試,只保留少量的Smoke測試,將更多的測試下移。
同時,技術(shù)雷達上新的技術(shù)“生產(chǎn)環(huán)境下的QA”出現(xiàn),項目也開始關(guān)心生產(chǎn)環(huán)境,并且在QA測試階段結(jié)合微服務(wù)的特點進行對應(yīng)的探索式測試。
2. 應(yīng)對微服務(wù)的挑戰(zhàn)
前文提到過微服務(wù)帶來的挑戰(zhàn),下面來看項目是如何應(yīng)對這些挑戰(zhàn)的。
(1) 服務(wù)間的依賴、連通性
微服務(wù)架構(gòu)下,獨立開發(fā)的服務(wù)要整合起來最具挑戰(zhàn),如何保證服務(wù)間的依賴關(guān)系和連通性非常關(guān)鍵。前面已經(jīng)講過E2E集成測試有很大的挑戰(zhàn),并不適合,而消費端驅(qū)動的契約測試是個不錯的選擇。項目正是利用契約測試去保證服務(wù)間的連通性,取代一部分E2E集成測試。
(2) 服務(wù)的容錯、可用性
在系統(tǒng)負荷達到一定程度或者某個服務(wù)出現(xiàn)故障的時候,微服務(wù)架構(gòu)有兩種技術(shù)來確保系統(tǒng)的可用性:服務(wù)的熔斷和降級。服務(wù)的熔斷是指當(dāng)某個服務(wù)出現(xiàn)故障時,為了保證系統(tǒng)整體的可用性,會關(guān)閉掉出現(xiàn)故障的服務(wù);服務(wù)的降級則是當(dāng)系統(tǒng)整體負荷過載的時候,考慮關(guān)閉某些外圍服務(wù)來保證系統(tǒng)的整體可用性。
對應(yīng)的測試包括:
- 熔斷:從性能角度,當(dāng)系統(tǒng)負載達到某個熔斷狀態(tài)的時候,服務(wù)是否能正確熔斷;同時,從功能角度驗證熔斷后系統(tǒng)的行為是否跟預(yù)期相符;
- 降級:從業(yè)務(wù)的角度,要能區(qū)分出核心業(yè)務(wù)和外圍業(yè)務(wù),在需要降級的時候不能影響核心業(yè)務(wù);當(dāng)某個服務(wù)降級后,從功能角度驗證系統(tǒng)行為是否跟預(yù)期相符。
(3) 數(shù)據(jù)的最終一致性
數(shù)據(jù)一致性
數(shù)據(jù)一致性是微服務(wù)特別需要關(guān)注的。舉個例子,電商平臺某個訂單支付成功以后,需要更新積分和訂單狀態(tài),當(dāng)訂單服務(wù)或者積分服務(wù)其中有一個出現(xiàn)故障的時候,就會導(dǎo)致最終的數(shù)據(jù)不一致性。
測試這種情況,從業(yè)務(wù)的角度分析哪些服務(wù)會導(dǎo)致數(shù)據(jù)不一致性,制造對應(yīng)的異常情況去測試數(shù)據(jù)的最終一致性。
(4) 獨立部署
微服務(wù)的獨立部署需要有CI、CD的支持,跟DevOps實踐分不開。同時,更為關(guān)鍵的是需要契約測試來驗證獨立部署后服務(wù)行為的正確性。項目在這方面的工作,請參考王健的文章:你的微服務(wù)敢獨立交付嗎?
(5) 不確定性
微服務(wù)架構(gòu)使得系統(tǒng)復(fù)雜度增加不少,很多的事情發(fā)生都是不可預(yù)測的,只能在其發(fā)生以后找到產(chǎn)生的原因。因此,也就沒法在預(yù)生產(chǎn)環(huán)境通過測試去發(fā)現(xiàn)在真實生產(chǎn)環(huán)境才會發(fā)生的issue,我們需要把目光轉(zhuǎn)移到生產(chǎn)環(huán)境,利用生產(chǎn)環(huán)境的不確定性、微服務(wù)的不可預(yù)測性來構(gòu)建反脆弱的系統(tǒng)。
項目在這方面主要采用的技術(shù)是生產(chǎn)環(huán)境下的QA。
3. 項目測試策略
從前面介紹的演進過程可以看到,項目測試策略在不同階段結(jié)合參考了不同的策略模型:金字塔->近似鉆石(除非功能測試外,類似于鉆石模型)->蜂巢。后期全面服務(wù)化的時候,我們認為蜂巢模型是比較適合的。
當(dāng)然,光有符合這個策略模型的自動化測試是遠遠不夠的,我們項目還采用了針對微服務(wù)特點的探索式測試,保持持續(xù)交付節(jié)奏,踐行DevOps實踐,結(jié)合生產(chǎn)環(huán)境下的QA等技術(shù)把關(guān)注點右移到生產(chǎn)環(huán)境。
現(xiàn)在,項目整體測試策略演變成下圖的形式:
項目測試策略
- 項目采用的是敏捷迭代開發(fā)和持續(xù)交付的模式,每四周一個發(fā)布周期。
- 在開發(fā)過程中實現(xiàn)的自動化測試是分層實現(xiàn)的:底層少量的單元測試,中間量最多的是API測試(類似于老馬策略模型里的組件測試),上面有一部分契約測試和少量的Smoke測試來保證服務(wù)間的契約和集成。除此之外,QA有手動的探索式測試,其中包括針對微服務(wù)特點進行的一些測試。整個測試結(jié)構(gòu)是類似于蜂巢模型的。
- 采用生產(chǎn)環(huán)境下的QA技術(shù),利用生產(chǎn)環(huán)境,進行error監(jiān)控、用戶行為分析、用戶反饋收集,從而來影響和指導(dǎo)預(yù)生產(chǎn)環(huán)境的開發(fā)和測試工作。
- 利用DevOps實踐,做到高效的部署和監(jiān)控,跟生產(chǎn)環(huán)境下的QA結(jié)合,形成良性的環(huán)路,保證項目的正常交付。
測試策略再思考
項目上多次測試策略的調(diào)整,看似很簡單,其實每次調(diào)整并不是一個輕松的過程,都是平衡利弊、綜合考慮多個因素才做出的決定。
分析整個調(diào)整過程,最后突然發(fā)現(xiàn):當(dāng)我們面對多個策略模型不知道如何選擇的時候,其實我們陷入了一個太過于關(guān)注測試結(jié)構(gòu)的誤區(qū),忘記了最初的目標(biāo)是什么。
1. 影響測試策略的因素
跳出誤區(qū),回到原點,重新思考測試策略的目標(biāo)。影響策略的最關(guān)鍵因素是業(yè)務(wù)價值、質(zhì)量要求、痛點。
影響測試策略的因素
(1) 業(yè)務(wù)價值
帶來更大的業(yè)務(wù)價值、幫企業(yè)贏得更多的利潤,是軟件系統(tǒng)的目標(biāo);軟件測試是軟件系統(tǒng)成功的保障之一,業(yè)務(wù)價值也是測試策略的終極目標(biāo)。所有測試活動都要圍繞這個目標(biāo)開展,考慮業(yè)務(wù)優(yōu)先級,有效規(guī)避業(yè)務(wù)風(fēng)險。
(2) 質(zhì)量要求
不同的系統(tǒng)、同一系統(tǒng)的不同利益干系人(參與的不同角色)對于質(zhì)量的定義和要求都可能是不同的,這毫無疑問是影響測試策略的一個關(guān)鍵因素。
對于僅有內(nèi)部用戶的系統(tǒng),關(guān)注的重心可能是系統(tǒng)的功能;而對外發(fā)布的產(chǎn)品,則要求更高,一個按鈕位置的不恰當(dāng)都可能帶來大量用戶的流失。
(3) 痛點
真正的痛點往往也是優(yōu)先級最高,迫切需要解決的。那些可以通過測試策略的調(diào)整來解決的痛點,自然成為了關(guān)鍵的影響因素之一。比如,CI Pipeline出包太慢,為了提高出包的效率,一方面在Pipeline本身想辦法,另一方面調(diào)整自動化測試的比例、執(zhí)行頻率等也是解決方案之一。
演進式測試策略
處在不同階段的項目,在業(yè)務(wù)價值這個大目標(biāo)下,其他影響因素也是會不一樣的,跟技術(shù)架構(gòu)的演進一樣,測試策略也應(yīng)該是演進式的。
從目標(biāo)出發(fā),綜合所處階段各個方面的影響因素,制定出適合當(dāng)時的測試策略。隨著時間的推移,對策略進行評估和度量,并進一步改進、提高,以更好的滿足需求。這就是目標(biāo)驅(qū)動的演進式測試策略。
演進式測試策略
總結(jié)
微服務(wù)架構(gòu)下多個服務(wù)的整合是最具有挑戰(zhàn)的,對此最重要的是契約測試。契約測試有效保證服務(wù)間的契約關(guān)系不被破壞,確保服務(wù)的連通性,有助于實現(xiàn)真正的獨立部署和獨立交付。
微服務(wù)架構(gòu)引入的不確定性并不是壞事,可以利用這些不確定性,采用生產(chǎn)環(huán)境下的QA等技術(shù),增強系統(tǒng)的反脆弱性,從中獲益。
測試策略的影響因素不是唯一的,技術(shù)架構(gòu)并不是最關(guān)鍵的因素。微服務(wù)架構(gòu)下的測試策略跟其他架構(gòu)下的并不會有本質(zhì)的區(qū)別。
業(yè)務(wù)價值始終是我們的終極目標(biāo)。在這個終極目標(biāo)的驅(qū)動下,測試策略不是制定完了就可以束之高閣的,需要在整個軟件系統(tǒng)構(gòu)建過程中不斷的度量和改進,是演進式的。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件,微信公眾號:思特沃克,轉(zhuǎn)載請聯(lián)系原作者】