這是由來自AWS的工程師Nathan Peck發布的“測試微服務”系列文章的第一篇,介紹了測試金字塔模型以及如何建立測試文化。以下內容翻譯自Nathan的博客。
自動化測試是一個軟件公司取得成功的關鍵因素之一。經過嚴格測試的代碼容易獲得客戶的信賴,而沒有經過測試或缺乏嚴密測試的軟件系統容易出現故障,讓客戶感到失望。
盡管在測試單體系統方面已經有很多最佳實踐,但在測試分布式系統(比如微服務)時仍然面臨很多挑戰。開發者不但要確保每個組件的內部行為是一致的,也要確保組件之間能夠良好地集成。分布式系統需要額外的故障測試,比如針對網絡故障進行測試。有些分布式系統太過龐大,進行完整的端到端測試不太現實,所以開發人員需要制定一些策略,對整體架構的局部進行單獨測試,同時還能保證組件之間的互操作性。
這篇文章介紹了一些測試分布式系統的基礎概念,并討論了如何在開發流程中加入這些概念,確保它們可以有效地落地。
金字塔模型
為了構建一個全面的測試框架,我們需要先了解“測試金字塔”概念。這一概念是由Mike Cohn提出的,當時的大部分軟件測試還是通過用戶界面進行的。測試工程師直接手動操作用戶界面,或者編寫自動化宏腳本來操作界面。這種方式通常無法檢測出代碼內部的問題。此時,測試金字塔的概念就變得十分重要,因為它讓我們明白,用戶界面測試應該處于金字塔的頂端。
使用多種測試類型可以幫助我們檢測出不同類型的問題,不同的測試類型集中在系統的不同層面上。一個分布式系統的端到端測試可以被分為以下幾個層次。
單元測試
單元測試用于驗證服務內部的類方法或函數的行為。它們執行代碼文件里的類方法或函數,提供不同的輸入,并驗證與每一個輸入相對應的輸出。
集成測試
集成測試用于驗證服務的外部行為。測試框架會啟動服務的一個實例,并調用服務的外部接口來執行業務邏輯。
端到端測試
端到端測試用于驗證多個服務之間的交互行為。在一個獨立的環境里啟動多個服務的實例,讓服務實例間發生交互,以便完成測試。端到端測試需要發起網絡請求,比如REST請求,然后被調用的服務返回的響應進行驗證。
用戶界面測試
用戶界面測試用于驗證整個平臺的行為,不僅會測試客戶端的邏輯,也會測試后端系統的邏輯,確保客戶端和后端系統能夠正常交互。
建立測試文化
只有把測試作為開發流程和發布管道不可或缺的組成部分,才能讓它發揮應有的作用。如果代碼有問題,就不應該把它發布出去。
無法通過測試的代碼不應該被合并到代碼倉庫里。無法通過測試的代碼不應該被發布出去。金字塔模型里的每個測試層級都建立在下一個層級之上:
工程師們需要對測試抱有正確的態度,他們不僅要開發功能,也要負責編寫測試代碼,所以他們在很大程度上決定著測試的質量和效率。如果沒有認真對待測試,就無法測出很多邊界情況,又或者為了提高“覆蓋率”而走捷徑,但其實什么都沒有測到。
我們不能為了測試而測試,測試的真正目的是為了交付高質量的軟件給用戶。測試人員要保證軟件質量高起高走,在加入新特性或更改已有特性時仍能保證質量。
這就要求我們要嚴肅對待故障測試,我們不能為了讓測試能夠通過而去修改它們。有些測試時而通過時而失敗,它們都是假性的測試,需要引起我們的注意。如果生產環境出現了缺陷,說明測試沒有到位。如果發現了測試沒能覆蓋到的地方,需要給工程師足夠的時間和資源去修復缺陷。
我們不能僅僅依賴工程師來建立良好的測試文化。產品經理也需要了解測試流程,并參與其中。如果他們對開發人員作出過分的要求,要求開發新功能的速度超過了開發人員能夠對新功能作出全面測試的速度,那么軟件質量就會受到影響,問題會一路跟著進入到測試管道,到達用戶那里,影響用戶滿意度。
結論
為分布式系統創建完備的測試框架要求使用多個層級的測試。基于客戶端UI的測試無法捕捉到各種類型的錯誤。軟件工程師們必須建立起一種測試文化,把自動化測試融入到開發和發布管道的各個階段,包括單元測試、集成測試、端到端測試和UI測試。
查看英文原文:Microservice Testing: Introduction
感謝郭蕾對本文的審校。