雲原生應用的測試指南 | IDCF

譯者注：這是國外一篇介紹如何測試雲原生應用的文章，雲原生應用一般是基於微服務架構風格的分佈式應用程序，傳統的測試方法和技術已不能知足產品交付的質量要求，只有結合現代測試技術，既增強研發階段的測試，又引入產品發佈後的線上測試，纔能有效應對雲原生應用在功能、性能、安全、可靠性方面的挑戰。這些新的技術包括契約測試，灰度發佈，混沌工程，在線監控和日誌分析等。

1、應用程序的「雲原生化」

愈來愈多的公司正將本地部署的應用遷移（或計劃遷移）到雲上，它們的目標是設計、架構並構建的應用程序能夠很容易地擴展並部署到雲上，而且能夠充分利用雲平臺（如AWS、Azure，或GCP）提供的計算模式。

「雲原生化」和開發雲原生應用指的是設計、架構並構建的分佈式軟件應用可以徹底利用雲服務商提供的PaaS（Platform-as-a-Service，平臺即服務）和IaaS（Infrastructure-as-a-Server，基礎設施即服務）的服務模式。這些應用一般是做爲一組微服務（基於微服務架構風格）構建的。

這些鬆耦合的微服務運行在一個由公有云、私有云和混合雲提供的動態環境中的容器化和動態編排平臺上（基於Kubernets、Docker等技術）。促使企業進行應用的「雲原生化」儘管有不一樣方面的緣由，但其中包括一些最重要的驅動因素，如：縮短重要的軟件應用的宕機時間、增長應用的彈性能力、根據業務須要動態擴容或縮容，提升應用開發速度、快速響應用戶需求、更專一於創新從而增長更多的業務價值。

2、雲原生應用的測試方法

測試老是幫助咱們更深刻地挖掘問題，並向用戶交付高質量的產品。軟件測試在幫助咱們收集產品的狀態、可維護性、性能、健壯性和可靠性等大量有用信息方面發揮了重要做用。經過對這些信息進行分析，企業的決策者們能夠更有信心地進行產品發佈的決策。

相比其它軟件應用（例如單體架構的應用）的傳統測試方法，雲原生應用的測試要更復雜。這是由於雲原生應用是動態、分佈式構建的一組微服務（每一個微服務能夠獨立發佈），發佈速度更快（一般採用CI/CD和DevOps實踐），並且存在難以預測和跟蹤的故障模式。

這就要求咱們適應這些變化，從新審視傳統的測試技術，並採用新的、現代的測試方法來預見、檢測、響應、調試、分析和報告問題。

這些測試技術將在許多方面幫助咱們找到並揭示大量信息，這將有助於提升雲原生應用的總體質量。對於這類應用，軟件測試已成爲軟件開發生命週期的全部階段中不可分割的一部分，而且促使業務分析人員、開發人員、測試人員、架構師和軟件設計人員等進行更多溝通和交流：提出疑問，共享信息，討論並評估問題和風險。如今就讓咱們一塊兒看看針對雲原生應用的有效的測試技術。

2.1 單元測試，集成測試，端到端的測試

經過在微服務架構的雲原生應用中測試單個服務組件中的最小可測試單元，能夠在開發早期階段發現許多缺陷。快速、可靠、自動化的單元測試不只能肯定服務組件的獨立單元/模塊是否能正常工做，也將有助於開發人員觀察單元/模塊狀態的變化，檢查對象之間的交互，以及對象之間的依賴，對於組件的狀態得到快速反饋，或者因爲代碼變動致使了迴歸缺陷等。這些測試讓軟件代碼更具備可測試性並有利於代碼的重構。

軟件應用的服務組件在集成以後，由持續集成服務器觸發的集成測試將有助於測試各個服務組件之間或服務組件與外部服務、系統、數據存儲之間的通訊路徑和交互。儘管測試全部的集成點是困難的，但團隊必須採用基於風險的測試方法，根據制定的目標、範圍和優先級執行測試。
對於雲原生應用來講，執行端到端測試是比較困難的，由於這涉及到微服務架構中每一個獨立開發的部分，測試進度會比較緩慢，並且有時候會很是不穩定，不得不考慮到服務組件之間的異步調用和環境因素的影響。這都形成端到端的測試在測試準備、運行和維護方面的成本較高。儘管如此，研發團隊仍然須要運行其中的一些端到端的測試，儘管不那麼頻繁，但須要覆蓋重要的業務路徑，並驗證完整的應用是否知足業務需求。

2.2 契約測試

既然會涉及單個獨立的微服務，研發團隊也須要對微服務執行契約測試。微服務體系架構由「生產者」服務組件和「消費者」服務組件組成。當消費者組件試圖與生產者組件結合並使用它的輸出時，一個「服務契約」（由預期的輸入和輸出組成）就在它們之間造成。

由這些契約測試組成的自動化測試套件能夠集成到流水線中，運行這些測試來驗證生產者和消費者組件中的任何更改是否符合兩者之間的服務契約。開發和運行契約測試是測試雲原生應用的一項重要內容。

2.3 非功能測試

對於雲原生應用來講，功能測試很是重要，能夠驗證產品是否知足業務需求。可是，當產品發佈到生產環境中，功能測試可以提供產品將以預期的方式響應的信心嗎？當忽然出現服務器崩潰、服務組件宕機或某些依賴服務不可用時，服務是否可以安全降級？產品上線後是否足夠安全？該產品可否應付突發的大量用戶請求？

非功能測試對於雲原生應用很是重要。對於上述問題，任何缺陷或者偏離預期行爲的狀況都要求咱們以最少的工做量和步驟儘快發現、分析並修復問題，以免這些問題再次發生。

爲了確保這些問題發生的機率或影響很小，咱們須要藉助有用的工具（許多工具是雲提供商本身提供的）測試產品的性能（如延遲、負載平衡的影響、緩存、產品性能中的風險因素、基於性能指標來對比和提供反饋結果的基準測試等）、可用性、負載（例如在接近真實負載條件下對產品吞吐量的影響）和安全性（靜態和動態），並預先處理任何潛在的風險。

2.4 混沌工程和失效模式測試

說到質量工程，咱們大多數人都知道像「FMEA」（失效模式和影響分析）技術，它能夠幫助咱們識別產品中的潛在失效模式及其緣由和後果。對於單體應用，大多數潛在的故障模式是已知的，能夠識別的，所以能夠在代碼結構中處理。即便不處理，當缺陷發生時也可以快速修復。

可是對於微服務來講，產品在生產環境中失敗的方式是難以計數、不可預測的，由於涉及到大量的複雜性。在這些狀況下，「混沌工程」會頗有幫助。它是一種識別在生產環境中產品失效的方法，以創建對系統應對意外或未知操做能力的信心。

「混沌工程」和FMEA一塊兒，經過注入可控的故障，幫助咱們得到一個可靠性和彈性能力更高的產品，讓咱們可以檢測和分析這些故障，從而預知產品在哪些方面會出故障。這將幫助咱們調整現有的流程，以防止故障級聯的後果，並提早計劃如何縮短MTTR（Mean Time to Recovery/Restore，故障平均恢復時間）。

2.5 可觀察性、在線監控和日誌分析

做爲軟件工程師，對雲原生應用咱們既要在上線前進行測試也要在上線後進行測試。若是操做得當，線上測試能夠爲咱們提供許多有價值的信息，爲計劃下一個版本的彈性、可伸縮性和靈活性提供重要反饋信息。但必須記住，線上測試的設置和執行很複雜，在執行這些測試時必須很是當心，並充分考慮到，若是線上測試沒有正確和安全的執行，對業務和用戶帶來什麼樣的影響。
「可觀察性」是幫助咱們更好地理解產品中軟件行爲的方法之一，是指經過觀察產品的輸出來瞭解產品內部狀態的方法。咱們可使用一些監控技術和工具收集、存儲、維護和查詢應用的狀態、行爲，以及服務之間交互相關的信息。這些日誌和指標能夠被進一步分析來獲取有價值的發現，或者快速評估和分析缺陷。一些雲服務提供商會提供開箱即用的功能和工具幫助咱們實現監控、信息收集和分析。

3、結論

咱們必須明白，不管計劃和執行多少功能測試和非功能測試，不管咱們如何努力提升這些雲原生應用的質量，最終用戶仍然會面臨問題。咱們的目標是減小意外事件的風險，快速分析和修復故障，從既往事件中學習並將這些知識用於下一個版本。

在生產環境中發現缺陷的成本是很是高的，咱們應該在軟件的開發生命週期中儘早發現缺陷。在生產環境中，咱們能夠利用金絲雀部署（把全部功能推送給部分用戶），暗啓動（把新功能/主要功能推送給部分用戶），智能功能切換/標誌/位/翻轉器（容許特定功能的應用被激活或停用）等技術在生產環境中逐漸暴露缺陷。

但咱們也必須記住，因爲各類限制因素，包括預算、團隊承接能力、時間表、上市時間、大量互相依賴/獨立的服務、環境的可用性等，經過已知的測試策略作詳盡的測試是不可能的。所以，團隊須要採起基於風險的測試方法，也必須意識到和缺陷有關的各類類型的成本，好比檢測成本，分析調試成本，機會成本，修復成本，驗證成本和維護成本。

考慮到全部本文中討論的因素，能夠確定的是，儘管測試雲原生應用是困難和具備挑戰性的，但咱們可讓新的測試方結合自身的專業知識、不一樣的測試技術和策略，向用戶交付高質量的產品。

來源：軟件質量報道
做者：Sumon Dey

5月每週四晚8點，【冬哥有話說】質量與測試專場。公衆號留言「質量」可獲取地址

• 0506 朱少民 《如何最大化軟件測試效能》
• 0513 陳琦 《數據驅動測試》
• 0520 陳霽 《沒錯，去QA是提升質量最有效的方法！》
• 0527 施慧斌 《DevOps實踐之持續測試》