淺談基于模型的測試
很多朋友可能已經聽說了Spec Explorer 是一款強大的測試工具，但卻不是很了解所謂的基于模型的測試到底是什么，這篇文章可以讓你對模型測試有一個大致的認識。
如果你在互聯網上搜索“Model-Based Testing”（即基于模型的測試，簡稱MBT），你將發現大量的信息。基于模型的測試并不是一個新生事物，也不局限于Spec Explorer這一工具，而是一個在學術界和工業界都已存在多年的概念。只是諸如Spec Explorer的工具將這一概念變得更易于學習和使用，并使得更廣大的用戶群能夠廣泛接受。
基于模型的測試是一個輕量級的，形式化的驗證軟件系統的方法。為什么這么說呢，因為首先，基于模型的測試對待測軟件系統（通常被稱為System Under Test，簡稱SUT）進行形式化的建模，設計出機器可讀的模型；其次，和其他形式化方法比，基于模型的測試并不致力于讓待測軟件系統與規格說明在所有可能情況下都保持一致，而是系統化的從模型生成一組測試用例，使用這組測試用例測試待測軟件系統，得到充分的證據說明待測系統的行為與模型期望是一致的。輕量級和重量級的方法的根本區別在于一個是充分證明，一個是完全證明。
目前完全驗證一致性的代價非常高，重量級的形式化方法往往難以被應用到實際工程中，而基于模型的測試在這方面體現了優勢，并已被運用到很多大型項目中。
下面是一個基于模型測試的簡單圖解：
基于模型的測試從一組需求開始，這組需求可以是文字，草圖或者僅僅是團隊成員的一些想法。
首先，我們需要創建一個機器可讀的模型（#1），該模型表述了需求所表述的所有可能行為。這一步是由人工完成，并且是整個流程中工作量最大的一步。模型設計工作的關鍵點在于正確的抽象，一個建模者應該專注于系統的待測試的某一方面，而不需要關心系統的其余部分。不同部分可以被不同模型覆蓋，但是每一個模型都確保自己在清晰的抽象層面上。
具體到Spec Explorer，模型被表述為一組規則，這些規則可以使用主流程序開發語言C#開發，不需要再學習其他特定的形式化建模語言，降低了學習難度。同時，Spec Explorer是一個Visual Studio集成開發環境的插件，所以提供了諸如語法顏色標記，自動補全和代碼重構等功能。Spec Explorer還提供了一種小型的配置語言Cord（Coordination Language的簡稱）用于結合不同模型，生成代碼以及選擇特定的測試場景。
雖然創建模型的工作量很大，但是回報也是巨大的。通過把非形式化的需求轉化為形式化的模型，你將很容易發現需求中遺漏的部分（譬如：如果我連按兩次ESC鍵，系統到底應該怎么樣？）。上圖中的#2表明僅僅通過分析模型，就可以得到關于需求的反饋。
當模型成型以后，就到了Spec Explorer這種工具發揮作用的時候了。它能夠通過分析模型自動生成測試用例（#3），包括提供給待測試系統的輸入以及期望的輸出，我們稱之為測試預期。自動生成的測試用例一旦生成，就可以在一個標準的單元測試框架中（例如Visual Studio的測試框架或者NUnit）獨立于模型運行。
這些測試用例提供了測試序列（#4）去控制待測試系統，同時觀察（#5）待測試系統的返回值，并與生成預期值進行比較，然后做出判定（#6）測試是通過還是失敗。測試用例可以被反復執行以重現bug，最后找到問題所在。
對測試結果的判定是對待測試系統的一個重要反饋（#7），但是找到待測試系統的bug并不是我們的唯一目標。一個失敗的測試用例也有可能表明待測試系統的行為是正確的，但是模型的預期行為是錯的！或者更進一步，模型本身是正確的反映了需求，但是需求本身從一開始就錯了！
如果真的如此，你也不用特別悲觀，基于模型的測試與傳統人工測試相比的最大優勢就在于維護方便，你需要的僅僅是讓失敗的結果作為有效的反饋給模型或者需求（#8），修改模型使其能反映系統的預期行為，然后重新生成測試用例。
【編輯推薦】
