【正文】 而且該測試工具仍需要人工輸入系統(tǒng)模型，系統(tǒng)模型的構(gòu)建過程并不是特別的輕松。 基于模型的測試 是一種輕量級自動生成測試用例的方法。工具利用 基于模型的自動化測試工具的實現(xiàn) 第 24 頁 共 13 頁 pairwise 模塊一共只生成了 11 種組合情況，遠小于直接正交排列組合得到的 216 種。函數(shù)過程的定義則只需要輸入函數(shù)過程的名稱，隨后如轉(zhuǎn)換動作一樣填充 token 序列。右下角是 WinForm 提供的 PropertyGrid 組件，用于詳細設(shè)置組件內(nèi)置對象的各項屬性。完成工具的主界面如圖 51。對于測試工具來說，這些操作都由類 PictFile 封裝。如果 ri 為空 ，那么選擇一種剩有最多未覆蓋取值組合的參數(shù)組合，比如圖 46 例子中生成第一個測試用例時 AB 剩有 4 種取值組合，而 AC 和 BC 則各有 6 種取值組合。算法分為兩個階段：準備階段和生成階段。但是這樣遍歷出來的測試用例數(shù)目又往往過于龐大，其中很大一部分還是冗余性測試用例。首先把準備序列化的對象標記為 Serializable，然后根據(jù)不同的需要和屬性特點把公共屬性都標記為XmlAttribute、 XmlArray 或 XmlIgnore，公共屬性中的自定義類型也需要在定義文件中添加相應(yīng)的標記。 0..12..20..10..*IRenderable+ Position : Point+++++Paint ()PrePaint ()PostPaint ()PaintFocus ()IsSelected ()...: void: void: void: void: boolActionRactionfromto: Action: StateR: StateRFunctionRactionpositionname: Action: Point: stringStateRstateposition: State: intTourRtouractionsentry: Tour: ListActionR: StateRIActionRenderable+ InnerAction : Action 圖 42 FSM 模型可視化模塊的類圖 接口 IRenderable 定義了新組件通用的屬性和方法，包括組件的位置信息、繪制組件過 基于模型的自動化測試工具的實現(xiàn) 第 16 頁 共 13 頁 程中觸發(fā)不同事件的響應(yīng)函數(shù)（ Paint、 PrePaint、 PostPaint 和 PaintFocus），方法 IsSelected則用于判斷該組件是否被鼠標選中。抽象類 ActionImpl 描述了測試中調(diào)用的 SUT 接口，準確地說是測試適配器層中的接口，它的兩個抽象方法 GenDefault 和 GetCopy 分別用于初始化和返回克隆實例。對于一些簡單的 set 和 get 方法圖中并沒有標出，其它輔助性的方法也予于省略。 基于模型的自動化測試工具的實現(xiàn) 第 13 頁 共 13 頁 . 系統(tǒng)架構(gòu) 工具設(shè)計的主要目的是為了自動生成測試用例， 而模型是驅(qū)動 MBT 各測試過程的根本，所以系統(tǒng)架構(gòu)中最核心的部分是 FSM 的數(shù)據(jù)模型，數(shù)據(jù)模型描述了 FSM 中各個狀態(tài)和轉(zhuǎn)換動作的詳細屬性。 基于模型的自動化測試工具的實現(xiàn) 第 12 頁 共 13 頁 第三章 系統(tǒng)架構(gòu) . 功能概述及流程 課題要求完成的 基于模型的自動化測試工具 的功能包括：支持輸入 FSM 模型、支持添加token、支持 pairwise 組合測試、支持生成測試用例框架、支持序列化 FSM 模型到文件和反序列化讀入。這樣 MBT 的整個測試工具都變得項目之間可移植了，如果某一測試條件和預(yù)期結(jié)果不同則在 token 中拋出異常，拋出的異常隨后被測試工具捕獲，最終判定該測試用例不通過。 我們將模仿 PICT 工具中 pairwise 算法的主要思想，使用一維擴展的貪心算法來生成覆蓋數(shù)組。啟發(fā)式搜索算法是利用一個已有的數(shù)組，通過合適的變換得到一個更優(yōu)的覆蓋矩陣，不斷地變換直到得到一個較優(yōu)的矩陣。利用計算機也可以自動求解出部分類型的正交數(shù)組，由已知的大覆蓋數(shù)組構(gòu)造小覆蓋數(shù)組的方法被稱為坍塌 [19]。前面的經(jīng)驗告訴我們， 3way 的測試用例就能夠達到 90%以上的錯誤發(fā)現(xiàn)率，具有較高的收益 代價比。2目前 pairwise 是使用最普遍的組合測試技術(shù)，因為軟件中的絕大部分錯誤都只由一個或兩個參數(shù)造成， pairwise 生成的測試用例能夠覆蓋足夠的錯誤空間。 后來人們發(fā)現(xiàn)通過巧妙地選取測試用例，只要求某些參數(shù)的組合 情況被包含，能夠在保證測試效率的同時大大縮減測試用例數(shù)量。當 FSM 包含的狀態(tài)比較多時，遍歷組成 FSM 有向圖產(chǎn)生的測試用例數(shù)量可能太多，不僅難以測試包含冗余測試用例。為此， Hamon 等人詳細討論提出了高效模型檢測的方法 [16]。這些等 價類就可以用于生成測試用例，最簡單的劃分方法是析取范式的方法。 把系統(tǒng)抽象 為變量 集合 和修改這些變量操作的基于 Pre/Post 的模型需要測試人員預(yù)先學(xué)習(xí)一段時間才能完全掌握，所以基本不予考慮。在 MBT 中使用過 的模型可能有幾十甚至上百種， 我們不可能也沒有必要去逐一了解， Mark Utting 和 Bruno Legeard 把它們大致分為以下幾種 [14]： 類型 示例 基于 Pre/Post B、 OCL、 JML、 Spec、 Z 基于轉(zhuǎn)換 FSM、狀態(tài)圖、 UML 狀態(tài)機 統(tǒng)計式 馬爾可夫鏈 基于歷史 消息隊列圖、 UML 順序圖 函數(shù)式 HOL 系統(tǒng) 操作式 Petri 網(wǎng) 數(shù)據(jù)流式 Lustre、塊狀圖 表 21 MBT 模型分類 基于轉(zhuǎn)換的模型 是我們最為熟悉的模型類型， 它們集中于描述系統(tǒng)在不同狀態(tài)之間的轉(zhuǎn)換過程。針對各個不同的模型表現(xiàn)形式，如今已有許多測試用例算法與之對應(yīng)，我們可以在實際應(yīng)用過程中靈活地借鑒參考來設(shè)計自己的算法。 . 論文結(jié)構(gòu) 本文第二 章 主要介紹 MBT 測試 技術(shù)，依照 MBT 測試的一般流程來說明工具使用的模型表現(xiàn)形式、測試用例生成算法和預(yù)期輸出的生成。認識到這些 MBT 的不足之處，我們才能更加正確地利用 MBT。其它形式的軟件測試一般無法發(fā)現(xiàn)此類錯誤，但是 MBT 可以。 IBM公司和 BMW 公司的研究表明， MBT 發(fā)現(xiàn)的錯誤和手工設(shè)計的測試集發(fā)現(xiàn)的錯誤數(shù)量差不多。測試用例能夠被 快速和反復(fù)地執(zhí)行，方便地使得發(fā)現(xiàn)的軟件錯誤重現(xiàn)。如果一味地追求缺陷數(shù)量，很可能得不償失。 因此，如何保證軟件的質(zhì)量顯得尤為關(guān)鍵。其后 介紹 Nucleus Plus，給出進程通信、進程同步在菜單系統(tǒng)中支持藍牙模塊的應(yīng)用方法。本方案的實現(xiàn)提供了一套層次化、結(jié)構(gòu)化、可擴展的電子相框菜單系統(tǒng)，并有效支持 了 藍牙模塊的應(yīng)用。 軟件測試能夠 有效地幫助軟件開發(fā)人員找出系統(tǒng)中存在的錯誤，從而在很大程度上保證軟件的質(zhì)量。常用的判斷標準有：代碼覆蓋率、測試用例通過率、缺陷數(shù)量收斂率等等。當測試本身就需要多次重復(fù)時（比如回歸測試、壓力測試），其優(yōu)點將更加顯著。而微軟公司的某一應(yīng)用中， MBT 發(fā)現(xiàn)了多 10 倍的錯誤 [14]。我們知道，軟件開發(fā)中的錯誤越早發(fā)現(xiàn)需要付出的修復(fù)代價越小， MBT 把一些錯誤扼殺在需求階段，貢獻無疑是巨大的。 目前代表性的支持 MBT 的測試工具有： IBM 公司的 GOTCHATCBeans 軟件測試套件，面向 Java、 C/C++語言編寫的應(yīng)用 程序接口（ API, Application Program Interfaces）和軟件協(xié)議 [7]；微軟公司的 Spec Explorer 工具，具有創(chuàng)建軟件行為模型、可視化分析模型、驗證模型有效性和根據(jù)模型生成測試用例等功能 [8]；“凈室”公司的 CleanTest，主要用于凈室軟件工程中使用的統(tǒng)計測試過程 [9]。第三章介紹系統(tǒng)的總體架構(gòu)和簡要闡述系統(tǒng)各模塊的功能。至于產(chǎn)生其它輔助性內(nèi)容的工具，它在不同項目之間不具有可移植性，只有根據(jù)不同項目來專門設(shè)計實現(xiàn)。通常是以節(jié)點和弧線的形式出現(xiàn)，節(jié)點代表系統(tǒng)的狀態(tài)，弧線代表系統(tǒng)的動作或操作。我們也并不需要描述系統(tǒng)行為隨著時間變化的變化情況， RBAC 測試中不涉及分布式并發(fā)操作，側(cè)重關(guān)心系統(tǒng)控制流而不是數(shù)據(jù)流，可見基本的 FSM 模型就已經(jīng)滿足相關(guān)要求。當需要為程序的特定執(zhí)行路徑尋找輸入時，沿著路徑使用符號執(zhí)行的方法，結(jié)合途中遇到的一些分支斷言，我們可以求出預(yù)期輸入所需要滿足的約束。類似 于描述程序所有可執(zhí)行路徑的控制流 和描述程序所有變量定義和內(nèi)存使用的數(shù)據(jù)流，事件流模型描述的是 GUI 上所有可執(zhí)行的事件序列?？梢酝ㄟ^指定初始遍歷節(jié)點和限定路徑長度的方法來減少生成測試用例的數(shù)量，但是更好的是下面介紹的組合測試。該理論是基于以下事實的，軟件中的錯誤大部分都是由單個參數(shù)所導(dǎo)致的，一般最多是由兩個參數(shù)相互作用而觸發(fā)，三個或三個以上的情況幾乎沒有。使用 pairwise 技術(shù)后，總測試用例數(shù)目從原來的 MN下降到了約 M * N。2 圖 24 3way 覆蓋數(shù)組 圖 24 列出了對于具有 10 個變量、每個變量各有兩種取值的 3way 覆蓋數(shù)組。坍塌的缺陷在于，最終得到的覆蓋數(shù)組往往并不是最優(yōu)解，一般比最優(yōu)解要大。近年來流行的模擬自然界行為的智能優(yōu)化算法中，目前已經(jīng)應(yīng)用到組合測試中的主要有模擬退火、禁忌搜索、遺傳算法等等。同時給系統(tǒng)留好接口，利于以后換用新的 pairwise 生成算法，具體的算法設(shè)計將在第四章介紹。圖 25 展示了一個測試工具自動生成的測試用例，用戶需要實現(xiàn) token_1 和 token_2的具體邏輯，然后測試用例就能夠被真正執(zhí)行了。其中考慮到 token 的可復(fù)用性，用戶可以直接在工具上定義 token 順序執(zhí)行序列組成的函數(shù)過程，更復(fù)雜的函數(shù)過程則通過添加新的 token 實現(xiàn)。比如狀態(tài)名稱，轉(zhuǎn)換動作名稱，用戶所定義 token 的名稱和所需輸入輸出參數(shù)，函數(shù)過程的名稱和其中包含的 token 執(zhí)行序列等等。 0..10..*0..10..*0..10..*0..10..*0..10..10..10..*0..10..*1..11..10..10..*FSMstatesactionsstateMapactionMap: ListState: ListAction: Dictionarystring,State: Dictionarystring,Action++++++Initialize ()GenerateTours ()GetAction ()GetState ()LoadFromXML ()SaveToXML ()...: void: ListTour: Action: State: void: voidActionidfromtostubsheadtail: string: string: string: ListActionImpl: State: State+++++AddActionImpl ()RemoveActionImpl ()RemoveActionImplAt ()MoveUp ()GenDefaults ()...: void: void: void: void: voidActionImplnameinparasoutparas: string: ListParameter: ListParameter+++Apply ()GenDefaults ()GetCopy ()...: string: void: ActionImplParameternamedecriptionvar: string: string: Variable+ GetCopyWithoutVarValues ()...: ParameterVariablenameisVarvalues: string: boolean: Liststring IsVariable ()...: boolFunctionImpl action : Action++GenDefaults ()GetCopy ()...: void: ActionImplTokenImpl++GetDefaults ()GetCopy ()...: void: Actio