基于模型的測試屬于軟件測試領域的一種測試方法。MBT步驟如下：

常規測試一般是由人來設計幾個特定的測試場景，然后斷言測試結果。測試用例固定。缺少不確定性?；谀Ｐ偷臏y試（Model-based Testing）是需要實現一個模型，然后制定行為和行為之間的關系以及行為和系統的關系（有限狀態機），然后測試系統根據被測系統的狀態、之前設置的限制條件和策略來生成很多用例（每執行一次生成的用例會不同），測試結果受一系列操作的影響，可以產生不確定性，更有可能發現一些想不到的很深路徑下的BUG。
基于模型的測試主要包括以下部分：
1、模型程序（Model Program ）：在這里定義被測系統的可以被執行的一些操作（action）,比如創建一個虛機、刪除一個虛機等。還有這些操作能被執行的條件(xxx_enabled)和系統在各個操作下的狀態（state）。
2、Test Harness/Steper/adapter：訪問被測系統，具體實現模型中定義的操作（action）。
3、策略（Strategies）：在測試運行過程中，完成一個操作（action）后，下一個應該執行哪個操作，是由這個策略決定的，最簡單的策略可以用隨機選擇的方式，還可以自己實現一些更復雜的選擇策略算法，比如Zstack的公平調度算法和基于歷史測試路徑的調度算法。
4、測試執行器（Test Runer）：執行測試、檢查
基于模型的測試的一般步驟：
1、分析理解被測試軟件
基于模型的軟件測試要求充分理解被測試軟件。構造可以用于測試的模型的工作主要是根據測試目的確定測試對象和測試特征，針對被測試軟件的相關屬性建立相應模型。這個階段的具體工作包括,
充分了解軟件需求規范和設計文檔、用戶手冊和開發隊伍充分交流。
1)識別軟件系統的用戶，枚舉每個用戶的輸入序列，研究每項輸入的可能取值范圍，包括, 合法值、邊界值、非法值，以及預期輸出。這項工作往往需要工具支持。
2)記錄輸入發生條件和響應發生條件。軟件系統的響應是指用戶能夠得到的輸出或可見的軟件內部狀態的改變。其目的是設計可以引發特定響應的測試例和評價測試結果。
3)研究輸入序列，如，輸入發生時刻，軟件系統接收特定輸入的條件，輸入處理順序。
4)理解軟件內部數據交換和計算過程，產生可能發現缺陷的測試數據。
2、選擇合適的測試模型
不同的模型適用于不同類型軟件的測試 因此需要根據軟件特點選擇模型。
1）了解可用的模型：不同的應用領域要使用不同的測試模型。例如，電話交換系統多使用狀態模型；并發軟件系統中不同組件并發運行用狀態圖建模；馬爾可夫鏈可以對軟件進行失效統計分析。模型的選擇還依賴于軟件系統的工作特點，例如，測試長期運行軟件系統可以使用狀態機模型。
2）根據模型特征進行選擇：只有充分理解模型和軟件系統，才能選擇合適的模型對軟件進行測試。以狀態機為例，自動機理論可以對狀態機進行分類，說明不同的狀態機可以表達什么語言，從而可以根據應用程序的功能和特點，選擇不同的狀態機模型。由于根據有限狀態機產生測試數據相當于遍歷有向圖，因此圖論算法可以指導產生測試例。
3）人員、組織和工具的影響：基于模型的軟件測試對測試人員的知識結構和技術水平提出了一定要求。如果一個開發組織使用模型(如UML）完成需求分析和系統設計，開展基于模型的軟件測試就比較容易，因為根據系統分析和設計的模型進行測試，往往可以直接應用基于模型的軟件測試技術，還可以根據測試的進展不斷調整模型或模型的細節并有利于在開發過程早期進行測試規劃。另外還要根據開發組織使用的測試工具選擇特定的模型。
3、構造測試模型
以基于狀態機模型的測試為例說明如何構造測試模型。首先要抽象出軟件系統狀態，狀態抽象一般要根據輸入及輸出條件進行，一般包括以下過程：
1)生成一個輸入序列并說明每個輸入的適用條件，稱作輸入約束。例如電話未摘機時，才允許有摘機動作發生。
2)對每個輸入要說明產生不同響應的上下文環境，稱作響應約束。例如，電話摘機時，如果當前狀態為振鈴，則進行通話，否則為撥號音。
3)根據輸入序列、輸入約束和響應約束構造相應狀態機模型，如下圖示例。

4、生成和執行測試例
測試例的自動生成依賴于測試所使用的模型。以有限狀態機模型為例，被遍歷路徑中弧的標記構成的序列就是測試例。在構造滿足測試準則的路徑時，必須考慮約束條件，如路徑長度限制，統計測試還要考慮遷移概率。生成了滿足特定的測試充分性準則的測試例集合后就可以執行測試例。以狀態機模型為例~ 首先要寫出仿真該軟件系統的每個不同外界激勵的腳本，稱為仿真腳本( simulation script) ，每個仿真腳本對應模型中一個不同的遷移；然后把測試例集合翻譯為測試腳本( test script)。也可以用測試生成器通過遍歷狀態機的遷移直接產生測試腳本。測試例的執行就是測試腳本的執行過程。腳本是可以重復利用的資源，維護測試腳本也是測試工作的一部分。
5、收集測試結果進行分析
基于模型的軟件測試方法并沒有解決測試失效辨識(Test Oracle) 問題，仍然要人工檢查輸出是否正確。但是通過狀態驗證可以部分解決測試失效辨識問題，狀態是內部數據的抽象，比較容易驗證。另外，與傳統測試相比，基于模型的軟件測試的優勢之一就是可以根據測試結果分析軟件的其它質量因素，如可靠性。
基于模型的軟件測試的評價
1、基于模型的軟件測試的優勢
基于模型的軟件測試大大提高了測試自動化水平，部分解決了測試失效辨識問題，可以進行測試結果分析，有利于測試制品的重用，并可以應用成熟的理論和技術獲得比較完善的分析結果?，F代軟件工程強調增量和迭代的開發過程，采用面向對象開發技術，提高軟件開發質量和加快軟件開發速度。由于面向對象軟件系統的規范多數使用模型表達，這些模型中包含了大量可以用于軟件測試的信息，因此基于模型的軟件測試可以把軟件測試工作提前到開發過程早期，如進行測試工作的早期規劃。
2、基于模型的軟件測試的缺點
基于模型的軟件測試存在以下缺點：
1)測試人員需要具備一定的理論基礎，如狀態機理論和隨機過程的知識。還要掌握相關工具使用方法。
2)需要一定的前期投入，如模型的選擇，軟件功能劃分，模型構造等。
3)有時無法克服模型的固有缺陷，如狀態爆炸，這對檢驗，評審和維護模型都提出了要求，也直接影響了測試自動化。狀態爆炸問題一般通過抽象和排除方法( abstraction Sexclusion) 減小測試規模，降低測試難度來解決。