国产精品一品,欧美性猛交xxxx免费看漫画,激情不卡一区二区三区视频在线

基于模型的測試用例設計（1）

介紹
　　測試設計是測試過程中最重要的部分之一。一個好的測試用例不僅要為被測系統（ SUT ）提供一些輸入，還要驗證系統是否如預期進行。也就是說，它有助于確認利益相關者要求得以實現。但測試設計可以做的遠不止這些。理想情況下，測試設計有助于溝通兩方對這些需求的理解，驗證他們能被正確實施，并引發對利益相關者可能增加的更大價值的討論。
　　基于模型的測試（MBT）（下文都簡稱為：基模測試）是一種技術，有時被標榜為“自動化測試設計”。雖然一定程度上這并沒有錯，但它或許會給人以錯誤的印象。基模測試工具從一個由用戶指定的測試模型生成測試用例。沒有測試模型，該工具就無法生成任何測試用例。沒有好的測試模型，該工具就無法生成好的測試用例。因此，基模測試里，任務從測試設計變成了測試模型設計。不是設計單個測試集，我們設計了一個用于生成任何數量的測試用例的測試模型。
　　例子
　　為了給這個概念提供一個具體的理解，首先我們舉一個簡單的例子。這里所說的例子使用OSMO Tester MBT生成器的符號，它基于Java編程語言。這種情況下，測試模型是使用標準的Java編程語言結構編寫的，但卻被設計成被另一個稱作測試生成器的程序以不同的方式執行，以生成測試用例。有時候，這種模型被稱為模型程序。
　　圖1舉了一個簡化電信系統（其中多個移動終端被連接（注冊）到潛在多個服務器之一上，彼此相互調用）的這種符號的例子。
　　其他類似工具用于各種其他平臺，比如Python （PyModel）和．NET （Spec Explorer， NModel）。其他基于Java的工具和符號，包括ModelJUnit和Conformiq Designer。許多工具也定義了自己的建模語言，并提供一種方法將模型以不同的方式進行可視化。
　　根據用戶的喜好，可以選擇不同的工具提供一個熟悉的工作環境以及不同的算法和不同的特征等。
　　[BINDER]中可找到一個MBT工具列表。　

圖1.模型程序示例

　　注意，圖1中的試驗模型被稍微簡化以提供一個測試模型中的一些核心要素的例子。測試這樣一個系統的真實模型將包含更多步驟，動作和檢查，以及更多的規定。例如，我們需要來啟動和終止調動的步驟，注銷終端步驟，移動它們的網絡的步驟，啟動數據傳輸不同類型的步驟，等等更多。
　　至于這種模型中的規定，我們應該保持終端列能有效調用，消息列可以發送和接收，并保證一切有效數據傳輸。并且應在測試先知中用類似于圖1中檢查注冊終端的方式去再次堅持這項新規定。本文的其余部分將把示例模型引用為一個擴展版本。一個測試生成器可采取不同的方法從一個測試模型生成測試用例。對于OSMO Tester生成器及圖1所示測試模型，該模型可能如[ ACM ]所述那樣被最直觀地描述為一系列規則和動作。該模型定義了一組可以在被測系統上進行的動作（在OSMO Tester標記中用作@TestStep的一部分）。當這些動作中的每一個都被允許時，一組規則（OSMO Tester標記中的@Guard）就定義了。規則允許的話，生成器就以不同的方式組合這些動作以生成測試用例。整個測試模型可以被視作用來描述大量的可能測試用例集。隨后測試生成器從（使用一些由用戶定義的覆蓋準則的）這個模型去生成測試用例。可用標準的變化取決于所使用的工具，但一些例子包含了在模型中覆蓋用戶指定要求（手動標記的特定部分或路徑），覆蓋動作組合，并覆蓋不同動作的各種數據值。(可能已被用來為我們的示例模型指導生成器的)覆蓋準則的一些例子包括：注冊終端的數量，調用終端的數量，注冊卻自由（不處于調用狀態）的終端的數量，及動作結果配對。例如，它可以被定義為對將“零”，“一”和“多”類別都覆蓋到終端類型數中的每一個很感興趣。動作覆蓋可以與這些數值中的一些進一步配對，以激勵生成器來生成步驟，諸如注銷一個調用終端和注銷一個不同配置下的非調用終端。有了更嚴格/松散的覆蓋目標，以及從自由度變為在測試用例中添加隨機性，那么生成機就可以被用來生成一組更小/更大的測試用例。
　　圖2是一個（含有圖1模型中的一個測試生成流程的四個不同點的）例子。在點一（ 1 ）中，模型程序被5個未注冊終端初始化了。在點二（2 ）中，生成由幾個步驟推進，且三個終端已被注冊。在點三（ 3 ）中，幾個步驟再次被通過且兩個注冊終端有了有效調用（兩者間的單獨調用）。在點四（ 4 ）中，兩個以前未注冊的終端已經被注冊了，前面調用的一部分已經退出，已用兩個終端建了一個新的調用。

圖2.測試生成流程示例

　　它真正測試哪些東西呢？
　　測試生成的一個常見問題是：它真正測試什么呢？如果我們只是無休止地生成測試數據或測試步驟卻對結果的正確性一無所知，那還有什么意義呢？在基模測試中，測試模型也可以用來檢查測試用例。圖1中這是由模型中@Post注釋的方法舉例說明的。生成器在所有的測試步驟兩兩間（后）執行這個過程，以證明被測系統的情況與測試模型的情況一致。例如，在圖2的點二（ 2 ）中，它會檢查是否測試模型中被標記為注冊的三個終端在被測系統中也都處于相同情況。它還要檢查其他兩個沒有被注冊，而且他們都沒有正在進行有效調用。
　　類似地，更具體的檢查可以嵌入到任何可在其中獲得一些具體結果的行動中去。
　　如果需要的話，這些檢查可以是不同粒度的，且可以在按量進行，因為不像手工腳本，他們不需要手工編寫每個測試用例的每一步，卻可以由測試生成器進行，時間間隔與時間長短都不限。
　　當已經創建了一個測試模型，測試生成器就用來從這些模型生成測試用例。除了用指定的覆蓋準則為指導從整體模型生成測試，很多MBT工具還提供了一種手段來指導生成器用各種形式的用戶定義場景去關注特定部分。例如，有了（有調用等的）擴展示例模型，我們或許還想從某個角度專注分析管理終端注冊的網絡服務器。要做到這一點，用戶可以創建一個場景，確保只有測試步驟與該場景（如注冊和注銷）相關聯。
　　工具的具體場景定義語言，可以用來建立這樣的場景。要建一個特定測試配置，測試模式可用指定終端實例被參數化。
　　圖3說明了為我們只允許注冊和注銷步驟的示例模型建立一個場景，且每個步驟都必須在每個生成的測試用例中出現至少兩次。
　　更真實的例子會包括更多步驟，更多部分，并且可能還包括用以驅動SUT到場景起點的啟動腳本。
　　這樣一個場景甚至可以用來定義一個特定動作序列，該序列將被用作一個啟動腳本以生成一個類似于手工編寫測試用例的純手工特定測試用例，而不是當模型和其他生成的測試用例一樣變化時將被更新。

　　MBT的優點
　　基模測試的優點很多。相對于手動設計（編寫）單個測試用例，建立測試模型意味著有必要考慮和確定被測系統的整體行為。根據我們的經驗，反之這促使了組織間的交流以便把要求建立這樣一個模型的各方都匯集起來，既有利于協作又促進共同理解。
　　當從一個單一的模型生成大量測試用例時，維護也被簡化了，而且更新模型一次并重新運行生成器會可以立刻更新所有測試用例，而不要單獨重新運行幾百個測試用例。
　　一個精心設計的測試模型表現出了作為一個整體的被測系統的被選方面。被允許和支持的測試值而不是單個測試值的范圍應該在測試模型中被發現并表示。不利用測試（模型）設計師把開發人員和領域專家聚到一起是不可能。也許基模測試應用中通常觀察到的最大的好處是：建設和共享對系統的限制和功能的明確理解，并把所有的假設都列到表格中。
　　當這種理解被記錄到一個測試模型中，某種程度上它就成了一個可執行的規范，因為它可以被用來生成測試用例以實施。然后，不斷的測試用例將驗證被記錄的理解也與實施一致。如果不是這樣，就有待達成一個新的共同的理解，細化的模型，或不變的實施。
　　當然，該測試模型不能充分地描述該被測系統的所有可能的行為，或者它會變得和實現本身一樣復雜甚至更復雜。因此，需要為建模內容選擇一個合適的范圍，為測試模型選擇一個相當高的抽象級別。測試模型的設計需要把重點放在系統的核心部分，該核心部分被視為對嚴格的測試和驗證最重要。這個變化要跨幾個系統，例如，安全關鍵系統可能比不太重要的應用包含了更詳細的內容。因為基模測試過程不僅提供了所生成的測試用例，而且還有對系統規范和功能的嚴格審查，這個審查被要求用來生成測試模型。我們發現這對一個高層次的系統概述和核心關鍵要素的詳細研究特別有用。
　　從測試生成的角度來看，基模測試的主要好處在于它的自動模型探索能力且在探索測試模型中不挑測試生成器。根據我們的經驗，一個領域（測試）專家要查看系統并對它是如何工作的做出某些內在假設很簡單，凸顯一些東西，在手動設計測試用例中重復這些假設。手工操作也很昂貴，在各種不同的開發迭代中很少有時間或資源來廣泛測試一大組不同的選項，或者保證一個大堆測試得以審查和更新。
　　使用測試模型為基礎的測試生成器的限制較少。有一個好的測試模型，該工具就可以結合不同的模型覆蓋準則探索不同場景并把隨機模型覆蓋融合進去，就避免了一些專業偏差還擴大了探索選項集合。自然，該工具無法避免模型內的偏差，但是當幾位專家一起進行模型工作（甚至部分，如審查）時，模型具有巨大偏差的可能性就小了，工具將更加不知疲倦更徹底地探索模型。在現有計算能力和測試執行時間內，它可以生成并執行大量測試用例而不會厭倦，并在每次迭代中重復同樣的過程，只需更新單個測試模型就行。
　　許多關于使用基模測試的案例研究已經發表，也許這其中最廣泛的就是微軟協議文檔工作[ ACM ] 。微軟研究表明：把所有元素（包括學習曲線等）考慮在內時使用基模測試對比手工腳本有42％的利益。它還強調了許多我們所觀察到的接下來將要討論的問題。
　　采用需求及潛在問題
　　如果基模測試這么棒，為什么我們不一直用它呢？因為基模測試的初始成本較高，需要多樣化的技能，它的利益卻難以衡量。初始成本用于獲取技能，學習測試建模的思維模式，并創建測試模型。無法證明自己的系統和域的好處的話，這樣的初始成本很難被接受，如果所有人至今為止都一直手寫測試，就很容易安于現狀而不會為組織去嘗試不同的和未知的事物。
　　創建良好的測試模型需要良好的編程技巧（及一般的軟件工程技能），測試專業知識，建模專業知識和領域專業知識。這是一個多樣化的技能組合，很難靠單個專家獲得。而當有這樣的專家時，管理層往往快速將他們分配定位成為一個開發而不是測試。同樣，管理層基本不會提供各種昂貴的資源（如領域專家，軟件開發人員）用于和軟件測試的筒倉相關的活動，即使他們需要成功的測試活動。從模型設計角度來看，測試模型也并不是一個傳統的順序計算機程序，而是指導測試生成器的一個規則和行動的集合，它本身與傳統的順序程序設計有點不同。
　　一般情況下，當開始進行評估，（可能的話）采用基模測試方法的時候，或許最大的障礙就是需要采用一個完全不同類型的思維模式。有必要把重點放在考慮SUT的整體功能和目的或者它所選擇的一部分上，而不要獨自想著單用場景和單個測試用例。這需要與組織中的其他專家密切合作，這就可能需要對一般的工作實踐稍作改變。
　　這也強調了關于計算優點的問題。如果管理被用來測量如被寫測試用例的數量之類的東西，他們要么就看不到測試用例（只有一個測試模型）要么就是一大堆測試用例（所有生成的）。 [ GRAHAM ]中已對該問題及其可能結果做了詳細說明，[ GRAHAM ]中測試人員最初惡評如潮，后來因為已觀察到的影響而被承認。還有，最初獲得用該工具生成測試用例的啟動成本會顯得使用這種規格沒有任何價值。然而，它可以是建立共同理解并將之記錄在一個可執行的規范（測試模型）中的過程中最有用的部分。正如在任何自動化測試工作（或任何其他工作）中，管理支持，溝通和理解都是非常重要的。
　　該方法和測試生成結果的有效性取決于設計的測試模型的質量。沒有一個高質量的模型，就沒有測試生成可以生產好測試。因此，投入足夠精力去產生好模型并和其他專家一起檢驗它很重要。
　　生成一大組測試用例也能生出一大組需要進行分析的結果。根據我們的經驗，當考慮實施基模測試時，許多人通常認為這就是一個潛在的問題。然而，實踐中，我們已經觀察到：這問題不大，因為測試生成基本是使用某種形式的場景或（對系統具體部分分析關注的）專注模式指導的。然而，模型設計仍應仔細考慮諸如有趣元素有哪些以及它們從所有可能輸入到測試的組合，所以測試生成的重點應放在最有用的方面。至于結果分析，積極地說，當更多的精力可以從手動復制測試腳本中被轉移到分析結果時，這就可以使工作更有趣而不那么單調乏味。總之，測試自動化應該一層層往上建。
　　有效實施基模測試需要將之建于一個好的基礎的測試自動化平臺之上。如果它無法寫出可以自動化執行的測試腳本，那么繼續進行基模測試去產生這樣的腳本就毫無意義。建立基礎的測試自動化需要良好的水平，這個水平上，基模測試過程可作為一個額外工具來提高總體質量。例如，如自動控制SUT的GUI進行測試一類的事，應該在測試一個基于GUI的應用程序時就得到解決。
　　過程
　　使用基模測試的過程可以用四個簡單的步驟描述為一個迭代過程，圖3所示。開始時，我們通常為系統所選的小一部分創建一個最初的測試模型。這使我們能夠學習基本工具和框架，并看看他們是如何連接以形成整個測試環境并在該環境中定位基模測試工具。

圖4.過程模型設計

　　一旦擁有了測試模型的工作版本，我們就用它來生成并執行測試用例。生成的測試用例的執行可以在所謂的“在線基模測試”中與他們的生成進行交錯，或在所謂的“離線基模測試”中的一個單獨的階段中完成。這就很快地給我們提供了對模型情況和對當前模型設計中被測系統的那些部分的反饋。
　　當我們已經生成并執行測試用例時，我們分析出被測系統上及測試模型中錯誤的結果。
　　在令人滿意的水平上，我們開始一步步地擴展模型并添加更多功能。這意味著我們要從頭重復這些步驟及這個過程，直到在我們覺得我們已得到了一個描述有趣元素的合適水平上的測試模型。
　　一些測試模型可以用來設計系統的不同部分。測試場景被用來指導測試生成，或者它可以使用不同的模型和生成器配置去重點關注不同的區域和觀點。
　　我們采用的一種做法是幫助合作伙伴開始使用開源工具理解這個概念，看到好處，并學習技術。開源工具也有適應特定需求和環境的優點。一旦基本技術，及其實施和效益被更好的理解了，就可以選取不同的前進道路，包括轉用（從廣泛付費支持和大規模開發先進算法的資源獲益的，如Spec Explorer和Conformiq Designer的）商業工具這個選擇。然而，在許多情況下，我們早已經看到了開源選項提供的不錯利益。
　　可以運用基模測試的一個好地方是有很多變量和很多（需要進行測試的）交互的地方。一旦我們意識到把這個手動縮放到要求的復雜度和質量水平很昂貴的時候，基模測試就是一個值得考慮的好技術。另一個不錯的地方是安全性軟件，在這種軟件中必須完全相信一個好的幾乎無錯的解決方案已被建成。
　　結論
　　基模測試可能聽起來像一個很酷但卻嚇人的技術，很難上手。然而，經過一些初步學習之后，它并不比常規測試和測試自動化更復雜。我們一般采取的做法是建議一開始（最好是在熟悉這個概念的人的幫助下讓對該方法及其潛力超振奮的人）把它用在一個較小的試點項目中。我們通常以現有的測試自動化和測試腳本為出發點，以這些為基礎一次一小部分地開始建立測試模型。至于抽象層，一個好的起點可以是：（通過利用現有的SUT的API去定義可能采取的行動或關注可以觀察到很多變化且很難測量手動測試的地方，在該系統復雜／易出故障的部分或在核心關鍵功能上，構建一個促進共同理解的高層次的總體模型中的）任何東西。
作者介紹：
　　TeemuKanstrén是一名資深科學家，目前在芬蘭VTT技術研究中心工作，他還是多倫多大學的一名客座博士后。他的工作涉及：以改進行業現狀，和生產實際有用的解決方案并幫助行業伙伴接受采納它們為目的的自動化測試領域的研究和開發。他軟件行業工作了好幾年，已幫助眾多合作伙伴開發和采用以基于模型的測試技術為基礎的測試自動化解決方案。他是開源的基于模型的測試工具OSMO Tester的主要創造者。2010年他獲得了芬蘭大學測試自動化和基于模型的測試的博士學位。

posted on 2014-05-08 16:02 順其自然EVO 閱讀(704) 評論(0) 編輯收藏所屬分類: 測試學習專欄

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 如何進行Web服務的性能測試？利用drozer進行Android滲透測試 Appium Android Bootstrap源碼分析之命令解析執行 Fliptest—iOS 的應用A/B測試框架 iOS功能測試工具 Frank iOS單元測試框架Kiwi for iOS Appium Android Bootstrap之控件AndroidElement 移動應用測試框架—Calabash Android 簡介 Appium Server源碼分析之作為Bootstrap客戶端移植MonkeyRunner的圖片對比功能實現-Appium篇

qileilove

基于模型的測試用例設計（1）

導航

統計

常用鏈接

留言簿(55)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜