微服務的災難：測試越來越痛苦---

大家好，我是煎魚。

小鹹魚經過前文所提到的折磨人的 “微服務拆分、微服務環境” 問題後，終於順順利利的上到了測試環境進行測試。

這時候開發、測試同學又鬧新的頭疼了，測了一輪下來。發現好好的。結果發現一上生產就有一些地方有問題，發現沒測到。

這到底是爲什麼呢？

背景

在以往，小鹹魚他們團隊都是傳統的大單體應用。也就是一體化應用，包含了前端、後端等模塊，具備天然的協調性：

但現在，做了微服務化（雛形）後，小鹹魚他們就翻車了，爲什麼呢？

因爲考慮到微服務，微服務就是嚮往單拎一個服務出來，都可以獨立修改，獨立發佈。於是小鹹魚提交了一個迭代的幾個服務變更，想着實現一把 “敏捷” 發佈。

結果一上線就炸了，一大堆的 BUG，光榮加班到晚上 12 點。

這實質上是缺乏端到端測試的一個問題，單服務，無法明確系統正在正常運行。

端到端測試

在測試的質量保障上，我們要站在用戶視角去驗證這個系統，保障整體的系統可用性，而不是單純的前端 BFF，又或是後端 Server 的某些接口能夠正常運行。

在定義上端到端測試（End-to-end Test）是一種用於測試整個應用程序的流程是否符合預期的測試技術。測試同學會模擬用戶真實的使用場景，通過用戶界面測試應用程序。

如下圖：

端到端測試

與小鹹魚團隊那種單純只測接口的方式不同，端到端測試是面向業務的。

其目的是驗證應用程序系統整體上是否符合業務訴求，主要通過 GUI 測試，也會有人稱其爲集成測試、系統測試，黑盒測試。不少公司會將這幾種混在一起。

實則在細節定義上各有不同：

圖來自網絡

本文不是測試方向文章，因此不深究。

問題癥結

那麼小鹹魚他們團隊主要是缺乏端到端的這類集成測試的校驗。直接在迭代中，把幾個微服務一改，接口跑幾下，以爲就是合理通過的了。

真實情況：

我們可以知道單純驗證接口，不走端到端類別的集成測試，是非常風騷的。設身處地的想想如下場景：

有沒有見過一些開發，他在本地測好接口後，一和前端集成上到測試環境。測試人員，一點一個報錯，正向流程壓根跑不通。測試同學苦不堪言，開發同學一下身背數十 BUG，齊齊加班。

但開發同學大呼我在本地的接口測試的完全沒問題。歸根結底，小鹹魚團隊的問題，還是因爲缺乏端到端測試，缺乏齊全的接口自動化用例導致的。

解決思路

在每個迭代中，實際上每個團隊都會專注於系統中所使用的所有服務中的某個服務。

系統中存在的大量微服務和子系統的功能和較窄的測試空間，有可能會導致沒有發現系統或服務中存在的隱患。

這樣測試，問題的出現，甚至是必然的。

在解決思路上常見於：

  1. 新增預發佈環境，做類似端到端測試的集成測試，確保系統集成後會是可用的。

  2. 嘗試更高覆蓋率的接口自動化測試，大多數公司會針對新的，做增量或存量的自動化測試用例的補全。

  3. 藉助線上、線下數據在 CI/CD 時進行自動化測試，實現更全面真實的測試用例。

業內基本是數種思路齊頭並進，最常見的是第一種方式。最有效，但開銷也是最大的，並且會導致預發佈環境的一定阻塞。

隨後第二第三種大多都會緊接着跟進，具體程度會根據公司的軟硬實力（例如：行政手段、基礎設施等）不同而做的深度不同。

甚至前幾天聽小鹹魚說，面試時還聽到不少公司延伸了外包崗位專門做一塊的內容。

總結

雖說這個問題並不是 “微服務” 架構所獨有的。但是顯然微服務化後放大了測試的深坑問題。

很多公司的流程和措施都是爲了保障一些東西，像小鹹魚團隊這樣，被網上佈道師例舉的優點遮蔽了雙眼，後面又被迫把端到端測試加回來的不在少數。

你們的團隊又是如何高效解決這個問題的呢，歡迎在評論區留言和交流！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ogi_pnmzRsjA5pic1arEjw

猜你喜歡