第02課 微服務對軟體測試提出的挑戰

2021-10-09 16:31:58 字數 2237 閱讀 2789

在上一課裡,我們學習了微服務的**和主要特點。對於軟體測試人員而言,微服務架構對軟體測試帶來了哪些新的挑戰呢?我們應該用什麼樣的策略和方法來迎接這些挑戰?

軟體測試的目的是確保軟體產品的質量符合預期。衡量測試質量的指標有很多,最常見的是測試覆蓋率和測試成本(包括測試所用時間、測試維護成本),而衡量測試效果的主要手段則是最終產品在實際使用中暴露出來的問題數量(bug number)。

具體到採用微服務架構的產品而言,martin fowler 在關於軟體測試的論述中提出了其目的:

開發團隊採用的任何測試策略,都應當力求為服務內部每個模組的完整性,以及每個模組之間、各個服務之間的互動,提供全面的測試覆蓋率,同時還要保持測試的輕便快捷。

因此,我們需要採取下面幾點測試策略:

不能為了測試而測試,測試的真正目的是為了交付高質量的軟體給使用者,而不是把資源浪費在沒有實際意義的測試用例上。所有的測試層次、流程和用例,都應該有的放矢。

以乙個常見的開發團隊為例,在採用了微服務架構之後,很可能同時會開發多個模組(即微服務),每個微服務有不同的客戶要求、開發周期、開發進度和交付期限,但是整個團隊又必須保證能夠在固定的時間節點(譬如每月一次、每兩周一次,甚至每天一次或者多次),持續地、穩定地為使用者提供可以部署、使用的產品。這意味著,過去那種先等產品經理、業務部門提供需求,開發人員再進行開發,最後交給測試人員執行整合測試、端到端測試的方法,已經無法提供足夠的測試粒度和足夠快的響應速度。

歸結起來,與基於單體式架構的傳統測試方法相比,微服務架構對測試提出了以下挑戰:

不同的服務可能會在不同的環境/設定下執行。

涉及多個服務的 ui 端到端測試(end-to-end 測試,簡稱 e2e 測試)非常容易出錯。

測試結果可能取決於網路的穩定性。

故障分析的複雜度會隨著服務的增加而提高。

與交付週期不同的開發團隊之間的交流成本。

如何應對這些挑戰,我總結了下面這三個原則:

1.自動化:測試任務的增加,要求測試人員必須把主要的精力用於將測試自動化,擺脫手動測試帶來的沉重負擔。當然,自動化測試必須足夠穩定、穩健,不能動輒誤報,否則反而會導致很高的維護成本。

2.層次化:這意味著採用分層次的測試方法,粒度由細到粗,範圍由小到大。下圖說明了幾個主要層次之間的關係:

這就是 mike cohn 提出的測試金字塔(test pyramid),其中最重要的兩個原則是:

最底層的是單元測試(unit test),粒度最細,速度最快,維護成本也最低。往上是針對每種服務內部的各種模組、業務流程的測試。最上面是基於前端 ui 的測試,這部分的粒度最粗,範圍最大(因為會覆蓋大多數服務),但是維護成本最高,因為稍微有些細微的變化就可能需要調整指令碼。而且,由於基於前端,需要設定很多響應時間和等待時間,所以速度最慢。

mike cohn 是 scrum 軟體開發方法的提出者之一,也是 scrum 聯盟的創始成員。他目前是 mountain goat software 公司的所有者,致力於提供關於 scrum 和 agile 軟體開發技術的培訓。

3.視覺化:為了降低交流成本,最好的辦法就是讓所有的測試結果視覺化。這意味著將構建(build)、測試(test)、部署(deploy)所有這些相關任務構建在乙個流水線之中,讓所有團隊成員都可以隨時監控專案進度,找到阻礙專案的瓶頸。

本達人課的後面幾節內容,將會以層次化的方式,逐一介紹在微服務架構中所採用的主要測試方法。如下圖所示,它們主要包括:

整合測試(integration test)

元件測試 (component test)

端到端測試(end-to-end test)

探索測試( exploratory test,即手動測試)

簡單總結一下本課程所學習的內容:

微服務架構對軟體測試提出了很多全新的挑戰。

應對這些挑戰的方法包括:

Spring Cloud 02 (微服務入門)

微服務架構 微服務架構和基礎框架 組建 服務註冊發現 服務提供方必須要註冊上來,並且將自己的訪問位址公開,之後服務的呼叫方才能在這個組建上發現目標服務 服務閘道器 service gateway 會對外遮蔽後台服務細節 可以將外部請求反向路由到具體某個為服務上去 可以做限流和容錯功能 監控和日誌 後...

第02課 裝飾器模式

裝飾器模式動態地將責任附加到物件上。若要擴充套件功能,裝飾者提供了比繼承更有彈性的替代方案。某一天隔壁老王赤果果地來到百貨商店,打算給自己買一套裝備,武裝到牙齒。他買了衣服褲子和帽子,於是老王這樣做 public class laowang 但老王很快發現了問題,每買一件裝備都要修改一次 show ...

軟體架構 微服務架構

我們可以將微服務架構 microservices architecture 理解為 soa 的公升級。基於以下相同點 當問到微服務架構與soa的區別,我們能找到以下回答 微服務其核心思想是在應用開發領域,使用一系列微小服務來實現單個應用的方式途徑,或者說微服務的目的是有效的拆分應用,實現敏捷開發和部...