MBT的優點
基模測試的優點很多。相對于手動設計（編寫）單個測試用例，建立測試模型意味著有必要考慮和確定被測系統的整體行為。根據我們的經驗，反之這促使了組織間的交流以便把要求建立這樣一個模型的各方都匯集起來，既有利于協作又促進共同理解。
當從一個單一的模型生成大量測試用例時，維護也被簡化了，而且更新模型一次并重新運行生成器會可以立刻更新所有測試用例，而不要單獨重新運行幾百個測試用例。
一個精心設計的測試模型表現出了作為一個整體的被測系統的被選方面。被允許和支持的測試值而不是單個測試值的范圍應該在測試模型中被發現并表示。不利用測試（模型）設計師把開發人員和領域專家聚到一起是不可能。也許基模測試應用中通常觀察到的大的好處是：建設和共享對系統的限制和功能的明確理解，并把所有的假設都列到表格中。
當這種理解被記錄到一個測試模型中，某種程度上它成了一個可執行的規范，因為它可以被用來生成測試用例以實施。然后，不斷的測試用例將驗證被記錄的理解也與實施一致。如果不是這樣，有待達成一個新的共同的理解，細化的模型，或不變的實施。
當然，該測試模型不能充分地描述該被測系統的所有可能的行為，或者它會變得和實現本身一樣復雜甚至更復雜。因此，需要為建模內容選擇一個合適的范圍，為測試模型選擇一個相當高的抽象級別。測試模型的設計需要把重點放在系統的核心部分，該核心部分被視為對嚴格的測試和驗證重要。這個變化要跨幾個系統，例如，安全關鍵系統可能比不太重要的應用包含了更詳細的內容。因為基模測試過程不僅提供了所生成的測試用例，而且還有對系統規范和功能的嚴格審查，這個審查被要求用來生成測試模型。我們發現這對一個高層次的系統概述和核心關鍵要素的詳細研究特別有用。
從測試生成的角度來看，基模測試的主要好處在于它的自動模型探索能力且在探索測試模型中不挑測試生成器。根據我們的經驗，一個領域（測試）專家要查看系統并對它是如何工作的做出某些內在假設很簡單，凸顯一些東西，在手動設計測試用例中重復這些假設。手工操作也很昂貴，在各種不同的開發迭代中很少有時間或資源來廣泛測試一大組不同的選項，或者保證一個大堆測試得以審查和更新。
使用測試模型為基礎的測試生成器的限制較少。有一個好的測試模型，該工具可以結合不同的模型覆蓋準則探索不同場景并把隨機模型覆蓋融合進去，避免了一些專業偏差還擴大了探索選項集合。自然，該工具無法避免模型內的偏差，但是當幾位專家一起進行模型工作（甚至部分，如審查）時，模型具有巨大偏差的可能性小了，工具將更加不知疲倦更徹底地探索模型。在現有計算能力和測試執行時間內，它可以生成并執行大量測試用例而不會厭倦，并在每次迭代中重復同樣的過程，只需更新單個測試模型行。
許多關于使用基模測試的案例研究已經發表，也許這其中廣泛的是微軟協議文檔工作[ ACM ] 。微軟研究表明：把所有元素（包括學習曲線等）考慮在內時使用基模測試對比手工腳本有42％的利益。它還強調了許多我們所觀察到的接下來將要討論的問題。
采用需求及潛在問題
如果基模測試這么棒，為什么我們不一直用它呢？因為基模測試的初始成本較高，需要多樣化的技能，它的利益卻難以衡量。初始成本用于獲取技能，學習測試建模的思維模式，并創建測試模型。無法證明自己的系統和域的好處的話，這樣的初始成本很難被接受，如果所有人至今為止都一直手寫測試，很容易安于現狀而不會為組織去嘗試不同的和未知的事物。
創建良好的測試模型需要良好的編程技巧（及一般的軟件工程技能），測試專業知識，建模專業知識和領域專業知識。這是一個多樣化的技能組合，很難靠單個專家獲得。而當有這樣的專家時，管理層往往快速將他們分配定位成為一個開發而不是測試。同樣，管理層基本不會提供各種昂貴的資源（如領域專家，軟件開發人員）用于和軟件測試的筒倉相關的活動，即使他們需要成功的測試活動。從模型設計角度來看，測試模型也并不是一個傳統的順序計算機程序，而是指導測試生成器的一個規則和行動的集合，它本身與傳統的順序程序設計有點不同。
一般情況下，當開始進行評估，（可能的話）采用基模測試方法的時候，或許大的障礙是需要采用一個完全不同類型的思維模式。有必要把重點放在考慮SUT的整體功能和目的或者它所選擇的一部分上，而不要獨自想著單用場景和單個測試用例。這需要與組織中的其他專家密切合作，這可能需要對一般的工作實踐稍作改變。
這也強調了關于計算優點的問題。如果管理被用來測量如被寫測試用例的數量之類的東西，他們要么看不到測試用例（只有一個測試模型）要么是一大堆測試用例（所有生成的）。 [ GRAHAM ]中已對該問題及其可能結果做了詳細說明，[ GRAHAM ]中測試人員初惡評如潮，后來因為已觀察到的影響而被承認。還有，初獲得用該工具生成測試用例的啟動成本會顯得使用這種規格沒有任何價值。然而，它可以是建立共同理解并將之記錄在一個可執行的規范（測試模型）中的過程中有用的部分。正如在任何自動化測試工作（或任何其他工作）中 ，管理支持，溝通和理解都是非常重要的。
該方法和測試生成結果的有效性取決于設計的測試模型的質量。沒有一個高質量的模型，沒有測試生成可以生產好測試。因此，投入足夠精力去產生好模型并和其他專家一起檢驗它很重要。
生成一大組測試用例也能生出一大組需要進行分析的結果。根據我們的經驗，當考慮實施基模測試時，許多人通常認為這是一個潛在的問題。然而，實踐中，我們已經觀察到：這問題不大，因為測試生成基本是使用某種形式的場景或（對系統具體部分分析關注的）專注模式指導的。然而，模型設計仍應仔細考慮諸如有趣元素有哪些以及它們從所有可能輸入到測試的組合，所以測試生成的重點應放在有用的方面。至于結果分析，積極地說，當更多的精力可以從手動復制測試腳本中被轉移到分析結果時，這可以使工作更有趣而不那么單調乏味。總之，測試自動化應該一層層往上建。
有效實施基模測試需要將之建于一個好的基礎的測試自動化平臺之上。如果它無法寫出可以自動化執行的測試腳本，那么繼續進行基模測試去產生這樣的腳本毫無意義。建立基礎的測試自動化需要良好的水平，這個水平上，基模測試過程可作為一個額外工具來提高總體質量。例如，如自動控制SUT的GUI進行測試一類的事，應該在測試一個基于GUI的應用程序時得到解決。
過程
使用基模測試的過程可以用四個簡單的步驟描述為一個迭代過程，圖3所示。開始時，我們通常為系統所選的小一部分創建一個初的測試模型。這使我們能夠學習基本工具和框架，并看看他們是如何連接以形成整個測試環境并在該環境中定位基模測試工具。
圖4.過程模型設計
一旦擁有了測試模型的工作版本，我們用它來生成并執行測試用例。生成的測試用例的執行可以在所謂的“在線基模測試”中與他們的生成進行交錯，或在所謂的“離線基模測試”中的一個單獨的階段中完成。這很快地給我們提供了對模型情況和對當前模型設計中被測系統的那些部分的反饋。
當我們已經生成并執行測試用例時，我們分析出被測系統上及測試模型中錯誤的結果。
在令人滿意的水平上，我們開始一步步地擴展模型并添加更多功能。這意味著我們要從頭重復這些步驟及這個過程，直到在我們覺得我們已得到了一個描述有趣元素的合適水平上的測試模型。
一些測試模型可以用來設計系統的不同部分。測試場景被用來指導測試生成，或者它可以使用不同的模型和生成器配置去重點關注不同的區域和觀點。
我們采用的一種做法是幫助合作伙伴開始使用開源工具理解這個概念，看到好處，并學習技術。開源工具也有適應特定需求和環境的優點。一旦基本技術，及其實施和效益被更好的理解了，可以選取不同的前進道路，包括轉用（從廣泛付費支持和大規模開發先進算法的資源獲益的，如Spec Explorer和Conformiq Designer的）商業工具這個選擇。然而，在許多情況下，我們早已經看到了開源選項提供的不錯利益。
可以運用基模測試的一個好地方是有很多變量和很多（需要進行測試的）交互的地方。一旦我們意識到把這個手動縮放到要求的復雜度和質量水平很昂貴的時候，基模測試是一個值得考慮的好技術。另一個不錯的地方是安全性軟件，在這種軟件中必須完全相信一個好的幾乎無錯的解決方案已被建成。
結論
基模測試可能聽起來像一個很酷但卻嚇人的技術，很難上手。然而，經過一些初步學習之后，它并不比常規測試和測試自動化更復雜。我們一般采取的做法是建議一開始（好是在熟悉這個概念的人的幫助下讓對該方法及其潛力超振奮的人）把它用在一個較小的試點項目中。我們通常以現有的測試自動化和測試腳本為出發點，以這些為基礎一次一小部分地開始建立測試模型。至于抽象層，一個好的起點可以是：（通過利用現有的SUT的API去定義可能采取的行動或關注可以觀察到很多變化且很難測量手動測試的地方，在該系統復雜／易出故障的部分或在核心關鍵功能上，構建一個促進共同理解的高層次的總體模型中的）任何東西。
參考文獻
[ACM] http://queue.acm.org/detail.cfm?id=1996412
[BINDER] http://www.robertvbinder.com/open-source-tools-for-modelbased-testing/
[GRAHAM] Harry Robinson， Ann Gustafson Robinson， Exploratory Test Automation: An Example Ahead of Its Time， in Dorothy Graham， Mark Fewster， Case Studies of Software Test Automation， 2012.
版權聲明：本文出自 SPASVO澤眾軟件測試網：http://m.eqie.com.cn/news/html/2014422145508.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
