模型驅動測試可以將需求與設計聯系起來，幫助開發人員以一種通用語言生成結果，將設計過程中的每個人聯系起來。這改善了工作流程并清楚地傳達了設計。

在系統和軟件測試社區中，生成基于代碼的結果被認為是軟件測試的黃金標準。但是，軟件復雜性的增加和上市時間的縮短迫使許多組織重新考慮他們如何處理測試過程。隨著基于模型的測試 （MBT） 的引入，開發人員獲得了更快的自動化流程，可以幫助他們獲得完整的模型和代碼覆蓋率。

即便如此，一些開發人員認為 MBT 未能達到預期，因為它沒有提供基于代碼的結果。然而，隨著 MBT 技術的最新進展，這種看法不再準確。新的 MBT 工具使測試人員能夠通過基于代碼的結果實現性能分析、內存分析和代碼覆蓋。

模型驅動測試 （MDT） 流程通過讓開發人員在實際應用程序上執行場景并執行這些測試來增強此工作流程。但關鍵問題是開發人員在運行這些基于場景的測試時需要基于代碼的測試結果。

入門

MDT 方法可以幫助組織滿足緊縮的上市時間窗口，因為它允許開發人員使用他們設計時使用的相同語言進行測試，即統一建模語言 （UML）。除了節省時間之外，MDT 還提供了另一個優勢，它以場景為需求，使測試與客戶的規范保持一致。

盡管 MDT 提供了許多好處，但批評者強調它有一個弱點：缺乏基于代碼的測試結果，這對于調試故障、泄漏和性能差距至關重要。

在深入探討有關基于代碼的測試的問題之前，讓我們解釋一下 MDT 過程?；?UML 的測試用例可以用許多不同的格式編寫，包括 UML 序列圖、流程圖，甚至代碼（使用斷言樣式語句）。簡而言之，MDT 流程迫使開發人員以上述格式之一閱讀他們的需求并基于它們設計場景。接下來，將模型構建到滿足這些場景的可執行文件中。然后將原始場景轉變為測試。最后，在軟件經過 MDT 過程之后，這些相同的場景可以作為測試執行。

使用傳統代碼和流程圖來捕獲測試用例行為

可以使用代碼或流程圖或序列圖來描述測試用例行為，提供比傳統編碼更高的生產力。使用代碼描述測試用例與目前描述測試用例的過程基本相同，不同之處在于，如圖1所示，測試用例需要關注刺激和預期結果。測試用例執行的上下文是從模型中自動生成的。

圖 1：開發人員可以使用代碼來描述測試用例的純粹行為。

捕獲代碼中的測試用例行為并讓它執行是利用 MDT 的最直接方法，而且風險最小且幾乎沒有學習曲線。這種方法的另一個優點是它允許輕松重用現有的基于代碼的測試用例。但是由于測試用例行為的邏輯通常很重要，開發人員傾向于將測試用例描繪成非正式的流程圖。由于將流程圖映射到代碼相對簡單，MDT 環境允許開發人員將測試用例行為捕獲為流程圖，從該流程圖生成測試代碼，將其鏈接到測試架構，然后運行測試。

將測試用例描述為流程圖，如圖 2 所示，具有與編碼相同的表達能力，但它更容易捕獲并與項目的所有利益相關者進行溝通。

圖 2：在流程圖/活動圖中比在代碼中更容易捕獲測試用例行為。

用序列圖描述測試用例行為

序列圖提供了在基于代碼的測試環境中很少使用的設計的獨特視圖。這些圖可以描述整個系統和與之交互的參與者之間的操作場景。在其他情況下，它們可能包括有關內部設計組件之間消息的排序和交換的詳細信息。

在系統級分析期間，設計人員確定了許多高級需求，并且大多數行為需求被描述為序列圖。這構成了系統分析師創建基本要求的許多變體以及基本要求的“未雨綢繆”排列的過程的基礎。此過程將作為序列圖捕獲的高級需求轉換為具體的測試用例。

開發人員可以查看描述需求的序列圖并將其作為測試用例以交互方式應用，將輸入注入被測系統并檢查輸出以查看它們是否與序列圖中定義的匹配。這些測試的來源包括記錄應用程序的執行并手動編寫它們。每個來源都有自己的好處。記錄執行不測試需求，但有助于回歸測試。手寫序列在測試需求中很有用。無論如何創建測試，都需要基于代碼的結果。

實現基于代碼的結果

今天的開發人員可以通過多種方式獲得基于代碼的結果，所有這些都需要在某些工具中重寫測試然后執行。完成后，團隊將收到結果。

對某些人來說，這似乎是一種完全合乎邏輯的方法，但是在使用這種測試方法時會發現一些問題。首先，開發人員必須確定原始需求與軟件可交付成果相匹配。要正確執行此操作，開發人員必須重寫相同的基于場景的測試，否則代碼結果可能無法映射到需求。開發人員需要能夠編寫符合其要求的測試并實現完整的基于場景和代碼的結果。當前的測試工具使這成為可能，因為基于 MDT 的工具執行實際代碼。

鑒于這些進步，為什么軟件測試社區遲遲沒有采用 MDT？這有幾個原因，首先是早期基于模型的測試沒有提供基于代碼的測試結果。此外，許多開發人員需要代碼覆蓋率、內存分析和性能分析指標。當工具缺乏這些功能時，有些人會認為 MDT 是一種負擔而不是解決方案，這是有道理的。

彌合這些差距是成功實施 MDT 的挑戰。市場上有幾種有效的基于代碼的測試工具，重新創建此功能為開發人員喜歡的基于代碼的結果樣式提供了更少的選擇。另一種選擇是執行基于模型的測試并包含基于代碼的結果。這是可能的，因為在運行基于模型的測試時，開發人員可以執行實際代碼，而不是模擬。如果開發人員使用基于代碼的測試工具來檢測代碼，則 MDT 可以運行，并且結果將在完成時出現。

分布式開發，更好的代碼

尋找方法幫助分布式團隊更好地協同工作，同時推動高質量的可交付成果是許多組織的首要任務。當開發過程采用 MDT 方法時，團隊可以實現基于代碼的測試結果。關鍵的支持技術是執行實際應用程序的 MDT 測試。這意味著使用可以直接提供測試結果的基于代碼的測試工具運行 MDT 測試?；诖a的測試工具跟蹤正在執行的應用程序，使其成為最佳方法。

MDT 在改進測試過程方面有著良好的記錄，但它沒有被廣泛采用，因為它不會產生基于代碼的測試結果?，F在這是可能的，提供了兩全其美的優勢——在 MDT 流程中輕松創建和理解測試——以及開發人員可以使用的完整和徹底的測試結果。通過利用 MDT 方法的收益，開發人員也可以得到他們的蛋糕并吃掉它。

審核編輯：郭婷