【正文】 ，MBT的測試用例生成算法難免產(chǎn)生一些無效冗余的測試用例，測試用例通過率不再是衡量軟件測試效率的有效標(biāo)準(zhǔn)。認(rèn)識到這些MBT的不足之處，我們才能更加正確地利用MBT。目前代表性的支持MBT的測試工具有：IBM公司的GOTCHATCBeans軟件測試套件，面向Java、C/C++語言編寫的應(yīng)用程序接口（API, Application Program Interfaces）和軟件協(xié)議[7]；微軟公司的Spec Explorer工具，具有創(chuàng)建軟件行為模型、可視化分析模型、驗(yàn)證模型有效性和根據(jù)模型生成測試用例等功能[8]；“凈室”公司的CleanTest，主要用于凈室軟件工程中使用的統(tǒng)計測試過程[9]。此外，軍方也積極嘗試MBT技術(shù)，比如美國海軍水面戰(zhàn)中心開發(fā)的SMERFS[10]和CASRE[11]。. 項(xiàng)目背景和論文結(jié)構(gòu). 項(xiàng)目背景本課題來源于作者實(shí)習(xí)所在的微軟公司，旨在遵照基于模型的軟件測試?yán)碚撻_始實(shí)現(xiàn)一款自動化測試工具，該工具能夠支持有限狀態(tài)機(jī)模型的輸入，然后自動生成抽象測試用例。用戶填充實(shí)現(xiàn)完整的測試用例后，此工具能執(zhí)行測試用例并給出測試報告。該測試工具將被主要用于微軟公司SCCM系統(tǒng)的基于角色權(quán)限控制（RBAC， RoleBased Access Control）功能的測試。特別地，在測試用例生成過程中算法需要結(jié)合參數(shù)配對組合測試技術(shù)，盡可能縮減測試用例數(shù)目卻又不影響測試質(zhì)量。因?yàn)榕c傳統(tǒng)的單純正交排列組合測試相比，配對組合測試技術(shù)具有較大的優(yōu)越性。. 論文結(jié)構(gòu)本文第二章主要介紹MBT測試技術(shù)，依照MBT測試的一般流程來說明工具使用的模型表現(xiàn)形式、測試用例生成算法和預(yù)期輸出的生成。第三章介紹系統(tǒng)的總體架構(gòu)和簡要闡述系統(tǒng)各模塊的功能。第四章使用類圖和算法偽代碼詳細(xì)討論系統(tǒng)的設(shè)計和實(shí)現(xiàn)。第五章通過一個虛構(gòu)的自動取款機(jī)（ATM， Automatic Teller Machines）系統(tǒng)來演示如何使用我們完成的工具進(jìn)行MBT測試。最后作簡要的總結(jié)及展望。第二章 基于模型的測試2.. MBT一般操作流程基于模型的測試依賴于三項(xiàng)關(guān)鍵技術(shù)：模型的表現(xiàn)形式、測試用例的生成算法和產(chǎn)生其它輔助性內(nèi)容（包括預(yù)期結(jié)果）的工具[12]。模型是MBT技術(shù)的核心，不同領(lǐng)域的不同軟件系統(tǒng)適用的模型表現(xiàn)形式都不盡相同，測試人員應(yīng)該結(jié)合被測系統(tǒng)的工作特點(diǎn)和自身對模型的熟悉程度來慎重選擇。如果沒有使用正確的模型表現(xiàn)形式，會拖累影響整個測試流程。針對各個不同的模型表現(xiàn)形式，如今已有許多測試用例算法與之對應(yīng)，我們可以在實(shí)際應(yīng)用過程中靈活地借鑒參考來設(shè)計自己的算法。至于產(chǎn)生其它輔助性內(nèi)容的工具，它在不同項(xiàng)目之間不具有可移植性，只有根據(jù)不同項(xiàng)目來專門設(shè)計實(shí)現(xiàn)。圖21 MBT一般操作流程[13]上圖展示了MBT的一般操作流程。首先在系統(tǒng)需求或者規(guī)約文檔的基礎(chǔ)上建立某種形式的模型（步驟1），模型說明了系統(tǒng)所有的潛在行為意圖。接下來需要定義測試用例的選擇要求（步驟2），形成測試用例規(guī)約（步驟3），編寫算法將其應(yīng)用于模型之上來生成測試用例（步驟4）。然后在被測系統(tǒng)（SUT， System Under Test）環(huán)境中真正執(zhí)行所有測試用例（步驟51），可以利用測試腳本來自動化執(zhí)行測試，最終得到測試結(jié)果（步驟52）。. MBT模型表現(xiàn)形式理想的模型需要容易被測試人員理解，能夠把大的復(fù)雜的問題描述成小的簡單的系統(tǒng)，最好還是以一種測試用例生成工具方便識別的形式。想要同時滿足以上所有的特性是很困難的，但是可以把幾種不同的模型整合成一個，揚(yáng)長避短地得到理想模型。在MBT中使用過的模型可能有幾十甚至上百種，我們不可能也沒有必要去逐一了解，Mark Utting和Bruno Legeard把它們大致分為以下幾種 [14]：類型示例基于Pre/PostB、OCL、JML、Spec、Z基于轉(zhuǎn)換FSM、狀態(tài)圖、UML狀態(tài)機(jī)統(tǒng)計式馬爾可夫鏈基于歷史消息隊列圖、UML順序圖函數(shù)式HOL系統(tǒng)操作式Petri網(wǎng)數(shù)據(jù)流式Lustre、塊狀圖表21 MBT模型分類基于轉(zhuǎn)換的模型是我們最為熟悉的模型類型，它們集中于描述系統(tǒng)在不同狀態(tài)之間的轉(zhuǎn)換過程。通常是以節(jié)點(diǎn)和弧線的形式出現(xiàn)，節(jié)點(diǎn)代表系統(tǒng)的狀態(tài)，弧線代表系統(tǒng)的動作或操作。有限狀態(tài)機(jī)（FSM， Finite State Machine）模型可以被認(rèn)為是該類模型的鼻祖，是極其重要的一種模型表現(xiàn)形式。圖22是一個描述了門的四種不同狀態(tài)及其轉(zhuǎn)換關(guān)系的FSM。Harel在FSM的基礎(chǔ)上添加了層次、并發(fā)和交流概念，擴(kuò)展成了狀態(tài)圖模型[15]，從而在面對復(fù)雜系統(tǒng)時也能夠輕松建立模型。之后又有人刪去了Harel的狀態(tài)圖模型中的部分特性，同時增加了一些新的特性，形成了統(tǒng)一建模語言（UML，Unified Modeling Language）狀態(tài)機(jī)模型。UML狀態(tài)機(jī)模型用于定義類之間狀態(tài)相關(guān)的行為，包括方法調(diào)用和數(shù)據(jù)域的修改。圖22 FSM示例我們工具主要面向的是RBAC功能的測試，頻繁關(guān)心具有不同權(quán)限的不同角色所能執(zhí)行的操作。把系統(tǒng)抽象為變量集合和修改這些變量操作的基于Pre/Post的模型需要測試人員預(yù)先學(xué)習(xí)一段時間才能完全掌握，所以基本不予考慮。我們也并不需要描述系統(tǒng)行為隨著時間變化的變化情況，RBAC測試中不涉及分布式并發(fā)操作，側(cè)重關(guān)心系統(tǒng)控制流而不是數(shù)據(jù)流，可見基本的FSM模型就已經(jīng)滿足相關(guān)要求。而且FMS模型也最為簡便，測試工具識別起來沒有任何問題，降低了編寫測試工具的難度，測試人員構(gòu)建模型時可以從SUT設(shè)計文檔中的UML狀態(tài)圖稍加變化直接轉(zhuǎn)化而來。如果以后需要額外考慮系統(tǒng)事件和測試輸入的概率分布，只需要為每個狀態(tài)之間的遷移動作增加概率相關(guān)屬性，非常輕松地支持統(tǒng)計式模型。. MBT測試用例生成軟件測試過程中的執(zhí)行和監(jiān)督過程已經(jīng)可以使用現(xiàn)代化的自動測試工具代替完成，至于如何生成測試用例，依然是一件棘手的事情。MBT中使用的測試用例生成方法主要依賴于所使用的模型表現(xiàn)形式，針對不同的模型表現(xiàn)形式，研究者分別想出了一些解決方案。如果系統(tǒng)的模型是由一系列邏輯表達(dá)式所組成的，那么可以使用定理證明的方法。定理證明方法原先是被用于自動證明數(shù)學(xué)公式，MBT生成測試用例時根據(jù)邏輯表達(dá)式的有效說明把模型劃分為不同等價類，每個等價類描述了SUT的某一行為。這些等價類就可以用于生成測試用例，最簡單的劃分方法是析取范式的方法。當(dāng)需要為程序的特定執(zhí)行路徑尋找輸入時，沿著路徑使用符號執(zhí)行的方法，結(jié)合途中遇到的一些分支斷言，我們可以求出預(yù)期輸入所需要滿足的約束。于是可以用各種約束來建立MBT的模型，收集不同執(zhí)行路徑中數(shù)據(jù)約束再利用約束編程中的方法求解得到測試用例。其中約束編程是一種通過約束來描述變量間關(guān)系的編程方法，求解約束的方法有布爾式求解方法和數(shù)值分析方法。MBT自然還會讓人想到模型檢測，即檢測模型是否滿足特定的屬性。無論檢測結(jié)果是滿足屬性還是違背屬性，都可以形成測試用例。但是一般來說反例的作用更大，因?yàn)闇y試用例中的各種斷言正是通過反例來生成的，從而有效地識別出系統(tǒng)是否正常工作。模型檢測會遇到的問題是，生成的用例中存在過多冗余用例,導(dǎo)致軟件測試執(zhí)行的代價增加。為此，Hamon 等人詳細(xì)討論提出了高效模型檢測的方法[16]。類似于描述程序所有可執(zhí)行路徑的控制流和描述程序所有變量定義和內(nèi)存使用的數(shù)據(jù)流，事件流模型描述的是GUI上所有可執(zhí)行的事件序列。通常情況下，GUI又可以分為不同的層次結(jié)構(gòu)，比如整個GUI系統(tǒng)是由各種對話框所組成的，那么系統(tǒng)的事件流圖就是由對話框各自的事件流圖組成的。把復(fù)雜系統(tǒng)拆分為相對獨(dú)立的組件單獨(dú)分析，也是所有MBT測試用例生成方法通用的竅門。馬爾可夫鏈也是MBT中生成測試用例的重要方法之一，它由兩大部件組成：代表系統(tǒng)所有使用場景的FSM和評價FSM來說明系統(tǒng)統(tǒng)計性使用信息的操作說明。馬爾可夫鏈模型為MBT提供了測試的側(cè)重點(diǎn)，即著重測試那些用戶經(jīng)常使用的功能。因?yàn)閷τ谙到y(tǒng)中那些極少概率出現(xiàn)的錯誤，是幾乎不可能被發(fā)現(xiàn)的。我們選用的是FSM模型，所以可以利用圖論中的一些遍歷方法，比如廣度優(yōu)先遍歷算法或者深度優(yōu)先遍歷算法，每找到的一條可執(zhí)行路徑對應(yīng)于一個測試用例。當(dāng)FSM包含的狀態(tài)比較多時，遍歷組成FSM有向圖產(chǎn)生的測試用例數(shù)量可能太多，不僅難以測試包含冗余測試用例?？梢酝ㄟ^指定初始遍歷節(jié)點(diǎn)和限定路徑長度的方法來減少生成測試用例的數(shù)量，但是更好的是下面介紹的組合測試。軟件開發(fā)者和用戶經(jīng)常還會遇到這樣的問題，把同樣的軟件應(yīng)用從一臺機(jī)器換到另外一臺機(jī)器上使用時，原先從未出過故障的軟件突然變得無法正常使用。問題有許多可能的影響因素，比如跟軟件安裝所在機(jī)器的操作系統(tǒng)類型有關(guān)，或者是系統(tǒng)物理內(nèi)存的大小，甚至網(wǎng)卡型號等等。除了硬件環(huán)境的不同，軟件接受的輸入?yún)?shù)也很可能不同，比如同一款Web應(yīng)用發(fā)布后，不同國家的用戶將會輸入不同編碼的內(nèi)容。軟件能否經(jīng)得住各種條件下的考驗(yàn)，是軟件測試需要解決的問題。當(dāng)然，最簡單和理想的情況下是把所有可能出現(xiàn)的硬件配置和參數(shù)取值都測試一遍。但是現(xiàn)實(shí)并不允許測試人員這么做，因?yàn)樵斐傻臏y試用例數(shù)量是指數(shù)性爆炸增長的，N個分別有M種取值的影響因素將需要MN個測試用例來完成測試。后來人們發(fā)現(xiàn)通過巧妙地選取測試用例，只要求某些參數(shù)的組合情況被包含，能夠在保證測試效率的同時大大縮減測試用例數(shù)量。該理論是基于以下事實(shí)的，軟件中的錯誤大部分都是由單個參數(shù)所導(dǎo)致的，一般最多是由兩個參數(shù)相互作用而觸發(fā)，三個或三個以上的情況幾乎沒有。如果測試用例集包含了任意t個參數(shù)的所有取值組合，那么稱該測試用例集組合強(qiáng)度為t，或者說它是tway的。圖23 不同組合強(qiáng)度下的錯誤發(fā)現(xiàn)率圖23是NIST報告中總結(jié)的幾個應(yīng)用使用不同組合強(qiáng)度的測試用例集測試后的錯誤發(fā)現(xiàn)率曲線[17]。我們可以看出，隨著組合強(qiáng)度的增加，錯誤發(fā)現(xiàn)率顯著增長。以NASA應(yīng)用為例，67%的錯誤由單個參數(shù)觸發(fā)，93%由兩個參數(shù)相互作用后觸發(fā)，98%由三個參數(shù)一起造成。其它應(yīng)用的錯誤發(fā)現(xiàn)率曲線也都比較相像，組合強(qiáng)度等于4到6時錯誤發(fā)現(xiàn)率都達(dá)到了將近100%。特別的，生成2way的測試用例集的方法被稱為pairwise（或allpairs）測試方法。目前pairwise是使用最普遍的組合測試技術(shù)，因?yàn)檐浖械慕^大部分錯誤都只由一個或兩個參數(shù)造成，pairwise生成的測試用例能夠覆蓋足夠的錯誤空間。使用pairwise技術(shù)后，總測試用例數(shù)目從原來的MN下降到了約M * N。至于生成高組合強(qiáng)度的測試用例，測試用例集發(fā)現(xiàn)錯誤的能力沒有實(shí)質(zhì)上的提高，卻會導(dǎo)致生成算法的更加復(fù)雜化和產(chǎn)生多得多的測試用例。最壞的情況下，當(dāng)組合強(qiáng)度和參數(shù)的數(shù)目相等時，組合測試退化為枚舉測試。組合測試的最早提出，也就是為了簡化軟件在各種配置環(huán)境下的測試。因?yàn)闋可娴接布h(huán)境的搭建，配置參數(shù)測試中每增加一種測試情況比單純地多寫一個測試用例所花的代價大得多。人們迫切需要解決這一問題，使得配置參數(shù)測試成為了組合測試中最為發(fā)達(dá)的形式，尤其在那些要求適應(yīng)不同硬件平臺和環(huán)境的軟件的測試過程中?？紤]一款受5個配置因素影響的應(yīng)用：操作系統(tǒng)（Windows XP、Apple OS X、Red H