本文首發於泊浮目的專欄：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的鏡像支持上可能有問題。
Pouch
放棄。阿里自研的富容器技術，可以完美解決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放在那邊（一天可能就跑1、2小時的測試），還不如大家都共享一個池內的vm，避免資源的浪費。就像公有云賣你1core512m，你去架個網站，但是它料到你用不了這麼多，所以它就會超分超賣。
這個類會根據配置文件或者網絡請求存入相應測試用的vm，並記錄這些vm是否被使用，爲了防止其他開發者一起跑測試的時候共用同一臺vm，會給使用中的vm打上一個user tag，避免衝撞。另外，SessionId等常量也是從這裏刷新而來。
小結
通過本文，向大家介紹了一下筆者目前在項目中設計的一個基於ZStack的自動化測試系統。基於各方各面的成本限制，故此設計的較爲簡單。如果後續有些較大的改動或顯著的改進，筆者還會與大家繼續分享。如果大家對於這方面的自動化測試有較好的實踐或者建議，也歡迎在留言中一起交流學習。**