基於ZStack設計一個較爲簡單的自動化測試系統

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

背景

在筆者目前的項目中，大部分業務跑在基於kvm的vm上。鑑於對項目質量的追求及儘量節省人力資源的目的，着手調研高測試覆蓋率的解決方案。

因爲項目基於ZStack，因此架構與其較爲類似，但在vm上添加了相應的agent，經過其來控制vm中的操做系統與軟件。

衆所周知，ZStack管理節點部分有一套較爲完善的自動化測試框架，能夠知足大多數場景。而Utility並不是如此，只能經過黑盒測試來保證其質量，且許多測試場景須要start up一個真實的ZStack的環境，測試成本較高。

若是一部分測試能夠設計在agent端，也就說是agent端的測試能夠自舉。這樣就能夠少設計一部分黑盒測試實例，下降潛在成本。

從業務看測試

從vm agent的業務邏輯來看，大多數業務都是修改DB配置、讀DB配置，start, stop DB等。而爲了case之間不受到影響，咱們在跑完測試以後，須要重置當前的測試環境。

方案選擇

Docker

放棄。其無狀態的特性簡直完美契合上述需求。可是docker裏只能跑單進程，對於oracle相關的業務，可能沒法知足。且部分版本oracle對Docker的鏡像支持上可能有問題。

在docker中能夠經過一些hack的手段去作到在一個容器中起多進程，好比systemd或supervisord。可是筆者對docker並非很是的瞭解，因此沒有繼續研究下去。

Pouch

放棄。阿里自研的富容器技術，能夠完美解決docker裏單進程的問題——其實本質上也是在容器鏡像起來時運行了一個init進程指定爲1號進程，而不是像docker裏在命令行中指定的進程。

在實踐過程當中發現有各類莫名其妙的報錯，且相關文檔不齊全。

VM By ZStack

目前的方案。經過ZStack來管理環境vm的生命週期，經過快照機制來還原環境。缺點也很是的明顯，僅僅一個case生命週期就須要1min+，生命週期大體以下：

• 使用vm跑測試
• 中止vm
• 恢復快照
• 啓動vm

讓人感到舒服的是，ZStack提供了一套Java SDK，能夠直接經過SDK完成上述操做。

基於ZStack的自動化測試

對接ZStack根本沒有什麼困難之處。更多的是要從成本這個點去考慮整個測試系統的設計。

這裏的成本則又能夠分爲兩種成本：

• 物理資源成本：產品線上目前可以投入進測試的host較少，故在資源稀缺的狀況下，得儘可能用較少的vm去完成這件事。
• 時間成本：一個開發人員跑測試的時間越短越好，而不是花大量時間去等待測試環境準備、清理等。舉個列子，若是我搭建一個mysql 主備庫，須要兩臺vm，若是串行去完成生命週期相關的操做，那麼就是2min+；若是並行的去作，即是1min+。同理，若是這些測試可以儘可能並行的去跑，則能夠省下更多的時間。

角色

角色示意圖以下：

TestCase

一個測試實例，含有測試代碼。同時它會向ResourcePool申請所需的vm。

TestGroup

根據當前的策略組織TestCase去並行的跑這些Case。在這裏能夠控制併發粒度，最後將會提交給Junit的跑測試。

JUnitCore.runClasses(new ParallelComputer(true, true)
                    , testGroup.toArray(arrayTestGroup));

ResourcePool

資源池的概念其實有點像雲。好比組內有4個開發，那麼4個開發幾乎是不可能同時跑測試的，同時有2個開發在跑測試也是小几率事件。與其每一個人都申請幾臺測試vm放在那邊（一天可能就跑一、2小時的測試），還不如你們都共享一個池內的vm，避免資源的浪費。就像公有云賣你1core512m，你去架個網站，可是它料到你用不了這麼多，因此它就會超分超賣。

這個類會根據配置文件或者網絡請求存入相應測試用的vm，並記錄這些vm是否被使用，爲了防止其餘開發者一塊兒跑測試的時候共用同一臺vm，會給使用中的vm打上一個user tag，避免衝撞。另外，SessionId等常量也是從這裏刷新而來。

小結

經過本文，向你們介紹了一下筆者目前在項目中設計的一個基於ZStack的自動化測試系統。基於各方各面的成本限制，故此設計的較爲簡單。若是後續有些較大的改動或顯著的改進，筆者還會與你們繼續分享。若是你們對於這方面的自動化測試有較好的實踐或者建議，也歡迎在留言中一塊兒交流學習。**