【正文】 測試不可能遍歷所有可能出現(xiàn)的情況，必須在適當?shù)臅r候終止測試。1983年美國國家標準局（NBS）發(fā)表了評估軟件生命周期各階段的測試方法[4]，同年美國電氣和電子工程師協(xié)會（IEEE）發(fā)布了八大軟件測試相關(guān)文檔的標準[5]，人們開始利用這些評估標準來衡量測試軟件的質(zhì)量。早期的軟件測試等同于程序調(diào)試，1957年Charles Baker才正式將兩者區(qū)別開來，他認為調(diào)試側(cè)重于保證程序運行，而測試側(cè)重于保證程序解決問題[2]。軟件測試能夠有效地幫助軟件開發(fā)人員找出系統(tǒng)中存在的錯誤，從而在很大程度上保證軟件的質(zhì)量。據(jù)美國國家標準技術(shù)研究院（NIST）2002年公布的一份研究報告顯示，軟件故障平均每年對美國經(jīng)濟造成的損失約為595億美元，% [1] 。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音樂播放器。s AtmelView is the application for board AT76C120, it has already provided low level realization for digital photo frame, and it could be an extendable and mature solution. Based on current functions of AtmelView, we will design and fulfill the Menu System.Firstly the framework of AtmelView, which role Menu System UI acts and how it relates with other function modules were introduced in this paper. Then the concept of SDRAM Mapping Window with OSD39。本方案的實現(xiàn)提供了一套層次化、結(jié)構(gòu)化、可擴展的電子相框菜單系統(tǒng)，并有效支持了藍牙模塊的應用。然后詳細闡述了基于AtmelView的菜單系統(tǒng)方案和框架結(jié)構(gòu)，針對最重要的MenuMode菜單構(gòu)建函數(shù)分析其數(shù)據(jù)抽象、界面繪制和事件響應處理過程。 基于模型的自動化測試工具的實現(xiàn)畢業(yè)設(shè)計論文基于模型的自動化測試工具的實現(xiàn)摘要基于模型的測試是本文首先介紹了AtmelView框架以及菜單系統(tǒng)UI在其中所將扮演的角色、與各個功能模塊間的關(guān)系。其次講解了AtmelView內(nèi)存映射窗口結(jié)合OSD應用的UI設(shè)計思想，涉及了多圖層表現(xiàn)的想法，硬件OSD與偽OSD的比較使用。其后介紹Nucleus Plus，給出進程通信、進程同步在菜單系統(tǒng)中支持藍牙模塊的應用方法。關(guān)鍵詞：OSD，內(nèi)存映射窗口，菜單系統(tǒng)，UIFULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMELVIEWABSTRACTAtmel Corporation39。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)鍵。現(xiàn)代軟件工程理論將軟件測試作為軟件開發(fā)過程的重要組成部分，軟件開發(fā)過程中有一半以上的資源都花費在軟件測試上。1979年Myers提出“測試是帶有發(fā)現(xiàn)錯誤意圖去執(zhí)行程序的過程”[3]，越是發(fā)現(xiàn)了錯誤才說明測試過程的成功。1988年David Gelperin等在書中寫道，“測試是為了證明軟件符合需求規(guī)約，發(fā)現(xiàn)缺陷和防止錯誤”[6]。如果一味地追求缺陷數(shù)量，很可能得不償失。圖11 缺陷數(shù)量收斂圖. 軟件測試工具發(fā)展現(xiàn)狀純手工地進行軟件測試往往是費時費力的，而且測試人員容易因為疏忽產(chǎn)生失誤，測試準確性無法得到足夠的保證。名稱產(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 常用軟件測試工具一般來說，自動化測試可以分為：基于代碼的測試和基于圖形化用戶界面的測試。而基于圖形化用戶界面的測試則是通過模擬用戶動作行為（比如鍵盤輸入、鼠標點擊），產(chǎn)生某些事件來觀察和判斷程序響應是否滿足預期，如WinRunner。測試用例能夠被快速和反復地執(zhí)行，方便地使得發(fā)現(xiàn)的軟件錯誤重現(xiàn)?；谀Ｐ偷臏y試（MBT, ModelBased Testing）是一種輕量級自動生成測試用例的方法，測試人員的關(guān)注點在于構(gòu)建一個能夠描述被測系統(tǒng)各方面數(shù)據(jù)和行為的形式化機器可讀模型。而且往往在將非形式化的需求轉(zhuǎn)化為形式化的模型過程中，需求中的遺漏和不足部分將被發(fā)現(xiàn)。軟件測試的主要目的就是發(fā)現(xiàn)錯誤。IBM公司和BMW公司的研究表明，MBT發(fā)現(xiàn)的錯誤和手工設(shè)計的測試集發(fā)現(xiàn)的錯誤數(shù)量差不多。其它的一些研究結(jié)果中（如圖12），和人工測試相比MBT都是發(fā)現(xiàn)更多或者相同數(shù)量的錯誤。圖12 各種測試方法整個測試過程的花費時間圖[14]MBT能否降低測試的花費和時間，取決于建立和維護模型加上生成測試用例花費的時間是否比其它方法設(shè)計和維護測試集所需要的時間少，通常情況下答案是肯定的。如果SUT支持大規(guī)模地測試，MBT必然將發(fā)現(xiàn)更多的錯誤。其它形式的軟件測試一般無法發(fā)現(xiàn)此類錯誤，但是MBT可以。此外， MBT具有良好的應付軟件需求變更的能力。凡事有利必有弊，好的模型可以讓測試過程一帆風順，模型也給測試過程帶來了許多問題。當MBT的測試用例沒有通過時，測試人員無法斷定是SUT存在錯誤還是建模存在錯誤，增加了錯誤分析的代價。認識到這些MBT的不足之處，我們才能更加正確地利用MBT。此外，軍方也積極嘗試MBT技術(shù)，比如美國海軍水面戰(zhàn)中心開發(fā)的SMERFS[10]和CASRE[11]。用戶填充實現(xiàn)完整的測試用例后，此工具能執(zhí)行測試用例并給出測試報告。特別地，在測試用例生成過程中算法需要結(jié)合參數(shù)配對組合測試技術(shù)，盡可能縮減測試用例數(shù)目卻又不影響測試質(zhì)量。. 論文結(jié)構(gòu)本文第二章主要介紹MBT測試技術(shù)，依照MBT測試的一般流程來說明工具使用的模型表現(xiàn)形式、測試用例生成算法和預期輸出的生成。第四章使用類圖和算法偽代碼詳細討論系統(tǒng)的設(shè)計和實現(xiàn)。最后作簡要的總結(jié)及展望。模型是MBT技術(shù)的核心，不同領(lǐng)域的不同軟件系統(tǒng)適用的模型表現(xiàn)形式都不盡相同，測試人員應該結(jié)合被測系統(tǒng)的工作特點和自身對模型的熟悉程度來慎重選擇。針對各個不同的模型表現(xiàn)形式，如今已有許多測試用例算法與之對應，我們可以在實際應用過程中靈活地借鑒參考來設(shè)計自己的算法。圖21 MBT一般操作流程[13]上圖展示了MBT的一般操作流程。接下來需要定義測試用例的選擇要求（步驟2），形成測試用例規(guī)約（步驟3），編寫算法將其應用于模型之上來生成測試用例（步驟4）。. MBT模型表現(xiàn)形式理想的模型需要容易被測試人員理解，能夠把大的復雜的問題描述成小的簡單的系統(tǒng)，最好還是以一種測試用例生成工具方便識別的形式。在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)換過程。有限狀態(tài)機（FSM， Finite State Machine）模型可以被認為是該類模型的鼻祖，是極其重要的一種模型表現(xiàn)形式。Harel在FSM的基礎(chǔ)上添加了層次、并發(fā)和交流概念，擴展成了狀