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