微服務(wù)特點(diǎn)
首先微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終服務(wù)。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用各種協(xié)議通信，例如我廠使用華為DSF微服務(wù)架構(gòu)的DSF協(xié)議。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、仿真環(huán)境、測試環(huán)境等。
每個(gè)服務(wù)都可以被獨(dú)立部署意味著隨著服務(wù)數(shù)量及調(diào)用關(guān)系復(fù)雜度的增加，如果依然使用傳統(tǒng)的集成測試方式對服務(wù)協(xié)作進(jìn)行驗(yàn)證，必然會面臨成本呈指數(shù)級增長的挑戰(zhàn)。具體體現(xiàn)在:
1.驗(yàn)證成本高?為了驗(yàn)證多個(gè)服務(wù)協(xié)作后的功能正確與否，需要為每個(gè)服務(wù)搭建基礎(chǔ)設(shè)施(包括其依賴的數(shù)據(jù)庫、緩存等)，并執(zhí)行部署、配置等步驟，以確保服務(wù)能正確運(yùn)行。
2.結(jié)果不穩(wěn)定?微服務(wù)構(gòu)建的系統(tǒng)本質(zhì)上是分布式系統(tǒng)，服務(wù)間通信通常都是跨網(wǎng)絡(luò)調(diào)用的。當(dāng)對服務(wù)間協(xié)作進(jìn)行測試時(shí)，網(wǎng)絡(luò)延遲、超時(shí)、帶寬等因素都會影響到測試結(jié)果，極易導(dǎo)致結(jié)果不穩(wěn)定。
3.反饋周期長?相比于傳統(tǒng)的單體應(yīng)用，微服務(wù)架構(gòu)下的可獨(dú)立部署單元多，因此集成測試的反饋周期比傳統(tǒng)的方式更長，定位問題所花費(fèi)的時(shí)間也更長。
微服務(wù)測試?yán)碚?br>
? ? ? ? ? 相比于常見的三層測試金字塔，在微服務(wù)場景下，這個(gè)層次可以被擴(kuò)展為5層（如果將UI測試單獨(dú)抽取出來，可以分為六層）。分別為單元測試、集成測試、組件測試、契約測試、端到端測試。
和測試金字塔的基本原則相同：
1.越往上，越接近業(yè)務(wù)/最終用戶；越往下，越接近開發(fā)
2.越往上，測試用例越少
3.越往上，測試成本越高（越耗時(shí)，失敗時(shí)的信息越模糊，越難跟蹤）
單元測試
單元測試，即每個(gè)微服務(wù)內(nèi)部，對于領(lǐng)域?qū)ο蠛皖I(lǐng)域邏輯的測試。它的隔離性比較高，去除其他依賴，執(zhí)行速度較快。它和其他組件原則上沒有依賴。即使要測試的對象對其他類有依賴，我們會Stub/Mock的手段來將這些依賴消除，比如使用mockito/PowerMock。
集成測試
系統(tǒng)內(nèi)模塊（一個(gè)模塊對其周邊的依賴項(xiàng)）間的集成，系統(tǒng)間的集成都可以歸類為集成測試。比如數(shù)據(jù)庫訪問模塊與數(shù)據(jù)庫的集成和外部service依賴的測試。
集成測試強(qiáng)調(diào)模塊和外部的交互的驗(yàn)證，在集成測試時(shí)，通常會涉及到外部的組件，比如數(shù)據(jù)庫和第三方服務(wù)。這時(shí)候需要盡可能真實(shí)的模擬實(shí)現(xiàn)與外部組件進(jìn)行交互，比如使用和真實(shí)環(huán)境相同類型的數(shù)據(jù)庫。
組件測試
貫穿應(yīng)用層和領(lǐng)域?qū)拥臏y試。不過通常來說，這部分的測試不會訪問真實(shí)的外部數(shù)據(jù)源，而是使用同schema的內(nèi)存數(shù)據(jù)庫，而且對外部service的訪問也會使用Mock的方式。
契約測試
在微服務(wù)場景中，服務(wù)之間會有很多依賴關(guān)系。根據(jù)消費(fèi)者驅(qū)動契約，我們可以將服務(wù)分為消費(fèi)者端和生產(chǎn)者端，通常消費(fèi)者自己會定義需要的數(shù)據(jù)格式以及交互細(xì)節(jié)，并生成一個(gè)契約文件。然后生產(chǎn)者根據(jù)自己的契約來實(shí)現(xiàn)自己的邏輯，并在持續(xù)集成環(huán)境中持續(xù)驗(yàn)證。有興趣研究下Pact框架。
端到端測試
端到端測試是整個(gè)微服務(wù)測試中最困難的，一個(gè)完整的環(huán)境的創(chuàng)建于維護(hù)可能需要花費(fèi)很大的經(jīng)歷，特別是當(dāng)有多個(gè)不同的團(tuán)隊(duì)在獨(dú)立開發(fā)的場景下。另一方面，從傳統(tǒng)的測試金字塔來看，端到端測試應(yīng)該覆蓋那些業(yè)務(wù)價(jià)值最高的Happy Path。也就是說，端到端測試并不關(guān)注異常場景，甚至大部分的業(yè)務(wù)場景都不考慮。在端到端測試中，最重要的反而不是測試本身，而是環(huán)境的自動化能力。實(shí)踐docker為主的devops思想。
項(xiàng)目舉例
XX項(xiàng)目為我廠使用微服務(wù)開發(fā)的一個(gè)產(chǎn)品類項(xiàng)目，系統(tǒng)調(diào)用關(guān)系圖如下，項(xiàng)目開發(fā)實(shí)現(xiàn)了部分單元測試、聯(lián)調(diào)與系統(tǒng)環(huán)境的人員集成測試和與外部系統(tǒng)的聯(lián)調(diào)測試。
項(xiàng)目測試分析
單元測試
單元測試需要實(shí)現(xiàn)在每個(gè)工程模塊中，開發(fā)人員編寫測試代碼，主要包括dao層、biz層和service層方法的測試，采用mock機(jī)制去除外部依賴、同時(shí)采用內(nèi)存數(shù)據(jù)庫也可以去除數(shù)據(jù)庫依賴。
集成測試
通過集成測試來完成測試各個(gè)模塊能否正確交互，并測試其作為子系統(tǒng)的交互性以查看接口的缺陷。
項(xiàng)目集成測試需要解決公有協(xié)議棧（http協(xié)議、webservice協(xié)議）和私有協(xié)議（dubbo協(xié)議、dsf協(xié)議）測試問題，對此使用工具列表如下：
http協(xié)議：postman ??
webservice協(xié)議：soapui ?
dubbo協(xié)議和dsf協(xié)議：自研發(fā)simulator系統(tǒng)?
壓力測試
壓力測試由測試部門發(fā)起，提供測試報(bào)告，主要技術(shù)是通過MockService樁服務(wù)實(shí)現(xiàn)微服務(wù)調(diào)用鏈各級服務(wù)的性能測試結(jié)果。
為滿足項(xiàng)目需求開發(fā)了統(tǒng)一的微服務(wù)mock系統(tǒng)實(shí)現(xiàn)樁服務(wù)，測試設(shè)計(jì)如下圖：
端到端測試
測試人員通過開發(fā)人員提供unifornt-web頁面進(jìn)行業(yè)務(wù)端到端測試，直接穿透后端眾多服務(wù)獲取測試結(jié)果驗(yàn)證測試是否正確，公司其他同事也在實(shí)現(xiàn)以docker為主的devops實(shí)踐方案。
結(jié)束語
本文主要討論了微服務(wù)測試關(guān)注點(diǎn)以及我廠服務(wù)化項(xiàng)目實(shí)踐微服務(wù)測試的時(shí)間，一路走來還存在大量的坑，目前也在慢慢填。后續(xù)文章，我會持續(xù)描述如何具體落實(shí)微服務(wù)單元測試、接口集成測試和自動化測試，同時(shí)也會單獨(dú)介紹微服務(wù)測試的自研發(fā)的測試工具simulator系統(tǒng)。敬請期待！
