【正文】 權(quán)限類型、實際操作類型、操作的操作數(shù)、操作數(shù)是否會導致余額為負數(shù)、操作數(shù)是否超過ATM上限、ATM所屬銀行。其中定義token時會彈出如圖54的對話框，用于詳細輸入token各項屬性內(nèi)容，雙擊樹結(jié)構(gòu)中已添加好的token節(jié)點可以重新編輯。選中的token或函數(shù)過程的輸入?yún)?shù)和輸出參數(shù)位于詳情面板的中間，用戶設置錯誤時下方提示區(qū)會給出友好的提示信息。為了體現(xiàn)工具的各項特點，該系統(tǒng)和我們熟知的ATM系統(tǒng)有所不同，論文在后面會詳細說明這些區(qū)別。系統(tǒng)調(diào)用該模塊時，首先通過配置文件提供的路徑定位。我們不考慮此特性的功能，下面介紹如何完成新測試用例ri的生成。. pairwise測試實現(xiàn)此部分的實現(xiàn)主要模仿微軟PICT工具[22]，運用一維擴展的貪心算法策略逐步得到覆蓋矩陣。最為全面地測試FSM模型的方法是找出其有向圖中的所有可執(zhí)行路徑，然后把它們都轉(zhuǎn)換為測試用例去執(zhí)行。圖43 自定義UI組件示例C語言提供了方便的標記功能來支持對象的序列化與反序列化（圖44）。雖然WinForm技術(shù)中已經(jīng)提供了許多可以直接使用的組件，但是距離我們的要求還是有一定差距，所以我們自己設計實現(xiàn)了新的組件來完成FSM模型的可視化。除了以上代表FSM實體組成部分的類，F(xiàn)SM數(shù)據(jù)模型還必須描述SUT相關(guān)部分的信息。. FSM數(shù)據(jù)模型實現(xiàn)我們知道FSM數(shù)據(jù)模型是影響系統(tǒng)的關(guān)鍵，圖41列出了系統(tǒng)實際實現(xiàn)過程中FSM數(shù)據(jù)模型相關(guān)各類之間的關(guān)系。最后用戶還可以在生成的測試用例中再人工選擇部分測試用例出來，保存為最終需要被執(zhí)行的測試用例。不過如果預期輸出涉及復雜的判斷邏輯，還是使用委托給token來處理的方法較好。我們把這些樁叫做token，token對應于適配器層中的某個函數(shù)和方法，兩者可以直接一一對應，也可以先序列化為可擴展標記語言（XML，Extensible Markup Language）文件再利用XML解析器之類的工具生成測試用例。首先構(gòu)造前兩個參數(shù)的所有組合，形成一個小的矩陣，再分別為矩陣添加一列和必要多的行，覆蓋完所有元組后結(jié)束。但我們可以利用局部搜索方法，比如啟發(fā)式搜索算法，在較短的時間內(nèi)就可以搜索出近似最優(yōu)解。Sloane在其網(wǎng)站上總結(jié)記錄了超過200個正交數(shù)組[18]。相關(guān)的字體處理函數(shù)需要根據(jù)用戶的輸入來相應修改文字效果，該函數(shù)需要在所有的可能情況下都正常工作，而一共有210=1024種可能?？紤]一款受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），一共3特別的，生成2way的測試用例集的方法被稱為pairwise（或allpairs）測試方法。但是現(xiàn)實并不允許測試人員這么做，因為造成的測試用例數(shù)量是指數(shù)性爆炸增長的，N個分別有M種取值的影響因素將需要MN個測試用例來完成測試。我們選用的是FSM模型，所以可以利用圖論中的一些遍歷方法，比如廣度優(yōu)先遍歷算法或者深度優(yōu)先遍歷算法，每找到的一條可執(zhí)行路徑對應于一個測試用例。模型檢測會遇到的問題是，生成的用例中存在過多冗余用例,導致軟件測試執(zhí)行的代價增加。定理證明方法原先是被用于自動證明數(shù)學公式，MBT生成測試用例時根據(jù)邏輯表達式的有效說明把模型劃分為不同等價類，每個等價類描述了SUT的某一行為。圖22 FSM示例我們工具主要面向的是RBAC功能的測試，頻繁關(guān)心具有不同權(quán)限的不同角色所能執(zhí)行的操作。想要同時滿足以上所有的特性是很困難的，但是可以把幾種不同的模型整合成一個，揚長避短地得到理想模型。如果沒有使用正確的模型表現(xiàn)形式，會拖累影響整個測試流程。因為與傳統(tǒng)的單純正交排列組合測試相比，配對組合測試技術(shù)具有較大的優(yōu)越性。傳統(tǒng)的人工測試的測試用例都是依據(jù)系統(tǒng)需求定義的，MBT的測試用例生成算法難免產(chǎn)生一些無效冗余的測試用例，測試用例通過率不再是衡量軟件測試效率的有效標準。有時侯測試用例沒有通過，并不是因為程序編寫的錯誤，而是因為系統(tǒng)需求定義存在錯誤。事實證明，MBT確實具有很強的錯誤發(fā)現(xiàn)能力。絕大部分軟件測試工具并不能自動完成整個測試過程，測試人員依然需要事先編寫好測試腳本或測試用例，即一組測試輸入、執(zhí)行條件和預期結(jié)果。時間測試階段 1956面向調(diào)試時期19571978面向論證時期19791982面向破壞時期19831987面向評估時期1988 now 面向防止時期表11 測試的發(fā)展階段[6]測試不可能遍歷所有可能出現(xiàn)的情況，必須在適當?shù)臅r候終止測試。據(jù)美國國家標準技術(shù)研究院（NIST）2002年公布的一份研究報告顯示，軟件故障平均每年對美國經(jīng)濟造成的損失約為595億美元，% [1] 。然后詳細闡述了基于AtmelView的菜單系統(tǒng)方案和框架結(jié)構(gòu)，針對最重要的MenuMode菜單構(gòu)建函數(shù)分析其數(shù)據(jù)抽象、界面繪制和事件響應處理過程。關(guān)鍵詞：OSD，內(nèi)存映射窗口，菜單系統(tǒng)，UIFULFILL UI OF DIGITAL PHOTO FRAMEBASED ON ATMELVIEWABSTRACTAtmel Corporation39?，F(xiàn)代軟件工程理論將軟件測試作為軟件開發(fā)過程的重要組成部分，軟件開發(fā)過程中有一半以上的資源都花費在軟件測試上。圖11 缺陷數(shù)量收斂圖. 軟件測試工具發(fā)展現(xiàn)狀純手工地進行軟件測試往往是費時費力的，而且測試人員容易因為疏忽產(chǎn)生失誤，測試準確性無法得到足夠的保證?；谀Ｐ偷臏y試（MBT, ModelBased Testing）是一種輕量級自動生成測試用例的方法，測試人員的關(guān)注點在于構(gòu)建一個能夠描述被測系統(tǒng)各方面數(shù)據(jù)和行為的形式化機器可讀模型。其它的一些研究結(jié)果中（如圖12），和人工測試相比MBT都是發(fā)現(xiàn)更多或者相同數(shù)量的錯誤。此外， MBT具有良好的應付軟件需求變更的能力。此外，軍方也積極嘗試MBT技術(shù)，比如美國海軍水面戰(zhàn)中心開發(fā)的SMERFS[10]和CASRE[11]。第四章使用類圖和算法偽代碼詳細討論系統(tǒng)的設計和實現(xiàn)。圖21 MBT一般操作流程[13]上圖展示了MBT的一般操作流程。有限狀態(tài)機（FSM， Finite State Machine）模型可以被認為是該類模型的鼻祖，是極其重要的一種模型表現(xiàn)形式。而且FMS模型也最為簡便，測試工具識別起來沒有任何問題，降低了編寫測試工具的難度，測試人員構(gòu)建模型時可以從SUT設計文檔中的UML狀態(tài)圖稍加變化直接轉(zhuǎn)化而來。于是可以用各種約束來建立MBT的模型，收集不同執(zhí)行路徑中數(shù)據(jù)約束再利用約束編程中的方法求解得到測試用例。通常情況下，GUI又可以分為不同的層次結(jié)構(gòu)，比如整個GUI系統(tǒng)是由各種對話框所組成的，那么系統(tǒng)的事件流圖就是由對話框各自的事件流圖組成的。軟件開發(fā)者和用戶經(jīng)常還會遇到這樣的問題，把同樣的軟件應用從一臺機器換到另外一臺機器上使用時，原先從未出過故障的軟件突然變得無法正常使用。如果測試用例集包含了任意t個參數(shù)的所有取值組合，那么稱該測試用例集組合強度為t，或者說它是tway的。至于生成高組合強度的測試用例，測試用例集發(fā)現(xiàn)錯誤的能力沒有實質(zhì)上的提高，卻會導致生成算法的更加復雜化和產(chǎn)生多得多的測試用例。2覆蓋數(shù)組并不唯一，這只是其中一種情況。另一種構(gòu)造方法剛好相反，是由已知的小覆蓋數(shù)組遞歸構(gòu)造出大覆蓋數(shù)組。更為有效的方法是貪心算法，貪心算法的思想是從空矩陣開始，然后逐行或者逐列地擴展矩陣，直到所有的t元組都被覆蓋。. MBT預期輸出生成三大關(guān)鍵技術(shù)就只剩下輔助性內(nèi)容生成工具了，輔助性工具主要還是為了解決預期輸出的生成問題。token_1和token_2執(zhí)行過程中如果發(fā)現(xiàn)錯誤會觸發(fā)異常，程序打印出錯誤提示，同時導致測試用例的總錯誤個數(shù)加一。用戶使用該工具生成測試用例的流程如下：圖31 生成測試用例流程用戶可以直接繪制FSM模型，或者在以前保存的模型基礎上修改模型，工具支持FSM模型的序列化與反序列化。圖32 系統(tǒng)總體架構(gòu)用戶不是生硬地使用形式化語言來描述FSM數(shù)據(jù)模型，工具提供了可視化界面，實現(xiàn)了鼠標選取不同繪圖元素再拖拽調(diào)整的繪圖方式。狀態(tài)由類State描述，該類的屬性有狀態(tài)標識id、狀態(tài)類型type和狀態(tài)后置動作鏈表nextActions?？紤]到函數(shù)過程和轉(zhuǎn)換動作的相似性，類FunctionImpl中直接包含了一個類Action的實例。這些類對應于FSM數(shù)據(jù)模型中的類，繪圖的實際過程由C，涉及到的API[24]參見表41。XmlAttribute表示把該屬性作為對象XML根節(jié)點的一個屬性；XmlArray表示該屬性是數(shù)組類型的，整個屬性將被添加為根節(jié)點的一個子節(jié)點，另外每個數(shù)組元素又會被序列化為該子節(jié)點的一個子節(jié)點；XmlIgnore則表示忽略此屬性，該屬性不參與對象的序列化過程。對于工具生成的測試用例集，用戶還可以在條件允許的情況下篩選出與SUT使用場景緊密相關(guān)的部分測試用例，形成最終的測試用例集。假設我們需要對A、B、C三個參數(shù)進行pairwise組合測試，A和B有兩種可能取值，C有三種可能取值。因為ri中還有未確定取值的參數(shù)B，所以繼續(xù)while循環(huán)到else部分，考慮所有取值情況集合P中包含至少一個未確定取值參數(shù)的子集Q，再從Q中篩選出與ri取值一致的取值情況。輸入?yún)?shù)和輸出格式由類PictInputVariable和類PictOutputVariable說明，因為輸出都是包含一組參數(shù)的取值情況的，所以類PictOutputVarList內(nèi)部封裝了一個類PictOutputVariable的鏈表。工具欄下方的按鈕代表的是三種不同的繪圖工具：最左邊的是選取工具，中間的是添加狀態(tài)工具，最右邊的是添加轉(zhuǎn)換動作工具。使用工具繪制的ATM系統(tǒng)FSM模型如圖52。添加的token必須被賦予適當個數(shù)的參數(shù)，參數(shù)之間用逗號分隔，工具會自動檢查用戶輸入的參數(shù)是否和token定義所匹配。目測有效測試用例的長度不超過10，同時指定最大重復次數(shù)為1，即產(chǎn)生的測試用例中將不包含任何回路。模型的表現(xiàn)形式、測試用例生成算法和預期輸出的生成是基于模型測試的三項關(guān)鍵技術(shù)。 參考文獻[1] Software Errors Cost . Economy $ Billion Annually, NIST Report[2] Baker, C. Review of . McCracken’s “Digital Computer Programming”.Mathematical Tables and Other Aids to Computation 1 I, 60(Oct. 1957). 298305.[3] Myers, . The Art of Software Testing. John Wiley amp。最終開發(fā)完成的基于模型的自動化測試工具基本達到了預期的各項要求。圖58 測試用例執(zhí)行結(jié)果第