基于模型的測試報告

基于模型的測試綜述2016年1月目錄TOC\o"1-3"\h\u13447摘要 I160911引言 2233352基于模型的測試、模型以及建模標(biāo)準(zhǔn) 216952.1基于模型的測試 2114112.2基于模型的測試的模型 313582.3建模標(biāo)準(zhǔn) 441643基于模型的測試的基本過程及支持工具 543843.1基于模型的測試的基本過程 5178613.2支持工具 6278634分類 7103874.1模型主體 788884.2模型冗余程度 7111814.3模型特征 7277294.4模型表示法 748154.5測試用例選擇標(biāo)準(zhǔn) 8136394.6測試用例生成技術(shù) 8241844.7聯(lián)機、脫機測試用例生成 9311755基于模型的測試的工具SpecExplorer 9187275.1SpecExplorer 913595.2連接測試用例和待測系統(tǒng) 9264815.3靜態(tài)模型和實例模型 11319756基于模型的測試的優(yōu)缺點 1118915參考文獻(xiàn) 13引言在軟件開發(fā)的生命周期中，測試是一個非常重要的階段。軟件測試[1]通過為特定測試目的而設(shè)計的測試用例的執(zhí)行情況，與預(yù)期的軟件行為進(jìn)行一致性對比，從而判定軟件錯誤所在，以此確保軟件的可靠性和正確性。由于軟件產(chǎn)品的固有的復(fù)雜性質(zhì)，軟件測試的難度也就不言而喻。傳統(tǒng)的測試方法被認(rèn)為是繁瑣的、強工作量且容易出錯。應(yīng)運而生的基于模型的測試開始受到日漸廣泛的關(guān)注。基于模型的測試（Model-BasedTesting）[2]是一種系統(tǒng)化的測試方法，可被應(yīng)用于軟件生命周期早期階段的產(chǎn)品的測試，并且它使完全自動化測試成為可能，其特點是：在產(chǎn)生測試?yán)瓦M(jìn)行測試結(jié)果評價時，都是根據(jù)被測試應(yīng)用程序的模型及其派生模型（一般稱作測試模型）進(jìn)行的。基于模型的測試深受工業(yè)界的青睞，原因如下：一是工業(yè)界通常需要驗證軟件產(chǎn)品的系統(tǒng)行為。在產(chǎn)品設(shè)計的早期，基于模型的測試的使用有利于幫助找出不清晰的、易存在二義性的軟件系統(tǒng)規(guī)格說明（“即編碼前的分析設(shè)計模型/文檔”）。二是基于模型的測試方法使得大量不重復(fù)的、有意義的測試用例產(chǎn)生變得可能。三是使用基于模型的測試一旦系統(tǒng)規(guī)格說明發(fā)生改變，只需要對測試模型進(jìn)行修改就可以輕松地達(dá)到更新測試用例的目的。本文組織如下，首先介紹了基于模型的測試及其特點，分析了主要的測試模型及如何選擇合適的測試模型，重點是有限狀態(tài)機模型、UML模型和馬爾可夫鏈模型，并且提出了建模的標(biāo)準(zhǔn)；接著介紹基于模型的測試的基本過程以及支持工具，再通過七個維度對基于模型的測試方法進(jìn)行描述，并對每一個維度探討了可能取值，然后與其他軟件測試技術(shù)相比，分析基于模型的測試的優(yōu)缺點，最后列舉了一些基于模型的測試的應(yīng)用案例?；谀Ｐ偷臏y試、模型以及建模標(biāo)準(zhǔn)2.1基于模型的測試首先應(yīng)該要明確軟件模型的概念，是指用抽象化的方式對軟件行為和軟件結(jié)構(gòu)進(jìn)行闡述，軟件行為可以通過一系列的輸入輸出邏輯和數(shù)據(jù)流分析來表示，軟件結(jié)構(gòu)則是通過部署圖、流程圖等圖形方式直觀表述，基于模型的測試就是通過上述兩種抽象化方式產(chǎn)生測試用例。相比于針對程序代碼本身的測試，而基于模型的測試方法不僅可以有效地提高測試效率，提高測試?yán)傻淖詣踊潭?，進(jìn)行測試失效辨識，也有利于評價測試結(jié)果?；谀Ｐ偷臏y試是對被測系統(tǒng)的模型化，然后根據(jù)模型特性，完全或者部分地自動生成測試用例的一種軟件測試技術(shù)?；谀Ｐ偷臏y試是一個輕量級的，形式化的驗證軟件系統(tǒng)的方法。首先，基于模型的測試對待測軟件系統(tǒng)（通常被稱為SystemUnderTest，簡稱SUT）進(jìn)行形式化的建模，設(shè)計出機器可讀的模型；其次，和其他形式化方法比，基于模型的測試并不致力于讓待測軟件系統(tǒng)與規(guī)格說明在所有可能情況下都保持一致，而是系統(tǒng)化的從模型生成一組測試用例，使用這組測試用例測試待測軟件系統(tǒng)，得到充分的證據(jù)說明待測系統(tǒng)的行為與模型期望是一致的。2.2基于模型的測試的模型理想的模型需要容易被測試人員理解，能夠把大的復(fù)雜的問題描述成小的簡單的系統(tǒng)，最好還是以一種測試用例生成工具方便識別的形式。想要同時滿足以上所有的特性是很困難的，但是可以把幾種不同的模型整合成一個，揚長避短地得到理想模型。在基于模型的測試中使用過的模型可能有幾十甚至上百種，我們不可能也沒有必要去逐一了解，MarkUtting和BrunoLegeard把它們大致分為以下幾種[3]：表2.1MBT模型分類類型示例基于Pre/PostB、OCL、JML、Spec#、Z基于轉(zhuǎn)換FSM、狀態(tài)圖、UML狀態(tài)機統(tǒng)計式馬爾可夫鏈基于歷史消息隊列圖、UML順序圖函數(shù)式HOL系統(tǒng)操作式Petri網(wǎng)數(shù)據(jù)流式Lustre、塊狀圖基于模型的測試中使用的典型模型有:有限狀態(tài)機（FSM，F(xiàn)initeStateMachine）、UML模型和馬爾可夫鏈等模型。有限狀態(tài)機該類模型是用狀態(tài)轉(zhuǎn)移圖來表示，并通過狀態(tài)的覆蓋來生成測試用例。這種模型可以將測試用的數(shù)據(jù)結(jié)合圖的遍歷算法自動生成輸入的序列進(jìn)行相應(yīng)測試。該種測試模型可以充分結(jié)合形式語言與自動機理論來進(jìn)行分析和設(shè)計，適用范圍主要是反應(yīng)式的軟件，但由于模型構(gòu)造的工作規(guī)模比較大，自動構(gòu)造就成為了這一模型的一個關(guān)鍵點。UML模型又稱為統(tǒng)一建模語言，是軟件工程中面向?qū)ο笤O(shè)計與分析中常用到的規(guī)范化建模語言。該模型主要是利用狀態(tài)圖進(jìn)行行為建模，狀態(tài)圖可以看作是有限狀態(tài)機的擴(kuò)展，強調(diào)了對復(fù)雜實時系統(tǒng)進(jìn)行建模，提供了層次狀態(tài)機的框架，即一個單獨狀態(tài)可以擴(kuò)展為更低級別的狀態(tài)機，并提供了并發(fā)機制的描述[4]，因此UML使用狀態(tài)圖作對單個類的行為建模。馬爾可夫鏈?zhǔn)且环N以統(tǒng)計理論為基礎(chǔ)的統(tǒng)計模型，可以描述軟件的使用在軟件統(tǒng)計測試中得到了廣泛應(yīng)用。馬爾可夫鏈實際上是一種遷移具有概率特征的有限狀態(tài)機，不僅可以根據(jù)狀態(tài)間遷移概率自動產(chǎn)生測試?yán)?，還可以分析測試結(jié)果對軟件性能指標(biāo)和可靠性指標(biāo)等進(jìn)行度量[5,6]。另外，馬爾可夫鏈模型適用于對多種軟件進(jìn)行統(tǒng)計測試，并可以通過仿真得到狀態(tài)和遷移覆蓋的平均期望時間，有利于在開發(fā)早期對大規(guī)模軟件系統(tǒng)進(jìn)行測試時間和費用的規(guī)劃。馬爾可夫鏈?zhǔn)墙y(tǒng)計測試的基本模型，在凈室軟件工程中得到了深入研究，在微軟、Raytheon及美國聯(lián)邦航空署(FAA）都得到了成功應(yīng)用[7]。馬爾可夫鏈可以用隨機遷移矩陣或者帶遷移概率的狀態(tài)遷移圖表示?；隈R爾可夫鏈的測試充分性準(zhǔn)則一般要求測試過程中對馬爾可夫鏈遷移的覆蓋與實際使用相同[6]。文法模型可以描述程序的語法。由于不同的文法等價于不同的狀態(tài)機因此也可以視為狀態(tài)機模型的變體。有關(guān)基于文法的測試可見文[8]，這方面研究工作相對較少。2.3建模標(biāo)準(zhǔn)隨著系統(tǒng)的增長，建模是捕獲和再利用有關(guān)系統(tǒng)知識的一個非常經(jīng)濟(jì)的手段。對于一個測試團(tuán)隊來說，這些信息是非常寶貴的：一個測試工程師了解被測系統(tǒng)的行為需要占據(jù)的工作量，一旦這個信息被理解，該如何保存給下一個工程師、下一個版本或者更改要求呢？如果你處于測試的設(shè)計階段，那么你是幸運的。但是更常見的是，這些信息被埋藏在一個測試腳本中，一旦改變或者丟失就只能等待重新發(fā)現(xiàn)。測試團(tuán)隊通過給系統(tǒng)構(gòu)建一個給予指定輸入得到所需行為的模型，可以獲得有重用的最大優(yōu)勢就是這些工作都不會丟失。一旦這個測試周期停止，下一周期就可以迅速開始。如果該產(chǎn)品具有新的功能，它們可以逐步加入到模型中；如果產(chǎn)品的質(zhì)量需要提高，那么模型需要改善和擴(kuò)大測試；如果有新的人員加入到測試團(tuán)隊中，他們可以通過回顧模型迅速投入進(jìn)來。一旦你決定想要為被測系統(tǒng)建模，下一步建模的時候要思考這個系統(tǒng)管理的數(shù)據(jù)、執(zhí)行的操作和與它通信的子系統(tǒng)。下面給出幾條原則：1．抽象原則，通常不把輸入、輸出納入到模型中。2．模型與被測系統(tǒng)不必完全一致。基于模型的測試的基本過程及支持工具3.1基于模型的測試的基本過程基于模型的測試的基本過程共有6個步驟，如圖2.1所示，其步驟如下：分析被測系統(tǒng)首先分析被測軟件的系統(tǒng)特性，主要分析的是開發(fā)方式，主要有所采用的開發(fā)技術(shù)(面向?qū)ο?、面向過程)，開發(fā)語言，開發(fā)系統(tǒng)環(huán)境等。然后根據(jù)分析結(jié)果，結(jié)合各個模型的特性選擇合適的模型作為測試用例生成的模型。建立抽象模型根據(jù)所選擇的模型對被測軟件進(jìn)行建模，可以進(jìn)一步分析該模型是否適合軟件。模型選擇和建立模型可能是個反復(fù)的過程，只有在充分了解該軟件系統(tǒng)的特點和各個模型的特點才可能為軟件系統(tǒng)建立最恰當(dāng)?shù)哪Ｐ?。這個模型是一個抽象模型，因為它應(yīng)該比待測軟件系統(tǒng)（通常被稱為SystemUnderTest，簡稱SUT）本身更小，更簡單，它只關(guān)注關(guān)鍵環(huán)節(jié)。建立完成后，需要檢查該模型與所期望的行為是否一致。生成抽象測試從模型生成抽象測試，必須選擇一些測試選擇標(biāo)準(zhǔn)，因為通常有無限多的可能的測試。比如使用有限狀態(tài)機FSM模型時，根據(jù)一定的覆蓋準(zhǔn)則遍歷狀態(tài)間的遷移所獲得的轉(zhuǎn)換路徑就是測試路徑，而且在使用FSM模型時選擇不同的測試覆蓋準(zhǔn)則所產(chǎn)生的測試用例是不同的。具體化抽象測試基于模型的測試的第四步是把高層的抽象測試轉(zhuǎn)化為可執(zhí)行的具體測試。主要有兩種方法：(1)使用模板和映射抽象測試的變換工具；(2)通過一些環(huán)繞在SUT和代碼實現(xiàn)間的適配器。執(zhí)行具體測試基于模型的測試的第五步是在被測系統(tǒng)上執(zhí)行具體的測試用例，不管是在在線的還是離線的基于模型的測試，都可以使用測試執(zhí)行工具和方法。分析測試結(jié)果得到測試結(jié)果后，必須確定產(chǎn)生該故障的原因并采取糾正措施，因為有可能是建模時的缺陷模型導(dǎo)致的測試用例本身故障。然后根據(jù)測試結(jié)果和分析結(jié)果，評估被測軟件的質(zhì)量，并且指出出錯的地方和提出改進(jìn)的意見和建議。圖2.1基于模型的測試過程3.2支持工具基于模型的軟件測試必須有相關(guān)工具支持。當(dāng)前支持基于模型的軟件測試工具中比較具有代表性的有：支持狀態(tài)機模型的工具。包括，SoftwareEngineeringTechnology的測試工具toolSET_Certify運行于RISC6OOO和SUN平臺；現(xiàn)在此工具屬于G-Lab，并已經(jīng)提供了對統(tǒng)計測試的支持；IBM的GOTCHA,可以根據(jù)用戶事先確定的測試充分性準(zhǔn)則進(jìn)行基于軟件狀態(tài)模型的測試?yán)?；IBM的TCBean是一個提供測試腳本管理功能的基于狀態(tài)機的測試引擎。支持馬爾可夫鏈模型的工具。包括，CleanroomSoftwareEngineering的CleanTest，支持統(tǒng)計測試，是商用的使用模型及統(tǒng)計測試?yán)晒ぞ撸籌BM的CleanroomCertificationAssistant，可以自動化統(tǒng)計驗證過程，通過使用概率分布產(chǎn)生測試?yán)?，并對測試結(jié)果進(jìn)行分析。對UML模型提供測試支持的工具。包括，SilverMark公司針對IBM公司的VisualAge開發(fā)的支持測試用例生成和回歸測試的TestMetor和UMLdesignerConnection。對統(tǒng)計測試結(jié)果進(jìn)行分析的工具。包括AT&ST的軟件可靠性工程工具箱和美國海軍水面戰(zhàn)中心開發(fā)的SMERFS，均提供多種時間域和區(qū)間域模型進(jìn)行可靠性估計;美國空軍噴氣動力實驗室開發(fā)的CASRE，支持可靠性估計和預(yù)測。分類本文通過七個維度對基于模型的測試方法進(jìn)行描述。并對每一個維度探討了可能取值。4.1模型主體模型主體包括SUT模型和SUT所處環(huán)境模型。目前基于模型的軟件測試中往往兩者都同時考慮。SUT模型的作用包括：(1)作為SUT的oracle(因為SUT包含了預(yù)期行為)；(2)利用結(jié)構(gòu)信息產(chǎn)生測試用例。SUT所處環(huán)境模型用于限制SUT模型的可能輸出。4.2模型冗余程度基于模型的測試可以被應(yīng)用到不同的場景。大致說來，主要區(qū)別在用于測試和用于實現(xiàn)的模型間的冗余程度。文獻(xiàn)[9]中描述了兩個可能場景。第一個場景中模型被用來同時產(chǎn)生測試用例和系統(tǒng)實現(xiàn)。該場景中用于產(chǎn)生代碼的模型必須描述詳細(xì)，但對測試用例生成來說確需要抽象級別更高的模型。第二個場景是：模型僅用于產(chǎn)生測試用例。該模型根據(jù)規(guī)約文檔生成，而SUT則是手工實現(xiàn)。我們可以使用該模型作為系統(tǒng)的規(guī)約補充，但其相當(dāng)復(fù)雜。往往需要補充文檔輔助才能使用。4.3模型特征模型特征與非確定性、時序問題、模型的連續(xù)性或事件離散性有關(guān)。非確定性在SUT和模型中均會發(fā)生。時序問題一般與實時系統(tǒng)相關(guān)。而就動態(tài)性而言。模型可能是離散的、連續(xù)的或兩者綜合?；谀Ｐ偷能浖y試過去往往關(guān)注離散模型，但連續(xù)或者混合模型目前在嵌入式系統(tǒng)中得到廣泛使用和研究。不同的模型特征將影響對模型表示法的選擇、測試用例的生成和執(zhí)行。4.4模型表示法目前存在大量模型范式對SUT進(jìn)行建模，根據(jù)[10]獲得如下的分類：基于狀態(tài)的表示法：針對變量集和修改變量的操作對系統(tǒng)進(jìn)行建模，變量集代表系統(tǒng)內(nèi)部狀態(tài)的一個快照，操作通過前置條件和后置條件定義。典型代表為Z、B、VDM和JML?；赥ransition的表示法：描述不同系統(tǒng)狀態(tài)間的transition。采用類似FSM的形式進(jìn)行表示。結(jié)點代表系統(tǒng)的狀態(tài)，邊代表系統(tǒng)的操作或行為。目前常通過添加數(shù)據(jù)變量、采用分層的機器和機器之間的并行來加強表示能力。典型代表為Statecharts．hbeledtransitionsystem和I／Oautomata?；跉v史的表示法：通過描述隨著時間的推移，行為允許的軌跡對系統(tǒng)進(jìn)行建模?？梢允褂貌煌念愋偷臅r間記號(離散或連續(xù)，線性或分支，點或區(qū)間等)，導(dǎo)致了不同類型的時序邏輯。函數(shù)表示法：將系統(tǒng)描述為數(shù)學(xué)函數(shù)集。有可能是一階的也有可能是多階的。但該類表示法較為抽象和難于使用。所以在基于模型的測試中使用并不多。操作表示法：認(rèn)為系統(tǒng)是可執(zhí)行進(jìn)程集，進(jìn)程間并行執(zhí)行。該表示法適合描述分布式系統(tǒng)或通訊協(xié)議。典型代表是進(jìn)程代數(shù)或者Petrinet。隨機表示法：通過基于事件或者輸入值的概率模型來描述系統(tǒng)，更傾向于為環(huán)境建模。例如使用Markovchain為期望的用戶操作版本建模．據(jù)此產(chǎn)生的測試用例集可以體現(xiàn)用戶的實際使用場景。4.5測試用例選擇標(biāo)準(zhǔn)測試用例選擇標(biāo)準(zhǔn)可以輔助測試用例的生成。目前并不存在一個最優(yōu)標(biāo)準(zhǔn)。普遍使用的標(biāo)準(zhǔn)包括：結(jié)構(gòu)化模型覆蓋標(biāo)準(zhǔn)：標(biāo)準(zhǔn)充分利用了模型結(jié)構(gòu)信息，例如在基于transition的模型中。采用與圖相關(guān)的覆蓋標(biāo)準(zhǔn)來生成測試用例。數(shù)據(jù)覆蓋標(biāo)準(zhǔn)：標(biāo)準(zhǔn)主要關(guān)注如何從大規(guī)模數(shù)據(jù)空間里面選擇典型取值。常見的方式是等價類劃分和邊界值分析?；谛枨蟮母采w標(biāo)準(zhǔn)：當(dāng)模型的元素與SUT的非形式化需求相關(guān)時，需要基于需求的覆蓋標(biāo)準(zhǔn)。例如：需求數(shù)量可能與UML狀態(tài)圖的transition有關(guān)。Ad—hoc測試用例規(guī)約：除了模型，測試工程師可以依據(jù)經(jīng)驗，用形式化的表示方法編寫必須覆蓋的測試用例規(guī)約。指定對應(yīng)的測試用例。隨機標(biāo)準(zhǔn)：大部分用于環(huán)境模型。因為是環(huán)境決定了SUT的使用方式。行為概率直接用模型表示。產(chǎn)生的測試用例反應(yīng)了用戶的實際操作情況?；谌毕莸臉?biāo)準(zhǔn)：適用于SUT模型。最常見的基于缺陷的覆蓋標(biāo)準(zhǔn)是變異覆蓋。包括對模型進(jìn)行變異、產(chǎn)生測試用例用于區(qū)分變異模型和原有模型。4.6測試用例生成技術(shù)目前在給定SUT模型和測試用例規(guī)約下。主要包括如下技術(shù)：測試用例隨機生成：采用隨機游走的方式從系統(tǒng)的輸入空間隨機采樣。但可能導(dǎo)致每次生成的測試用例集擁有不同的特征，目前常常將隨機游走與用戶操作版本相結(jié)合。專用的圖搜索算法：包括結(jié)點覆蓋、邊覆蓋算法。受限的模型檢驗：用來確認(rèn)或者證偽一個系統(tǒng)的屬性。對于特定的屬性。如果屬性不滿足的時候。模型驗證將輸出一個反例。符號執(zhí)行：它采用符號(如變量的名稱)而不是實際的值來代表系統(tǒng)的輸入，作為結(jié)果。執(zhí)行過程中系統(tǒng)所有的變量及輸出為符號或關(guān)于符號的表達(dá)式。演繹定理證明：與模型驗證相似。用定理證明器代替了模型驗證器。一般用來檢查公式的可滿足性。4.7聯(lián)機、脫機測試用例生成主要關(guān)注測試用例產(chǎn)生和執(zhí)行的時機。在聯(lián)機測試用例生成時，測試用例產(chǎn)生算法可以依據(jù)SUT的實際輸出予以調(diào)整。這在SUT是非確定的時候是必要的。脫機測試用例生成意味著測試用例在生成結(jié)束后才能執(zhí)行。脫機測試的一個優(yōu)勢是測試用例易于管理，因為測試用例變動較小。并且可以嘗試采用最小化方法對測試用例規(guī)模進(jìn)行縮減?；谀Ｐ偷臏y試的工具SpecExplorer5.1SpecExplorerSpecExplorer[11]是微軟發(fā)布的一款與VisualStudio緊密整合的基于模型測試的工具。用戶可以通過SpecExplorer對一個軟件系統(tǒng)的期望行為進(jìn)行建模，并自動生成能夠在VisualStudio的測試框架下運行的測試代碼。模型可以用當(dāng)前主流的程序設(shè)計語言C#開發(fā)，然后通過Cord語言腳本對模型進(jìn)行配置和裁剪。SpecExplorer[12]這個名字來源于該工具可以自動探索規(guī)格說明（即Specification，簡稱Spec）的所有潛在行為，并將其行為模型表示為狀態(tài)機。一次探索的輸出有可能非常巨大，所以SpecExplorer提供了Cord語言對輸出進(jìn)行裁剪，并選出測試中真正關(guān)心的場景。SpecExplorer能夠高效的解決狀態(tài)爆炸的問題。5.2連接測試用例和待測系統(tǒng)SpecExplorer支持兩種連接測試用例和待測系統(tǒng)的方式[13]：直接連接和適配器連接。直接連接是指將待測系統(tǒng)實現(xiàn)中的方法和事件直接聲明成Cord配置中的Action（既可以依次聲明也可以使用"actionall"提取所有公用方法），這樣生成的測試代碼會直接調(diào)用待測系統(tǒng)的方法，并期待待測系統(tǒng)的事件，如圖5.1所示。這種連接只能被運用于測試托管代碼實現(xiàn)的系統(tǒng)，并且要求待測系統(tǒng)提供的API足夠進(jìn)行測試。圖5.1直接連接方式測試適配器是則是位于測試用例和待測系統(tǒng)之間的一層。當(dāng)創(chuàng)建測試適配器時，Cord配置文件中的Action并不是待測系統(tǒng)的方法和事件，而是適配器中的方法與事件；那么生成的測試代碼也調(diào)用適配器中的方法，期待適配器發(fā)起的事件。適配器的作用是把這些方法調(diào)用轉(zhuǎn)換為待測系統(tǒng)的方法調(diào)用，如圖5.2所示。當(dāng)待測系統(tǒng)是非托管代碼實現(xiàn)，或者測試用例與待測系統(tǒng)需要遠(yuǎn)程通信，或者存在一個中間層用于抽象模型和測試（比如控制待測系統(tǒng)的用戶界面）時，這種連接被廣泛運用。適配器由于避免了對托管測試代碼的依賴，從而極大的增加了specExplorer的適用范圍。圖5.2測試適配器方式模型開發(fā)者與適配器或者待測系統(tǒng)的實現(xiàn)者基于Action的接口規(guī)范打成一致，即可并行工作。接口實現(xiàn)只要在需要運行生成的測試代碼時能夠執(zhí)行即可。對于模型開發(fā)者來說，他們可以先把Action聲明成abstract，即可在沒有適配器或者待測系統(tǒng)實現(xiàn)的情況下進(jìn)行建模。5.3靜態(tài)模型和實例模型SpecExplorer在使用過程中會讓用戶根據(jù)不同的情況選擇不同的模型，主要分為2種類型的模型：靜態(tài)模型和實例模型[14]。前面提到了兩種連接測試用例與待測系統(tǒng)的方式：直接連接和適配器連接。如果你決定使用后者，那么適配器本身的設(shè)計決定了你選擇靜態(tài)模型還是實例模型。一個靜態(tài)的適配器可以被用來控制一個基于實例的待測系統(tǒng)，反之亦然。考慮到測試適配器只是整個測試體系中的一個組件，所以這里進(jìn)行選擇的基本原理和設(shè)計任何一個面向?qū)ο蟮慕M件的基本原理是一致的。注意這里并不是一個是或者否的決定，靜態(tài)和基于實例的Action可以共存于同一個適配器中。Cord腳本中Action的聲明被用于連接測試用例與待測系統(tǒng)或者適配器。總的來說，如果你的測試用例是調(diào)用待測系統(tǒng)或者適配器的靜態(tài)方法，那么Action就應(yīng)該是靜態(tài)的；如果調(diào)用的是待測系統(tǒng)或者適配器的實例化方法，那么Action就是基于實例的。所以選擇靜態(tài)模型還是實例模型的決策權(quán)并不在建模者，而在于待測系統(tǒng)或者適配器的設(shè)計者。當(dāng)然，兩者可以是扮演不同角色的同一個人。基于實例的Action意味著模型調(diào)用某一對象的方法，該對象不僅僅在模型探索階段存在，在測試運行階段也是存在的。所以該對象必須是之前某個步驟的輸出，如果一個方法創(chuàng)建了一個沒有返回的對象，那么顯然這一對象不能在模型的后續(xù)步驟中被用到。SpecExplorer允許把基于實例的Action與靜態(tài)的模型方法進(jìn)行對應(yīng)（反過來亦可）。雖然一般來說不推薦這么做，因為基于實例的Action對應(yīng)基于實例的模型方法，靜態(tài)Action對應(yīng)靜態(tài)模型方法是很自然的設(shè)計，但是有時建模者不同意待測系統(tǒng)或適配器的設(shè)計，而希望用另一種模型設(shè)計。我們的目標(biāo)是盡可能在滿足需求的基礎(chǔ)上讓用戶模型更為簡單并更容易維護(hù)?；谀Ｐ偷臏y試的優(yōu)缺點與其他軟件測試技術(shù)相比，基于模型的測試有以下優(yōu)點[15]：SUT的故障檢測軟件測試的主要目的是發(fā)現(xiàn)SUT中的錯誤，事實證明，基于模型的測試可以很好的檢測到故障數(shù)目。降低測試成本和時間基于模型的測試在編寫和維護(hù)模型上花費的時間和精力要低于手工測試中設(shè)計和維護(hù)一個測試套件的投入成本。提高測試質(zhì)量手工測試的質(zhì)量依賴于富有創(chuàng)造力的測試工程師，每個測試用例產(chǎn)生的原因是不會記錄的，并且這些測試用例不容易涉及到初始的系統(tǒng)需求?；谀Ｐ偷臏y重復(fù)化。通過考慮模型的覆蓋就可以測量測試套件的“質(zhì)量”。同時，基于模型的測試相比手動測試可以用來生成更多的測試。通過改變模型的測試選擇標(biāo)準(zhǔn)或者告訴工具來生成更多的測試，我們可以很容易地獲得非常大的測試套件，這可以幫助發(fā)現(xiàn)更多的錯誤。需求缺陷檢測一個有時意想不到的好處是對于非正式的需求，基于模型的測試可以通過編寫模型來暴露問題的所在，而這些需求通常是記錄在一個大型的、可能包含遺漏、矛盾的、不清楚的自然語言文檔中?；谀Ｐ偷臏y試的第一步就是通過構(gòu)建一個抽象模型SUT來澄清這個預(yù)期的行為，這個模型要求具有精確的語義，以便它可以分析一個機器。所以建模階段通常要求公開許多問題?？勺匪菪钥勺匪菪允悄軌蛏婕暗侥Ｐ椭忻總€測試用例，測試選擇標(biāo)準(zhǔn)，甚至到非正式的系統(tǒng)需求?？勺匪菪杂兄诮忉寽y試用例的生成原因，也可以在模型發(fā)展時優(yōu)化測試執(zhí)行。例如，當(dāng)我們使用UML狀態(tài)機作為建模表示法，測試生成算法會記錄模型的哪些轉(zhuǎn)換被用于每個測試用例。需求的演變手工測試中，如果測試設(shè)計和系統(tǒng)的需求變化，大量的工作經(jīng)常需要花費在更新測試套件上來反映新的需求?；谀Ｐ偷臏y試可以通過更新模型來重新測試，因為模型通常遠(yuǎn)小于測試套件，這樣就可以花費更少的時間來應(yīng)對不斷變化的需求。并且使用工具分析新舊需求的差異，還可以報告哪些測試不再相關(guān)，哪些測試涉及修改后的需求，哪些測試是新加的。所以，一個需求改變后，相應(yīng)變化的模型可以將測試分為：刪除、不變、改變、新增四組。當(dāng)測試時間有限的情況下，只執(zhí)行后兩組是非常有用的。正是由于基于模型的測試具有諸多優(yōu)點，可以解決許多其他測試技術(shù)不能解決的問題，所以在WEB應(yīng)用測試、通信協(xié)議測試等復(fù)雜系統(tǒng)中具有廣泛的應(yīng)用。不過，基于模型測試也不是萬能的，也存在一些局限性：1．過時的需求作為一個軟件工程的發(fā)展，有時非正式的需求變得過時了。如果一些基于模型的測試人員從過時的需求開始工作，他們將建立錯誤的模型，這樣就會在SUT找到大量的“錯誤”。2．不適當(dāng)使用基于模型的測試基于模型的測試并不是一顆可以迅速發(fā)現(xiàn)程序每個漏洞的子彈，也不會比標(biāo)準(zhǔn)的自動化測試流程更有效或更經(jīng)濟(jì)。它的作用是在輸入準(zhǔn)確的前提下為復(fù)雜的項目(比如實時或嵌入式程序設(shè)計)實現(xiàn)有實際價值的、非重復(fù)性模擬測試。3．分析失敗的測試時間當(dāng)一個生成的測試失敗，我們必須決定是否由于SUT、適配器代碼或錯誤的模型引起。基于模型的測試生成測試序列相比手工設(shè)計的測試序列可能會更復(fù)雜，這就使得發(fā)現(xiàn)導(dǎo)致失敗的測試更加困難和耗時。4．無用的指標(biāo)當(dāng)測試設(shè)計，大多數(shù)經(jīng)理使用手動測試用例的數(shù)量作為衡量設(shè)計測試進(jìn)展順利。但基于模型的測試容易產(chǎn)生大量的測試，所以測試數(shù)量指標(biāo)是沒有用的。有必要引入其他的測量測試方法，如SUT代碼覆蓋率，需求覆蓋率，和模型覆蓋率。參考文獻(xiàn)[1]毛澄映,盧炎生.構(gòu)件軟件測試技術(shù)研究進(jìn)展[J].計算機研究與發(fā)展,2006,43(8):1375-1382.[2]SchieferdeckerI.Model-BasedTesting[J].IEEESoftware,2012,29(1):14-18.[3]BouquetF,DadeauF,LegeardB,etal.JML-Testing-Tools:ASymbolicAnimatorforJMLSpecificationsUsingCLP.[M]//ToolsandAlgorithmsfortheConstructionandAnalysisofSystems.SpringerBerlinHeidelberg,2005:551-556.[4]HarelD.Statecharts:avisualformalismforcomplexsystems[J].ScienceofComputerProgramming,1987,8(3):231-274.[5]AvritzerA,LarsonB.LoadTestingSoftwareUsingDeterministicStateTesting.[M].ACM,1993.[6]HoornAV,RohrM,HasselbringW.Generatingprobabilisticandintensity-varyingworkloadforweb-basedsoftwaresystems[C]//PerformanceEvaluation–Metrics,ModelsandBenchmarks:ProceedingsoftheSPECInternationalPerformanceEvaluationWorkshop(SIPEW’08),volume5119ofLectureNotesinComputerScience(LNCS.2008:124--143.[7]PooreJH.Introductiontothespecialissueon:model-basedstatisticaltestingofsoftwareintensivesystems[J].Information&SoftwareTechnology,2000,42(12):797-799.[8]MaurerPM.TheDesignandImplementationofaGrammar-basedDataGenerator.[J].SoftwarePractice&Experience,1992,22(3):223-244.[9]PretschnerA,PhilippsJ.10MethodologicalIssuesinModel-BasedTesting[J].LectureNotesinComputerScience,2005,3472:11-18.[10]LamsweerdeAV.Formalspecification:aroadmap.[J].FutureofSoftwareEngineeringAFinkelsteinAcm,2000:147-159.[11]\o"查看此用戶資料"xianglims.百度百科SpecExplorer.[EB/OL].[2016-01-18]./link?url=wGJJPEPVVYUNI5dn69s9uJKp1p4iw7FyNtj0TlMZ8eaRDxdt-uWt_tnTIbzJ_IJoS-sKhaMiBqlcgg1BUfa84_.[12]朱永光.用SpecExplorer進(jìn)行基于模型的測試.[EB/HYPERLINK"/s?wd=OL&tn=44039180_cpr&fenlei=mv6quAkxTZn0IZRqIHckPjm4nH00T1d9rH7WmymYn1Rz