前各個軟件公司都很重視自動化軟件測試。甚至會把軟件測試自動化率（自動化測試用例占整個測試用例的比例）作為軟件測試人員（也叫質量保證工程師）績效考核的內容之一。追求自動化測試比例的初衷是很好的，但是不顧軟件產品的實際情況和軟件測試人員的情況，而過分追求高的測試自動化比例，會得到適得其反的效果。我們常常會聽到某軟件的自動化測試率高達70～80%，可是還是不得不聘請大量的測試人員來進行手動測試。這在無形之中把軟件測試引入了誤區。

ZStack的測試架構師認為，軟件自動化測試的好壞可以用軟件缺陷的發現的比率來衡量。換句話說如果整個系統的自動化測試比例達到80%，那么通過自動化測試發現軟件缺陷的數量應該達到甚至超過全部軟件缺陷數量的80%。舉個例子，iSCSI主存儲是即將發布的ZStack 0.7版本的重要功能。ZStack現有的自動化測試用例在沒有修改一行代碼的情況下，就可以用于測試iSCSI主存儲的功能。之前開發人員手動測試沒有發現的軟件缺陷，但是用自動化測試用例發現了5個缺陷。這個就是非常有效的自動化測試用例。

ZStack對軟件質量非常看重，因為我們深知人是最聰明也是最不可靠的（以后我們也許可以探討一下人性與軟件測試的相關話題），所以從整個軟件設計的開始，ZStack就決定盡可能地依靠全自動的測試手段來探測各種可能出現的軟件缺陷。

傳統的自動化測試有一個優勢就是每輪測試都會嚴格執行之前定義好的全部測試用例，無一遺漏。通過對前后測試結果的比較，就可以得出質量的變化情況。不過這個優勢也是它的弱點。設計軟件測試的人員都知道，由于無法窮舉所有的測試可能，所以預先設計的測試用例也只能覆蓋一部分最常見（或者說是測試人員最希望測試到）的領域。那么對于沒有測試到的領域就無法確定其是否存在軟件缺陷。這個問題該怎么破呢？為此，ZStack的自動化測試特別引入了一種特別的測試－－基于模型的測試（Model-based Testing)。

基于模型的測試是一種人工智能的測試方法，可以用于自動的構造測試場景和測試用例。它要求測試人員首先基于軟件功能構造出各種模型（或者叫做行為），然后制定行為和行為之間的關系以及行為和系統的關系（有限狀態機），之后自動測試系統就可以智能的根據當前的被測系統的狀態（場景）以及預設的規則，選擇下一步要執行的行為。理論上這種測試方法可以盡可能的遍歷被測試系統中各種可能經歷的行為鏈，從而極大的提高了測試覆蓋率。由于它每次執行的路徑和以往不同，所以可以構造出完全不同的測試用例，我們也可以稱之為智能的軟件測試。

下面，我們來大致看看ZStack是怎么構造基于模型的測試的。不過首先我們要說明的是，整個基于模型測試的難點在于提取測試模型，以及編寫測試模型驗證代碼，而非基于模型的測試框架本身和模型算法。所以以后遇到推銷基于模型測試“框架”的人，千萬不要覺得他們牛的一塌糊涂，真正牛的是實現具體測試的人，而非框架本身。實現測試系統的工程師才是真正的英雄。換句話說，雖然現實中有一些現成的基于模型的測試的框架，但是如果其他IaaS想要重現ZStack的智能測試也絕非易事。

ZStack基于模型的測試首先就是要把各種IaaS操作定義成模型。這里我們拿虛擬機實例的各種操作舉例。虛擬機實例通常只有4個狀態，狀態和狀態之間可以定義標準的操作。把狀態和操作畫出來后，我們就得到了虛擬機實例的狀態遷移圖（有限狀態機）。可以看到上圖中Running和Stopped的狀態之間可以通過stop和start操作做成狀態環。那么智能測試就可以根據預先設定的規則，可能會讓虛擬機在這個環里做有限的測試。這一個看起來好像很簡單，但是要知道IaaS里面還有很多其他資源的狀態遷移圖。而且很多資源之間是有相互依賴關系的，例如在某些系統中只有虛擬機處于Stopped的狀態才可以做磁盤快照。而且用戶在操作IaaS的時候，也不會只做虛擬機狀態的改變，通常會和其他資源的actions混合操作。所有當把所有資源的遷移圖畫完，就會發現整個IaaS的場景和可選的行為之間的關系還是非常非常復雜的。ZStack的測試工程師可是花費了不少的時間來完成這項艱巨的工作。

當創造完場景和行為關系圖后，智能測試就可以開始最初的測試工作。一開始的時候，它的智力水平并不高，只能從當前可執行的所有操作中隨機的選擇一個操作。極端情況，這可能會導致它一直在虛擬機實例的操作中繞圈子，而有些操作從來就沒有執行過。慢慢的ZStack工程師就開始給他添加了兩個更高的智慧：公平調度算法和基于歷史測試路徑的調度算法。

公平調度算法會讓智能測試系統盡量選擇最少執行的行為作為下一個操作。

而基于歷史測試路徑的算法可以讓智能系統選擇曾經沒有測試過的路徑。有了這兩種更加智能的調度算法，智能測試系統也就可以更好的發揮它的能力，未來ZStack的測試工程師們還會設計出一些更高級的復合測試算法，來增加智能測試系統的智商。除了發現一些常規的問題外，通過基于模型的測試還發現了不少我們稱之為Corner Case的缺陷，它們可能是90%的ZStack用戶永遠也不會觸發的問題。雖說是corner case，但是一旦在開發的階段沒有發現，等到用戶遇到的時候，就會花費很大的力氣來修復，有一些可能還是致命的。所以這種基于模型的智能測試給ZStack帶來了很大的好處。

基于模型的測試和ZStack的另外兩大自動化測試系統：集成測試和系統測試構成了ZStack質量控制的三駕馬車。在當今DevOps當道的今天，我們希望ZStack的測試和研發投入比力求做到1:1（以后我們也許可以和大家交流為什么純粹的靠開發人員來做測試是有問題的） ，我們希望把軟件質量永遠放在ZStack的第一位。

希望今天淺析的ZStack智能測試方法能給廣大軟件質量保證師從實踐角度帶來一些好的想法。最后我們想要感謝全世界的軟件測試工程師，感謝你們在每一件軟件產品后面付出的辛苦努力！

總結

以上是生活随笔為你收集整理的如果软件测试是门艺术，软件测试工程师就是艺术家 －－ 浅析ZStack是如何做智能软件测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。