ZStack——自動化測試系統2：系統測試

 

ZStack的系統測試系統在真實的硬件環境中運行測試用例；像集成測試同樣，這個系統測試也是全自動的，並且覆蓋的層面包括：功能性測試、壓力測試、性能測試。

 

概述

雖然集成測試系統，如咱們在ZStack—自動化測試系統1：集成測試中所介紹的，強大到能夠暴露開發過程當中大多數的缺陷，也是有着固有的弱點的。首先，因爲測試用例使用模擬器，它們不能測試真實場景，好比在一個物理的KVM主機上建立一個VM。第二，集成測試用例主要關注一個簡單的場景，在一個簡單的人造的環境中；舉個例子，仍是建立VM的這個用例，它可能只部署一個最小的環境，包括一個主機和一個L3網絡，僅僅用於知足建立一個VM的需求。這些弱點，然而也是深思熟慮過的，由於咱們想要開發人員可以在他們開發新特性時快速和容易地寫測試用例，這是一個咱們必須採起的權衡。

 

系統測試，目標在於測試整個軟件，在一個真實的、複雜的環境中，很天然地補充集成測試。ZStack的系統測試系統被設計用於如下兩個目標：

1. 複雜的場景：這些場景應該比真實世界的使用場景更復雜，以測試軟件的極限。舉個例子，掛載和卸載磁盤的測試用例應該持續地、重複地對虛擬機執行，以一種很是快，人類沒法手動作到的方式。
2. 易於編寫和維護測試用例：就像集成測試系統，系統測試系統接管了大多數無聊重複的任務，讓測試人員有效率地寫測試用例。

 

這個系統測試系統是一個Python項目，命名爲zstack-woodpecker，由如下三個部分組成：

1. 測試框架：一個測試框架，管理全部的測試用例，以及提供必須的庫和工具。
2. 環境部署工具：一個工具，用於從XML配置文件部署一個環境；它很是相似於集成測試系統的部署器。
3. 模塊化測試用例：測試用例是高度模塊化的，並且覆蓋了：功能測試、性能測試和壓力測試。

 

系統測試

zstack-woodpecker徹底由咱們本身建立；在決定從新造這個輪子以前，咱們試過了流行的Python測試框架，像nose，而後最終選擇了創造一個新的工具，用以最大化地知足咱們的目標。

 

套件配置

相似全部的其餘測試框架，一個zstack-woodpecker中的測試套件是以suite setup開始，以suite teardown結束，在其中有一些測試用例。這裏的suite setup和suite teardown是兩個特殊的測試用例，suite setup負責準備後續的測試用例所需的環境，suite teardown負責在全部測試用例結束以後清理這個環境。一個典型的測試套件配置文件看起來像：

 

敏銳的讀者可能會注意到一些參數是在其餘的測試框架中看不到的。

第一個是timeout；每個測試用例能夠定義本身的超時時間，若是在這段時間內不能完成，它將被在最終的結果裏被標記成超時。

第二個是repeat，容許你在測試套件中指定這個用例應該被執行多少次。

第三個，也是殺手級的參數是parallel，容許測試人員設定這個套件的並行級別；這是一個使得zstack-woodpecker運行測試用例很是快的關鍵特性；在上面這個例子中，parallel被設置成8，這意味着將有至多8個用例在同時運行；這不僅是加速運行測試用例，也創造了一個複雜的場景，模擬許多用戶在共享同一個環境時執行不一樣的任務。然而，不是全部的用例均可以被同時執行；在咱們的例子中，用例test_delete_l2.py將會刪除被其餘用例依賴的L2網絡，因此在其餘用例執行時，它不能被執行；這就是第四個參數noparallel發揮做用的地方；一旦它被設置成true，這個用例將會單獨被執行，不會有其餘用例能夠同時運行。

 

命令行工具

zstest.py是一個命令行工具，用於幫助測試人員控制測試框架，執行任務，像啓動測試套件，列出測試用例，等等。zstest.py提供了豐富的選項幫助測試人員簡化他們的工做。這些選項中的一些，用於在咱們的平常測試中，特別有用，列在了下面。

測試人員能夠經過選項-l獲取可用的測試用例，例如：./zstest.py -l

它將會展現以下的結果：

 

測試套件名，是測試用例的第一級文件夾的名稱；例如，在上圖中你看到了大量的用例以basic開頭（例如：basic/test_reboot_vm.py），是的，basic就是這個測試套件的名字。測試人員能夠經過選項-s啓動一個套件，使用套件名的全稱或者部分都行，只要它是獨一無二的，例如：./zstest.py -s basic 或 ./zstest.py -s ba

 

測試人員也能夠選擇性地執行測試用例，經過使用它們的名字或者ID，已經選項-c；例如：./zstest.py -c 1,6 或 ./zstest.py -c suite_setup,test_add_volume.py

記住，你須要運行suite setup的用例：suite_setup.py做爲第一個用例，除非你已經這麼作了。

因爲一個測試套件將會執行全部的測試用例，清理環境，發出一個結果報告，測試人員有時可能想要中止測試套件，並在一個用例失敗時保持環境，這樣他們就能夠深刻查看失敗結果並調試；選項-n和-S就是爲此準備的；-n指示測試框架不要清理環境，-S要求跳過沒有被執行的用例；例如：./zstest.py -s virtualrouter -n -S

另外，選項-b能夠拉取最新的源代碼並構建一個全新的zstack.war，這在Nightly測試中特別有用，這種測試被假定爲測試最新的代碼：./zstest.py -s virtualrouter -b

一旦全部的測試用例完成，一個報告將會被生成並被打印到屏幕上：

測試框架將會保存全部的日誌，並直接輸出每個失敗日誌的絕對路徑，若是存在的話。爲了在通常的日誌中記錄更多的細節，有一種特殊的日誌action log，用於記錄每個API調用；由於這是一個徹底純粹關於API的日誌，咱們能夠容易地找到一個失敗的根原本源，而不用被測試框架的日誌分散注意力。另外，它是一種重要的工具，能夠自動地生成一個新的用例用於重現失敗，這是一個咱們所使用的魔法武器，用於在基於模型的測試（每一個用例都隨機地執行各類API）中調試失敗。你能夠在ZStack--自動化測試系統3：基於模型的測試中找到細節。Action log的片斷以下：

 

環境部署工具

相似於集成測試，對每個測試用例來講，準備環境是頻繁且重複的任務；例如，用於測試建立虛擬機的用例須要去配置獨立的資源，像zone，cluster，host等等。Zstack-woodpecker調用zstack-cli，這個ZStack的命令行工具去從一個XML配置文件部署測試環境。例如：zstack-cli -d zstack-env.xml

這裏的XML配置文件的格式相似於集成測試所用的，一個片斷看起來像這樣：

部署工具一般在運行任何用例前被suite setup調用，測試人員能夠在XML配置文件中經過以$符號開頭來定義變量，而後在一個獨立的配置文件中解析。經過這種方式，這個XML配置文件像模板一個工做，能夠產生不一樣的環境。配置文件的例子以下：

注意:正如你可能會猜想的，這個工具能夠被管理員用於從一個XML配置文件部署一個雲環境；更進一步，管理員們作相反的事情，將一個雲環境寫入到一個XML配置文件，經過zstack-cli -D xml-file-name.

對於性能和壓力測試，環境一般須要大量的資源，例如100個zone，1000個cluster。爲了不手動在配置文件中重複1000行，咱們引入了一個屬性duplication，用於幫助建立重複的資源。例如：

這段不翻譯了。

 

模塊化的測試用例

在系統測試中測試用例能夠被高度模塊化。每個用例本質上執行如下三步：

1. 建立要被測試的資源
2. 驗證結果
3. 清理環境

Zstack-woodpecker 自己提供一個完整的庫用於幫助測試人員調度這些活動。API也很好地被封裝在一個，從zstack源代碼自動生成的庫中。測試人員不須要去寫任何的原生的API調用。檢查器，用於驗證測試結果，也已爲每個資源建立；例如，VM檢查器，雲盤檢查器。測試人員能夠很容易地調用這些檢查器去驗證他們建立的資源，而不需寫成頓成噸的代碼。若是當前檢查器不能知足某些場景，測試人員也能建立本身的檢查器，並做爲插件放入測試框架。

一段測試用例看起來像：

像集成測試同樣，測試人員能夠僅以十幾行便寫出一個測試用例。模塊化不僅是幫助簡化測試用例的編寫，也爲基於模型的測試構建了一個堅實的基礎，下篇文章咱們會詳細討論。

 

總結

在這篇文章中，咱們引入了咱們的系統測試系統。經過執行比現實世界的用例更復雜的測試，系統測試能夠給咱們更多的自信，關於ZStack在真實的硬件環境中的表現。使得咱們能夠快速進化成一個成熟的產品。