【正文】
,軟件開發(fā)過程中有一半以上的資源都花費在軟件測試上。但是軟件帶來巨大便利的同時,軟件中的任何微小缺陷也可能帶來難以估量的損失。關鍵詞:OSD,內存映射窗口,菜單系統(tǒng),UIFULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMELVIEWABSTRACTAtmel Corporation39。其次講解了AtmelView內存映射窗口結合OSD應用的UI設計思想,涉及了多圖層表現(xiàn)的想法,硬件OSD與偽OSD的比較使用。然后詳細闡述了基于AtmelView的菜單系統(tǒng)方案和框架結構,針對最重要的MenuMode菜單構建函數(shù)分析其數(shù)據(jù)抽象、界面繪制和事件響應處理過程。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。據(jù)美國國家標準技術研究院(NIST)2002年公布的一份研究報告顯示,軟件故障平均每年對美國經(jīng)濟造成的損失約為595億美元,% [1] 。早期的軟件測試等同于程序調試,1957年Charles Baker才正式將兩者區(qū)別開來,他認為調試側重于保證程序運行,而測試側重于保證程序解決問題[2]。時間測試階段 1956面向調試時期19571978面向論證時期19791982面向破壞時期19831987面向評估時期1988 now 面向防止時期表11 測試的發(fā)展階段[6]測試不可能遍歷所有可能出現(xiàn)的情況,必須在適當?shù)臅r候終止測試。于是人們需要開發(fā)一些自動化工具來管理或者執(zhí)行測試過程,雖然編寫軟件測試工具需要引入額外的工作量,但是軟件測試工具能大大提高軟件測試的效率和質量,并且市面上也已經(jīng)存在著許多現(xiàn)成的測試工具。絕大部分軟件測試工具并不能自動完成整個測試過程,測試人員依然需要事先編寫好測試腳本或測試用例,即一組測試輸入、執(zhí)行條件和預期結果。為了抽象出理想的模型可能需要花費一定的時間,但是模型構建的工作可以在軟件開發(fā)生命周期的早期就開始,只要求被測系統(tǒng)的需求定義完成即可。事實證明,MBT確實具有很強的錯誤發(fā)現(xiàn)能力。當然MBT也不是萬能的,它發(fā)現(xiàn)錯誤的能力很大程度上依賴于建模和選擇測試用例選擇要求人員的水平。有時侯測試用例沒有通過,并不是因為程序編寫的錯誤,而是因為系統(tǒng)需求定義存在錯誤。傳統(tǒng)的測試方法很可能需要重新設計編寫所有測試用例,MBT只需要調整模型后再自動生成測試用例。傳統(tǒng)的人工測試的測試用例都是依據(jù)系統(tǒng)需求定義的,MBT的測試用例生成算法難免產生一些無效冗余的測試用例,測試用例通過率不再是衡量軟件測試效率的有效標準。. 項目背景和論文結構. 項目背景本課題來源于作者實習所在的微軟公司,旨在遵照基于模型的軟件測試理論開始實現(xiàn)一款自動化測試工具,該工具能夠支持有限狀態(tài)機模型的輸入,然后自動生成抽象測試用例。因為與傳統(tǒng)的單純正交排列組合測試相比,配對組合測試技術具有較大的優(yōu)越性。第五章通過一個虛構的自動取款機(ATM, Automatic Teller Machines)系統(tǒng)來演示如何使用我們完成的工具進行MBT測試。如果沒有使用正確的模型表現(xiàn)形式,會拖累影響整個測試流程。首先在系統(tǒng)需求或者規(guī)約文檔的基礎上建立某種形式的模型(步驟1),模型說明了系統(tǒng)所有的潛在行為意圖。想要同時滿足以上所有的特性是很困難的,但是可以把幾種不同的模型整合成一個,揚長避短地得到理想模型。圖22是一個描述了門的四種不同狀態(tài)及其轉換關系的FSM。圖22 FSM示例我們工具主要面向的是RBAC功能的測試,頻繁關心具有不同權限的不同角色所能執(zhí)行的操作。如果以后需要額外考慮系統(tǒng)事件和測試輸入的概率分布,只需要為每個狀態(tài)之間的遷移動作增加概率相關屬性,非常輕松地支持統(tǒng)計式模型。定理證明方法原先是被用于自動證明數(shù)學公式,MBT生成測試用例時根據(jù)邏輯表達式的有效說明把模型劃分為不同等價類,每個等價類描述了SUT的某一行為。其中約束編程是一種通過約束來描述變量間關系的編程方法,求解約束的方法有布爾式求解方法和數(shù)值分析方法。模型檢測會遇到的問題是,生成的用例中存在過多冗余用例,導致軟件測試執(zhí)行的代價增加。把復雜系統(tǒng)拆分為相對獨立的組件單獨分析,也是所有MBT測試用例生成方法通用的竅門。我們選用的是FSM模型,所以可以利用圖論中的一些遍歷方法,比如廣度優(yōu)先遍歷算法或者深度優(yōu)先遍歷算法,每找到的一條可執(zhí)行路徑對應于一個測試用例。問題有許多可能的影響因素,比如跟軟件安裝所在機器的操作系統(tǒng)類型有關,或者是系統(tǒng)物理內存的大小,甚至網(wǎng)卡型號等等。但是現(xiàn)實并不允許測試人員這么做,因為造成的測試用例數(shù)量是指數(shù)性爆炸增長的,N個分別有M種取值的影響因素將需要MN個測試用例來完成測試。圖23 不同組合強度下的錯誤發(fā)現(xiàn)率圖23是NIST報告中總結的幾個應用使用不同組合強度的測試用例集測試后的錯誤發(fā)現(xiàn)率曲線[17]。特別的,生成2way的測試用例集的方法被稱為pairwise(或allpairs)測試方法。最壞的情況下,當組合強度和參數(shù)的數(shù)目相等時,組合測試退化為枚舉測試??紤]一款受5個配置因素影響的應用:操作系統(tǒng)(Windows XP、Apple OS X、Red Hat Enterprise Linux),瀏覽器(IE、FireFox),網(wǎng)絡協(xié)議(IPvIPv6),處理器平臺(Intel、AMD)和數(shù)據(jù)庫(MySQL、Sybase、Oracle),一共33=72種硬件平臺。相關的字體處理函數(shù)需要根據(jù)用戶的輸入來相應修改文字效果,該函數(shù)需要在所有的可能情況下都正常工作,而一共有210=1024種可能。tway覆蓋數(shù)組的特點是,任意t個參數(shù)的所有排列組合都將分別出現(xiàn)在覆蓋數(shù)組的某一行中,比如上圖中的ABC、DEG、HIJ,三個參數(shù)共有8種排列組合(000、00001100、101111)都被覆蓋數(shù)組所覆蓋。Sloane在其網(wǎng)站上總結記錄了超過200個正交數(shù)組[18]。構造最優(yōu)覆蓋數(shù)組的實際上是一個NP完全問題[20],我們知道,NP完全問題是一系列可以互相轉化的問題。但我們可以利用局部搜索方法,比如啟發(fā)式搜索算法,在較短的時間內就可以搜索出近似最優(yōu)解。按照擴展方式的不同,又可以分為一維擴展和二維擴展。首先構造前兩個參數(shù)的所有組合,形成一個小的矩陣,再分別為矩陣添加一列和必要多的行,覆蓋完所有元組后結束。前面我們構造了系統(tǒng)的模型,模型描述了系統(tǒng)的狀態(tài)和狀態(tài)之間的動作,這些動作都是由一個個函數(shù)和方法的調用序列組成的。我們把這些樁叫做token,token對應于適配器層中的某個函數(shù)和方法,兩者可以直接一一對應,也可以先序列化為可擴展標記語言(XML,Extensible Markup Language)文件再利用XML解析器之類的工具生成測試用例。反之,一切正常并給出通過提示。不過如果預期輸出涉及復雜的判斷邏輯,還是使用委托給token來處理的方法較好。繪制FSM模型時首先需要定義一些FSM的狀態(tài)轉換動作中用到的token和這些token組成的若干函數(shù)過程,隨后在模型繪制面板中畫出FSM模型相應的有向圖。最后用戶還可以在生成的測試用例中再人工選擇部分測試用例出來,保存為最終需要被執(zhí)行的測試用例。此外,為了持久化保存繪制好的FSM模型,系統(tǒng)包含了序列化模塊,用于模型的序列化與反序列化。. FSM數(shù)據(jù)模型實現(xiàn)我們知道FSM數(shù)據(jù)模型是影響系統(tǒng)的關鍵,圖41列出了系統(tǒng)實際實現(xiàn)過程中FSM數(shù)據(jù)模型相關各類之間的關系。我們定義了三種狀態(tài)類型:Entry、Free和Exit,Entry和Exit分別代表初始狀態(tài)和終止狀態(tài),F(xiàn)ree代表其他自由狀態(tài)。除了以上代表FSM實體組成部分的類,F(xiàn)SM數(shù)據(jù)模型還必須描述SUT相關部分的信息。最后,注意一下參數(shù)和變量的區(qū)別:參數(shù)指的是函數(shù)方法頭中定義的輸入,而變量是在實際調用函數(shù)方法時對參數(shù)的賦值。雖然WinForm技術中已經(jīng)提供了許多可以直接使用的組件,但是距離我們的要求還是有一定差距,所以我們自己設計實現(xiàn)了新的組件來完成FSM模型的可視化。方法名稱作用DrawCurve繪制經(jīng)過一組指定的Point結構的曲線DrawLine繪制一條連接由坐標對指定的兩個點的線條DrawPolygon繪制由一組Point結構定義的多邊形DrawString在指定位置并由指定的Brush和Font對象繪制指定的文本字符串FillEllipse填充邊框所定義橢圓的內部,該邊框由一對坐標、一個寬度和一個高度指定表41 類Graphics部分方法圖43展示了這幾個類的繪圖效果,類StateR繪制紫色的圓圈代表狀態(tài)節(jié)點,類ActionR則繪制了兩種代表轉換動作的深綠色弧線。圖43 自定義UI組件示例C語言提供了方便的標記功能來支持對象的序列化與反序列化(圖44)。,并且支持從XML文件中重新創(chuàng)建原始狀態(tài)的對象。最為全面地測試FSM模型的方法是找出其有向圖中的所有可執(zhí)行路徑,然后把它們都轉換為測試用例去執(zhí)行。圖45 模型遍歷算法核心代碼模型遍歷算法的本質是圖論中的廣度優(yōu)先搜索(BFS, BreadthFirst Search)算法,圖45給出了算法的核心代碼。. pairwise測試實現(xiàn)此部分的實現(xiàn)主要模仿微軟PICT工具[22],運用一維擴展的貪心算法策略逐步得到覆蓋矩陣。那么它們之間的兩兩組合情況有:AB、AC、BC,具體的取值可能如圖46所示,pairwise測試的最終目的就是全部覆蓋這些取值情況。我們不考慮此特性的功能,下面介紹如何完成新測試用例ri的生成。于是我們篩選出了AB的00、01,BC的00、10。系統(tǒng)調用該模塊時,首先通過配置文件提供的路徑定位。圖48 PICT相關封裝類. 最終測試用例集實現(xiàn)有了模型遍歷算法的實現(xiàn)和pairwise測試算法,結合兩者我們就能構建生成最終的測試用例集了。為了體現(xiàn)工具的各項特點,該系統(tǒng)和我們熟知的ATM系統(tǒng)有所不同,論文在后面會詳細說明這些區(qū)別。利用這些繪圖工具就可以在右側的繪圖區(qū)繪制FSM可視化模型,此外可以隨時通過切換上方選項