基于模型的自動化測試工具的實現(xiàn)

./基于模型的自動化測試工具的實現(xiàn)摘要基于模型的測試是本文首先介紹了Atmel-View框架以及菜單系統(tǒng)UI在其中所將扮演的角色、與各個功能模塊間的關(guān)系。其次講解了Atmel-View存映射窗口結(jié)合OSD應(yīng)用的UI設(shè)計思想,涉及了多圖層表現(xiàn)的想法,硬件OSD與偽OSD的比較使用。然后詳細(xì)闡述了基于Atmel-View的菜單系統(tǒng)方案和框架結(jié)構(gòu),針對最重要的MenuMode菜單構(gòu)建函數(shù)分析其數(shù)據(jù)抽象、界面繪制和事件響應(yīng)處理過程。其后介紹NucleusPlus,給出進(jìn)程通信、進(jìn)程同步在菜單系統(tǒng)中支持藍(lán)牙模塊的應(yīng)用方法。本方案的實現(xiàn)提供了一套層次化、結(jié)構(gòu)化、可擴(kuò)展的電子相框菜單系統(tǒng),并有效支持了藍(lán)牙模塊的應(yīng)用。關(guān)鍵詞：OSD,存映射窗口,菜單系統(tǒng),UIFULFILLUIOFDIGITALPHOTOFRAMEBASEDONATMEL-VIEWABSTRACTAtmelCorporation'sAtmel-ViewistheapplicationforboardAT76C120,ithasalreadyprovidedlowlevelrealizationfordigitalphotoframe,anditcouldbeanextendableandmaturesolution.BasedoncurrentfunctionsofAtmel-View,wewilldesignandfulfilltheMenuSystem.FirstlytheframeworkofAtmel-View,whichroleMenuSystemUIactsandhowitrelateswithotherfunctionmoduleswereintroducedinthispaper.ThentheconceptofSDRAM-MappingWindowwithOSD'susagewasproposed.ItreferredtotheideaofmultipleimagelayerinterfaceandthecomparisontheusageofhardwareOSDandPseudoOSD.ThenthedetailsofMenuSystem'sframeworkwereillustrated.Theprocessofdataabstraction,interfacedrawingandeventhandlingwereanalyzedforthemostimportantMenubuildingfunctionMenuMode.AfterthatNucleusPluswasintroducedandthemethodtouseprocesscommunication,processsynchronizationforsupportingBluetoothmoduleinMenuSystemwasgiven.TheUIsolutionprovidesalayered,structuralandextendableMenuSystemfordigitalphotoframe.AnditeffectivelysupportsBluetoothmodule.Keywords:OSD,SDRAM-MappingWindow,MenuSystem,UI目錄第一章緒論21.1.軟件測試簡介21.2.軟件測試工具發(fā)展現(xiàn)狀21.3.項目背景和論文結(jié)構(gòu)21.3.1.項目背景2.論文結(jié)構(gòu)2第二章基于模型的測試22.1.MBT一般操作流程22.2.MBT模型表現(xiàn)形式22.3.MBT測試用例生成22.4.MBT預(yù)期輸出生成2第三章系統(tǒng)架構(gòu)23.1.功能概述及流程23.2.系統(tǒng)架構(gòu)2第四章系統(tǒng)各功能實現(xiàn)2第五章實例分析：ATM系統(tǒng)2第六章結(jié)論及展望2參考文獻(xiàn)2.第一章緒論軟件測試簡介隨著電子信息化的飛速發(fā)展,計算機(jī)軟件已經(jīng)遍布于人類社會的各個角落,遠(yuǎn)至月球探測衛(wèi)星的發(fā)射系統(tǒng),近至個人攜帶的MP3音樂播放器。但是軟件帶來巨大便利的同時,軟件中的任何微小缺陷也可能帶來難以估量的損失。據(jù)美國國家標(biāo)準(zhǔn)技術(shù)研究院〔NIST20XX公布的一份研究報告顯示,軟件故障平均每年對美國經(jīng)濟(jì)造成的損失約為595億美元,占其國民生產(chǎn)總值的0.6%[1]。因此,如何保證軟件的質(zhì)量顯得尤為關(guān)鍵。軟件測試能夠有效地幫助軟件開發(fā)人員找出系統(tǒng)中存在的錯誤,從而在很大程度上保證軟件的質(zhì)量。現(xiàn)代軟件工程理論將軟件測試作為軟件開發(fā)過程的重要組成部分,軟件開發(fā)過程中有一半以上的資源都花費在軟件測試上。早期的軟件測試等同于程序調(diào)試,1957年CharlesBaker才正式將兩者區(qū)別開來,他認(rèn)為調(diào)試側(cè)重于保證程序運行,而測試側(cè)重于保證程序解決問題[2]。1979年Myers提出"測試是帶有發(fā)現(xiàn)錯誤意圖去執(zhí)行程序的過程"[3],越是發(fā)現(xiàn)了錯誤才說明測試過程的成功。1983年美國國家標(biāo)準(zhǔn)局〔NBS發(fā)表了評估軟件生命周期各階段的測試方法[4],同年美國電氣和電子工程師協(xié)會〔IEEE發(fā)布了八大軟件測試相關(guān)文檔的標(biāo)準(zhǔn)[5],人們開始利用這些評估標(biāo)準(zhǔn)來衡量測試軟件的質(zhì)量。1988年DavidGelperin等在書中寫道,"測試是為了證明軟件符合需求規(guī)約,發(fā)現(xiàn)缺陷和防止錯誤"[6]。時間測試階段-1956面向調(diào)試時期1957-1978面向論證時期1979-1982面向破壞時期1983-1987面向評估時期1988-面向防止時期表1-1測試的發(fā)展階段[6]測試不可能遍歷所有可能出現(xiàn)的情況,必須在適當(dāng)?shù)臅r候終止測試。如果一味地追求缺陷數(shù)量,很可能得不償失。常用的判斷標(biāo)準(zhǔn)有：代碼覆蓋率、測試用例通過率、缺陷數(shù)量收斂率等等。圖1-1缺陷數(shù)量收斂圖軟件測試工具發(fā)展現(xiàn)狀純手工地進(jìn)行軟件測試往往是費時費力的,而且測試人員容易因為疏忽產(chǎn)生失誤,測試準(zhǔn)確性無法得到足夠的保證。于是人們需要開發(fā)一些自動化工具來管理或者執(zhí)行測試過程,雖然編寫軟件測試工具需要引入額外的工作量,但是軟件測試工具能大大提高軟件測試的效率和質(zhì)量,并且市面上也已經(jīng)存在著許多現(xiàn)成的測試工具。名稱產(chǎn)商簡介WinRunnerMercuryInteractive支持自動錄制、檢測和回放用戶操作LoadRunnerMercuryInteractive模擬大量并發(fā)負(fù)載來預(yù)測系統(tǒng)性能TestDirectorMercuryInteractive基于Web的測試管理系統(tǒng)RobotIBM具有測試和管理的雙重功能xUnit\最流行的開源單元測試框架SilkTestBorland軟件功能測試工具WASMicrosoft強(qiáng)大的壓力測試工具JTestParasoft針對Java語言的自動化白盒測試工具JMeterApache100%用Java實現(xiàn)的功能和性能測試工具WebLoadRadViewWeb性能測試和分析工具表1-2常用軟件測試工具一般來說,自動化測試可以分為：基于代碼的測試和基于圖形化用戶界面的測試?；诖a的測試是指通過程序提供的公共接口,直接驗證各個類、庫和模塊在不同的輸入情況下返回結(jié)果的正確性與否,如xUnit系列框架。而基于圖形化用戶界面的測試則是通過模擬用戶動作行為〔比如鍵盤輸入、鼠標(biāo)點擊,產(chǎn)生某些事件來觀察和判斷程序響應(yīng)是否滿足預(yù)期,如WinRunner。絕大部分軟件測試工具并不能自動完成整個測試過程,測試人員依然需要事先編寫好測試腳本或測試用例,即一組測試輸入、執(zhí)行條件和預(yù)期結(jié)果。測試用例能夠被快速和反復(fù)地執(zhí)行,方便地使得發(fā)現(xiàn)的軟件錯誤重現(xiàn)。當(dāng)測試本身就需要多次重復(fù)時〔比如回歸測試、壓力測試,其優(yōu)點將更加顯著。基于模型的測試〔MBT,Model-BasedTesting是一種輕量級自動生成測試用例的方法,測試人員的關(guān)注點在于構(gòu)建一個能夠描述被測系統(tǒng)各方面數(shù)據(jù)和行為的形式化機(jī)器可讀模型。為了抽象出理想的模型可能需要花費一定的時間,但是模型構(gòu)建的工作可以在軟件開發(fā)生命周期的早期就開始,只要求被測系統(tǒng)的需求定義完成即可。而且往往在將非形式化的需求轉(zhuǎn)化為形式化的模型過程中,需求中的遺漏和不足部分將被發(fā)現(xiàn)。模型所帶來的回報也是巨大的,因為一旦模型被確立且其能夠準(zhǔn)確反映被測系統(tǒng)的真實需求,軟件測試工具就能夠分析模型自動得到測試用例。軟件測試的主要目的就是發(fā)現(xiàn)錯誤。事實證明,MBT確實具有很強(qiáng)的錯誤發(fā)現(xiàn)能力。IBM公司和BMW公司的研究表明,MBT發(fā)現(xiàn)的錯誤和手工設(shè)計的測試集發(fā)現(xiàn)的錯誤數(shù)量差不多。而微軟公司的某一應(yīng)用中,MBT發(fā)現(xiàn)了多10倍的錯誤[14]。其它的一些研究結(jié)果中〔如圖1-2,和人工測試相比MBT都是發(fā)現(xiàn)更多或者相同數(shù)量的錯誤。當(dāng)然MBT也不是萬能的,它發(fā)現(xiàn)錯誤的能力很大程度上依賴于建模和選擇測試用例選擇要求人員的水平。圖1-2各種測試方法整個測試過程的花費時間圖[14]MBT能否降低測試的花費和時間,取決于建立和維護(hù)模型加上生成測試用例花費的時間是否比其它方法設(shè)計和維護(hù)測試集所需要的時間少,通常情況下答案是肯定的。而且MBT可以提高測試效率,因為人工測試受限于測試人員的思維活躍程度,MBT使用的測試用例生成算法和啟發(fā)式用例選擇機(jī)制能夠快速生成大量測試用例,達(dá)到對模型更高的覆蓋率卻僅需要多花費少量運行測試用例生成程序的時間。如果SUT支持大規(guī)模地測試,MBT必然將發(fā)現(xiàn)更多的錯誤。有時侯測試用例沒有通過,并不是因為程序編寫的錯誤,而是因為系統(tǒng)需求定義存在錯誤。其它形式的軟件測試一般無法發(fā)現(xiàn)此類錯誤,但是MBT可以。我們知道,軟件開發(fā)中的錯誤越早發(fā)現(xiàn)需要付出的修復(fù)代價越小,MBT把一些錯誤扼殺在需求階段,貢獻(xiàn)無疑是巨大的。此外,MBT具有良好的應(yīng)付軟件需求變更的能力。傳統(tǒng)的測試方法很可能需要重新設(shè)計編寫所有測試用例,MBT只需要調(diào)整模型后再自動生成測試用例。凡事有利必有弊,好的模型可以讓測試過程一帆風(fēng)順,模型也給測試過程帶來了許多問題。實施MBT的測試人員需要具有比普通測試人員更強(qiáng)的系統(tǒng)抽象能力,因為SUT很可能并不容易建模。當(dāng)MBT的測試用例沒有通過時,測試人員無法斷定是SUT存在錯誤還是建模存在錯誤,增加了錯誤分析的代價。傳統(tǒng)的人工測試的測試用例都是依據(jù)系統(tǒng)需求定義的,MBT的測試用例生成算法難免產(chǎn)生一些無效冗余的測試用例,測試用例通過率不再是衡量軟件測試效率的有效標(biāo)準(zhǔn)。認(rèn)識到這些MBT的不足之處,我們才能更加正確地利用MBT。目前代表性的支持MBT的測試工具有：IBM公司的GOTCHA-TCBeans軟件測試套件,面向Java、C/C++語言編寫的應(yīng)用程序接口〔API,ApplicationProgramInterfaces和軟件協(xié)議[7]；微軟公司的SpecExplorer工具,具有創(chuàng)建軟件行為模型、可視化分析模型、驗證模型有效性和根據(jù)模型生成測試用例等功能[8]；"凈室"公司的CleanTest,主要用于凈室軟件工程中使用的統(tǒng)計測試過程[9]。此外,軍方也積極嘗試MBT技術(shù),比如美國海軍水面戰(zhàn)中心開發(fā)的SMERFS[10]和CASRE[11]。項目背景和論文結(jié)構(gòu)項目背景本課題來源于作者實習(xí)所在的微軟公司,旨在遵照基于模型的軟件測試?yán)碚撻_始實現(xiàn)一款自動化測試工具,該工具能夠支持有限狀態(tài)機(jī)模型的輸入,然后自動生成抽象測試用例。用戶填充實現(xiàn)完整的測試用例后,此工具能執(zhí)行測試用例并給出測試報告。該測試工具將被主要用于微軟公司SCCM系統(tǒng)的基于角色權(quán)限控制〔RBAC,Role-BasedAccessControl功能的測試。特別地,在測試用例生成過程中算法需要結(jié)合參數(shù)配對組合測試技術(shù),盡可能縮減測試用例數(shù)目卻又不影響測試質(zhì)量。因為與傳統(tǒng)的單純正交排列組合測試相比,配對組合測試技術(shù)具有較大的優(yōu)越性。論文結(jié)構(gòu)本文第二章主要介紹MBT測試技術(shù),依照MBT測試的一般流程來說明工具使用的模型表現(xiàn)形式、測試用例生成算法和預(yù)期輸出的生成。第三章介紹系統(tǒng)的總體架構(gòu)和簡要闡述系統(tǒng)各模塊的功能。第四章使用類圖和算法偽代碼詳細(xì)討論系統(tǒng)的設(shè)計和實現(xiàn)。第五章通過一個虛構(gòu)的自動取款機(jī)〔ATM,AutomaticTellerMachines系統(tǒng)來演示如何使用我們完成的工具進(jìn)行MBT測試。最后作簡要的總結(jié)及展望。第二章基于模型的測試MBT一般操作流程基于模型的測試依賴于三項關(guān)鍵技術(shù)：模型的表現(xiàn)形式、測試用例的生成算法和產(chǎn)生其它輔助性容〔包括預(yù)期結(jié)果的工具[12]。模型是MBT技術(shù)的核心,不同領(lǐng)域的不同軟件系統(tǒng)適用的模型表現(xiàn)形式都不盡相同,測試人員應(yīng)該結(jié)合被測系統(tǒng)的工作特點和自身對模型的熟悉程度來慎重選擇。如果沒有使用正確的模型表現(xiàn)形式,會拖累影響整個測試流程。針對各個不同的模型表現(xiàn)形式,如今已有許多測試用例算法與之對應(yīng),我們可以在實際應(yīng)用過程中靈活地借鑒參考來設(shè)計自己的算法。至于產(chǎn)生其它輔助性容的工具,它在不同項目之間不具有可移植性,只有根據(jù)不同項目來專門設(shè)計實現(xiàn)。圖2-1MBT一般操作流程[13]上圖展示了MBT的一般操作流程。首先在系統(tǒng)需求或者規(guī)約文檔的基礎(chǔ)上建立某種形式的模型〔步驟1,模型說明了系統(tǒng)所有的潛在行為意圖。接下來需要定義測試用例的選擇要求〔步驟2,形成測試用例規(guī)約〔步驟3,編寫算法將其應(yīng)用于模型之上來生成測試用例〔步驟4。然后在被測系統(tǒng)〔SUT,SystemUnderTest環(huán)境中真正執(zhí)行所有測試用例〔步驟5-1,可以利用測試腳本來自動化執(zhí)行測試,最終得到測試結(jié)果〔步驟5-2。MBT模型表現(xiàn)形式理想的模型需要容易被測試人員理解,能夠把大的復(fù)雜的問題描述成小的簡單的系統(tǒng),最好還是以一種測試用例生成工具方便識別的形式。想要同時滿足以上所有的特性是很困難的,但是可以把幾種不同的模型整合成一個,揚(yáng)長避短地得到理想模型。在MBT中使用過的模型可能有幾十甚至上百種,我們不可能也沒有必要去逐一了解,MarkUtting和BrunoLegeard把它們大致分為以下幾種[14]：類型示例基于Pre/PostB、OCL、JML、Spec#、Z基于轉(zhuǎn)換FSM、狀態(tài)圖、UML狀態(tài)機(jī)統(tǒng)計式馬爾可夫鏈基于歷史消息隊列圖、UML順序圖函數(shù)式HOL系統(tǒng)操作式Petri網(wǎng)數(shù)據(jù)流式Lustre、塊狀圖表2-1MBT模型分類基于轉(zhuǎn)換的模型是我們最為熟悉的模型類型,它們集中于描述系統(tǒng)在不同狀態(tài)之間的轉(zhuǎn)換過程。通常是以節(jié)點和弧線的形式出現(xiàn),節(jié)點代表系統(tǒng)的狀態(tài),弧線代表系統(tǒng)的動作或操作。有限狀態(tài)機(jī)〔FSM,FiniteStateMachine模型可以被認(rèn)為是該類模型的鼻祖,是極其重要的一種模型表現(xiàn)形式。圖2-2是一個描述了門的四種不同狀態(tài)及其轉(zhuǎn)換關(guān)系的FSM。Harel在FSM的基礎(chǔ)上添加了層次、并發(fā)和交流概念,擴(kuò)展成了狀態(tài)圖模型[15],從而在面對復(fù)雜系統(tǒng)時也能夠輕松建立模型。之后又有人刪去了Harel的狀態(tài)圖模型中的部分特性,同時增加了一些新的特性,形成了統(tǒng)模語言〔UML,UnifiedModelingLanguage狀態(tài)機(jī)模型。UML狀態(tài)機(jī)模型用于定義類之間狀態(tài)相關(guān)的行為,包括方法調(diào)用和數(shù)據(jù)域的修改。圖2-2FSM示例我們工具主要面向的是RBAC功能的測試,頻繁關(guān)心具有不同權(quán)限的不同角色所能執(zhí)行的操作。把系統(tǒng)抽象為變量集合和修改這些變量操作的基于Pre/Post的模型需要測試人員預(yù)先學(xué)習(xí)一段時間才能完全掌握,所以基本不予考慮。我們也并不需要描述系統(tǒng)行為隨著時間變化的變化情況,RBAC測試中不涉及分布式并發(fā)操作,側(cè)重關(guān)心系統(tǒng)控制流而不是數(shù)據(jù)流,可見基本的FSM模型就已經(jīng)滿足相關(guān)要求。而且FMS模型也最為簡便,測試工具識別起來沒有任何問題,降低了編寫測試工具的難度,測試人員構(gòu)建模型時可以從SUT設(shè)計文檔中的UML狀態(tài)圖稍加變化直接轉(zhuǎn)化而來。如果以后需要額外考慮系統(tǒng)事件和測試輸入的概率分布,只需要為每個狀態(tài)之間的遷移動作增加概率相關(guān)屬性,非常輕松地支持統(tǒng)計式模型。MBT測試用例生成軟件測試過程中的執(zhí)行和監(jiān)督過程已經(jīng)可以使用現(xiàn)代化的自動測試工具代替完成,至于如何生成測試用例,依然是一件棘手的事情。MBT中使用的測試用例生成方法主要依賴于所使用的模型表現(xiàn)形式,針對不同的模型表現(xiàn)形式,研究者分別想出了一些解決方案。如果系統(tǒng)的模型是由一系列邏輯表達(dá)式所組成的,那么可以使用定理證明的方法。定理證明方法原先是被用于自動證明數(shù)學(xué)公式,MBT生成測試用例時根據(jù)邏輯表達(dá)式的有效說明把模型劃分為不同等價類,每個等價類描述了SUT的某一行為。這些等價類就可以用于生成測試用例,最簡單的劃分方法是析取式的方法。當(dāng)需要為程序的特定執(zhí)行路徑尋找輸入時,沿著路徑使用符號執(zhí)行的方法,結(jié)合途中遇到的一些分支斷言,我們可以求出預(yù)期輸入所需要滿足的約束。于是可以用各種約束來建立MBT的模型,收集不同執(zhí)行路徑中數(shù)據(jù)約束再利用約束編程中的方法求解得到測試用例。其中約束編程是一種通過約束來描述變量間關(guān)系的編程方法,求解約束的方法有布爾式求解方法和數(shù)值分析方法。MBT自然還會讓人想到模型檢測,即檢測模型是否滿足特定的屬性。無論檢測結(jié)果是滿足屬性還是違背屬性,都可以形成測試用例。但是一般來說反例的作用更大,因為測試用例中的各種斷言正是通過反例來生成的,從而有效地識別出系統(tǒng)是否正常工作。模型檢測會遇到的問題是,生成的用例中存在過多冗余用例,導(dǎo)致軟件測試執(zhí)行的代價增加。為此,Hamon等人詳細(xì)討論提出了高效模型檢測的方法[16]。類似于描述程序所有可執(zhí)行路徑的控制流和描述程序所有變量定義和存使用的數(shù)據(jù)流,事件流模型描述的是GUI上所有可執(zhí)行的事件序列。通常情況下,GUI又可以分為不同的層次結(jié)構(gòu),比如整個GUI系統(tǒng)是由各種對話框所組成的,那么系統(tǒng)的事件流圖就是由對話框各自的事件流圖組成的。把復(fù)雜系統(tǒng)拆分為相對獨立的組件單獨分析,也是所有MBT測試用例生成方法通用的竅門。馬爾可夫鏈也是MBT中生成測試用例的重要方法之一,它由兩大部件組成：代表系統(tǒng)所有使用場景的FSM和評價FSM來說明系統(tǒng)統(tǒng)計性使用信息的操作說明。馬爾可夫鏈模型為MBT提供了測試的側(cè)重點,即著重測試那些用戶經(jīng)常使用的功能。因為對于系統(tǒng)中那些極少概率出現(xiàn)的錯誤,是幾乎不可能被發(fā)現(xiàn)的。我們選用的是FSM模型,所以可以利用圖論中的一些遍歷方法,比如廣度優(yōu)先遍歷算法或者深度優(yōu)先遍歷算法,每找到的一條可執(zhí)行路徑對應(yīng)于一個測試用例。當(dāng)FSM包含的狀態(tài)比較多時,遍歷組成FSM有向圖產(chǎn)生的測試用例數(shù)量可能太多,不僅難以測試包含冗余測試用例。可以通過指定初始遍歷節(jié)點和限定路徑長度的方法來減少生成測試用例的數(shù)量,但是更好的是下面介紹的組合測試。軟件開發(fā)者和用戶經(jīng)常還會遇到這樣的問題,把同樣的軟件應(yīng)用從一臺機(jī)器換到另外一臺機(jī)器上使用時,原先從未出過故障的軟件突然變得無常使用。問題有許多可能的影響因素,比如跟軟件安裝所在機(jī)器的操作系統(tǒng)類型有關(guān),或者是系統(tǒng)物理存的大小,甚至網(wǎng)卡型號等等。除了硬件環(huán)境的不同,軟件接受的輸入?yún)?shù)也很可能不同,比如同一款Web應(yīng)用發(fā)布后,不同國家的用戶將會輸入不同編碼的容。軟件能否經(jīng)得住各種條件下的考驗,是軟件測試需要解決的問題。當(dāng)然,最簡單和理想的情況下是把所有可能出現(xiàn)的硬件配置和參數(shù)取值都測試一遍。但是現(xiàn)實并不允許測試人員這么做,因為造成的測試用例數(shù)量是指數(shù)性爆炸增長的,N個分別有M種取值的影響因素將需要MN個測試用例來完成測試。后來人們發(fā)現(xiàn)通過巧妙地選取測試用例,只要求某些參數(shù)的組合情況被包含,能夠在保證測試效率的同時大大縮減測試用例數(shù)量。該理論是基于以下事實的,軟件中的錯誤大部分都是由單個參數(shù)所導(dǎo)致的,一般最多是由兩個參數(shù)相互作用而觸發(fā),三個或三個以上的情況幾乎沒有。如果測試用例集包含了任意t個參數(shù)的所有取值組合,那么稱該測試用例集組合強(qiáng)度為t,或者說它是t-way的。圖2-3不同組合強(qiáng)度下的錯誤發(fā)現(xiàn)率圖2-3是NIST報告中總結(jié)的幾個應(yīng)用使用不同組合強(qiáng)度的測試用例集測試后的錯誤發(fā)現(xiàn)率曲線[17]。我們可以看出,隨著組合強(qiáng)度的增加,錯誤發(fā)現(xiàn)率顯著增長。以NASA應(yīng)用為例,67%的錯誤由單個參數(shù)觸發(fā),93%由兩個參數(shù)相互作用后觸發(fā),98%由三個參數(shù)一起造成。其它應(yīng)用的錯誤發(fā)現(xiàn)率曲線也都比較相像,組合強(qiáng)度等于4到6時錯誤發(fā)現(xiàn)率都達(dá)到了將近100%。特別的,生成2-way的測試用例集的方法被稱為pair-wise〔或all-pairs測試方法。目前pair-wise是使用最普遍的組合測試技術(shù),因為軟件中的絕大部分錯誤都只由一個或兩個參數(shù)造成,pair-wise生成的測試用例能夠覆蓋足夠的錯誤空間。使用pair-wise技術(shù)后,總測試用例數(shù)目從原來的MN下降到了約M*N。至于生成高組合強(qiáng)度的測試用例,測試用例集發(fā)現(xiàn)錯誤的能力沒有實質(zhì)上的提高,卻會導(dǎo)致生成算法的更加復(fù)雜化和產(chǎn)生多得多的測試用例。最壞的情況下,當(dāng)組合強(qiáng)度和參數(shù)的數(shù)目相等時,組合測試退化為枚舉測試。組合測試的最早提出,也就是為了簡化軟件在各種配置環(huán)境下的測試。因為牽涉到硬件環(huán)境的搭建,配置參數(shù)測試中每增加一種測試情況比單純地多寫一個測試用例所花的代價大得多。人們迫切需要解決這一問題,使得配置參數(shù)測試成為了組合測試中最為發(fā)達(dá)的形式,尤其在那些要求適應(yīng)不同硬件平臺和環(huán)境的軟件的測試過程中。考慮一款受5個配置因素影響的應(yīng)用：操作系統(tǒng)〔WindowsXP、AppleOSX、RedHatEnterpriseLinux,瀏覽器〔IE、FireFox,網(wǎng)絡(luò)協(xié)議〔IPv4、IPv6,處理器平臺〔Intel、AMD和數(shù)據(jù)庫〔MySQL、Sybase、Oracle,一共3·2·2·2·3=72種硬件平臺。pair-wise測試只需要設(shè)計如下10個測試,就覆蓋了每一種影響因素和另外一種影響因素的所有組合。編號操作系統(tǒng)瀏覽器網(wǎng)絡(luò)協(xié)議處理器平臺數(shù)據(jù)庫1XPIEIPv4IntelMySQL2XPFireFoxIPv6AMDSybase3XPIEIPv6IntelOracle4OSXFireFoxIPv4AMDMySQL5OSXIEIPv4IntelSybase6OSXFireFoxIPv4IntelOracle7RHELIEIPv6AMDMySQL8RHELFireFoxIPv4IntelSybase9RHELFireFoxIPv4AMDOracle10OSXFireFoxIPv6AMDOracle表2-2pair-wise測試的配置即使被測軟件沒有配置選項,軟件仍要處理一些輸入。例如,Word2010應(yīng)用程序至少允許用戶對拖黑文字進(jìn)行10種不同操作：設(shè)為上標(biāo)、設(shè)為下標(biāo)、加粗、加下劃線、設(shè)為斜體、加刪除線、加灰色背景、加陰影效果、加倒影效果、加熒光效果。相關(guān)的字體處理函數(shù)需要根據(jù)用戶的輸入來相應(yīng)修改文字效果,該函數(shù)需要在所有的可能情況下都正常工作,而一共有210=1024種可能。前面的經(jīng)驗告訴我們,3-way的測試用例就能夠達(dá)到90%以上的錯誤發(fā)現(xiàn)率,具有較高的收益-代價比。圖2-43-way覆蓋數(shù)組圖2-4列出了對于具有10個變量、每個變量各有兩種取值的3-way覆蓋數(shù)組。覆蓋數(shù)組并不唯一,這只是其中一種情況。t-way覆蓋數(shù)組的特點是,任意t個參數(shù)的所有排列組合都將分別出現(xiàn)在覆蓋數(shù)組的某一行中,比如上圖中的ABC、DEG、HIJ,三個參數(shù)共有8種排列組合〔000、001、010、011、100、101、110、111都被覆蓋數(shù)組所覆蓋。覆蓋數(shù)組的每一行對應(yīng)一個測試用例,相比之前的1024個測試用例,組合測試只需要13個測試用例。組合測試用例生成的本質(zhì)是構(gòu)造覆蓋數(shù)組,最早的構(gòu)造方法是利用正交數(shù)組,其定義和覆蓋數(shù)組類似,唯一區(qū)別在于正交數(shù)組中所有t元組出現(xiàn)的次數(shù)相同,而覆蓋數(shù)組不保證這一點。在某些特殊的情況下,正交數(shù)組就是最優(yōu)的覆蓋數(shù)組,為此,如何構(gòu)造正交數(shù)組問題吸引了大量的研究者研究。Sloane在其上總結(jié)記錄了超過200個正交數(shù)組[18]。利用計算機(jī)也可以自動求解出部分類型的正交數(shù)組,由已知的大覆蓋數(shù)組構(gòu)造小覆蓋數(shù)組的方法被稱為坍塌[19]。坍塌的缺陷在于,最終得到的覆蓋數(shù)組往往并不是最優(yōu)解,一般比最優(yōu)解要大。另一種構(gòu)造方法剛好相反,是由已知的小覆蓋數(shù)組遞歸構(gòu)造出大覆蓋數(shù)組。構(gòu)造最優(yōu)覆蓋數(shù)組的實際上是一個NP完全問題[20],我們知道,NP完全問題是一系列可以互相轉(zhuǎn)化的問題。于是我們可以利用和借鑒其它NP完全問題的研究成果來構(gòu)造覆蓋數(shù)組,比如第一個被證明為NP完全問題的可滿足性問題,整數(shù)規(guī)劃問題,圖論問題等等。數(shù)學(xué)構(gòu)造方法僅限于某些特定大小或者組合強(qiáng)度的覆蓋數(shù)組的構(gòu)造,不具有通用性。NP完全問題則是困擾了人類多年的超級難題,目前還沒有突破性解法,所以轉(zhuǎn)化為其它問題也是小異。但我們可以利用局部搜索方法,比如啟發(fā)式搜索算法,在較短的時間就可以搜索出近似最優(yōu)解。啟發(fā)式搜索算法是利用一個已有的數(shù)組,通過合適的變換得到一個更優(yōu)的覆蓋矩陣,不斷地變換直到得到一個較優(yōu)的矩陣。近年來流行的模擬自然界行為的智能優(yōu)化算法中,目前已經(jīng)應(yīng)用到組合測試中的主要有模擬退火、禁忌搜索、遺傳算法等等。更為有效的方法是貪心算法,貪心算法的思想是從空矩陣開始,然后逐行或者逐列地擴(kuò)展矩陣,直到所有的t元組都被覆蓋。按照擴(kuò)展方式的不同,又可以分為一維擴(kuò)展和二維擴(kuò)展。商業(yè)工具AETG最先提出一維擴(kuò)展的方法[21],依次增加一行,每次盡可能多地覆蓋未覆蓋的t元組。微軟開發(fā)的工具PICT采用類似AETG的方法生成測試用例[22],不同之處在于,PICT每次產(chǎn)生的結(jié)果是相同的。Lei等人提出的IPO〔In-parameter-order[23]方法屬于二維擴(kuò)展,該算法主要針對pair-wise測試。首先構(gòu)造前兩個參數(shù)的所有組合,形成一個小的矩陣,再分別為矩陣添加一列和必要多的行,覆蓋完所有元組后結(jié)束。我們將模仿PICT工具中pair-wise算法的主要思想,使用一維擴(kuò)展的貪心算法來生成覆蓋數(shù)組。同時給系統(tǒng)留好接口,利于以后換用新的pair-wise生成算法,具體的算法設(shè)計將在第四章介紹。MBT預(yù)期輸出生成三大關(guān)鍵技術(shù)就只剩下輔助性容生成工具了,輔助性工具主要還是為了解決預(yù)期輸出的生成問題。前面我們構(gòu)造了系統(tǒng)的模型,模型描述了系統(tǒng)的狀態(tài)和狀態(tài)之間的動作,這些動作都是由一個個函數(shù)和方法的調(diào)用序列組成的。SUT提供的API往往不能和測試用例的要求完全契合,為了讓測試用例能夠順利地在SUT上執(zhí)行,需要測試人員在SUT之上再包裝一層,即圖2-1中的適配器層。嚴(yán)格地說,我們編寫的工具只負(fù)責(zé)生成基本的測試用例框架,或者稱為抽象的測試用例。測試用例中相當(dāng)于使用了打樁的設(shè)計模式,樁的實際實現(xiàn)由最終的測試人員補(bǔ)充完成,樁的實現(xiàn)包括對SUT提供的API的封裝組合和測試判斷邏輯的編寫。我們把這些樁叫做token,token對應(yīng)于適配器層中的某個函數(shù)和方法,兩者可以直接一一對應(yīng),也可以先序列化為可擴(kuò)展標(biāo)記語言〔XML,ExtensibleMarkupLanguage文件再利用XML解析器之類的工具生成測試用例。這樣MBT的整個測試工具都變得項目之間可移植了,如果某一測試條件和預(yù)期結(jié)果不同則在token中拋出異常,拋出的異常隨后被測試工具捕獲,最終判定該測試用例不通過。圖2-5展示了一個測試工具自動生成的測試用例,用戶需要實現(xiàn)token_1和token_2的具體邏輯,然后測試用例就能夠被真正執(zhí)行了。token_1和token_2執(zhí)行過程中如果發(fā)現(xiàn)錯誤會觸發(fā)異常,程序打印出錯誤提示,同時導(dǎo)致測試用例的總錯誤個數(shù)加一。反之,一切正常并給出通過提示。圖2-5測試用例示例另外我們也可以利用pair-wise來完成部分情況下預(yù)期輸出的生成。對于相同輸出結(jié)果的某些參數(shù)取值組合,把輸出結(jié)果也當(dāng)作pair-wise算法輸入?yún)?shù)的一項,輸出結(jié)果列和其它輸入?yún)?shù)的區(qū)別在于其取值唯一。PICT工具還支持混合組合強(qiáng)度的測試用例生成,以及輸入各種約束,比如指定某些參數(shù)的組合形式必須出現(xiàn)或者不出現(xiàn),所以具有較強(qiáng)的預(yù)期輸出生成能力。不過如果預(yù)期輸出涉及復(fù)雜的判斷邏輯,還是使用委托給token來處理的方法較好。第三章系統(tǒng)架構(gòu)功能概述及流程課題要求完成的基于模型的自動化測試工具的功能包括：支持輸入FSM模型、支持添加token、支持pair-wise組合測試、支持生成測試用例框架、支持序列化FSM模型到文件和反序列化讀入。其中考慮到token的可復(fù)用性,用戶可以直接在工具上定義token順序執(zhí)行序列組成的函數(shù)過程,更復(fù)雜的函數(shù)過程則通過添加新的token實現(xiàn)。用戶使用該工具生成測試用例的流程如下：圖3-1生成測試用例流程用戶可以直接繪制FSM模型,或者在以前保存的模型基礎(chǔ)上修改模型,工具支持FSM模型的序列化與反序列化。繪制FSM模型時首先需要定義一些FSM的狀態(tài)轉(zhuǎn)換動作中用到的token和這些token組成的若干函數(shù)過程,隨后在模型繪制面板中畫出FSM模型相應(yīng)的有向圖。FSM模型的有向圖包括代表不同狀態(tài)的圓形節(jié)點,以及代表狀態(tài)間轉(zhuǎn)換動作的弧線。一個token或函數(shù)過程可以在相同的或者不同的狀態(tài)轉(zhuǎn)換動作中被反復(fù)使用,只要求這些token或函數(shù)過程方法頭中所定義的參數(shù)被正確地賦予某個常量或者變量。變量可以有多個允許的取值,用戶在pair-wise相關(guān)面板輸入各個變量的可能取值,接下來工具將分析FSM模型尋找所以可執(zhí)行路徑,同時結(jié)合路徑長度限制和pair-wise技術(shù)來生成測試用例。最后用戶還可以在生成的測試用例中再人工選擇部分測試用例出來,保存為最終需要被執(zhí)行的測試用例。系統(tǒng)架構(gòu)工具設(shè)計的主要目的是為了自動生成測試用例,而模型是驅(qū)動MBT各測試過程的根本,所以系統(tǒng)架構(gòu)中最核心的部分是FSM的數(shù)據(jù)模型,數(shù)據(jù)模型描述了FSM中各個狀態(tài)和轉(zhuǎn)換動作的詳細(xì)屬性。比如狀態(tài)名稱,轉(zhuǎn)換動作名稱,用戶所定義token的名稱和所需輸入輸出參數(shù),函數(shù)過程的名稱和其中包含的token執(zhí)行序列等等。圖3-2系統(tǒng)總體架構(gòu)用戶不是生硬地使用形式化語言來描述FSM數(shù)據(jù)模型,工具提供了可視化界面,實現(xiàn)了鼠標(biāo)選取不同繪圖元素再拖拽調(diào)整的繪圖方式。此外,為了持久化保存繪制好的FSM模型,系統(tǒng)包含了序列化模塊,用于模型的序列化與反序列化。測試用例的生成過程是基于兩大模塊來完成的,FSM模型遍歷模塊負(fù)責(zé)生成各種可執(zhí)行路徑,pair-wise測試模塊負(fù)責(zé)生成參數(shù)變量取值的不同組合。最后把參數(shù)變量取值代入可執(zhí)行路徑中,即得到測試用例。第四章系統(tǒng)各功能實現(xiàn)前一章中我們介紹了系統(tǒng)的整體架構(gòu),下面將逐一介紹系統(tǒng)各模塊的具體實現(xiàn),整個系統(tǒng)都使用C#語言編寫完成。FSM數(shù)據(jù)模型實現(xiàn)我們知道FSM數(shù)據(jù)模型是影響系統(tǒng)的關(guān)鍵,圖4-1列出了系統(tǒng)實際實現(xiàn)過程中FSM數(shù)據(jù)模型相關(guān)各類之間的關(guān)系。對于一些簡單的set和get方法圖中并沒有標(biāo)出,其它輔助性的方法也予于省略。圖4-1FSM數(shù)據(jù)模型的類圖類FSM中記錄著系統(tǒng)FSM數(shù)據(jù)模型的所有信息,它里面有兩個鏈表分別記錄FSM的狀態(tài)實例和轉(zhuǎn)換動作實例,同時有兩個Dictionary分別記錄狀態(tài)和轉(zhuǎn)換動作的名稱與實例之間的映射關(guān)系。狀態(tài)由類State描述,該類的屬性有狀態(tài)標(biāo)識id、狀態(tài)類型type和狀態(tài)后置動作鏈表nextActions。我們定義了三種狀態(tài)類型：Entry、Free和Exit,Entry和Exit分別代表初始狀態(tài)和終止?fàn)顟B(tài),Free代表其他自由狀態(tài)。狀態(tài)動作由類Action描述,該類的屬性有動作標(biāo)識id、出發(fā)狀態(tài)名稱from、目的狀態(tài)名稱to以及動作的方法實現(xiàn)鏈表stubs。在尋找可執(zhí)行的測試路徑過程中,程序從初始狀態(tài)開始深度遍歷FSM有向圖,直到到達(dá)某個終止?fàn)顟B(tài)或路徑長度達(dá)到限制才結(jié)束。類Tour的每個實例代表一條被發(fā)現(xiàn)的可執(zhí)行路徑,因為用戶并不參與Tour的命名,所以該類中設(shè)置了一個全局靜態(tài)的標(biāo)識計數(shù)器域idCounter,每新創(chuàng)建一個新實例時計數(shù)器自動加一,必要的時候可以通過ResetIdCounter方法重置計數(shù)器。除了以上代表FSM實體組成部分的類,FSM數(shù)據(jù)模型還必須描述SUT相關(guān)部分的信息。抽象類ActionImpl描述了測試中調(diào)用的SUT接口,準(zhǔn)確地說是測試適配器層中的接口,它的兩個抽象方法GenDefault和GetCopy分別用于初始化和返回克隆實例。類TokenImpl和類FunctionImpl繼承了類ActionImpl,其中類TokenImpl表示的是用戶定義的基本token,而類FunctionImpl表示的這些token順序序列組成的函數(shù)過程。考慮到函數(shù)過程和轉(zhuǎn)換動作的相似性,類FunctionImpl中直接包含了一個類Action的實例。最后,注意一下參數(shù)和變量的區(qū)別：參數(shù)指的是函數(shù)方法頭中定義的輸入,而變量是在實際調(diào)用函數(shù)方法時對參數(shù)的賦值。我們使用類Parameter來表示參數(shù),而用類Variable來表示對參數(shù)的賦值,包括常量和變量。類Variable中包含一個根據(jù)其標(biāo)識名稱name來判斷的方法IsVariable?？梢暬托蛄谢瘜崿F(xiàn)系統(tǒng)的用戶界面部分是利用WinForm技術(shù)實現(xiàn)的。雖然WinForm技術(shù)中已經(jīng)提供了許多可以直接使用的組件,但是距離我們的要求還是有一定差距,所以我們自己設(shè)計實現(xiàn)了新的組件來完成FSM模型的可視化。圖4-2FSM模型可視化模塊的類圖接口IRenderable定義了新組件通用的屬性和方法,包括組件的位置信息、繪制組件過程中觸發(fā)不同事件的響應(yīng)函數(shù)〔Paint、PrePaint、PostPaint和PaintFocus,方法IsSelected則用于判斷該組件是否被鼠標(biāo)選中。類StateR和TourR直接實現(xiàn)了接口IRenderable,但是類ActionR和類FunctionR實現(xiàn)的則是接口IRenderable的擴(kuò)展接口IActionRenderable,該接口添加了一個保存轉(zhuǎn)換動作信息的域。這些類對應(yīng)于FSM數(shù)據(jù)模型中的類,繪圖的實際過程由C#語言提供的系統(tǒng)類System.Drawing.Graphics完成,涉及到的API[24]參見表4-1。方法名稱作用DrawCurve繪制經(jīng)過一組指定的Point結(jié)構(gòu)的曲線DrawLine繪制一條連接由坐標(biāo)對指定的兩個點的線條DrawPolygon繪制由一組Point結(jié)構(gòu)定義的多邊形DrawString在指定位置并由指定的Brush和Font對象繪制指定的文本字符串FillEllipse填充邊框所定義橢圓的部,該邊框由一對坐標(biāo)、一個寬度和一個高度指定表4-1類Graphics部分方法圖4-3展示了這幾個類的繪圖效果,類StateR繪制紫色的圓圈代表狀態(tài)節(jié)點,類ActionR則繪制了兩種代表轉(zhuǎn)換動作的深綠色弧線。如果出發(fā)狀態(tài)和目的狀態(tài)相同,那么將繪制如action_0的弧線；如果出發(fā)狀態(tài)和目的狀態(tài)不同,則按照事先設(shè)計的弧度在兩個狀態(tài)節(jié)點之間繪制如action_1的弧線,另外增加一個三角形標(biāo)志表明方向。類FunctionR以灰色粗線加圓點的形式繪制用戶自定義函數(shù)過程的標(biāo)記,默認(rèn)排列在FSM繪制區(qū)域的左上角。類TourR把用戶選中的可執(zhí)行路徑用黃色重描一遍。圖4-3自定義UI組件示例C#語言提供了方便的標(biāo)記功能來支持對象的序列化與反序列化〔圖4-4。首先把準(zhǔn)備序列化的對象標(biāo)記為Serializable,然后根據(jù)不同的需要和屬性特點把公共屬性都標(biāo)記為XmlAttribute、XmlArray或XmlIgnore,公共屬性中的自定義類型也需要在定義文件中添加相應(yīng)的標(biāo)記。每個希望被序列化的公共屬性必須提供set和get方法,否則該屬性無法被正確序列化到XML文件中。XmlAttribute表示把該屬性作為對象XML根節(jié)點的一個屬性；XmlArray表示該屬性是數(shù)組類型的,整個屬性將被添加為根節(jié)點的一個子節(jié)點,另外每個數(shù)組元素又會被序列化為該子節(jié)點的一個子節(jié)點；XmlIgnore則表示忽略此屬性,該屬性不參與對象的序列化過程。系統(tǒng)類.XmlSerializer使得編程人員能夠控制如何將對象編碼到XML文件中,并且支持從XML文件中重新創(chuàng)建原始狀態(tài)的對象。接下來FSM模型的序列化與反序列化工作只要通過調(diào)用類XmlSerializer的兩個簡單方法就可以了。方法Serialize負(fù)責(zé)把對象的某個實例序列化到某個輸出流中,方法DeSerialize則負(fù)責(zé)從某個輸入流中反序列化出原始狀態(tài)的對象。圖4-4XML序列化與反序列化示例代碼模型遍歷算法實現(xiàn)顯然測試的基本要求之一應(yīng)該是至少把FSM模型中的每個狀態(tài)和每個轉(zhuǎn)換動作都執(zhí)行一遍,不過這樣并不能很好地覆蓋被測代碼,而且許多重要的測試場景都會被遺漏。最為全面地測試FSM模型的方法是找出其有向圖中的所有可執(zhí)行路徑,然后把它們都轉(zhuǎn)換為測試用例去執(zhí)行。但是這樣遍歷出來的測試用例數(shù)目又往往過于龐大,其中很大一部分還是冗余性測試用例。折衷的辦法是通過路徑長度來限制測試用例的產(chǎn)生,同時用戶構(gòu)建FSM模型時有意識地把復(fù)雜系統(tǒng)拆分為幾個子系統(tǒng)來單獨進(jìn)行測試,繪制FSM模型時也可以分別指定不同的初始狀態(tài)來尋找路徑。對于工具生成的測試用例集,用戶還可以在條件允許的情況下篩選出與SUT使用場景緊密相關(guān)的部分測試用例,形成最終的測試用例集。圖4-5模型遍歷算法核心代碼模型遍歷算法的本質(zhì)是圖論中的廣度優(yōu)先搜索〔BFS,Breadth-FirstSearch算法,圖4-5給出了算法的核心代碼。算法初始時中間結(jié)果鏈表tours中只有一項包含初始狀態(tài)entry的路徑,以后每次迭代都檢查tours里的每個出口狀態(tài)的下一轉(zhuǎn)換動作,試圖增長一個單位的路徑長度。為了不讓搜索得到的路徑包含太多重復(fù)回路,如果新擴(kuò)展的動作已經(jīng)被原路徑多次包含,該路徑及其擴(kuò)展路徑都將被拋棄。此外,路徑的末狀態(tài)必須為出口狀態(tài),并且沒有后續(xù)動作或者指向其自身,路徑還必須滿足設(shè)定的長度要求。pair-wise測試實現(xiàn)此部分的實現(xiàn)主要模仿微軟PICT工具[22],運用一維擴(kuò)展的貪心算法策略逐步得到覆蓋矩陣。算法分為兩個階段：準(zhǔn)備階段和生成階段。圖4-6參數(shù)組合示例[22]準(zhǔn)備階段將計算出生成階段所要用到的各種信息,包括需要被覆蓋的不同參數(shù)取值組合。假設(shè)我們需要對A、B、C三個參數(shù)進(jìn)行pair-wise組合測試,A和B有兩種可能取值,C有三種可能取值。那么它們之間的兩兩組合情況有：AB、AC、BC,具體的取值可能如圖4-6所示,pair-wise測試的最終目的就是全部覆蓋這些取值情況。PICT中把每種取值情況分為三種狀態(tài)：已覆蓋、未覆蓋、排除,我們實現(xiàn)的自動化測試工具中不考慮帶有約束的pair-wise測試,所以只有前兩種狀態(tài)。每當(dāng)生成一種新的測試用例時,被新測試用例覆蓋的取值情況狀態(tài)會跟隨之改變,算法直到所有取值情況的狀態(tài)都為覆蓋時終止。圖4-7PICT算法偽代碼[22]原始算法的偽代碼如圖4-7,算法生成新測試用例時優(yōu)先選取種子組合,即某些測試者認(rèn)為比較重要,應(yīng)該優(yōu)先出現(xiàn)的取值組合。我們不考慮此特性的功能,下面介紹如何完成新測試用例ri的生成。如果ri為空,那么選擇一種剩有最多未覆蓋取值組合的參數(shù)組合,比如圖4-6例子中生成第一個測試用例時AB剩有4種取值組合,而AC和BC則各有6種取值組合。當(dāng)存在多個相同最大剩余取值組合的參數(shù)組合時,只選擇第一個參數(shù)組合的第一種取值情況,即AC的00情況首先被選用。因為ri中還有未確定取值的參數(shù)B,所以繼續(xù)while循環(huán)到else部分,考慮所有取值情況集合P中包含至少一個未確定取值參數(shù)的子集Q,再從Q中篩選出與ri取值一致的取值情況。于是我們篩選出了AB的00、01,BC的00、10。如果在這些篩選出的取值情況中有未覆蓋組合,那么選擇能新覆蓋最多取值組合的一項；如果它們都已覆蓋,那么隨機(jī)選擇一項。這里篩選出的4種取值情況都只能新覆蓋1種取值組合,所以使用AB的00,至此我們就生成了第一個測試用例,隨后的測試用例生如上述過程。為了方便調(diào)試和用戶擴(kuò)充pair-wise算法,該模塊被設(shè)計為獨立的可執(zhí)行文件。系統(tǒng)調(diào)用該模塊時,首先通過配置文件提供的路徑定位,然后利用系統(tǒng)類另外啟動一個隱藏命令行窗口的進(jìn)程運行。對于測試工具來說,這些操作都由類PictFile封裝。用戶自己實現(xiàn)的pair-wise算法只要滿足輸入?yún)?shù)和輸出格式與我們設(shè)計的相同,即能夠在配置文件中指定并良好地整合。輸入?yún)?shù)和輸出格式由類PictInputVariable和類PictOutputVariable說明,因為輸出都是包含一組參數(shù)的取值情況的,所以類PictOutputVarList部封裝了一個類PictOutputVariable的鏈表。圖4-8PICT相關(guān)封裝類最終測試用例集實現(xiàn)有了模型遍歷算法的實現(xiàn)和pair-wise測試算法,結(jié)合兩者我們就能構(gòu)建生成最終的測試用例集了。類SuiteMaker提供添加這兩個模塊所需要信息的接口,比如圖4-9中列出的AppendToken、AppendFunction、AppendCaseGroup和AppendVarMap。方法MakeSuite實際調(diào)用的是FSM模型遍歷算法,最后方法Save根據(jù)收集好的信息按照一定的格式生成測試用例文件,用戶也可以根據(jù)自己需要覆寫該方法。圖4-9類SuiteMaker目前生成的測試用例文件是一個可執(zhí)行的C#語言程序,能夠簡單地統(tǒng)計測試用例通過數(shù)、未通過數(shù)等信息,該文件的大概結(jié)構(gòu)如下表：區(qū)域說明TOKENS所有token定義,唯一用戶需要填充部分FUNCTIONS所有token組成的函數(shù)過程定義VARIABLES所有用于調(diào)用token或函數(shù)過程的變量聲明DEFAULT所有用于生成測試報告的輔助性變量聲明TESTCASES所有生成的測試用例主函數(shù)程序入口表4-2測試用例文件的構(gòu)成第五章實例分析：ATM系統(tǒng)本章將通過一個虛構(gòu)的ATM系統(tǒng)例子來演示工具的使用過程。為了體現(xiàn)工具的各項特點,該系統(tǒng)和我們熟知的ATM系統(tǒng)有所不同,論文在后面會詳細(xì)說明這些區(qū)別。完成工具的主界面如圖5-1。圖5-1主界面工具頂端的工具欄提供了一些基本操作的按鈕,例如新建、打開、保存等功能。工具欄下方的按鈕代表的是三種不同的繪圖工具：最左邊的是選取工具,中間的是添加狀態(tài)工具,最右邊的是添加轉(zhuǎn)換動作工具。利用這些繪圖工具就可以在右側(cè)的繪圖區(qū)繪制FSM可視化模型,此外可以隨時通過切換上方選項卡來查看模型序列化后的XML格式容。用戶定義的token和函數(shù)過程位于左側(cè)下方的樹結(jié)構(gòu)之上,用戶可以通過鼠標(biāo)右擊該樹結(jié)構(gòu)默認(rèn)的Token和Function節(jié)點來分別添加token和函數(shù)過程。下方選項卡默認(rèn)選擇的是FSM詳情面板,當(dāng)繪圖區(qū)中FSM模型的轉(zhuǎn)換動作或函數(shù)過程組件被選中時,其部包含的token或函數(shù)過程將被列在詳情面板的左側(cè)。用戶需要添加token或函數(shù)過程時可以直接從左側(cè)樹結(jié)構(gòu)上拖拽下來,同時工具提供了上移、下移和刪除功能讓用戶自由安排序列。選中的token或函數(shù)過程的輸入?yún)?shù)和輸出參數(shù)位于詳情面板的中間,用戶設(shè)置錯誤時下方提示區(qū)會給出友好的提示信息。右下角是WinForm提供的PropertyGrid組件,用于詳細(xì)設(shè)置組件置對象的各項屬性。至于下方選項卡上的另外兩個標(biāo)簽頁,分別用于設(shè)置pair-wise測試參數(shù)取值和遍歷模型生成測試用例。使用工具繪制的ATM系統(tǒng)FSM模型如圖5-2。和現(xiàn)實中的ATM系統(tǒng)相比,我們添加了ATM的初始配置過程〔動作initATM,用以設(shè)定ATM所屬銀行的名稱,結(jié)合不同的銀行卡類型來說明pair-wise測試功能。ATM支持取款和存款操作,不同類型的銀行卡將擁有執(zhí)行不同操作的權(quán)限〔比如只能取款或只能存款,或者都可以,如此就和我們實際應(yīng)用環(huán)境中的RBAC特性相像。輸入密碼的過程被區(qū)分為正確輸入與連續(xù)三次輸錯,連續(xù)三次輸錯的動作會用到token函數(shù)過程,模型中不考慮連續(xù)輸錯不足三次又最后輸入正確的情況。圖5-2ATM系統(tǒng)的FSM模型添加token和函數(shù)過程的不同方式如圖5-3左側(cè)所示,右側(cè)為添加完成后樹結(jié)構(gòu)的效果。其中定義token時會彈出如圖5-4的對話框,用于詳細(xì)輸入token各項屬性容,雙擊樹結(jié)構(gòu)中已添加好的token節(jié)點可以重新編輯。函數(shù)過程的定義則只需要輸入函數(shù)過程的名稱,隨后如轉(zhuǎn)換動作一樣填充token序列。圖5-3定義token和函數(shù)過程圖5-4添加token的對話框轉(zhuǎn)換動作〔包括函數(shù)過程都是由token序列組成的,工具提供從token列表中直接拖放添加的方式,同時支持特定token在序列中位置的上移、下移或刪除。添加的token必須被賦予適當(dāng)個數(shù)的參數(shù),參數(shù)之間用逗號分隔,工具會自動檢查用戶輸入的參數(shù)是否和token定義所匹配。圖5-5中展示的是函數(shù)過程TripleInvalidPswd,它的token序列為連續(xù)三次調(diào)用EnterPswd,每次EnterPswd調(diào)用傳入的參數(shù)都為0,代表錯誤的密碼。圖5-5token序列的添加前面完成了整個ATM系統(tǒng)的FSM模型的建立,下面開始使用工具分析模型,尋找可執(zhí)行路徑并結(jié)合pair-wise測試技術(shù)生成測試用例。首先切換到變量信息標(biāo)簽頁,工具會把FSM模型中用過的變量都識別出來,而常量則不被列出。用戶指定這些變量的可能取值后,就能調(diào)用pair-wise模塊生成組合測試用例。圖5-6中識別出了6個變量,分別代表銀行卡的權(quán)限類型、實際操作類型、操作的操作數(shù)、操作數(shù)是否會導(dǎo)致余額為負(fù)數(shù)、操作數(shù)是否超過ATM上限、ATM所屬銀行。工具利用pair-wise模塊一共只生成了11種組合情況,遠(yuǎn)小于直接正交排列組合得到的216種。圖5-6組合測試生成測試用例生成算法的另一大模塊是模型遍歷算法,其相關(guān)組件位于標(biāo)簽頁中的最后一項。目測有效測試用例的長度不超過10,同時指定最大重復(fù)次數(shù)為1,即產(chǎn)生的測試用例中將不包含任何回路。工具最終搜索到了17條有效路徑〔圖5-7a,如果只限定路徑長度,那么將產(chǎn)生264條可執(zhí)行路徑〔圖5-7b,其中包含大量的冗余路徑。<a>最大重復(fù)數(shù)為1<b>最大重復(fù)數(shù)為10圖5-7可執(zhí)行路徑的搜索最終生成的測試用例文件中將依次使用pair-wise測試產(chǎn)生的11種參數(shù)取值情況,依次測試模型遍歷產(chǎn)生的17條可執(zhí)行用例所代表的17個測試用例,總計需要執(zhí)行11*17=187個測試用例。因為所有的token都未實現(xiàn),所以全部的測試用例都顯示為不通過。圖5-8測試用例執(zhí)行結(jié)果第六章結(jié)論及展望軟件質(zhì)量一直是人們關(guān)注和探索的焦點,軟件測試已經(jīng)滲透到了軟件開發(fā)過程的方方面面。傳統(tǒng)的測試技術(shù)越來越難以滿足日益復(fù)雜龐大系統(tǒng)的測試需求,高效的測試方法和測試工具成為業(yè)界追逐的主流?；谀Ｐ偷臏y試是一種輕量級自動生成測試用例的方法。測試人員的關(guān)注點在于構(gòu)建一個能夠描述被測系統(tǒng)各方面數(shù)據(jù)和行為的形式化機(jī)器可讀模型,通過對模型的分析就可以自動生成測試用例,包括提供給待測試系統(tǒng)的輸入和預(yù)期輸出。模型的表現(xiàn)形式、測試用例生成算法和預(yù)期輸出的生成是基于模型測試的三項關(guān)鍵技術(shù)。我們開發(fā)的工具使用了較為簡便和熟悉的有限狀態(tài)機(jī)模型,同時提供了對模型的可視化輸入和持久序列化功能。測試用例的生成算法結(jié)合了圖論中廣度優(yōu)先搜索算法和組合測試技術(shù),其中廣度遍歷時額外增加了路徑長度限制,并且記錄每條單獨路徑的使用次數(shù)來剔除冗余回路,同時在模型中指定某些特定狀態(tài)作為出口狀態(tài)來讓路徑在必要的時候停止擴(kuò)展。組合測試在保證測試用例對所有取值組合進(jìn)行足夠覆蓋的前提下,有效地壓縮了多參數(shù)多可能取值情況下生成的測試用例數(shù)目。最終開發(fā)完成的基于模型的自動化測試工具基本達(dá)到了預(yù)期的各項要求。隨著軟件測試領(lǐng)域不斷涌現(xiàn)的測試用例生成算法,可以考慮讓工具支持更多更強(qiáng)大的算法。而且該測試工具仍需要人工輸入系統(tǒng)模型,系統(tǒng)模型的構(gòu)建過程并不是特別的輕松。如果日后的工具能夠支持自動分析自然語言需求來生成系統(tǒng)模型,對于完善整個軟件測試過程的自動化將有著重大意義。參考文獻(xiàn)[1]SoftwareErrorsCostU.S.Economy$59.5BillionAnnually,NISTReport[2]Baker,C.ReviewofD.D.McCracken’s"DigitalComputerProgramming".MathematicalTablesandOtherAidstoComputation1I,60<Oct.1957>.298-305.[3]Myers,G.J.TheArtofSoftwareTesting.JohnWiley&Sons,NewYork,1979.[4]GuidelineforLifecycleValidation,Verification,andTestingofComputerSoftware.NationalBureauofStandardsReportNBSFIPS101.Washington,D.C..1983.[5]ANSI/IEEESTD829-1983StandardforSoftwareTestDocumentation.InstituteofElectricalandElectronicsEngineers,NewYork,1983.[6]Gelperin,D.;B.Hetzel<1988>."TheGrowthofSoftwareTesting".CACM31<6>.ISSN0001-0782.[7]https://.research.ibm./haifa/projects/verificat