ZStack實踐匯 | 高效開發測試打造產品化私有云

做者：許佳珺
 

 

前言

隨着愈來愈多的企業將雲計算產品應用到基礎設施及其核心業務中，如何提升和保證軟件交付質量、減小軟件開發迭代週期、加速軟件發佈頻率成爲全部雲廠商面臨的關鍵問題。

根據IDC 2018年的預測，中國雲計算市場在將來5年將持續高速發展的態勢，主要表現爲：中國傳統的非雲計算IT基礎架構佔總體IT基礎架構的投入比例將從2018年的50.3%降低到2022年的40.7%；中國私有云平臺建設的市場規模將以年均24.8%的複合增加率快速增加；中國雲計算IT基礎架構支出佔全球市場比將從2018年的12%上升到2022年的25%，屆時中國私有云IT基礎架構支出將超過美國，成爲全球第一大市場。在這一輪新的迭代更新中，更多的企業和行業開始部署或者創建更大規模的私有云；而新應用（數據分析，AI，IoT，移動）和新場景（邊緣計算，智慧/平安城市，行業雲）也對雲平臺提出了更高的需求。

ZStack憑藉創新的產品化理念，在業內率先提出雲計算的4S標準 – 簡單Simple，健壯Strong，彈性Scalable，智能Smart。同時，ZStack企業版從初版發佈到最新的3.5.0版本，一直以每六週一次的週期迭代更新軟件版本，快速提高和擴展產品功能，積極應對雲計算市場對私有云產品不斷增加的需求。而保證其私有云產品化的關鍵要素有如下三點：

1.    流程 – 快速敏捷
2.    運維 – 智能高效
3.    測試 – 嚴謹全面

 

注：ZStack堅持快速、簡潔、高效的開發、運維、測試流程，確保新需求六週即可實現

1.    流程 – 快速敏捷

ZStack開發流程依然定義了傳統開發模式中的幾個關鍵階段 - FF、CF、RC和GA。同時針對不一樣階段的任務和目標，進行有的放矢地優化。在Feature Freeze階段，主要以需求分析爲主，要求產品經理將客戶的需求分片化、分級化，需求描述本地化，更有效地將需求安排到不一樣發佈版本週期中。開發和測試工程師則須要將Code Freeze和Release Candidate的任務提早到Feature Freeze階段中，減小互相之間任務的依賴，提升各個階段的併發度。而測試不只須要滲透到開發的每一個環節中，同時也要經過模型測試、路徑測試、穩定性測試等方法，提升代碼的覆蓋度和測試效率。每一個發佈週期經過反覆地從需求->開發->測試的快速迭代，保證了產品的新需求和問題始終可以被快速知足和解決。

 注：ZStack產品開發流程高度併發，保證版本之間快速迭代

2.    運維 – 智能高效

做爲私有云產品開發的基礎保證，一套快速、穩定、高併發、可伸縮的運維繫統是必要的。而傳統運維提供的簡單CI和CD功能是顯然沒法知足這樣快速迭代的需求。ZStack產品化過程當中，搭建了一套以ZStack + Kubernetes爲基礎、面向公司各個部門的總體性服務框架。這套框架中所包括的服務內容涵蓋從開發&測試人員使用的測試環境、到整個項目的管理工具。框架的底層以ZStack做爲IaaS提供給上層可靠的、可擴展的物理資源，同時結合Kubernetes，將容器運行於雲主機中，既保證了隔離性、又充分利用了ZStack和Kubernetes對雲主機和Docker調度的優點，起到了對上層服務高可用、高併發及可伸縮的雙重保障。

注：ZStack做爲IaaS層向上層服務提供可靠的物理資源，而更重要的是，內部的ZStack環境也會隨着發佈版本更新，真正作到了本身的產品本身先用起來
 

注：實際生產環境中，一次自動化測試至少在Jenkins上併發建立500+個請求，每一個請求包含10~50個測試用例，ZStack + Kubernetes保證了這些請求幾秒內能夠被處理

3.    測試 – 嚴謹全面

打造一個產品化的私有云軟件須要全面且嚴謹的測試，這不只僅是單元測試和集成測試能保證的。ZStack從如下四個方面入手強化測試：

3.1     測試高效化：整個產品流程中開發和測試要同步進行，這包括了對不一樣的開發分支須要有不一樣深度的測試代碼保證其質量——例如，對於Release分支，必須有持續性的Nightly測試把控天天進入的代碼質量；對於Feature分支，須要能快速檢測出patch對代碼核心功能影響的BAT測試。同時測試系統和CI系統要高度集成而且作到同步觸發。

高效化的另外一個重點就是要作到全部測試都能運行在雲端，提升測試的併發度和資源利用率。ZStack內部的測試都是跑在雲端的，而云端環境也是基於ZStack自身搭建的，利用其對底層硬件資源的抽象和管理，模擬出測試中須要的不一樣的硬件配置場景，包括網絡、存儲、虛擬化平臺、甚至不一樣的ZStack高級功能配置，如企業管理、災備服務等。同時，爲了知足大規模資源需求的測試場景，例如1萬臺或10萬臺雲主機的測試場景，ZStack測試中還實現了simulator機制，即不真實分配硬件資源，而使用mock後端API的方式提供了對後端資源的調配，真正作到了有針對性的測試。

注：ZStack雲端測試的環境構建是經過XML配置文件實現的，測試工程師能夠很是簡單地用幾分鐘配置出一臺自動化環境

3.2    測試標準化：ZStack所涵蓋的測試內容不只包括功能性測試，還包括一套完整測試體系所須要的各類測試，如開發工程師須要作的集成/單元測試，測試工程師須要作的系統測試中的壓力、性能、可靠性測試、以及針對不一樣版本定製的發佈測試。例如ZStack的可靠性測試就包括了兩類測試 – MTBF和DPMO測試，MTBF會對ZStack平臺進行15,000小時長時間的真實用戶操做模擬；DPMO測試則會對ZStack平臺進行高達10,000次的斷/上電、重啓等測試。

標準化的另外一方面體如今對關鍵節點的標準把控上，對FF、CF、RC和GA各個階段都會有相應的代碼准入和驗收標準，例如CF階段後功能開發代碼禁止進入發佈分支而只能進入下一個發佈版本的週期；又例如各個階段驗收時要求的bug數量限制，CF階段要求小於5個P0，GA階段要求沒有P0的bug。

 

3.3 測試覆蓋智能化：軟件測試無法達到100%的覆蓋率，因此咱們要作的是在資源有限的狀況下，以儘可能少的代價作到儘量高的覆蓋率。要提升覆蓋率，需從兩方面入手，一方面是對代碼進行覆蓋率檢查，咱們在平常CI的包中插入了代碼不一樣模塊的覆蓋率，不論是手動仍是自動測試，或是平常bug的驗證，都會爲覆蓋率提供數據。

另外一方面咱們增長了模型測試，它能夠產生由隨機API組合構成的場景，會持續運行直到遇到預約義的退出條件或者找到一個缺陷。這種模型測試很好地彌補了人爲定義用例的不足，提升了測試場景和路徑的覆蓋率。由這種測試模型，也衍生出了三種不一樣場景的覆蓋率提升測試：

 

 

3.3.1 覆蓋率測試：除常規有序的測試步驟外，運用模型測試，收集無序測試步驟下的測試覆蓋率。

3.3.2 MTBF測試： 從有序和無序兩種測試維度，對系統穩定性及可靠性進行測試。

3.3.3 路徑測試： 一般一個系統測試用例最多5-6個操做步驟，而最終客戶的問題場景是極其複雜的，一般須要10~20個以上的步驟才能重現，運用模型測試的方法，能夠有效減小構建測試用例的代碼量。

 

注：一個典型路徑測試，只須要將測試對象和操做步驟寫到測試用例中便可完成

3.4 報告立體化： 主要從兩方面實現，一是測試報告的結果自動化、可讀化，是經過對測試用例中插入DITA描述實現的。另外一方面是結果的可追溯和可回放，這是經過記錄測試過程當中API的調用順序和參數實現的。

 

注：一個測試結果的操做記錄及回放方法，可以有效幫助開發測試工程師重現bug

總結

做爲產品化的雲計算公司，ZStack一直致力於打造自研的ZStack私有云、ZStack混合雲、ZStack Mini超融合一體機、ZStack CMP多雲管理平臺、ZStack企業級分佈式存儲等產品和方案。本文從開發流程、基礎運維以及測試能效等角度，介紹了 ZStack 團隊如何高效打造一個產品化的私有云。

 

歡迎關注ZStack中國社區QQ羣、ZStack官方微信！