MBT的優(yōu)點(diǎn)
　　基模測試的優(yōu)點(diǎn)很多。相對于手動設(shè)計（編寫）單個測試用例，建立測試模型意味著有必要考慮和確定被測系統(tǒng)的整體行為。根據(jù)我們的經(jīng)驗，反之這促使了組織間的交流以便把要求建立這樣一個模型的各方都匯集起來，既有利于協(xié)作又促進(jìn)共同理解。
　　當(dāng)從一個單一的模型生成大量測試用例時，維護(hù)也被簡化了，而且更新模型一次并重新運(yùn)行生成器會可以立刻更新所有測試用例，而不要單獨(dú)重新運(yùn)行幾百個測試用例。
　　一個精心設(shè)計的測試模型表現(xiàn)出了作為一個整體的被測系統(tǒng)的被選方面。被允許和支持的測試值而不是單個測試值的范圍應(yīng)該在測試模型中被發(fā)現(xiàn)并表示。不利用測試（模型）設(shè)計師把開發(fā)人員和領(lǐng)域?qū)＜揖鄣揭黄鹗遣豢赡堋Ｒ苍S基模測試應(yīng)用中通常觀察到的大的好處是：建設(shè)和共享對系統(tǒng)的限制和功能的明確理解，并把所有的假設(shè)都列到表格中。
　　當(dāng)這種理解被記錄到一個測試模型中，某種程度上它成了一個可執(zhí)行的規(guī)范，因為它可以被用來生成測試用例以實施。然后，不斷的測試用例將驗證被記錄的理解也與實施一致。如果不是這樣，有待達(dá)成一個新的共同的理解，細(xì)化的模型，或不變的實施。
　　當(dāng)然，該測試模型不能充分地描述該被測系統(tǒng)的所有可能的行為，或者它會變得和實現(xiàn)本身一樣復(fù)雜甚至更復(fù)雜。因此，需要為建模內(nèi)容選擇一個合適的范圍，為測試模型選擇一個相當(dāng)高的抽象級別。測試模型的設(shè)計需要把重點(diǎn)放在系統(tǒng)的核心部分，該核心部分被視為對嚴(yán)格的測試和驗證重要。這個變化要跨幾個系統(tǒng)，例如，安全關(guān)鍵系統(tǒng)可能比不太重要的應(yīng)用包含了更詳細(xì)的內(nèi)容。因為基模測試過程不僅提供了所生成的測試用例，而且還有對系統(tǒng)規(guī)范和功能的嚴(yán)格審查，這個審查被要求用來生成測試模型。我們發(fā)現(xiàn)這對一個高層次的系統(tǒng)概述和核心關(guān)鍵要素的詳細(xì)研究特別有用。
　　從測試生成的角度來看，基模測試的主要好處在于它的自動模型探索能力且在探索測試模型中不挑測試生成器。根據(jù)我們的經(jīng)驗，一個領(lǐng)域（測試）專家要查看系統(tǒng)并對它是如何工作的做出某些內(nèi)在假設(shè)很簡單，凸顯一些東西，在手動設(shè)計測試用例中重復(fù)這些假設(shè)。手工操作也很昂貴，在各種不同的開發(fā)迭代中很少有時間或資源來廣泛測試一大組不同的選項，或者保證一個大堆測試得以審查和更新。
　　使用測試模型為基礎(chǔ)的測試生成器的限制較少。有一個好的測試模型，該工具可以結(jié)合不同的模型覆蓋準(zhǔn)則探索不同場景并把隨機(jī)模型覆蓋融合進(jìn)去，避免了一些專業(yè)偏差還擴(kuò)大了探索選項集合。自然，該工具無法避免模型內(nèi)的偏差，但是當(dāng)幾位專家一起進(jìn)行模型工作（甚至部分，如審查）時，模型具有巨大偏差的可能性小了，工具將更加不知疲倦更徹底地探索模型。在現(xiàn)有計算能力和測試執(zhí)行時間內(nèi)，它可以生成并執(zhí)行大量測試用例而不會厭倦，并在每次迭代中重復(fù)同樣的過程，只需更新單個測試模型行。
　　許多關(guān)于使用基模測試的案例研究已經(jīng)發(fā)表，也許這其中廣泛的是微軟協(xié)議文檔工作[ ACM ] 。微軟研究表明：把所有元素（包括學(xué)習(xí)曲線等）考慮在內(nèi)時使用基模測試對比手工腳本有42％的利益。它還強(qiáng)調(diào)了許多我們所觀察到的接下來將要討論的問題。

　　采用需求及潛在問題
　　如果基模測試這么棒，為什么我們不一直用它呢？因為基模測試的初始成本較高，需要多樣化的技能，它的利益卻難以衡量。初始成本用于獲取技能，學(xué)習(xí)測試建模的思維模式，并創(chuàng)建測試模型。無法證明自己的系統(tǒng)和域的好處的話，這樣的初始成本很難被接受，如果所有人至今為止都一直手寫測試，很容易安于現(xiàn)狀而不會為組織去嘗試不同的和未知的事物。
　　創(chuàng)建良好的測試模型需要良好的編程技巧（及一般的軟件工程技能），測試專業(yè)知識，建模專業(yè)知識和領(lǐng)域?qū)�業(yè)知識。這是一個多樣化的技能組合，很難靠單個專家獲得。而當(dāng)有這樣的專家時，管理層往往快速將他們分配定位成為一個開發(fā)而不是測試。同樣，管理層基本不會提供各種昂貴的資源（如領(lǐng)域?qū)＜�，軟件開發(fā)人員）用于和軟件測試的筒倉相關(guān)的活動，即使他們需要成功的測試活動。從模型設(shè)計角度來看，測試模型也并不是一個傳統(tǒng)的順序計算機(jī)程序，而是指導(dǎo)測試生成器的一個規(guī)則和行動的集合，它本身與傳統(tǒng)的順序程序設(shè)計有點(diǎn)不同。
　　一般情況下，當(dāng)開始進(jìn)行評估，（可能的話）采用基模測試方法的時候，或許大的障礙是需要采用一個完全不同類型的思維模式。有必要把重點(diǎn)放在考慮SUT的整體功能和目的或者它所選擇的一部分上，而不要獨(dú)自想著單用場景和單個測試用例。這需要與組織中的其他專家密切合作，這可能需要對一般的工作實踐稍作改變。
　　這也強(qiáng)調(diào)了關(guān)于計算優(yōu)點(diǎn)的問題。如果管理被用來測量如被寫測試用例的數(shù)量之類的東西，他們要么看不到測試用例（只有一個測試模型）要么是一大堆測試用例（所有生成的）。 [ GRAHAM ]中已對該問題及其可能結(jié)果做了詳細(xì)說明，[ GRAHAM ]中測試人員初惡評如潮，后來因為已觀察到的影響而被承認(rèn)。還有，初獲得用該工具生成測試用例的啟動成本會顯得使用這種規(guī)格沒有任何價值。然而，它可以是建立共同理解并將之記錄在一個可執(zhí)行的規(guī)范（測試模型）中的過程中有用的部分。正如在任何自動化測試工作（或任何其他工作）中 ，管理支持，溝通和理解都是非常重要的。
　　該方法和測試生成結(jié)果的有效性取決于設(shè)計的測試模型的質(zhì)量。沒有一個高質(zhì)量的模型，沒有測試生成可以生產(chǎn)好測試。因此，投入足夠精力去產(chǎn)生好模型并和其他專家一起檢驗它很重要。
　　生成一大組測試用例也能生出一大組需要進(jìn)行分析的結(jié)果。根據(jù)我們的經(jīng)驗，當(dāng)考慮實施基模測試時，許多人通常認(rèn)為這是一個潛在的問題。然而，實踐中，我們已經(jīng)觀察到：這問題不大，因為測試生成基本是使用某種形式的場景或（對系統(tǒng)具體部分分析關(guān)注的）專注模式指導(dǎo)的。然而，模型設(shè)計仍應(yīng)仔細(xì)考慮諸如有趣元素有哪些以及它們從所有可能輸入到測試的組合，所以測試生成的重點(diǎn)應(yīng)放在有用的方面。至于結(jié)果分析，積極地說，當(dāng)更多的精力可以從手動復(fù)制測試腳本中被轉(zhuǎn)移到分析結(jié)果時，這可以使工作更有趣而不那么單調(diào)乏味�？傊�，測試自動化應(yīng)該一層層往上建。
　　有效實施基模測試需要將之建于一個好的基礎(chǔ)的測試自動化平臺之上。如果它無法寫出可以自動化執(zhí)行的測試腳本，那么繼續(xù)進(jìn)行基模測試去產(chǎn)生這樣的腳本毫無意義。建立基礎(chǔ)的測試自動化需要良好的水平，這個水平上，基模測試過程可作為一個額外工具來提高總體質(zhì)量。例如，如自動控制SUT的GUI進(jìn)行測試一類的事，應(yīng)該在測試一個基于GUI的應(yīng)用程序時得到解決。

　　過程
　　使用基模測試的過程可以用四個簡單的步驟描述為一個迭代過程，圖3所示。開始時，我們通常為系統(tǒng)所選的小一部分創(chuàng)建一個初的測試模型。這使我們能夠?qū)W習(xí)基本工具和框架，并看看他們是如何連接以形成整個測試環(huán)境并在該環(huán)境中定位基模測試工具。

圖4.過程模型設(shè)計

　　一旦擁有了測試模型的工作版本，我們用它來生成并執(zhí)行測試用例。生成的測試用例的執(zhí)行可以在所謂的“在線基模測試”中與他們的生成進(jìn)行交錯，或在所謂的“離線基模測試”中的一個單獨(dú)的階段中完成。這很快地給我們提供了對模型情況和對當(dāng)前模型設(shè)計中被測系統(tǒng)的那些部分的反饋。
　　當(dāng)我們已經(jīng)生成并執(zhí)行測試用例時，我們分析出被測系統(tǒng)上及測試模型中錯誤的結(jié)果。
　　在令人滿意的水平上，我們開始一步步地擴(kuò)展模型并添加更多功能。這意味著我們要從頭重復(fù)這些步驟及這個過程，直到在我們覺得我們已得到了一個描述有趣元素的合適水平上的測試模型。
　　一些測試模型可以用來設(shè)計系統(tǒng)的不同部分。測試場景被用來指導(dǎo)測試生成，或者它可以使用不同的模型和生成器配置去重點(diǎn)關(guān)注不同的區(qū)域和觀點(diǎn)。
　　我們采用的一種做法是幫助合作伙伴開始使用開源工具理解這個概念，看到好處，并學(xué)習(xí)技術(shù)。開源工具也有適應(yīng)特定需求和環(huán)境的優(yōu)點(diǎn)。一旦基本技術(shù)，及其實施和效益被更好的理解了，可以選取不同的前進(jìn)道路，包括轉(zhuǎn)用（從廣泛付費(fèi)支持和大規(guī)模開發(fā)先進(jìn)算法的資源獲益的，如Spec Explorer和Conformiq Designer的）商業(yè)工具這個選擇。然而，在許多情況下，我們早已經(jīng)看到了開源選項提供的不錯利益。
　　可以運(yùn)用基模測試的一個好地方是有很多變量和很多（需要進(jìn)行測試的）交互的地方。一旦我們意識到把這個手動縮放到要求的復(fù)雜度和質(zhì)量水平很昂貴的時候，基模測試是一個值得考慮的好技術(shù)。另一個不錯的地方是安全性軟件，在這種軟件中必須完全相信一個好的幾乎無錯的解決方案已被建成。

　　結(jié)論
　　基模測試可能聽起來像一個很酷但卻嚇人的技術(shù)，很難上手。然而，經(jīng)過一些初步學(xué)習(xí)之后，它并不比常規(guī)測試和測試自動化更復(fù)雜。我們一般采取的做法是建議一開始（好是在熟悉這個概念的人的幫助下讓對該方法及其潛力超振奮的人）把它用在一個較小的試點(diǎn)項目中。我們通常以現(xiàn)有的測試自動化和測試腳本為出發(fā)點(diǎn)，以這些為基礎(chǔ)一次一小部分地開始建立測試模型。至于抽象層，一個好的起點(diǎn)可以是：（通過利用現(xiàn)有的SUT的API去定義可能采取的行動或關(guān)注可以觀察到很多變化且很難測量手動測試的地方，在該系統(tǒng)復(fù)雜／易出故障的部分或在核心關(guān)鍵功能上，構(gòu)建一個促進(jìn)共同理解的高層次的總體模型中的）任何東西。

　　參考文獻(xiàn)
　　[ACM] http://queue.acm.org/detail.cfm?id=1996412
　　[BINDER] http://www.robertvbinder.com/open-source-tools-for-modelbased-testing/
　　[GRAHAM] Harry Robinson， Ann Gustafson Robinson， Exploratory Test Automation: An Example Ahead of Its Time， in Dorothy Graham， Mark Fewster， Case Studies of Software Test Automation， 2012.  

　　版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://hgh666.cn/news/html/2014422145508.html

　　原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。