再談自動化測試——咱們在編寫測試時,應該注意什麼

本文首發於泊浮目的專欄： https://segmentfault.com/blog...

背景

最近項目在測試階段陸陸續續的測出了一些bug.這個狀況剛出現的時候,讓筆者很困惑——平時咱們的每一個feature代碼都是跟隨着大量看起來考慮很周全的case進入代碼倉庫的,然而事實仍是打了咱們的臉.故在本文,筆者將會從最近的所學所想來談談編寫測試的時候咱們應該注意什麼.

AIR原則與BCDE原則

前陣子看了一本書,裏面提到了單元測試的一些原則:

• 宏觀上,單元測試要符合AIR原則
• 微觀上,單元測試的代碼層面要符合BCDE原則

AIR原則

AIR即空氣,單元測試亦是如此。當業務代碼在線上運行時,可能感受不到測試用例的存在和價值,但在代碼質量的保障上,倒是很是關鍵的。新增代碼應該同步增長測試用例,修改代碼邏輯時也應該同步保證測試用例成功執行。AIR原則具體包括:

• A: Automatic (自動化)
• I: Independent (獨立性)
• R: Repeatable (可重複)

簡單的解釋一下三個原則:

• 單元測試應該是全自動執行的。測試用例一般會被頻繁地觸發執行,執行過程必須徹底自動化纔有意義。
• 若是單元測試的輸出結果須要人工介入檢查,那麼它必定是不合格的。單元測試中不容許使用System.out等方法來進行人工驗證,而必須使用斷言來驗證。
• 爲了保證單元測試穩定可靠且便於維護，須要保證其獨立性。用例之間不容許互相調用,也不容許出現執行次序的前後依賴。

BCDE原則

編寫單元測試用例時,爲了保證被測模塊的交付質量,須要符合BCDE原則。

• B: Border,邊界值測試,包括循環邊界、特殊取值、特殊時間點、數據順序等。
• C: Correct,正確的輸入,並獲得預期的結果。
• D: Design,與設計文檔相結合,來編寫單元測試。
• E: Error,單元測試的目標是證實程序有錯,而不是程序無錯。爲了發現代碼中潛在的錯誤,咱們須要在編寫測試用例時有一些強制的錯誤輸入(如非法數據、異常流程、非業務容許輸入等)來獲得預期的錯誤結果。

在ZStack白盒集成測試中實踐原則

以前提到的原則是基於單元測試的,但在ZStack的白盒測試中也能夠做爲有價值的參考.

戳此瞭解ZStack的白盒集成測試: https://segmentfault.com/a/11...

因爲ZStack的整套測試框架也是基於Junit擴展而來,所以也是必定程度上遵循了上面提到的AIR原則.除了A原則,I和R原則在必定程度上打了折扣:

• I: 若是上一個測試沒有清理乾淨狀態,則會影響下一個測試
• R: 基於上面提到的I,頗有可能致使可重複性大打折扣

固然,出現這些問題時則表示當前的代碼中有bug.但單元測試則不會受到這樣的影響——它能測出bug,AIR原則也得以保證.

在本次示例中,咱們將以VmInstance的建立API即——APICreateVmInstacneMsg做爲測試對象.若是讀者不是很瞭解上下文,也能夠簡單的看一下這個Case:OneVmBasicLifeCycleCase

Border Test && Error Test

邊界測試是用來探測和驗證代碼在處理極端的狀況下會發生什麼.而錯誤測試爲了保證ZStack在一些錯誤的狀態下作出咱們所期待的行爲.

那麼咱們該如何編寫這樣的測試呢?咱們先來簡單的理一下建立Vm的流程:

1. VmImageSelectBackupStorageFlow
2. VmAllocateHostFlow
3. VmAllocatePrimaryStorageFlow
4. VmAllocateVolumeFlow
5. VmAllocateNicFlow
6. VmInstantiateResourcePreFlow
7. VmCreateOnHypervisorFlow
8. VmInstantiateResourcePostFlow

而其中每個步驟能夠分紅好幾個小步驟,以VmAllocateHostFlow爲例:

咱們能夠看到,根據不一樣的策略,allocateHost裏還會有好幾個flow.而因爲鬆耦合架構,咱們能夠在測試中輕易的模擬極端問題的出現,如:

• 找不到合適的BackupStorage
• HostCapacity的不夠
• Agent返回的回覆在某一個時刻與管理節點的狀態不一樣
• .......

以此類推,以上建立vm的8個flow均可以輕易模擬各類邊界條件及錯誤狀況.

Correct Test && Design Test

正確性測試聽起來應該會很簡單,(好比調用一個API,而後看結果返回是否正確)但若是放到集成測試中,咱們仍是能夠拓展出一些額外的關注點的.仍是以上面提到的createVm爲例子,咱們看到了8個flow,而後裏面可能還嵌套着好幾個子flow.如圖所示:

在編寫正確性測試時,咱們能夠考慮額外關注如下幾點:

1. APIParam在各個Flow間中轉時是否如預期

2. 關注管理節點內的服務:

   • Flow之間調用的時序是否符合預期
   • Flow之間流轉時,業務目標狀態是否符合預期

3. 關注管理節點外的服務:

   • 對於agent的請求是否符合預期
4. 在API調用完後,相關資源的目標狀態是否符合預期

而與文檔結合的測試用例,則應當由團隊的測試人員來定義.能夠肯定的是,這類的測試更加關注於API(即輸入輸出),而不是內部的狀態.