基於模型的測試的測試設計
 |
TeemuKanstrén是一名資深科學家，目前在芬蘭VTT技術研究中心工作，他還是多倫多大學的一名客座博士後。他的工作涉及：以改進行業現狀，和生產實際有用的解決方案並幫助行業夥伴接受採納它們為目的的自動化測試領域的研究和開發。他軟體行業工作了好幾年，已幫助眾多合作伙伴開發和採用以基於模型的測試技術為基礎的測試自動化解決方案。他是開源的基於模型的測試工具OSMO Tester的主要創造者。2010年他獲得了芬蘭大學測試自動化和基於模型的測試的博士學位。 ? |
?
介紹
測試設計是測試過程中最重要的部分之一。一個好的測試用例不僅要為被測系統（ SUT ）提供一些輸入，還要驗證系統是否如預期進行。也就是說，它有助於確認利益相關者要求得以實現。但測試設計可以做的遠不止這些。理想情況下，測試設計有助於溝通兩方對這些需求的理解，驗證他們能被正確實施，並引發對利益相關者可能增加的更大價值的討論。
例子
為了給這個概念提供一個具體的理解，首先我們舉一個簡單的例子。這裡所說的例子使用OSMO Tester MBT生成器的符號，它基於Java程式語言。這種情況下，測試模型是使用標準的Java程式語言結構編寫的，但卻被設計成被另一個稱作測試生成器的程式以不同的方式執行，以生成測試用例。有時候，這種模型被稱為模型程式。
其他類似工具用於各種其他平臺，比如Python （PyModel）和．NET （Spec Explorer， NModel）。其他基於Java的工具和符號，包括ModelJUnit和Conformiq Designer。許多工具也定義了自己的建模語言，並提供一種方法將模型以不同的方式進行視覺化。
根據使用者的喜好，可以選擇不同的工具提供一個熟悉的工作環境以及不同的演算法和不同的特徵等。
[BINDER]中可找到一個MBT工具列表。
?
圖1.模型程式示例
注意，圖1中的試驗模型被稍微簡化以提供一個測試模型中的一些核心要素的例子。測試這樣一個系統的真實模型將包含更多步驟，動作和檢查，以及更多的規定。例如，我們需要來啟動和終止調動的步驟，登出終端步驟，移動它們的網路的步驟，啟動資料傳輸不同型別的步驟，等等更多。
圖2是一個（含有圖1模型中的一個測試生成流程的四個不同點的）例子。在點一（ 1 ）中 ，模型程式被5個未註冊終端初始化了。在點二（2 ）中，生成由幾個步驟推進，且三個終端已被註冊。在點三（ 3 ）中 ，幾個步驟再次被通過且兩個註冊終端有了有效呼叫（兩者間的單獨呼叫）。在點四（ 4 ）中，兩個以前未註冊的終端已經被註冊了，前面呼叫的一部分已經退出，已用兩個終端建了一個新的呼叫。
圖2.測試生成流程示例
? 它真正測試哪些東西呢？
測試生成的一個常見問題是：它真正測試什麼呢？如果我們只是無休止地生成測試資料或測試步驟卻對結果的正確性一無所知，那還有什麼意義呢？在基模測試中，測試模型也可以用來檢查測試用例。圖1中這是由模型中@Post註釋的方法舉例說明的。生成器在所有的測試步驟兩兩間（後）執行這個過程，以證明被測系統的情況與測試模型的情況一致。例如，在圖2的點二（ 2 ）中，它會檢查是否測試模型中被標記為註冊的三個終端在被測系統中也都處於相同情況。它還要檢查其他兩個沒有被註冊，而且他們都沒有正在進行有效呼叫。
類似地，更具體的檢查可以嵌入到任何可在其中獲得一些具體結果的行動中去。
如果需要的話，這些檢查可以是不同粒度的，且可以在按量進行，因為不像手工指令碼，他們不需要手工編寫每個測試用例的每一步，卻可以由測試生成器進行，時間間隔與時間長短都不限。
當已經建立了一個測試模型，測試生成器就用來從這些模型生成測試用例。除了用指定的覆蓋準則為指導從整體模型生成測試，很多MBT工具還提供了一種手段來指導生成器用各種形式的使用者定義場景去關注特定部分。例如，有了（有呼叫等的）擴充套件示例模型，我們或許還想從某個角度專注分析管理終端註冊的網路伺服器。要做到這一點，使用者可以建立一個場景，確保只有測試步驟與該場景（如註冊和登出）相關聯。
工具的具體場景定義語言，可以用來建立這樣的場景。要建一個特定測試配置，測試模式可用指定終端例項被引數化。
圖3說明了為我們只允許註冊和登出步驟的示例模型建立一個場景，且每個步驟都必須在每個生成的測試用例中出現至少兩次。
更真實的例子會包括更多步驟，更多部分，並且可能還包括用以驅動SUT到場景起點的啟動指令碼。
這樣一個場景甚至可以用來定義一個特定動作序列，該序列將被用作一個啟動指令碼以生成一個類似於手工編寫測試用例的純手工特定測試用例，而不是當模型和其他生成的測試用例一樣變化時將被更新。
圖3.使用OSMOTester的場景定義示例
MBT的優點
基模測試的優點很多。相對於手動設計（編寫）單個測試用例，建立測試模型意味著有必要考慮和確定被測系統的整體行為。根據我們的經驗，反之這促使了組織間的交流以便把要求建立這樣一個模型的各方都彙集起來，既有利於協作又促進共同理解。
當從一個單一的模型生成大量測試用例時，維護也被簡化了，而且更新模型一次並重新執行生成器會可以立刻更新所有測試用例，而不要單獨重新執行幾百個測試用例。
一個精心設計的測試模型表現出了作為一個整體的被測系統的被選方面。被允許和支援的測試值而不是單個測試值的範圍應該在測試模型中被發現並表示。不利用測試（模型）設計師把開發人員和領域專家聚到一起是不可能。也許基模測試應用中通常觀察到的最大的好處是：建設和共享對系統的限制和功能的明確理解，並把所有的假設都列到表格中。
當這種理解被記錄到一個測試模型中，某種程度上它就成了一個可執行的規範，因為它可以被用來生成測試用例以實施。然後，不斷的測試用例將驗證被記錄的理解也與實施一致。如果不是這樣，就有待達成一個新的共同的理解，細化的模型，或不變的實施。
當然，該測試模型不能充分地描述該被測系統的所有可能的行為，或者它會變得和實現本身一樣複雜甚至更復雜。因此，需要為建模內容選擇一個合適的範圍，為測試模型選擇一個相當高的抽象級別。測試模型的設計需要把重點放在系統的核心部分，該核心部分被視為對嚴格的測試和驗證最重要。這個變化要跨幾個系統，例如，安全關鍵系統可能比不太重要的應用包含了更詳細的內容。因為基模測試過程不僅提供了所生成的測試用例，而且還有對系統規範和功能的嚴格審查，這個審查被要求用來生成測試模型。我們發現這對一個高層次的系統概述和核心關鍵要素的詳細研究特別有用。
從測試生成的角度來看，基模測試的主要好處在於它的自動模型探索能力且在探索測試模型中不挑測試生成器。根據我們的經驗，一個領域（測試）專家要檢視系統並對它是如何工作的做出某些內在假設很簡單，凸顯一些東西，在手動設計測試用例中重複這些假設。手工操作也很昂貴，在各種不同的開發迭代中很少有時間或資源來廣泛測試一大組不同的選項，或者保證一個大堆測試得以審查和更新。
使用測試模型為基礎的測試生成器的限制較少。有一個好的測試模型，該工具就可以結合不同的模型覆蓋準則探索不同場景並把隨機模型覆蓋融合進去，就避免了一些專業偏差還擴大了探索選項集合。自然，該工具無法避免模型內的偏差，但是當幾位專家一起進行模型工作（甚至部分，如審查）時，模型具有巨大偏差的可能性就小了，工具將更加不知疲倦更徹底地探索模型。在現有計算能力和測試執行時間內，它可以生成並執行大量測試用例而不會厭倦，並在每次迭代中重複同樣的過程，只需更新單個測試模型就行。
許多關於使用基模測試的案例研究已經發表，也許這其中最廣泛的就是微軟協議文件工作[ ACM ] 。微軟研究表明：把所有元素（包括學習曲線等）考慮在內時使用基模測試對比手工指令碼有42％的利益。它還強調了許多我們所觀察到的接下來將要討論的問題。
採用需求及潛在問題
如果基模測試這麼棒，為什麼我們不一直用它呢？因為基模測試的初始成本較高，需要多樣化的技能，它的利益卻難以衡量。初始成本用於獲取技能，學習測試建模的思維模式，並建立測試模型。無法證明自己的系統和域的好處的話，這樣的初始成本很難被接受，如果所有人至今為止都一直手寫測試，就很容易安於現狀而不會為組織去嘗試不同的和未知的事物。
建立良好的測試模型需要良好的程式設計技巧（及一般的軟體工程技能），測試專業知識，建模專業知識和領域專業知識。這是一個多樣化的技能組合，很難靠單個專家獲得。而當有這樣的專家時，管理層往往快速將他們分配定位成為一個開發而不是測試。同樣，管理層基本不會提供各種昂貴的資源（如領域專家，軟體開發人員）用於和軟體測試的筒倉相關的活動，即使他們需要成功的測試活動。從模型設計角度來看，測試模型也並不是一個傳統的順序計算機程式，而是指導測試生成器的一個規則和行動的集合，它本身與傳統的順序程式設計有點不同。
一般情況下，當開始進行評估，（可能的話）採用基模測試方法的時候，或許最大的障礙就是需要採用一個完全不同型別的思維模式。有必要把重點放在考慮SUT的整體功能和目的或者它所選擇的一部分上，而不要獨自想著單用場景和單個測試用例。這需要與組織中的其他專家密切合作，這就可能需要對一般的工作實踐稍作改變。
這也強調了關於計算優點的問題。如果管理被用來測量如被寫測試用例的數量之類的東西，他們要麼就看不到測試用例（只有一個測試模型）要麼就是一大堆測試用例（所有生成的）。 [ GRAHAM ]中已對該問題及其可能結果做了詳細說明，[ GRAHAM ]中測試人員最初惡評如潮，後來因為已觀察到的影響而被承認。還有，最初獲得用該工具生成測試用例的啟動成本會顯得使用這種規格沒有任何價值。然而，它可以是建立共同理解並將之記錄在一個可執行的規範（測試模型）中的過程中最有用的部分。正如在任何自動化測試工作（或任何其他工作）中 ，管理支援，溝通和理解都是非常重要的。
該方法和測試生成結果的有效性取決於設計的測試模型的質量。沒有一個高質量的模型，就沒有測試生成可以生產好測試。因此，投入足夠精力去產生好模型並和其他專家一起檢驗它很重要。
生成一大組測試用例也能生出一大組需要進行分析的結果。根據我們的經驗，當考慮實施基模測試時，許多人通常認為這就是一個潛在的問題。然而，實踐中，我們已經觀察到：這問題不大，因為測試生成基本是使用某種形式的場景或（對系統具體部分分析關注的）專注模式指導的。然而，模型設計仍應仔細考慮諸如有趣元素有哪些以及它們從所有可能輸入到測試的組合，所以測試生成的重點應放在最有用的方面。至於結果分析，積極地說，當更多的精力可以從手動複製測試指令碼中被轉移到分析結果時，這就可以使工作更有趣而不那麼單調乏味。總之，測試自動化應該一層層往上建。
有效實施基模測試需要將之建於一個好的基礎的測試自動化平臺之上。如果它無法寫出可以自動化執行的測試指令碼，那麼繼續進行基模測試去產生這樣的指令碼就毫無意義。建立基礎的測試自動化需要良好的水平，這個水平上，基模測試過程可作為一個額外工具來提高總體質量。例如，如自動控制SUT的GUI進行測試一類的事，應該在測試一個基於GUI的應用程式時就得到解決。
過程
使用基模測試的過程可以用四個簡單的步驟描述為一個迭代過程，圖3所示。開始時，我們通常為系統所選的小一部分建立一個最初的測試模型。這使我們能夠學習基本工具和框架，並看看他們是如何連線以形成整個測試環境並在該環境中定位基模測試工具。
圖4.過程模型設計
一旦擁有了測試模型的工作版本，我們就用它來生成並執行測試用例。生成的測試用例的執行可以在所謂的“線上基模測試”中與他們的生成進行交錯，或在所謂的“離線基模測試”中的一個單獨的階段中完成。這就很快地給我們提供了對模型情況和對當前模型設計中被測系統的那些部分的反饋。
當我們已經生成並執行測試用例時，我們分析出被測系統上及測試模型中錯誤的結果。
在令人滿意的水平上，我們開始一步步地擴充套件模型並新增更多功能。這意味著我們要從頭重複這些步驟及這個過程，直到在我們覺得我們已得到了一個描述有趣元素的合適水平上的測試模型。
一些測試模型可以用來設計系統的不同部分。測試場景被用來指導測試生成，或者它可以使用不同的模型和生成器配置去重點關注不同的區域和觀點。
我們採用的一種做法是幫助合作伙伴開始使用開源工具理解這個概念，看到好處，並學習技術。開源工具也有適應特定需求和環境的優點。一旦基本技術，及其實施和效益被更好的理解了，就可以選取不同的前進道路，包括轉用（從廣泛付費支援和大規模開發先進演算法的資源獲益的，如Spec Explorer和Conformiq Designer的）商業工具這個選擇。然而，在許多情況下，我們早已經看到了開源選項提供的不錯利益。
可以運用基模測試的一個好地方是有很多變數和很多（需要進行測試的）互動的地方。一旦我們意識到把這個手動縮放到要求的複雜度和質量水平很昂貴的時候，基模測試就是一個值得考慮的好技術。另一個不錯的地方是安全性軟體，在這種軟體中必須完全相信一個好的幾乎無錯的解決方案已被建成。
結論
基模測試可能聽起來像一個很酷但卻嚇人的技術，很難上手。然而，經過一些初步學習之後，它並不比常規測試和測試自動化更復雜。我們一般採取的做法是建議一開始（最好是在熟悉這個概念的人的幫助下讓對該方法及其潛力超振奮的人）把它用在一個較小的試點專案中。我們通常以現有的測試自動化和測試指令碼為出發點，以這些為基礎一次一小部分地開始建立測試模型。至於抽象層，一個好的起點可以是：（通過利用現有的SUT的API去定義可能採取的行動或關注可以觀察到很多變化且很難測量手動測試的地方，在該系統複雜／易出故障的部分或在核心關鍵功能上，構建一個促進共同理解的高層次的總體模型中的）任何東西。
參考文獻
[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.??
版權宣告：本文出自 SPASVO澤眾軟體測試網：http://www.spasvo.com/news/html/2014422145508.html
原創作品，轉載時請務必以超連結形式標明本文原始出處、作者資訊和本宣告，否則將追究法律責任。
轉載於:https://my.oschina.net/spasvo/blog/261033