Categories
程式開發

聊聊雲原生時代的測試


傳統意義上的測試是足球場上的守門員,互聯網下的測試提倡更多的左移,類似保健醫生,雲原生下的測試應該怎麼努力呢?個人覺得縱向深入專項測試右移 OPS 可能是一個方向。

什麼是雲原生?

概述:在動態、開放的生態環境中構建和運行彈性服務。代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。

以下是 CNCF 對雲原生的重新定義(中英對照):

loud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中,構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段,雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

雲原生計算基金會(CNCF)致力於培育和維護一個廠商中立的開源生態系統,來推廣云原生技術。我們通過將最前沿的模式民主化,讓這些創新為大眾所用。

雲原生帶來的機遇與挑戰

個人理解該體系的出現促進業務應用更快捷的迭代、運維 (發布、維護、監控),進一步促成雲端 Devops。在互聯網唯快不破的勢頭下,快速上線是很多產品搶占市場和生存的製勝法寶。

所以,當云原生這個體係出現的時候,很多搞雲的大廠迅速加入雲原生的隊伍,推出眾多雲原生服務組件,網易云也不例外,除了服務網格、CI&CD、分佈式事務等,也開始了中間件Operator 的研發。雲原生下面已經衍生出很多標準體系,並且有很多工具提升研發效率。

但除了機遇,也有一定的挑戰,如對 kubernets 特性和配置的應用和了解如何?底座是否穩定?研發是否吃得透這些開源組件?開源組件版本如何管理,如何與社區版本進行同步?出現問題是否能快速定位並解決?這都是我們傳統測試思維會想到的。下面看一下云原生的思考方式,這對於我們構建自己的測試思維比較有幫助:

聊聊雲原生時代的測試 1

雲原生下對我們 QA 同學的現實衝擊

我們傳統互聯網領導的 QA 職責包括:

  • 需求分析
  • 設計分析
  • 測試分析
  • 自動化或性能等測試
  • 質量風險管理等

而在雲原生背景下,更快的開發節奏,對測試要求會更高。如,傳統的paas 服務新版本上線需要3 個月的時間,但是雲原生的paas 服務新版本上線時間按照業界標準只需要1-1.5 個月(paas 研發時間主要節省在資源調度和管理上,這部分功能都由強大的kubernetes 提供)。 3 月或 1.5 個月這個時間都是包含測試時間的,但是測試工具或體系在雲原生下並沒有出現特別的一站式解決方案。

如何更快的更好的保障質量是我們面臨的挑戰,挑戰來自多方便,如paas 研發和QA 對kubernetes 底座的了解有限,kubernetes 自身版本升級和運維操作較頻繁,對內核和docker 版本有依賴,會出現內核等bug。底座的問題還是需要上層服務不斷實踐和測試去發現。

目前,我簡單的總結了 QA 在 service mesh 和 paas on k8s 系統裡可以參與到前期設計和測試發力的內容有:

1.設計考慮:

  • 高可用設計
  • 故障自愈設計 (包括依賴的 k8s 各組件)
  • 可擴展和彈性設計
  • 可管理資源與實例設計
  • 可監控與遙測設計
  • 運維操作 (頻繁或高影響操作)

2.測試考慮

  • 管控與數據面功能自動化
  • 故障自愈自動化 (在 k8s 體系下更為重要)
  • 長穩(動態環境)壓測(包括依賴的各組件)
  • 縱向單級和多級的混沌故障測試
  • 全鏈路性能壓測
  • 運維操作自動化測試
  • api 層面的模糊測試,保障系統 api 健壯性

我們團隊 QA 的發展方向

1. 專項測試專家:18 年 Q4 我們進行了團隊轉型,QA 重點負責專項測試設計和執行。

經過 1 年多的實踐,利用這個工具或平台,雲計算 2.0 的項目基本經過我們高頻的折騰,穩定性基本達標。 19 年下半年業務重點逐步轉到雲原生之後,我們接觸了很多開源系統和組件,如istio、enovy 等,這些系統有的提供了單元測試和e2e 測試用例,如何利用這些基礎的測試,系統化的保障雲原生服務的質量是我們要努力的方向。

初步是設想是研發負責功能測試,維護功能 checklist,保障各功能測試百分百覆蓋,輸出完整用例集(交付使用);

QA 負責持續集成建設和非功能質量建設。簡單舉例,如QA 提供持續集成建設方案和實施,實現代碼自動卡點與上述場景自動化、故障自愈自動化,檢測測試代碼覆蓋率;非功能測試方面加大故障測試投入,利用大組平台或開源工具,深入組件和網絡異常,將故障測試頻率加大。

拉齊非功能測試基線如:

  • 故障自愈 – 關注是否自愈和自愈時長
  • 性能測試基線
  • 組件或 OS 兼容性

目前,輕舟或云的解決方案多樣性或交付還不是很多,如果這塊的需求增多,則需要有單獨的環境進行解決方案集成測試。

2. 效能專項組:理想情況下,需要有持續集成和專項提效組,所有的同學都投身於業務測試中,小的改進也來自問題反饋後集體的頭腦風暴。

先說下必要性:為了提升測試執行或測試設計的效率,離不開測試沉澱和好的測試工具。效能組的同學需要調研或自研優秀的測試工具,為專項測試執行同學輸出便利。專項測試同學與效能同學需要有密切的合作和溝通,工作上也要相輔相成,有能力的同學,可以適當相互輪崗。

總而言之,質量保障是充滿艱辛和挑戰的一條路,沒有放之四海而皆準的準則。在復雜的系統中,更沒有通過一種技術就可以解決所有的質量問題,我們必須不斷實踐,按照雲原生契約精神踏踏實實的探索混沌測試,完善質量體系,才能更好的保障系統的穩定性和健壯性。

參考資料:

雲原生定義

雲原生設計哲學