模型驅(qū)動測試可以將需求與設(shè)計聯(lián)系起來，幫助開發(fā)人員以一種通用語言生成結(jié)果，將設(shè)計過程中的每個人聯(lián)系起來。這改善了工作流程并清楚地傳達(dá)了設(shè)計。

在系統(tǒng)和軟件測試社區(qū)中，生成基于代碼的結(jié)果被認(rèn)為是軟件測試的黃金標(biāo)準(zhǔn)。但是，軟件復(fù)雜性的增加和上市時間的縮短迫使許多組織重新考慮他們?nèi)绾翁幚頊y試過程。隨著基于模型的測試 （MBT） 的引入，開發(fā)人員獲得了更快的自動化流程，可以幫助他們獲得完整的模型和代碼覆蓋率。

即便如此，一些開發(fā)人員認(rèn)為 MBT 未能達(dá)到預(yù)期，因為它沒有提供基于代碼的結(jié)果。然而，隨著 MBT 技術(shù)的最新進(jìn)展，這種看法不再準(zhǔn)確。新的 MBT 工具使測試人員能夠通過基于代碼的結(jié)果實現(xiàn)性能分析、內(nèi)存分析和代碼覆蓋。

模型驅(qū)動測試 （MDT） 流程通過讓開發(fā)人員在實際應(yīng)用程序上執(zhí)行場景并執(zhí)行這些測試來增強(qiáng)此工作流程。但關(guān)鍵問題是開發(fā)人員在運(yùn)行這些基于場景的測試時需要基于代碼的測試結(jié)果。

入門

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

盡管 MDT 提供了許多好處，但批評者強(qiáng)調(diào)它有一個弱點(diǎn)：缺乏基于代碼的測試結(jié)果，這對于調(diào)試故障、泄漏和性能差距至關(guān)重要。

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

使用傳統(tǒng)代碼和流程圖來捕獲測試用例行為

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

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

捕獲代碼中的測試用例行為并讓它執(zhí)行是利用 MDT 的最直接方法，而且風(fēng)險最小且?guī)缀鯖]有學(xué)習(xí)曲線。這種方法的另一個優(yōu)點(diǎn)是它允許輕松重用現(xiàn)有的基于代碼的測試用例。但是由于測試用例行為的邏輯通常很重要，開發(fā)人員傾向于將測試用例描繪成非正式的流程圖。由于將流程圖映射到代碼相對簡單，MDT 環(huán)境允許開發(fā)人員將測試用例行為捕獲為流程圖，從該流程圖生成測試代碼，將其鏈接到測試架構(gòu)，然后運(yùn)行測試。

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

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

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

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

在系統(tǒng)級分析期間，設(shè)計人員確定了許多高級需求，并且大多數(shù)行為需求被描述為序列圖。這構(gòu)成了系統(tǒng)分析師創(chuàng)建基本要求的許多變體以及基本要求的“未雨綢繆”排列的過程的基礎(chǔ)。此過程將作為序列圖捕獲的高級需求轉(zhuǎn)換為具體的測試用例。

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

實現(xiàn)基于代碼的結(jié)果

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

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

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

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

分布式開發(fā)，更好的代碼

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

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

審核編輯：郭婷