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