注意，圖1中的試驗(yàn)?zāi)Ｐ捅簧晕⒑喕蕴峁┮粋�測試模型中的一些核心要素的例子。測試這樣一個系統(tǒng)的真實(shí)模型將包含更多步驟，動作和檢查，以及更多的規(guī)定。例如，我們需要來啟動和終止調(diào)動的步驟，注銷終端步驟，移動它們的網(wǎng)絡(luò)的步驟，啟動數(shù)據(jù)傳輸不同類型的步驟，等等更多。
至于這種模型中的規(guī)定，我們應(yīng)該保持終端列能有效調(diào)用，消息列可以發(fā)送和接收，并保證一切有效數(shù)據(jù)傳輸。并且應(yīng)在測試先知中用類似于圖1中檢查注冊終端的方式去再次堅(jiān)持這項(xiàng)新規(guī)定。本文的其余部分將把示例模型引用為一個擴(kuò)展版本。一個測試生成器可采取不同的方法從一個測試模型生成測試用例。對于OSMO Tester生成器及圖1所示測試模型，該模型可能如[ ACM ]所述那樣被直觀地描述為一系列規(guī)則和動作。該模型定義了一組可以在被測系統(tǒng)上進(jìn)行的動作（在OSMO Tester標(biāo)記中用作@TestStep的一部分）。當(dāng)這些動作中的每一個都被允許時，一組規(guī)則（OSMO Tester標(biāo)記中的@Guard）定義了。規(guī)則允許的話，生成器以不同的方式組合這些動作以生成測試用例。整個測試模型可以被視作用來描述大量的可能測試用例集。隨后測試生成器從（使用一些由用戶定義的覆蓋準(zhǔn)則的）這個模型去生成測試用例。可用標(biāo)準(zhǔn)的變化取決于所使用的工具，但一些例子包含了在模型中覆蓋用戶指定要求（手動標(biāo)記的特定部分或路徑），覆蓋動作組合，并覆蓋不同動作的各種數(shù)據(jù)值。(可能已被用來為我們的示例模型指導(dǎo)生成器的)覆蓋準(zhǔn)則的一些例子包括：注冊終端的數(shù)量，調(diào)用終端的數(shù)量，注冊卻自由（不處于調(diào)用狀態(tài)）的終端的數(shù)量，及動作結(jié)果配對。例如，它可以被定義為對將“零”，“一”和“多”類別都覆蓋到終端類型數(shù)中的每一個很感興趣。動作覆蓋可以與這些數(shù)值中的一些進(jìn)一步配對，以激勵生成器來生成步驟，諸如注銷一個調(diào)用終端和注銷一個不同配置下的非調(diào)用終端。有了更嚴(yán)格/松散的覆蓋目標(biāo)，以及從自由度變?yōu)樵跍y試用例中添加隨機(jī)性，那么生成機(jī)可以被用來生成一組更小/更大的測試用例。
圖2是一個（含有圖1模型中的一個測試生成流程的四個不同點(diǎn)的）例子。在點(diǎn)一（ 1 ）中 ，模型程序被5個未注冊終端初始化了。在點(diǎn)二（2 ）中，生成由幾個步驟推進(jìn)，且三個終端已被注冊。在點(diǎn)三（ 3 ）中 ，幾個步驟再次被通過且兩個注冊終端有了有效調(diào)用（兩者間的單獨(dú)調(diào)用）。在點(diǎn)四（ 4 ）中，兩個以前未注冊的終端已經(jīng)被注冊了，前面調(diào)用的一部分已經(jīng)退出，已用兩個終端建了一個新的調(diào)用。
圖2.測試生成流程示例
它真正測試哪些東西呢？
測試生成的一個常見問題是：它真正測試什么呢？如果我們只是無休止地生成測試數(shù)據(jù)或測試步驟卻對結(jié)果的正確性一無所知，那還有什么意義呢？在基模測試中，測試模型也可以用來檢查測試用例。圖1中這是由模型中@Post注釋的方法舉例說明的。生成器在所有的測試步驟兩兩間（后）執(zhí)行這個過程，以證明被測系統(tǒng)的情況與測試模型的情況一致。例如，在圖2的點(diǎn)二（ 2 ）中，它會檢查是否測試模型中被標(biāo)記為注冊的三個終端在被測系統(tǒng)中也都處于相同情況。它還要檢查其他兩個沒有被注冊，而且他們都沒有正在進(jìn)行有效調(diào)用。
類似地，更具體的檢查可以嵌入到任何可在其中獲得一些具體結(jié)果的行動中去。
如果需要的話，這些檢查可以是不同粒度的，且可以在按量進(jìn)行，因?yàn)椴幌袷止つ_本，他們不需要手工編寫每個測試用例的每一步，卻可以由測試生成器進(jìn)行，時間間隔與時間長短都不限。
當(dāng)已經(jīng)創(chuàng)建了一個測試模型，測試生成器用來從這些模型生成測試用例。除了用指定的覆蓋準(zhǔn)則為指導(dǎo)從整體模型生成測試，很多MBT工具還提供了一種手段來指導(dǎo)生成器用各種形式的用戶定義場景去關(guān)注特定部分。例如，有了（有調(diào)用等的）擴(kuò)展示例模型，我們或許還想從某個角度專注分析管理終端注冊的網(wǎng)絡(luò)服務(wù)器。要做到這一點(diǎn)，用戶可以創(chuàng)建一個場景，確保只有測試步驟與該場景（如注冊和注銷）相關(guān)聯(lián)。
工具的具體場景定義語言，可以用來建立這樣的場景。要建一個特定測試配置，測試模式可用指定終端實(shí)例被參數(shù)化。
圖3說明了為我們只允許注冊和注銷步驟的示例模型建立一個場景，且每個步驟都必須在每個生成的測試用例中出現(xiàn)至少兩次。
更真實(shí)的例子會包括更多步驟，更多部分，并且可能還包括用以驅(qū)動SUT到場景起點(diǎn)的啟動腳本。
這樣一個場景甚至可以用來定義一個特定動作序列，該序列將被用作一個啟動腳本以生成一個類似于手工編寫測試用例的純手工特定測試用例，而不是當(dāng)模型和其他生成的測試用例一樣變化時將被更新。
圖3.使用OSMOTester的場景定義示例
