|
寫(xiě)在前邊 微服務(wù)應(yīng)用程序的另一個(gè)好處是更快且更容易更新。當(dāng)開(kāi)發(fā)者對(duì)一個(gè)傳統(tǒng)的單體應(yīng)用程序進(jìn)行變更時(shí)，他們必須做詳細(xì)的QA測(cè)試，以確保變更不會(huì)影響其他特性或功能。但有了微服務(wù)，開(kāi)發(fā)者可以更新應(yīng)用程序的單個(gè)組件。 
微服務(wù)在帶來(lái)好處的同時(shí)，同樣也帶來(lái)了挑戰(zhàn)，具體可以總結(jié)為以下幾點(diǎn)。 系統(tǒng)依賴(lài)性增加由單體應(yīng)用過(guò)渡到微服務(wù)架構(gòu)時(shí)，需要加入更多的隔離組件，這些組件的加入勢(shì)必會(huì)帶來(lái)更多的依賴(lài)性。也就是說(shuō)，復(fù)雜性會(huì)變得更高。這同樣給測(cè)試帶來(lái)了相應(yīng)的復(fù)雜度，原本只需要從接口層開(kāi)始的測(cè)試，一下子從深度上多出來(lái)更多的依賴(lài)，測(cè)試的工作量也是成倍地增加。 我們拿一個(gè)單體應(yīng)用有10個(gè)接口的工程舉例，原本測(cè)試只需要測(cè)試這10個(gè)接口就可以，但是使用微服務(wù)構(gòu)建之后，接口的數(shù)量明顯增加，每一一個(gè)接口所衍生出來(lái)的新接口都需要測(cè)試，這樣可能是一一個(gè)倍數(shù)的關(guān)系。所以，微服務(wù)的接口抽象及經(jīng)驗(yàn)就顯得非常重要。 并行開(kāi)發(fā)接口數(shù)量的增加還會(huì)帶來(lái)-一個(gè)問(wèn)題，就是原本一個(gè)團(tuán)隊(duì)維護(hù)的項(xiàng)目，被拆分之后，可能是兩個(gè)或者更多的團(tuán)隊(duì)來(lái)進(jìn)行維護(hù)。在需求變化時(shí)，一個(gè)接口的變動(dòng)，導(dǎo)致的可能是連鎖反應(yīng)，當(dāng)其中的一個(gè)接口出現(xiàn)延期時(shí)，整個(gè)測(cè)試計(jì)劃就很難得到保證。團(tuán)隊(duì)需要等待其他團(tuán)隊(duì)以完整相關(guān)微服務(wù)的并行開(kāi)發(fā)，微服務(wù)數(shù)量越多，需要考慮的對(duì)象就越廣泛，這意味著以并行方式開(kāi)發(fā)及發(fā)布新功能就變得更加困難。所以，微服務(wù)的并行開(kāi)發(fā)同樣帶來(lái)了管理上的挑戰(zhàn)。 與傳統(tǒng)測(cè)試的沖突對(duì)于單塊應(yīng)用，在一個(gè)機(jī)器上就可以模擬出所有的依賴(lài)，但是在微服務(wù)場(chǎng)景下，由于依賴(lài)的服務(wù)往往很多，因此要搭建一個(gè)完整的環(huán)境非常困難。 更多潛在的故障微服務(wù)遷移的另一大負(fù)面影響在于引發(fā)大量獨(dú)立故障點(diǎn)。 更多的團(tuán)隊(duì)交互微服務(wù)的方式對(duì)于測(cè)試來(lái)說(shuō)，意味著需要交互和溝通的人數(shù)必然增加，因?yàn)橐话愕膱F(tuán)隊(duì)很難做到需求和實(shí)現(xiàn)的高效溝通。溝通成本的增加有可能導(dǎo)致某個(gè)重要的功能點(diǎn)沒(méi)得到優(yōu)先測(cè)試，而不重要的功能點(diǎn)卻被優(yōu)先測(cè)試，從而導(dǎo)致整體工期的拖延。 微服務(wù)測(cè)試 在微服務(wù)中，測(cè)試是一個(gè)非常重要的環(huán)節(jié)，相比于常見(jiàn)的三層測(cè)試金字塔，在微服務(wù)場(chǎng)景下，這個(gè)層次可以被擴(kuò)展為5層，如下圖所示。
和測(cè)試金字塔的基本原則相同： 越往上，越接近業(yè)務(wù)/最終用戶(hù)；越往下，越接近開(kāi)發(fā)。越往上，測(cè)試用例越少。越往上，測(cè)試成本越高(越耗時(shí)，失敗時(shí)的信息越模糊，越難跟蹤)。越往上，測(cè)試的實(shí)現(xiàn)和維護(hù)成本就越高，測(cè)試速度也越慢。接下來(lái)看一下，上面的測(cè)試模型。 UI/UE 測(cè)試 需要測(cè)試的方面很多，包括功能測(cè)試、兼容性測(cè)試、安裝卸載測(cè)試等。一般是根據(jù)業(yè)務(wù)模型編寫(xiě)測(cè)試用例，然后根據(jù)測(cè)試用例來(lái)判斷結(jié)果的正確性與否。當(dāng)然也包括測(cè)試用戶(hù)界面的風(fēng)格是否滿(mǎn)足客戶(hù)要求，文字是否正確，頁(yè)面美工是否好看，文字、圖片組合是否完美，背景是否美觀，操作是否友好，等等。UI測(cè)試還可確保UI中的對(duì)象按照預(yù)期的方式運(yùn)行，并符合公司或行業(yè)的標(biāo)準(zhǔn)，包括用戶(hù)友好性、人性化、易操作性測(cè)試。UI測(cè)試比較主觀，與測(cè)試人員的喜好有關(guān)，比如頁(yè)面基調(diào)顏色刺眼、用戶(hù)登錄頁(yè)面比較難以找到、文字中出現(xiàn)錯(cuò)別字、頁(yè)面圖片范圍太廣等都屬于UI測(cè)試中的缺陷。嚴(yán)格來(lái)說(shuō)，所有的測(cè)試都包括UI/UE 測(cè)試，不僅僅是在微服務(wù)測(cè)試中。 端對(duì)端測(cè)試 除了測(cè)試服務(wù)，測(cè)試者還需要確保無(wú)論使用何種架構(gòu)構(gòu)建，應(yīng)用都必須實(shí)現(xiàn)業(yè)務(wù)目標(biāo)，同時(shí)我們還要測(cè)試集成系統(tǒng)運(yùn)行的完整性。因此在微服務(wù)測(cè)試方案中，端對(duì)端測(cè)試占據(jù)了重要的角色。除此之外，考慮到在微服務(wù)架構(gòu)中有一些執(zhí)行相同行為的可移動(dòng)部件，端對(duì)端測(cè)試時(shí)需要找出覆蓋缺口，并確保在架構(gòu)重構(gòu)時(shí)業(yè)務(wù)功能不會(huì)受到影響。 API 測(cè)試 API (Application Programming Interface， 簡(jiǎn)稱(chēng)API)又稱(chēng)為應(yīng)用編程接口，就是軟件系統(tǒng)不同組成部分銜接的約定。 API測(cè)試是針對(duì)系統(tǒng)所提供的API做各方面的驗(yàn)證。API 的功能測(cè)試類(lèi)似于UI功能測(cè)試，都是在已知輸入內(nèi)容和期望結(jié)果的前提下，使用這個(gè)功能/調(diào)用這個(gè)API并且驗(yàn)證是否能返回期望的結(jié)果。不同的是，API測(cè)試在返回結(jié)果被呈現(xiàn)給客戶(hù)前就完成了，從而對(duì)測(cè)試環(huán)境的依賴(lài)會(huì)比較小。 API功能測(cè)試的主要手段是使用工具/軟件調(diào)用待測(cè)API,然后驗(yàn)證是否返回期望的output。這個(gè)output通?？赡苁? 返回成功或者失敗的status;一段數(shù)據(jù)或者information;跳轉(zhuǎn)到其他API。組件接口測(cè)試 盡管單獨(dú)測(cè)試模塊非常重要，但測(cè)試各個(gè)模塊能否正確交互，并測(cè)試其作為子系統(tǒng)的交互性以查看接口的缺陷同樣重要，這項(xiàng)工作可以通過(guò)集成測(cè)試來(lái)完成。集成測(cè)試的目的在于：通過(guò)集成模塊檢查路徑暢通與否，來(lái)確認(rèn)模塊與外部組件的交互情況。執(zhí)行“網(wǎng)關(guān)集成測(cè)試”與“持續(xù)集成測(cè)試”能確保在找到外部組件間的邏輯回歸與斷裂之處時(shí)迅速獲得反饋，從而有助于評(píng)估各個(gè)單獨(dú)模塊中所含邏輯的正確性。 單元測(cè)試 單元測(cè)試的范圍局限在服務(wù)內(nèi)部，它是圍繞著一組相關(guān)聯(lián)的案例編寫(xiě)的。由于單元測(cè)試的數(shù)量較多，理論上應(yīng)當(dāng)是以自動(dòng)化方式執(zhí)行的。在微服務(wù)中執(zhí)行單元測(cè)試時(shí)，必須將協(xié)作型單元測(cè)試(Sociable Unit Testing)與孤立型單元測(cè)試( Solitary Unit Testing)相結(jié)合，通過(guò)觀察其狀態(tài)變化來(lái)檢查模塊行為，并查看對(duì)象及其依賴(lài)項(xiàng)之間的交互情況。然而，測(cè)試者需要確保在單元測(cè)試中，當(dāng)單元“行為”受限時(shí)，“實(shí)現(xiàn)"不會(huì)受到測(cè)試的限制——可以通過(guò)不斷將單元測(cè)試的價(jià)值與維護(hù)成本/實(shí)現(xiàn)受限的成本相對(duì)比來(lái)做到這一點(diǎn)。 單元測(cè)試 單元測(cè)試就是編寫(xiě)測(cè)試代碼，用來(lái)檢測(cè)特定的、明確的、細(xì)顆粒的功能。單元測(cè)試不僅僅用來(lái)保證當(dāng)前代碼的正確性，更重要的是用來(lái)保證代碼修復(fù)、改進(jìn)或重構(gòu)之后的正確性。 一個(gè)良好的單元測(cè)試包括三個(gè)步驟: 準(zhǔn)備測(cè)試環(huán)境和數(shù)據(jù);執(zhí)行目標(biāo)方法;驗(yàn)證執(zhí)行結(jié)果(判斷程序的運(yùn)行結(jié)果是否如你所想)。在做單元測(cè)試時(shí)，代碼覆蓋率常常被拿來(lái)作為衡量測(cè)試好壞的指標(biāo)，甚至用代碼覆蓋率來(lái)考核測(cè)試任務(wù)完成情況，比如代碼覆蓋率必須達(dá)到80%或90%。 那么一般的代碼覆蓋率都包含哪些呢?通常的評(píng)估指標(biāo)如下:， 行覆蓋率;分支覆蓋率;路徑覆蓋率;條件覆蓋率;狀態(tài)機(jī)覆蓋率。目前很多公司已經(jīng)意識(shí)到了單元測(cè)試的重要性，但國(guó)內(nèi)堅(jiān)持寫(xiě)單元測(cè)試的團(tuán)隊(duì)并不多，其中一個(gè)難點(diǎn)在于沒(méi)有考量，沒(méi)有很好地執(zhí)行單元測(cè)試覆蓋率檢測(cè)。 API測(cè)試 對(duì)于API的測(cè)試，根據(jù)不同團(tuán)隊(duì)的不同情況，如果測(cè)試人員的編碼能力強(qiáng)，則建議使用編碼的方式進(jìn)行，方便與持續(xù)集成系統(tǒng)進(jìn)行集成。但是目前能夠達(dá)到這種級(jí)別的測(cè)試少之又少，所以測(cè)試一般使用工具完成。 Postman最基礎(chǔ)的功能就是發(fā)送HTTP請(qǐng)求，支持GET/PUT/POST/DELETE,還有很多其他HTTP方法。 通過(guò)填寫(xiě)URL、header、 body 等就可以發(fā)送一個(gè)請(qǐng)求， 這對(duì)于我們平時(shí)做一些簡(jiǎn) 單的測(cè)試是夠用的。 每次配置完一個(gè)請(qǐng)求都可以保存到一個(gè)集合中，如此一來(lái)，下次測(cè)試可以直接從集合中找到你要執(zhí)行的測(cè)試。 集合不單單只有分類(lèi)和存儲(chǔ)功能，Postman支持--鍵運(yùn)行整個(gè)集合內(nèi)的測(cè)試。 當(dāng)然，也可以使用Hitchhiker。Hitchhiker是一款開(kāi)源的 Restful API測(cè)試工具，支持Schedule、數(shù)據(jù)對(duì)比、壓力測(cè)試、支持上傳腳本定制請(qǐng)求,可以輕松部署到本地，和團(tuán)隊(duì)成員一起管理API。 
A/B 測(cè)試 A/B測(cè)試 A/B測(cè)試又叫分離測(cè)試，類(lèi)似于顧客焦點(diǎn)團(tuán)體，將一系列內(nèi)容變化在一定基準(zhǔn)內(nèi)進(jìn)行比較。A/B測(cè)試來(lái)自郵件宣傳，發(fā)信者將同一目的內(nèi)容的不同版本郵寄到目標(biāo)群體中，測(cè)量回應(yīng)率。根據(jù)這些數(shù)據(jù)，商家可以對(duì)以后的直郵的內(nèi)容做相應(yīng)修改，向更多回應(yīng)率的版本改進(jìn)。 A/B測(cè)試最核心的思想，即: 多個(gè)方案并行測(cè)試;每個(gè)方案只有一個(gè)變量不同;以某種規(guī)則優(yōu)勝劣汰。事實(shí)上，完全可以設(shè)計(jì)多個(gè)方案進(jìn)行測(cè)試，比如A B C測(cè)試，“AB測(cè)試”這個(gè)名字只是一個(gè)習(xí)慣的叫法。A/B測(cè)試需要將多個(gè)不同的版本展現(xiàn)給不同的用戶(hù)，即需要一個(gè)“分流"的環(huán)節(jié)。分流可以在客戶(hù)端做，也可以在服務(wù)器端做。傳統(tǒng)的AB測(cè)試- -般是在服務(wù)端分流的，即基于后端的A/B測(cè)試(Back-end AB test)。當(dāng)用戶(hù)的請(qǐng)求到達(dá)服務(wù)器時(shí)，服務(wù)器根據(jù)一定的規(guī)則，給不同的用戶(hù)返回不同的版本，同時(shí)記錄數(shù)據(jù)的工作也在服務(wù)端完成。 基于前端的A/B測(cè)試的監(jiān)控的粒度則更細(xì)一些，能夠定位到具體的用戶(hù)。利用前端JavaScript方法，在客戶(hù)端進(jìn)行分流，同時(shí)可以用JavaScript記錄下用戶(hù)的鼠標(biāo)行為，甚至鍵盤(pán)行為，直接發(fā)送到對(duì)應(yīng)的打點(diǎn)服務(wù)器。這樣的好處是不需要技術(shù)部(如果前端工程師與后端工程師分屬不同部門(mén))參與，并且可以比較精確地記錄下用戶(hù)在頁(yè)面上的每一個(gè)行為，甚至包括后端方法難以記錄到的無(wú)效點(diǎn)擊。 對(duì)于大部分需求來(lái)說(shuō)，我們希望各個(gè)版本的訪問(wèn)人數(shù)平均分配。解決辦法有很多種，比如根據(jù)某一個(gè)Cookie ID來(lái)劃分用戶(hù)，這需要為每一個(gè)用戶(hù)植入-一個(gè)全局不重復(fù)的Cookie ID，因?yàn)橐?guī)則是自定義的，所以可以根據(jù)CookieID的規(guī)則對(duì)流量進(jìn)行切分。比如單數(shù)的顯示A版本，偶數(shù)的顯示B版本。因?yàn)镃ookie ID 一般設(shè)定后不會(huì)輕易改變，但不足之處就是如果用戶(hù)瀏覽器不支持Cookie, 則分流就不能正常進(jìn)行了。不過(guò)，現(xiàn)代瀏覽器默認(rèn)情況下都是支持Cookie的，所以如果出現(xiàn)這種小概率的情況，我們也可以在處理樣本時(shí)忽略。 還有一點(diǎn)需要注意的是，A/B測(cè)試的頁(yè)面必須有較高的UV，即獨(dú)立訪客數(shù)，因?yàn)榉至鲙в幸欢ǖ碾S機(jī)性，如果頁(yè)面UV太小，分到每-一個(gè)版本的人數(shù)就更少，結(jié)果很有可能被一些偶然因素影響。而UV較大時(shí)，根據(jù)大數(shù)定理，我們得到的結(jié)果會(huì)接近于真實(shí)數(shù)據(jù)。 對(duì)于微服務(wù)的場(chǎng)景，我們可以使用網(wǎng)關(guān)進(jìn)行分流，分流之后就可以定向采集需要的數(shù)據(jù)。采集的數(shù)據(jù)根據(jù)業(yè)務(wù)分析的需要，包括用戶(hù)的瀏覽器版本、點(diǎn)擊事件的擱置、點(diǎn)擊的時(shí)間、訪問(wèn)的URL信息等。將采集到的數(shù)據(jù)存儲(chǔ)到大數(shù)據(jù)平臺(tái)，以供需要分析的部門(mén)進(jìn)行二次加工分析。 靜態(tài)代碼分析 在軟件開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)團(tuán)隊(duì)往往要花費(fèi)大量的時(shí)間和精力發(fā)現(xiàn)并修改代碼缺陷。靜態(tài)代碼分析(static code analysis) 工具能夠在代碼構(gòu)建過(guò)程中幫助開(kāi)發(fā)人員快速、有效地定位代碼缺陷并及時(shí)糾正這些問(wèn)題，僅通過(guò)分析或檢查源程序的語(yǔ)法、結(jié)構(gòu)、過(guò)程、接口等來(lái)檢查程序的正確性，找出代碼隱藏的錯(cuò)誤和缺陷，如參數(shù)不匹配、有歧義的嵌套語(yǔ)句、錯(cuò)誤的遞歸、非法計(jì)算、可能出現(xiàn)的空指針引用等。從而極大地提高軟件可靠性并節(jié)省軟件開(kāi)發(fā)和測(cè)試成本。 常用的分析工具包括Checkstyle、FindBugs、 PMD等，下面我們來(lái)一起認(rèn)識(shí)一下這些工具。 SonarQube 質(zhì)量監(jiān)控 Sonar ( SonarQube)是一個(gè)開(kāi)源平臺(tái)，用于管理源代碼的質(zhì)量。Sonar 不只是一個(gè)質(zhì)量數(shù)據(jù)報(bào)告工具，更是代碼質(zhì)量管理平臺(tái)。通過(guò)插件機(jī)制，Sonar 可以集成不同的測(cè)試工具，代碼分析工具，以及持續(xù)集成工具。 與持續(xù)集成工具(例如，Hudson/Jenkins 等)不同，Sonar 并不是簡(jiǎn)單地把不同的代碼檢查工具(例如，F(xiàn)indBugs、 PMD等)結(jié)果直接顯示在Web頁(yè)面上，而是通過(guò)不同的插件對(duì)這些結(jié)果進(jìn)行再加工處理，通過(guò)量化的方式度量代碼質(zhì)量的變化，從而可以方便地對(duì)不同規(guī)模和種類(lèi)的工程進(jìn)行代碼質(zhì)量管理。 在對(duì)其他工具的支持方面，Sonar不僅提供了對(duì)IDE的支持，可以在Eclipse 和IntelliJ IDEA這些工具里聯(lián)機(jī)查看結(jié)果；同時(shí)Sonar 對(duì)大量的持續(xù)集成工具提供了接口支持，可以很方便地在持續(xù)集成中使用Sonar。 此外，Sonar ( SonarQube)的插件還可以對(duì)Java以外的其他編程語(yǔ)言提供支持，對(duì)國(guó)際化及報(bào)告文檔化也有良好的支持，支持的語(yǔ)言包括Java、PHP、C#、C、Cobol、PL/SQL、Flex等。 SonarQube可以從多個(gè)維度檢測(cè)代碼質(zhì)量，包括以下維度。 復(fù)雜度分布(complexity): 代碼復(fù)雜度過(guò)高將難以理解、難以維護(hù)。重復(fù)代碼(duplications): 程序中包含大量復(fù)制粘貼的代碼是質(zhì)量低下的表現(xiàn)。單元測(cè)試(unittests):統(tǒng)計(jì)并展示單元測(cè)試覆蓋率。編碼規(guī)范(coding rules):通過(guò)FindBugs、PMD、CheckStyle 等規(guī)范代碼編寫(xiě)。注釋(comments): 少了可讀性差，多了看起來(lái)費(fèi)勁。潛在的Bug (potential bugs):通過(guò)FindBugs、PMD、CheckStyle 等檢測(cè)潛在的Bug。結(jié)構(gòu)與設(shè)計(jì)(architecture & design):依賴(lài)、耦合等。后記 不論是自動(dòng)化測(cè)試，還是質(zhì)量管理，都只是一種實(shí)現(xiàn)手段；它們真正存在的價(jià)值在于提高代碼質(zhì)量和提高產(chǎn)品的持續(xù)交付能力。 在現(xiàn)在的軟件開(kāi)發(fā)過(guò)程中，能夠自動(dòng)化地實(shí)現(xiàn)測(cè)試和質(zhì)量管理是非常重要的，既節(jié)省了測(cè)試和質(zhì)量管理人員的成本，也提高了整體軟件構(gòu)建的速度，在AI大行其道的今天，必將成為微服務(wù)生態(tài)閉環(huán)中非常重要一個(gè)環(huán)節(jié)。
|
客服電話(huà)
官方微信
請(qǐng)發(fā)表評(píng)論