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