【正文】 em Under Test）環(huán)境中真正執(zhí)行所有測(cè)試用例（步驟51），可以利用測(cè)試腳本來自動(dòng)化執(zhí)行測(cè)試，最終得到測(cè)試結(jié)果（步驟52）。至于產(chǎn)生其它輔助性內(nèi)容的工具，它在不同項(xiàng)目之間不具有可移植性，只有根據(jù)不同項(xiàng)目來專門設(shè)計(jì)實(shí)現(xiàn)。第二章 基于模型的測(cè)試2.. MBT一般操作流程基于模型的測(cè)試依賴于三項(xiàng)關(guān)鍵技術(shù)：模型的表現(xiàn)形式、測(cè)試用例的生成算法和產(chǎn)生其它輔助性內(nèi)容（包括預(yù)期結(jié)果）的工具[12]。第三章介紹系統(tǒng)的總體架構(gòu)和簡(jiǎn)要闡述系統(tǒng)各模塊的功能。該測(cè)試工具將被主要用于微軟公司SCCM系統(tǒng)的基于角色權(quán)限控制（RBAC， RoleBased Access Control）功能的測(cè)試。目前代表性的支持MBT的測(cè)試工具有：IBM公司的GOTCHATCBeans軟件測(cè)試套件，面向Java、C/C++語(yǔ)言編寫的應(yīng)用程序接口（API, Application Program Interfaces）和軟件協(xié)議[7]；微軟公司的Spec Explorer工具，具有創(chuàng)建軟件行為模型、可視化分析模型、驗(yàn)證模型有效性和根據(jù)模型生成測(cè)試用例等功能[8]；“凈室”公司的CleanTest，主要用于凈室軟件工程中使用的統(tǒng)計(jì)測(cè)試過程[9]。實(shí)施MBT的測(cè)試人員需要具有比普通測(cè)試人員更強(qiáng)的系統(tǒng)抽象能力，因?yàn)镾UT很可能并不容易建模。我們知道，軟件開發(fā)中的錯(cuò)誤越早發(fā)現(xiàn)需要付出的修復(fù)代價(jià)越小，MBT把一些錯(cuò)誤扼殺在需求階段，貢獻(xiàn)無(wú)疑是巨大的。而且MBT可以提高測(cè)試效率，因?yàn)槿斯y(cè)試受限于測(cè)試人員的思維活躍程度，MBT使用的測(cè)試用例生成算法和啟發(fā)式用例選擇機(jī)制能夠快速生成大量測(cè)試用例，達(dá)到對(duì)模型更高的覆蓋率卻僅需要多花費(fèi)少量運(yùn)行測(cè)試用例生成程序的時(shí)間。而微軟公司的某一應(yīng)用中，MBT發(fā)現(xiàn)了多10倍的錯(cuò)誤[14]。模型所帶來的回報(bào)也是巨大的，因?yàn)橐坏┠Ｐ捅淮_立且其能夠準(zhǔn)確反映被測(cè)系統(tǒng)的真實(shí)需求，軟件測(cè)試工具就能夠分析模型自動(dòng)得到測(cè)試用例。當(dāng)測(cè)試本身就需要多次重復(fù)時(shí)（比如回歸測(cè)試、壓力測(cè)試），其優(yōu)點(diǎn)將更加顯著?；诖a的測(cè)試是指通過程序提供的公共接口，直接驗(yàn)證各個(gè)類、庫(kù)和模塊在不同的輸入情況下返回結(jié)果的正確性與否，如xUnit系列框架。常用的判斷標(biāo)準(zhǔn)有：代碼覆蓋率、測(cè)試用例通過率、缺陷數(shù)量收斂率等等。1983年美國(guó)國(guó)家標(biāo)準(zhǔn)局（NBS）發(fā)表了評(píng)估軟件生命周期各階段的測(cè)試方法[4]，同年美國(guó)電氣和電子工程師協(xié)會(huì)（IEEE）發(fā)布了八大軟件測(cè)試相關(guān)文檔的標(biāo)準(zhǔn)[5]，人們開始利用這些評(píng)估標(biāo)準(zhǔn)來衡量測(cè)試軟件的質(zhì)量。軟件測(cè)試能夠有效地幫助軟件開發(fā)人員找出系統(tǒng)中存在的錯(cuò)誤，從而在很大程度上保證軟件的質(zhì)量。s framework were illustrated. The process of data abstraction, interface drawing and event handling were analyzed for the most important Menu building function MenuMode. After that Nucleus Plus was introduced and the method to use process munication, process synchronization for supporting Bluetooth module in Menu System was given. The UI solution provides a layered, structural and extendable Menu System for digital photo frame. And it effectively supports Bluetooth module.Key words: OSD, SDRAMMapping Window, Menu System, UI目 錄第一章 緒論 3. 軟件測(cè)試簡(jiǎn)介 3. 軟件測(cè)試工具發(fā)展現(xiàn)狀 3. 項(xiàng)目背景和論文結(jié)構(gòu) 3. 項(xiàng)目背景 3. 論文結(jié)構(gòu) 3第二章 基于模型的測(cè)試 3. MBT一般操作流程 3. MBT模型表現(xiàn)形式 3. MBT測(cè)試用例生成 3. MBT預(yù)期輸出生成 3第三章 系統(tǒng)架構(gòu) 3. 功能概述及流程 3. 系統(tǒng)架構(gòu) 3第四章 系統(tǒng)各功能實(shí)現(xiàn) 3第五章 實(shí)例分析：ATM系統(tǒng) 3第六章 結(jié)論及展望 3參考文獻(xiàn) 3第一章 緒論. 軟件測(cè)試簡(jiǎn)介隨著電子信息化的飛速發(fā)展，計(jì)算機(jī)軟件已經(jīng)遍布于人類社會(huì)的各個(gè)角落，遠(yuǎn)至月球探測(cè)衛(wèi)星的發(fā)射系統(tǒng)，近至個(gè)人攜帶的MP3音樂播放器。本方案的實(shí)現(xiàn)提供了一套層次化、結(jié)構(gòu)化、可擴(kuò)展的電子相框菜單系統(tǒng)，并有效支持了藍(lán)牙模塊的應(yīng)用。 基于模型的自動(dòng)化測(cè)試工具的實(shí)現(xiàn)畢業(yè)設(shè)計(jì)論文基于模型的自動(dòng)化測(cè)試工具的實(shí)現(xiàn)摘要基于模型的測(cè)試是本文首先介紹了AtmelView框架以及菜單系統(tǒng)UI在其中所將扮演的角色、與各個(gè)功能模塊間的關(guān)系。其后介紹Nucleus Plus，給出進(jìn)程通信、進(jìn)程同步在菜單系統(tǒng)中支持藍(lán)牙模塊的應(yīng)用方法。s usage was proposed. It referred to the idea of multiple image layer interface and the parison the usage of hardware OSD and Pseudo OSD. Then the details of Menu System39。因此，如何保證軟件的質(zhì)量顯得尤為關(guān)鍵。1979年Myers提出“測(cè)試是帶有發(fā)現(xiàn)錯(cuò)誤意圖去執(zhí)行程序的過程”[3]，越是發(fā)現(xiàn)了錯(cuò)誤才說明測(cè)試過程的成功。如果一味地追求缺陷數(shù)量，很可能得不償失。名稱產(chǎn)商簡(jiǎn)介WinRunnerMercury Interactive支持自動(dòng)錄制、檢測(cè)和回放用戶操作LoadRunnerMercury Interactive模擬大量并發(fā)負(fù)載來預(yù)測(cè)系統(tǒng)性能TestDirectorMercury Interactive基于Web的測(cè)試管理系統(tǒng)RobotIBM具有測(cè)試和管理的雙重功能xUnit\最流行的開源單元測(cè)試框架SilkTestBorland軟件功能測(cè)試工具WASMicrosoft強(qiáng)大的網(wǎng)站壓力測(cè)試工具JTestParasoft針對(duì)Java語(yǔ)言的自動(dòng)化白盒測(cè)試工具JMeterApache100%用Java實(shí)現(xiàn)的功能和性能測(cè)試工具WebLoadRadViewWeb性能測(cè)試和分析工具表12 常用軟件測(cè)試工具一般來說，自動(dòng)化測(cè)試可以分為：基于代碼的測(cè)試和基于圖形化用戶界面的測(cè)試。測(cè)試用例能夠被快速和反復(fù)地執(zhí)行，方便地使得發(fā)現(xiàn)的軟件錯(cuò)誤重現(xiàn)。而且往往在將非形式化的需求轉(zhuǎn)化為形式化的模型過程中，需求中的遺漏和不足部分將被發(fā)現(xiàn)。IBM公司和BMW公司的研究表明，MBT發(fā)現(xiàn)的錯(cuò)誤和手工設(shè)計(jì)的測(cè)試集發(fā)現(xiàn)的錯(cuò)誤數(shù)量差不多。圖12 各種測(cè)試方法整個(gè)測(cè)試過程的花費(fèi)時(shí)間圖[14]MBT能否降低測(cè)試的花費(fèi)和時(shí)間，取決于建立和維護(hù)模型加上生成測(cè)試用例花費(fèi)的時(shí)間是否比其它方法設(shè)計(jì)和維護(hù)測(cè)試集所需要的時(shí)間少，通常情況下答案是肯定的。其它形式的軟件測(cè)試一般無(wú)法發(fā)現(xiàn)此類錯(cuò)誤，但是MBT可以。凡事有利必有弊，好的模型可以讓測(cè)試過程一帆風(fēng)順，模型也給測(cè)試過程帶來了許多問題。認(rèn)識(shí)到這些MBT的不足之處，我們才能更加正確地利用MBT。用戶填充實(shí)現(xiàn)完整的測(cè)試用例后，此工具能執(zhí)行測(cè)試用例并給出測(cè)試報(bào)告。. 論文結(jié)構(gòu)本文第二章主要介紹MBT測(cè)試技術(shù)，依照MBT測(cè)試的一般流程來說明工具使用的模型表現(xiàn)形式、測(cè)試用例生成算法和預(yù)期輸出的生成。最后作簡(jiǎn)要的總結(jié)及展望。針對(duì)各個(gè)不同的模型表現(xiàn)形式，如今已有許多測(cè)試用例算法與之對(duì)應(yīng)，我們可以在實(shí)際應(yīng)用過程中靈活地借鑒參考來設(shè)計(jì)自己的算法。接下來需要定義測(cè)試用例的選擇要求（步驟2），形成測(cè)試用例規(guī)約（步驟3），編寫算法將其應(yīng)用于模型之上來生成測(cè)試用例（步驟4）。在MBT中使用過的模型可能有幾十甚至上百種，我們不可能也沒有必要去逐一了解，Mark Utting和Bruno Legeard把它們大致分為以下幾種 [14]：類型示例基于Pre/PostB、OCL、JML、Spec、Z基于轉(zhuǎn)換FSM、狀態(tài)圖、UML狀態(tài)機(jī)統(tǒng)計(jì)式馬爾可夫鏈基于歷史消息隊(duì)列圖、UML順序圖函數(shù)式HOL系統(tǒng)操作式Petri網(wǎng)數(shù)據(jù)流式Lustre、塊狀圖表21 MBT模型分類基于轉(zhuǎn)換的模型是我們最為熟悉的模型類型，它們集中于描述系統(tǒng)在不同狀態(tài)之間的轉(zhuǎn)換過程。Harel在FSM的基礎(chǔ)上添加了層次、并發(fā)和交流概念，擴(kuò)展成了狀態(tài)圖模型[15]，從而在面對(duì)復(fù)雜系統(tǒng)時(shí)也能夠輕松建立模型。把系統(tǒng)抽象為變量集合和修改這些變量操作的基于Pre/Post的模型需要測(cè)試人員預(yù)先學(xué)習(xí)一段時(shí)間才能完全掌握，所以基本不予考慮。. MBT測(cè)試用例生成軟件測(cè)試過程中的執(zhí)行和監(jiān)督過程已經(jīng)可以使用現(xiàn)代化的自動(dòng)測(cè)試工具代替完成，至于如何生成測(cè)試用例，依然是一件棘手的事情。這些等價(jià)類就可以用于生成測(cè)試用例，最簡(jiǎn)單的劃分方法是析取范式的方法。MBT自然還會(huì)讓人想到模型檢測(cè)，即檢測(cè)模型是否滿足特定的屬性。為此，Hamon 等人詳細(xì)討論提出了高效模型檢測(cè)的方法[16]。馬爾可夫鏈也是MBT中生成測(cè)試用例的重要方法之一，它由兩大部件組成：代表系統(tǒng)所有使用場(chǎng)景的FSM和評(píng)價(jià)FSM來說明系統(tǒng)統(tǒng)計(jì)性使用信息的操作說明。當(dāng)FSM包含的狀態(tài)比較多時(shí)，遍歷組成FSM有向圖產(chǎn)生的測(cè)試用例數(shù)量可能太多，不僅難以測(cè)試包含冗余測(cè)試用例。除了硬件環(huán)境的不同，軟件接受的輸入?yún)?shù)也很可能不同，比如同一款Web應(yīng)用發(fā)布后，不同國(guó)家的用戶將會(huì)輸入不同編碼的內(nèi)容。后來人們發(fā)現(xiàn)通過巧妙地選取測(cè)試用例，只要求某些參數(shù)的組合情況被包含，能夠在保證測(cè)試效率的同時(shí)大大縮減測(cè)試用例數(shù)量。我們可以看出，隨著組合強(qiáng)度的增加，錯(cuò)誤發(fā)現(xiàn)率顯著增長(zhǎng)。目前pairwise是使用最普遍的組合測(cè)試技術(shù)，因?yàn)檐浖械慕^大部分錯(cuò)誤都只由一個(gè)或兩個(gè)參數(shù)造成，pairwise生成的測(cè)試用例能夠覆蓋足夠的錯(cuò)誤空間。組合測(cè)試的最早提出，也就是為了簡(jiǎn)化軟件在各種配置環(huán)境下的測(cè)試。2pairwise測(cè)試只需要設(shè)計(jì)如下10個(gè)測(cè)試，就覆蓋了每一種影響因素和另外一種影響因素的所有組合。前面的經(jīng)驗(yàn)告訴我們，3way的測(cè)試用例就能夠達(dá)到90%以上的錯(cuò)誤發(fā)現(xiàn)率，具有較高的收益代價(jià)比。覆蓋數(shù)組的每一行對(duì)應(yīng)一個(gè)測(cè)試用例，相比之前的1024個(gè)測(cè)試用例，組合測(cè)試只需要13個(gè)測(cè)試用例。利用計(jì)算機(jī)也可以自動(dòng)求解出部分類型的正交數(shù)組，由已知的大覆蓋數(shù)組構(gòu)造小覆蓋數(shù)組的方法被稱為坍塌[19]。于是我們可以利用和借鑒其它NP完全問題的研究成果來構(gòu)造覆蓋數(shù)組，比如第一個(gè)被證明為NP