面向winform_control的自動化測試框架的設(shè)計與實現(xiàn)-畢業(yè)設(shè)計

1、<p><b>　　摘要</b></p><p>　　隨著控件技術(shù)的不斷發(fā)展，用戶對WinForm Control的需求不斷增加，使得WinForm Control逐漸產(chǎn)品化，一批以WinForm Control為產(chǎn)品的公司或者部門的建立更加推動了其快速發(fā)展。與此同時，也給WinForm Control的自動化測試提出了新的要求。目前，現(xiàn)有的用于WinForm Control自動化

2、測試的自動化測試框架都是單元測試框架，只能用于測試WinForm Control的基本屬性、方法和事件，而其他測試只能手動進行，因此，開發(fā)一套面向WinForm Control的自動化測試框架是非常有必要的。</p><p>　　本文深入研究了WinForm Control的特點，詳細分析了WinForm Control自動化測試的原理及過程，對現(xiàn)有的單元測試框架做了簡單的介紹，通過研究，在單元測試框架NUnit

3、的基礎(chǔ)上，著重處理鼠標和鍵盤的交互操作，并將GUI測試思想應用到WinForm Control的自動化測試中，將WinForm Control的各個組成部分抽象成一個ComponentGUI，讓測試人員可以方便地定位控件并進行自動化測試，最終實現(xiàn)了面向WinForm Control的自動化測試框架。整個框架在設(shè)計上充分考慮了代碼的可復用性、可移植性和可維護性。目前，該自動化測試框架已經(jīng)在日本多家控件公司投入使用，達到實用化水平。<

4、/p><p>　　關(guān)鍵詞：WinForm Control 自動化測試 GUI Input</p><p><b>　　Abstract</b></p><p>　　With the continuous development of control techniques and the increasing demand for WinFo

5、rm Control，WinForm Control is gradually commercialized in recent years，and the establishment of a group of corporations or departments taking WinForm Control as their product further promotes its rapid development. Meanw

6、hile, new requirements of automatic testing of WinForm Control have been arisen. At present，existing automatic testing frameworks for WinForm Control are all unit testing frameworks，which can</p><p>　　In thi

7、s article，the features of WinForm Control are firstly introduced，then，the principles and procedures of automatic testing for WinForm Control are discussed in detail and existing unit testing frameworks are also introduce

8、d briefly. Finally，a new automatic testing framework for WinForm Control is introduced. The new framework is mainly based on the following ideas：on the basis of the unit testing framework NUnit，focusing on the handling o

9、f the interactive operations of keyboard and mouse；and</p><p>　　KeyWords: WinForm Control Automatic Testing GUI Input</p><p><b>　　目錄</b></p><p><b>　　第一章 緒論1&

10、lt;/b></p><p>　　1.1 研究背景1</p><p>　　1.2 國內(nèi)外現(xiàn)狀2</p><p>　　1.3 課題的意義2</p><p>　　1.4 論文的工作和結(jié)構(gòu)3</p><p>　　第二章 WinForm Control及常用單元測試框架5</p><p>

11、;　　2.1 WinForm Control的定義及分類5</p><p>　　2.1.1 WinForm Control的定義5</p><p>　　2.1.2 WinForm Control的分類6</p><p>　　2.2 常用單元測試框架9</p><p>　　2.2.1 JUnit測試框架原理9</p>&

12、lt;p>　　2.2.2 CppUnit測試框架原理12</p><p>　　2.2.3 NUnit測試框架原理13</p><p>　　2.2.4 XUnit.net測試框架原理15</p><p><b>　　2.3 小結(jié)16</b></p><p>　　第三章 WinForm Control自動化測試

13、研究與分析17</p><p>　　3.1 WinForm Control自動化測試原理分析17</p><p>　　3.1.1 基本屬性、方法和事件的測試17</p><p>　　3.1.2 鼠標和鍵盤相關(guān)事件的測試20</p><p>　　3.1.3 GUI測試24</p><p>　　3.2 WinFo

14、rm Control自動化測試的流程26</p><p>　　3.3 WinForm Control自動化測試的優(yōu)點26</p><p><b>　　3.4 小結(jié)27</b></p><p>　　第四章 面向WinForm Control的自動化測試框架的設(shè)計29</p><p>　　4.1 GUI測試框架的設(shè)計

15、29</p><p>　　4.2 Input測試框架的設(shè)計35</p><p>　　4.2.1 鼠標輸入測試框架的設(shè)計35</p><p>　　4.2.2 鍵盤輸入測試框架的設(shè)計38</p><p>　　4.3 結(jié)果比較方法的設(shè)計40</p><p>　　4.4 面向WinForm Control的自動化測試

16、框架的優(yōu)點41</p><p><b>　　4.5 小結(jié)42</b></p><p>　　第五章 面向WinForm Control的自動化測試框架的驗證45</p><p>　　5.1 制定測試用例45</p><p>　　5.2 編寫測試腳本46</p><p>　　5.3 運行測試

17、腳本51</p><p>　　5.4 生成測試報告53</p><p><b>　　5.5 小結(jié)54</b></p><p>　　第六章 結(jié)束語55</p><p><b>　　致謝57</b></p><p><b>　　參考文獻59</b>

18、;</p><p><b>　　第一章 緒論</b></p><p>　　隨著計算機技術(shù)的發(fā)展，人們對軟件產(chǎn)品的質(zhì)量有了更高的要求，因此軟件測試工作在整個軟件開發(fā)的過程中也越發(fā)重要。從繁雜的手工測試到實用性強的自動化測試，從最初只提供簡單的捕捉/回放功能的測試工具到功能和靈活性更強的測試腳本工具，自動化測試已經(jīng)取得了很大的進步[2]。但隨著軟件規(guī)模的不斷擴大，軟件類型

19、的不斷增多，人們希望自動化測試能夠更加高效和簡便。自動化測試框架的出現(xiàn)，加速了自動化腳本的生成，提高腳本的可維護性，加速腳本執(zhí)行效率等，目的是減少實現(xiàn)和維護的成本，使測試人員可以把精力集中在應用程序的測試用例設(shè)計上，而不是開發(fā)測試。</p><p><b>　　1.1 研究背景</b></p><p>　　2001年后，.NET Framework2.0的誕生，人們將

20、它看作是多年來最重要的新技術(shù)。.NET Framework以多種方式對面向組件的開發(fā)模式做了強而有力的支持。.NET Framework為開發(fā)人員提供了兩種控件支持：一種是Web Control，一種是WinForm Control[15]。其中WinForm Control是目前發(fā)展最快，應用最廣泛的。.NET Framework使得開發(fā)人員可以通過將多個標準WinForm Control組合，而定制出符合用戶需求的應用程序。開發(fā)人員

21、還可以通過繼承某個標準WinForm Control，附加新的功能與業(yè)務(wù)邏輯滿足自己的需要。更高級的開發(fā)人員可以直接從.NET Framework提供的Control基類派生出自定義的WinForm Control（Custom Control）[20]。盡管面向組件的開發(fā)模式和.NET Framework的支持，使得WinForm Control的開發(fā)人員以及廠商獲取了更多的好處，但卻給WinForm Control的測試工作帶

22、來了很多困難，因為目前市場上并不存在面向WinForm C</p><p><b>　　1.2 國內(nèi)外現(xiàn)狀</b></p><p>　　目前，可用于對WinForm Control的基本屬性、方法和事件進行自動化測試的單元測試框架很多，常用的單元測試框架根據(jù)開發(fā)語言不同，可分為[13]：</p><p>　　1 JUnit：JUnit就是為Ja

23、va程序開發(fā)者實現(xiàn)單元測試提供一種框架，使得Java單元測試更規(guī)范有效，并且更有利于測試的集成。此框架是由Alan Ray和Erich Gamma開發(fā)的。</p><p>　　2 CppUnit：CppUnit是從著名的JUnit框架為C++移植過來的。是由Michael Feathers開發(fā)的。</p><p>　　3 Microsoft.NET Framework提供的單元測試框架，包

24、括：NUnit、CsUnit、MbUnit和XUnit.net。許多.NET開發(fā)人員都或多或少有一些使用NUnit的經(jīng)驗，它是.NET的一個最主要的單元測試框架，是由James Newkirk所開發(fā)的。雖然NUnit涵蓋了.NET應用程序單元測試的大多數(shù)必要情景，但MbUnit可以讓單元測試更進一步。MbUnit是由Jonathan “Peli” de Halleux首先編寫的一個開源單元測試框架。最新推出的單元測試框架為XUnit.n

25、et，此框架從現(xiàn)有框架中脫穎而出的因素有很多。最重要的一點是，它是由James Newkirk和Brad Wilson構(gòu)建的。Newkirk是Microsoft負責CodePlex項目的產(chǎn)品經(jīng)理，曾幫助構(gòu)建NUnit，他撰寫了大量有關(guān)于單元測試的書籍。Brad Wilson是thedotguy上的一位資深博客作者，模式和實施方案小組的前成員，還是Microsoft的特別員工。這一全新框架的目標是利用在過去五年內(nèi)積累的有關(guān)單元測試的最佳實

26、踐，構(gòu)建一種能體現(xiàn)并鼓勵這些實踐的全新框架[23</p><p><b>　　1.3 課題的意義</b></p><p>　　目前，單元測試框架技術(shù)一直在不斷發(fā)展，現(xiàn)有的單元測試框架也一直在被更新和改進，但隨著WinForm Control的類型和復雜度不斷增加，現(xiàn)有的單元測試框架無法準確定位WinForm Control，尤其是無法獲取WinForm Control

27、的各個組成部分信息并進行測試，而且現(xiàn)有的單元測試框架也無法模擬鼠標和鍵盤的操作，因此無法測試用鼠標和鍵盤對WinForm Control操作后的結(jié)果是否正確，也無法監(jiān)聽鼠標或鍵盤觸發(fā)的事件是否正確，驗證數(shù)據(jù)和腳本代碼維護也有諸多不便，由此可見，現(xiàn)有的單元測試框架已經(jīng)無法滿足現(xiàn)有WinForm Control的自動化測試需求。本人通過在西安某控件開發(fā)公司一年的實習，在NUnit單元測試框架的基礎(chǔ)上，設(shè)計并實現(xiàn)了GUI測試框架和Input測

28、試框架，最終成功開發(fā)了這套面向WinForm Control的自動化測試框架，此框架不僅基本解決了現(xiàn)有WinForm Control自動化測試存在的問題，而且對于面向控件的自動化測試框架的研究具有長遠的現(xiàn)實意義。目前，該框架已被很多日本控件公司投入使用，取得了良好的市場反映。</p><p>　　1.4 論文的工作和結(jié)構(gòu)</p><p>　　本論文選題來自西安某控件開發(fā)公司基于面向WinF

29、orm Control的自動化測試系統(tǒng)研發(fā)項目。</p><p>　　本人在WinForm Control自動化測試的研究與設(shè)計自動化測試框架的工作經(jīng)歷了四個主要階段：</p><p>　　第一階段：學習階段。在原有單元測試框架的理論基礎(chǔ)上，進一步對NUnit單元測試框架進行了深入學習，閱讀了大量自動化測試及WinForm Control開發(fā)技術(shù)的書籍，為后續(xù)的工作奠定了良好的專業(yè)理論基礎(chǔ)

30、。同時，為了更好地進行自動化測試框架的設(shè)計，學習了C#語言和相關(guān)開發(fā)工具。</p><p>　　第二階段：研究階段。對WinForm Control的測試特點進行分析和研究，總結(jié)了WinForm Control自動化測試的特點和原理，并給出了WinForm Control自動化測試的流程，為WinForm Control自動化測試框架的設(shè)計提供了明確方案。</p><p>　　第三階段：設(shè)

31、計階段。根據(jù)目前WinForm Control自動化測試存在的問題，在之前研究方案的基礎(chǔ)上，設(shè)計了GUI測試框架和Input測試框架，最終實現(xiàn)了面向WinForm Control的自動化測試框架。</p><p>　　第四階段：驗證階段。通過幾個典型的測試用例，證明了面向WinForm Control的自動化測試框架的實用性。</p><p>　　根據(jù)所完成的工作，將論文結(jié)構(gòu)安排如下：&l

32、t;/p><p><b>　　第一章 緒論</b></p><p>　　本章首先分析了課題的研究背景，然后通過介紹國內(nèi)外現(xiàn)有的單元測試框架，分析了現(xiàn)有的單元測試框架無法滿足WinForm Control自動化測試需求的原因，闡明了開發(fā)一套面向WinForm Control的自動化測試框架的意義，最后對論文的工作進行了總結(jié)以及對各章節(jié)內(nèi)容進行了安排。</p>

33、<p>　　第二章 WinForm Control及常用單元測試框架</p><p>　　本章介紹了WinForm Control的定義及分類，并分析了幾個常用的單元測試框架的原理。</p><p>　　第三章 WinForm Control自動化測試研究與分析</p><p>　　本章根據(jù)WinForm Control的特點，研究總結(jié)了WinForm C

34、ontrol自動化測試的原理，著重研究了鼠標和鍵盤的事件處理，提出了WinForm Control的GUI測試思想，并給出了WinForm Control自動化測試的流程及分析了WinForm Control自動化測試的優(yōu)點。</p><p>　　第四章 面向WinForm Control的自動化測試框架的設(shè)計</p><p>　　本章詳細描述了如何對GUI測試框架和Input測試框架進行

35、設(shè)計實現(xiàn)，以及對結(jié)果比較方法的設(shè)計實現(xiàn)，并分析了面向WinForm Control的自動化測試框架的優(yōu)點。</p><p>　　第五章 面向WinForm Control的自動化測試框架的驗證</p><p>　　本章將此框架運用于WinForm Control的自動化測試工作中，根據(jù)具體的測試用例，運用此框架編寫測試腳本，根據(jù)腳本運行的情況及測試結(jié)果報告，驗證了框架的正確性和實用性。&l

36、t;/p><p><b>　　第六章 結(jié)束語</b></p><p>　　本章一方面對本文所研究的項目加以總結(jié)，另一方面提出進一步改進和完善該項目的方法。希望能有更多更好的面向控件領(lǐng)域的自動化測試框架推出，并投入實際生產(chǎn)當中。</p><p>　　第二章 WinForm Control及常用單元測試框架</p><p>　　

37、2.1 WinForm Control的定義及分類</p><p>　　控件（Control）是在圖形用戶界面（GUI）中屏幕上的一種對象，用戶可操作該對象來執(zhí)行某一行為。 控件是用戶可與之交互以輸入或操作數(shù)據(jù)的對象?？丶ǔ３霈F(xiàn)在對話框中或工具欄上[16]。WinForm Control是控件的一種，目前，對于WinForm Control的應用非常廣泛。</p><p>　　2.1.1

38、 WinForm Control的定義</p><p>　　.NET Framework為開發(fā)人員提供了兩種控件支持。一種是Web Control，一種是WinForm Control。顧名思義，Web Control是Web開發(fā)所需要的控件產(chǎn)品，而WinForm Control則是在設(shè)計和開發(fā)Windows應用程序時，用到的控件[17]。</p><p>　　WinForm Contro

39、l是可重用的控件，它們封裝了用戶界面的功能，可以在基于Windows的客戶端應用程序中使用。“Windows窗體”不僅提供了許多現(xiàn)成控件，還提供了自行開發(fā)控件的基礎(chǔ)結(jié)構(gòu)?？梢越M合現(xiàn)有控件、擴展現(xiàn)有控件或創(chuàng)作自己的自定義控件。</p><p>　　WinForm Control是從System.Windows.Forms.Control直接或間接派生的類。以下列表描述了開發(fā)Windows窗體控件的常見方案[9]：&

40、lt;/p><p>　　1 組合現(xiàn)有控件來創(chuàng)作一個復合控件。</p><p>　　復合控件封裝有一個可以作為控件重復使用的用戶界面。其中的一個示例就是由文本框和重置按鈕組成的控件?？梢暬O(shè)計器為創(chuàng)建復合控件提供了有力的支持。若要創(chuàng)作復合控件，請從System.Windows.Forms.UserControl派生?；怳serControl為子控件提供了鍵盤路由并使子控件可以作為一個組進行工作

41、。</p><p>　　2 擴展現(xiàn)有控件，對其進行自定義或為其添加功能。</p><p>　　一個不能更改顏色的按鈕和一個具有跟蹤點擊次數(shù)屬性的按鈕就是擴展控件的具體示例?？梢酝ㄟ^從任何Windows窗體控件派生控件并重寫或添加屬性、方法和事件的方式來自定義Windows窗體控件。</p><p>　　3 創(chuàng)作一個不是通過組合或擴展現(xiàn)有控件而形成的控件。</p

42、><p>　　在這種方案中，需從基類Control派生控件。可以添加和重寫基類的屬性、方法和事件。</p><p>　　4 WinForm Control的基類提供了客戶端基于Windows的應用程序中的可視顯示所需的機制。Control提供窗口句柄，處理消息路由，并提供鼠標和鍵盤事件以及許多其他用戶界面事件。還提供了高級布局，并具有特定于可視顯示的屬性，如ForeColour、BackCol

43、our、Height、Width和許多其他屬性。此外，它還提供了安全性、線程支持以及與ActiveX控件的交互性。由于基類提供了很多基礎(chǔ)結(jié)構(gòu)，使得開發(fā)自己的Windows窗體控件變得相對簡單。</p><p>　　2.1.2 WinForm Control的分類</p><p>　　目前，微軟已經(jīng)推出三代控件，分別是：</p><p>　　1 ActiveX控件：A

44、ctiveX控件是微軟公司提供的功能強大的程序設(shè)計和開發(fā)技術(shù)，是COM組件開發(fā)技術(shù)的重要組成部分。它是OLE的第三個版本，對原先OLE控件的最大擴展是增加了Internet功能，它不僅可以在支持OLE控件的容器中使用，更可以作為一個Internet控件，直接成為網(wǎng)頁的一部分。另外，ActiveX控件作為一種可重用的組件，相當于一個封裝好的代碼模塊，它是通過其方法、屬性、事件來與應用程序進行通信的，此外，ActiveX控件是與開發(fā)語言無關(guān)

45、的。用戶在使用控件時不必考慮它是VC還是用VB等其它語言開發(fā)的，應用程序都是通過COM與控件進行通信的[19]?？梢?，任何支持ActiveX控件的軟件平臺上都可以使用ActiveX控件，它使得不同廠商所開發(fā)的控件可以真正地組裝在一起，從而令軟件的生產(chǎn)過程類似于硬件業(yè)的各個插件的裝配過程一樣，實現(xiàn)了軟件的工業(yè)化，大大降低了軟件的開發(fā)成本，極大地提高了軟件的生產(chǎn)效率，實現(xiàn)了軟件資源的共享。</p><p>　　2 C

46、OM控件：COM組件是以WIN32動態(tài)鏈接庫（DLL）或可執(zhí)行文件（EXE）形式發(fā)布的可執(zhí)行代碼組成，它是遵循COM規(guī)范編寫的，是一些小的二進制可執(zhí)行文件，COM控件可以給應用程序、操作系統(tǒng)以及其他組件提供服務(wù)。自定義的COM控件可以在運行時刻同其他組件連接起來構(gòu)成某個應用程序。COM組件可以動態(tài)的插入或卸出應用，而且必須是動態(tài)鏈接的，它必須隱藏（封裝）其內(nèi)部實現(xiàn)細節(jié)，必須可以在不妨礙已有用戶的情況下被升級，且可以透明的在網(wǎng)絡(luò)上被重新分

47、配位置[24]。</p><p>　　3 WinForm Control：常用的WinForm Control可以分為六大類[11]，分別是：</p><p>　　(1)最根本的父控件Form：</p><p>　　這個類別中只包含一種控件：窗體類。這樣分類的理由在于：窗體類是所有其他類的父親（parent），這里的“父親”你可以作以下的理解。</p>

48、<p>　　如果這里的“父親”你理解作“容器”，那么窗體類是所有控件的父類。這就是說，每個控件在視覺上都處在某個窗體中（或者是在別的控件中，例如面板（Panel）控件，面板控件自己還是被包含在一個窗體中的）。 </p><p>　　(2)容器控件，常用的有：</p><p><b>　　1) Panel</b></p><p>　　

49、2) TabControl</p><p>　　3) TabPage</p><p>　　4) FlowLayoutPanel</p><p>　　5) GroupBox</p><p>　　容器控件用來盛放別的控件。它們沒有自己的GUI能力，而是依賴于被包含的控件來做真正的工作。把控件放在一個容器中的真正理由在于，你能夠把放在其中的控件做為

50、一個整體進行顯示、隱藏、移動等操作。</p><p>　　容器控件都能接受鼠標事件，而別的控件類都不能接受原始鼠標輸入。對別的控件而言，鼠標消息被轉(zhuǎn)換成特定控件事件，例如Click事件，或者產(chǎn)生一個副作用，例如使控件獲得或失去焦點。</p><p>　　(3)單項控件，常用的有：</p><p><b>　　1) Button</b></

51、p><p>　　2) CheckBox</p><p>　　3) CheckedListBox</p><p><b>　　4) Label</b></p><p>　　5) PictureBox</p><p>　　6) RadioButton</p><p>　　7) St

52、atusBar</p><p>　　8) TextBox</p><p>　　9) ProgressBar</p><p>　　單項控件通常用來顯示和接收單項信息。它們具有用以保存數(shù)值的Text屬性，并且當這一數(shù)值改變時，它們會接收到一個TextChanged事件。舉例來說，如果一個用戶正在向一個TextBox控件輸入文本，那么每一個被輸入的字符都會引發(fā)TextCh

53、anged事件。</p><p>　　所有的單項控件都支持一種被稱為數(shù)據(jù)綁定的特性。這個特性使你可以將你的用戶界面對象連接到數(shù)據(jù)對象。這樣的連接一旦建立，任何用戶界面中的改變都會引起內(nèi)存中對應對象的自動更新——反之亦然。數(shù)據(jù)綁定使得在此之前的GUI程序員必須手動處理的工作得以自動完成，并且使你的編碼工作大大簡化。所有的單項控件都使用了同樣的數(shù)據(jù)綁定方法，這種方法被稱為簡單數(shù)據(jù)綁定[4]。</p>&

54、lt;p>　　(4)復合項控件，常用的有：</p><p>　　1) ComboBox</p><p>　　2) DataGrid</p><p>　　3) DominUpDown</p><p>　　4) ListBox</p><p>　　5) ListView</p><p>　　6

55、) TreeView</p><p>　　復合項控件可以顯示一個列表或是一個數(shù)組，并且允許用戶從列表中選取某一選項。每一個控件類都允許你通過容器來訪問被顯示的數(shù)據(jù)——數(shù)組或是列表——這被作為控件的一個屬性得以實現(xiàn)。這些控件使你可以使用面向?qū)ο蟮姆绞絹碓L問底層數(shù)據(jù)。對幾乎所用控件而言——除了DataGrid控件——實際的數(shù)據(jù)都存在于一個對應的底層Win32控件之中。</p><p>　　除了

56、DataGrid控件之外，每一個復合項控件都允許你在程序編譯時給定一個初始化列表。Visual Studio .NET設(shè)計器使你可以通過控件的屬性窗口來創(chuàng)建這一列表。（對樹形控件（TreeView）而言，用來初始化的集合被稱為節(jié)點（Node），并且這一集合擁有和其他控件初始集合平面結(jié)構(gòu)不相同的層次結(jié)構(gòu)。）這一為控件設(shè)定初始值的能力將使你的工作變得簡單，因為除非在運行時（runtime）才知道初始值，設(shè)計器都可以提前為你創(chuàng)建初始化所需代碼

57、。如果你確實需要在運行時再進行初始化，那么在你開始學習怎樣訪問初始化集合時，看看設(shè)計器所產(chǎn)生的代碼是個不錯的選擇[10]。</p><p>　　為了幫助你將程序中的數(shù)據(jù)與這些控件的數(shù)據(jù)在運行時相連接，復合項控件也支持數(shù)據(jù)綁定。復合項控件實現(xiàn)數(shù)據(jù)綁定的方法與單項控件的大不相同。這里就不再詳細介紹了。</p><p>　　(5)命令輸入控件，常用的有：</p><p>

58、　　1) ContextMenu</p><p>　　2) MainMenu</p><p>　　3) MenuItem</p><p>　　4) ToolBar</p><p>　　5) ToolBarButton</p><p>　　命令輸入控件允許用戶指定一個操作以便執(zhí)行，這通常通過直接在控件上的點擊完成。每個命

59、令輸入控件具有Text屬性描述這一操作，還有三個布爾屬性——Visible，Enabled和Checked——來指示控件的狀態(tài)。當被用戶選中時，該控件會接到一個Click事件。</p><p>　　(6)背景控件，常用的有：</p><p><b>　　1) Timer</b></p><p>　　2) ImageList</p>

60、<p>　　背景控件沒有圖形界面，因此它們對用戶是不可見的，而且它們只能被包含在窗體控件中，而不能被放置于容器控件中。</p><p>　　Timer控件在一定間隔觸發(fā)Tick事件，這一時間間隔在Interval屬性中指定（以毫秒為單位）。這一屬性是一個整型值，因此可接收的范圍從1毫秒到Int32.MaxValue毫秒，也就是大約23天。一旦被啟動并且Enabled屬性為真（true）,</p&

61、gt;<p>　　Timer控件就會不停的觸發(fā)Tick事件，這使它看起來有點像一個鬧鐘。一旦被設(shè)定，它就每過Interval屬性個毫秒報響。你可以通過將Enabled屬性設(shè)置為假（False）來關(guān)掉它。計時器事件的優(yōu)先級較低。例如在用戶點擊一個TextBox控件的同時，一個Timer控件也觸發(fā)了一個事件，那么所有點擊觸發(fā)的事件（例如GotFocus, LostFocus，Validating和Validated）都會在Ti

62、ck事件提交之前被處理。</p><p>　　ImageList控件可以存放一組圖像，這通常被用來支持ToolBar按鈕。和別的控件一樣，你可以在Visual Studio .NET設(shè)計器中為ImageList控件設(shè)定初始值——一組圖像[10]。Visual Studio .NET支持的文件類型范圍很廣，包括支持位圖（bitmaps）、JPEG、GIF、PNG、Icons和Window圖元文件（Window me

63、tafiles）。</p><p>　　2.2 常用單元測試框架</p><p>　　目前，專門用于WinForm Control的自動化測試框架并不存在，一般的開發(fā)WinForm Control的公司都是用常用的單元測試框架對WinForm Control的基本屬性、方法及事件進行自動化測試，其他大部分對于WinForm Control的測試只能依靠測試人員手動完成。目前的最流行的單元測

64、試框架是XUnit系列框架。常用的有JUnit、CppUnit、NUnit以及XUnit.net[23]。</p><p>　　2.2.1 JUnit測試框架原理</p><p>　　JUnit就是為Java程序開發(fā)者實現(xiàn)單元測試提供一種框架，使得Java單元測試更規(guī)范有效，并且更有利于測試的集成[5]。 </p><p>　　1 JUnit的優(yōu)點</p>

65、;<p>　　(1)可以使測試代碼與產(chǎn)品代碼分開。</p><p>　　(2)針對某一個類的測試代碼通過較少的改動便可以應用于另一個類的測試。</p><p>　　(3)易于集成到測試人員的構(gòu)建過程中，JUnit和Ant的結(jié)合可以實施增量開發(fā)。</p><p>　　(4)JUnit是公開源代碼的，可以進行二次開發(fā)。</p><p&g

66、t;　　(5)可以方便地對JUnit進行擴展。</p><p>　　2 JUnit的編寫原則</p><p>　　(1)簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫。</p><p>　　(2)是使測試單元保持持久性。</p><p>　　(3)是可以利用既有的測試來編寫相關(guān)的測試。</p><p>

67、　　3 JUnit的特點</p><p>　　(1)使用斷言方法判斷期望值和實際值差異，返回Boolean值。</p><p>　　(2)測試驅(qū)動設(shè)備使用共同的初始化變量或者實例。</p><p>　　(3)測試包結(jié)構(gòu)便于組織和集成運行。</p><p>　　(4)支持圖型交互模式和文本交互模式。</p><p>　　

68、4 JUnit框架的組成</p><p>　　(1)對測試目標進行測試的方法與過程集合，可稱為測試用例(TestCase)。</p><p>　　(2)測試用例的集合，可容納多個測試用例(TestCase)，將其稱作測試包(TestSuite)。JUnit框架是一個典型的Composite模式：TestSuite可以容納任何派生自Test的對象；當調(diào)用TestSuite對象的run()方法

69、是，會遍歷自己容納的對象，逐個調(diào)用它們的run()方法。</p><p>　　(3)測試結(jié)果的描述與記錄。(TestResult) 。</p><p>　　(4)測試過程中的事件監(jiān)聽者(TestListener)。</p><p>　　(5)每一個測試方法所發(fā)生的與預期不一致狀況的描述，稱其測試失敗元素(TestFailure)</p><p&g

70、t;　　(6)JUnit Framework中的出錯異常（AssertionFailedError）。</p><p>　　5 JUnit中常用的接口和類</p><p>　　(1)Test接口——運行測試和收集測試結(jié)果</p><p>　　Test接口使用了Composite設(shè)計模式，是單獨測試用例 （TestCase），聚合測試模式（TestSuite）及測試擴

71、展（TestDecorator）的共同接口。它的public int countTestCases（）方法，它來統(tǒng)計這次測試有多少個TestCase，另外一個方法就是public void run（TestResult），TestResult是實例接受測試結(jié)果，run方法執(zhí)行本次測試。</p><p>　　(2)TestCase抽象類——定義測試中固定方法</p><p>　　TestCa

72、se是Test接口的抽象實現(xiàn)，（不能被實例化，只能被繼承）其構(gòu)造函數(shù)TestCase(string name)根據(jù)輸入的測試名稱name創(chuàng)建一個測試實例。由于每一個TestCase在創(chuàng)建時都要有一個名稱，若某測試失敗了，便可識別出是哪個測試失敗。 TestCase類中包含的setUp()、tearDown()方法。setUp()方法集中初始化測試所需的所有變量和實例，并且在依次調(diào)用測試類中的每個測試方法之前再次執(zhí)行setUp(

73、)方法。tearDown()方法則是在每個測試方法之后，釋放測試程序方法中引用的變量和實例。 開發(fā)人員編寫測試用例時，只需繼承TestCase，來完成run方法即可，然后JUnit獲得測試用例，執(zhí)行它的run方法，把測試結(jié)果記錄在TestResult之中。 </p><p>　　(3)Assert靜態(tài)類——一系列斷言方法的集合</p><p>　　Assert包含了一組靜態(tài)的測試

74、方法，用于期望值和實際值比對是否正確，即測試失敗，Assert類就會拋出一個AssertionFailedError異常，JUnit測試框架將這種錯誤歸入Failes并加以記錄，同時標志為未通過測試。如果該類方法中指定一個String類型的傳參則該參數(shù)將被做為AssertionFailedError異常的標識信息，告訴測試人員該異常的詳細信息。 JUnit 提供了6大類31組斷言方法，包括基礎(chǔ)斷言、數(shù)字斷言、字符斷言、布爾斷言、

75、對象斷言。其中assertEquals（Object expected，Object actual）內(nèi)部邏輯判斷使用equals()方法，這表明斷言兩個實例的內(nèi)部哈希值是否相等時，最好使用該方法對相應類實例的值進行比較。而assertSame（Object expected，Object actual）內(nèi)部邏輯判斷使用了Java運算符“==”，這表明該斷言判斷兩個實例是否來自于同一個引用（Reference），最好使用該方法對不同類的實

76、例的值進行比對。assertEquals(String message，String e</p><p>　　(4)TestSuite測試包類——多個測試的組合</p><p>　　TestSuite類負責組裝多個Test Cases。待測的類中可能包括了對被測類的多個測試，而TestSuite負責收集這些測試，使我們可以在一個測試中，完成全部的對被測類的多個測試。 TestSu

77、ite類實現(xiàn)了Test接口，且可以包含其它的TestSuites。它可以處理加入Test時的所有拋出的異常。 TestSuite處理測試用例有6個規(guī)約（否則會被拒絕執(zhí)行測試）        1)測試用例必須是公有類（Public）</p><p>　　2)測試用例必須繼承與TestCase類 </p><p>

78、;　　3)測試用例的測試方法必須是公有的（Public）</p><p>　　4)測試用例的測試方法必須被聲明為Void</p><p>　　5)測試用例中測試方法的前置名詞必須是test</p><p>　　6)測試用例中測試方法無任何傳遞參數(shù)</p><p>　　(5)TestResult結(jié)果類和其它類與接口</p><

79、;p>　　TestResult結(jié)果類集合了任意測試累加結(jié)果，通過TestResult實例傳遞每個測試的Run()方法。TestResult在執(zhí)行TestCase時如果失敗會異常拋出。TestListener接口是個事件監(jiān)聽規(guī)約，可供TestRunner類使用。它通知listener的對象相關(guān)事件，方法包括測試開始startTest(Test test)，測試結(jié)束endTest(Test test)，增加異常addError(Tes

80、t test,Throwable t)和增加失敗addFailure(Test test,AssertionFailedError t) ，TestFailure失敗類是個“失敗”狀況的收集類，解釋每次測試執(zhí)行過程中出現(xiàn)的異常情況。其toString()方法返回“失敗”狀況的簡要描述。</p><p>　　2.2.2 CppUnit測試框架原理</p><p>　　CppUnit 是一個單

81、元測試框架，它是從著名的 JUnit 框架為 C++ 而移植過來的。 </p><p>　　類似于大多數(shù)開源項目，CppUnit 下載下來之后，第一次就是將源代碼進行編譯（安裝），在該下載包的目錄中，INSTALL_WIN.txt 詳細的講解了如何在 Windows 上進行編譯。如果機器中裝有 Visual Studio 6.0 以上，可以在源代碼目錄中直接打開項目文件，然后使用該集成環(huán)境直接進行編譯即可[14]

82、。</p><p>　　在CppUnit的lib目錄下，包括這些文件： </p><p>　　1CppUnit運行時庫，用于撰寫單元測試代碼。</p><p>　　(1)cppunitd.lib：CppUnit 運行時庫的靜態(tài)編譯庫文件。</p><p>　　(2)cppunitd_dll.dll：CppUnit 運行時庫編譯的動態(tài)鏈接庫文件

83、。 </p><p>　　(3)cppunitd_dll.lib：CppUnit 運行時庫動態(tài)鏈接庫的導入庫文件。</p><p>　　2執(zhí)行單元測試的程序文件，用于執(zhí)行撰寫的單元測試代碼。</p><p>　　(1)DllPluginTesterd_dll.exe：命令行可執(zhí)行文件，指定編譯的單元測試代碼動態(tài)鏈接庫，然后運行并輸出。典型的用法：TestPlugIn

84、Runnerd_dll a.dll-t。</p><p>　　(2)TestPlugInRunnerd.exe：GUI可執(zhí)行文件，可以打開任何編譯的單元測試代碼動態(tài)鏈接庫，指定需要測試的case, 進行測試并檢測測試結(jié)果，如果沒問題，進度條為綠色，如果有問題，進度條為紅色。</p><p>　　在CppUnit中，每一個測試用例用一個類表示，該類通常用于測試一個模塊，如果該模塊是一個類，正

85、好對應這個測試用例。</p><p><b>　　1定義類</b></p><p>　　每個測試用例類都必須要繼承自CPPUNIT_NS::TestFixture。如：class SampleTestCase：public CPPUNIT_NS::TestFixture </p><p>　　并且，這個類還需要定義一對宏：</p>

86、<p>　　CPPUNIT_TEST_SUITE (SampleTestCase)；</p><p>　　CPPUNIT_TEST_SUITE_END()；</p><p>　　這對宏里面用于定義這個測試類所包含的測試方法。而且，在實現(xiàn)的源程序中也需要定義一個宏來標識該測試類：</p><p>　　CPPUNIT_TEST_SUITE_REGISTRAT

87、ION (SampleTestCase)；</p><p>　　除此之外，每個類還可以實現(xiàn)兩個方法：setUp()，tearDown()。第一個方法在運行這個類的測試方法之前被調(diào)用，而第二個方法則是在運行完這個類的測試方法之后被調(diào)用。例如，如果這個測試類需要操作一個文件里的信息，通常在運行測試方法之前，需要打開指定的文件，這些處理則可以放在setUp()中實現(xiàn)。而完成測試之后，又需要將打開的文件關(guān)閉，這些操作可以

88、在TearDown()中實現(xiàn)。這兩個方法的原型是：</p><p>　　void setUp()；</p><p>　　void TearDown()；</p><p><b>　　2定義測試方法</b></p><p>　　每個測試方法用于測試一段功能，通常對應于被測試類的某公開方法。例如，在Sample類中有一個fo

89、o()方法，在測試類SampleTestCase中也可以聲明一個foo()方法。注意，強烈建議使用相同的名稱，這樣便于維護。</p><p>　　每一個測試方法需要在類的CPPUNIT_TEST_SUITE 宏中添加一個定義，以便 CppUnit 能夠發(fā)現(xiàn)該測試方法，如：</p><p>　　CPPUNIT_TEST (foo)；</p><p>　　在定義測試方法

90、之后，就可以在該方法內(nèi)編寫單元測試代碼了。單元測試框架都采用斷言式的測試方式，即編寫一個表達式，檢查其結(jié)果是否為真，真則表示通過。在CppUnit中，用于檢驗測試是否通過的宏包括：</p><p>　　CPPUNIT_ASSERT (expr)：檢查表達式expr是否為真，真則通過，假則錯誤。</p><p>　　CPPUNIT_ASSERT_TRHOW (expr, exception)

91、：檢查表達式expr是否拋出異常類型exception，如果拋出了指定類型的異常，則通過測試。</p><p>　　CPPUNIT_ASSERT_MESSAGE (message, expr)：類似于CPPUNIT_ASSERT, 但在沒有通過時輸出消息 message。</p><p>　　CPPUNIT_FAIL (message)：強制性不通過測試，并輸出消息message。<

92、/p><p>　　2.2.3 NUnit測試框架原理</p><p>　　NUnit是一個單元測試框架,專門針對于.NET來寫的。NUnit最初是由James W. Newkirk，Alexei A. Vorontsov和Philip A. Craig，后來開發(fā)團隊逐漸龐大起來，在開發(fā)過程中，KentBeck和ErichGamma兩位也提供了許多幫助。</p><p>

93、　　NUnit是xUnit家族中的第四個主打產(chǎn)品，完全由C#語言來編寫，并且編寫時充分利用了許多.NET的特性，比如反射，客戶屬性等等。最重要的一點是它適合于所有.NET語言。</p><p>　　在使用NUnit框架時，有很多有用的特性。靈活使用這些特性，將有助于提高測試代碼開發(fā)的效率[3]。</p><p>　　1 Per-method的Setup和Teardown</p>

94、<p>　　(1)Setup：用此Attribute指定的方法用于環(huán)境的建立，NUnit在調(diào)用每個Test方法之前，將調(diào)用此特性標記的方法。 (2)Teardown：和Setup一樣，只是調(diào)用的時機是在每個Test方法完成后， 用于環(huán)境的清理。</p><p>　　2 Per-class Setup和Per-class Teardown</p>&l

95、t;p>　　TestFixtureSetup以及TestFixtureTearDown特性和上述的Setup以及Teardown類似，只是其作用于整個TestFixture類而已?？梢允褂眠@兩個特性標記的方法對整個test class設(shè)置和清理環(huán)境。</p><p>　　3使用Categories分類</p><p>　　[Category(“分類名”)]用于指定某個測試方法所屬的“

96、類型”。用此特性將各個測試方法分類后，可以在NUnit環(huán)境中指定需要執(zhí)行的類型。可以將此特性寫在[Test]特性一起，如：[Test, Category(“test_0001”)]。也可以分開兩行：   [Test]   [Category(“test_0001”)]   Category還有一個Explicit屬性，可以顯式排除該Category的運行（除非在NU

97、nit GUI中指定），寫法如：[Category(“test_0001”， Explicit=true)]</p><p>　　4測試預期的異常：ExpectedException</p><p>　　對測試而言有兩種異常：從測試代碼拋出的異常；由于某個模塊錯誤而引發(fā)的異常。第二種異常會在NUnit中捕獲并作測試失敗處理。而有時我們需要測試被測試方法是否拋出了期望的異常（例如，特意傳入的

98、錯誤參數(shù)），就可以用以下方法：</p><p>　　[ExpectedException(typeof(SomeException))] [Test,ExpectedException(typeof(SomeException))]注意，一旦期望的異常拋出了，剩余的代碼就會被跳過。</p><p>　　5臨時忽略一些測試：Ignore</p><p>　　當你寫了

99、一些測試代碼，但并不打算馬上執(zhí)行時，可以使用Ignore特性。  [Test,Ignore(“message”)] 這個測試將被跳過，并且在NUnit GUI中給出黃色的狀態(tài)欄。</p><p>　　6 NUint中的斷言Assert類的靜態(tài)方法：</p><p>　　1) AreEquals：</p><p>　　Assert.Ar

100、eEqual(expected, actual[, string message])</p><p>　　expected：期望值（通常是硬編碼的）；actual：實際值（通常是硬編碼的）；message：一個可選消息，將會在發(fā)生錯誤時報告這個消息。</p><p>　　因計算機并不能精確地表示所有的浮點數(shù)，所以在比較浮點數(shù)時（float或double），需要指定一個額

101、外的誤差參數(shù)。</p><p>　　Assert.AreEqual(expected, actual, tolerance[, string message])</p><p>　　tolerance：指定的誤差，即只要精確到小數(shù)點后X位就足夠了。</p><p><b>　　2) IsNull</b>&

102、lt;/p><p>　　Assert.IsNull(object[, string message])</p><p>　　Assert.IsNotNull(object[, string message])</p><p>　　3) AreSame</p><p>　　Assert.AreSame(exp

103、ected, actual[, string message])</p><p>　　驗證expected和actual兩個參數(shù)是否引用一個相同的對象。</p><p><b>　　4) IsTrue</b></p><p>　　Assert.IsTrue(bool condition [,&#

104、160;string message])</p><p>　　Assert.IsFalse(bool condition [, string message])</p><p><b>　　5) Fail</b></p><p>　　Assert.Fail([string messag

105、e])</p><p>　　使測試立即失??；這種斷言通常被用于標記某個不應該被到達的分支，但實際中不常用。</p><p>　　7當有測試失敗時，無論如何都不能給原有代碼添加任何的新特性。</p><p>　　2.2.4 XUnit.net測試框架原理</p><p>　　Jim Newkirk和Brad Wilson這兩位XUnit.net

106、的創(chuàng)造者，從NUnit和其他單元測試框架的經(jīng)驗中總結(jié)出來以下改進：</p><p>　　1為每個測試方法產(chǎn)生一個對象實例</p><p>　　2取消了[SetUp]和[TearDown] </p><p>　　3取消了[ExpectedException]</p><p>　　4類似于Aspect的功能</p><p>

107、;　　5減少了自定義屬性（Attribute）的數(shù)目</p><p><b>　　6采用泛型 </b></p><p><b>　　7匿名委托</b></p><p>　　8可擴展的斷言、測試方法以及測試類 </p><p>　　XUnit.net減少了屬性（Attributes）的數(shù)量，屬性被用來

108、控制測試和測試的執(zhí)行過程。其中有個 [Test]屬性用來標出測試方法。跟NUnit不同，測試類并沒有任何標志。XUnit.net直接在程序集中查找所有公開類的全部公開測試方法。</p><p>　　XUnit.net團隊覺得每項測試分別執(zhí)行setup和teardown會產(chǎn)生難以理解與除錯的測試代碼，并且常常導致每一項測試執(zhí)行之前都要運行一些不必要的代碼。因此[SetUp]和[TearDown]被拋棄。</p

109、><p>　　原先[ExpectedException]屬性被用來聲明希望測試代碼拋出的異常，它已被Assert.Throws斷言取代。測試集（TestFixture）由ITestFixture接口標出，接口里面有兩個方法：BeforeAllTests()和AfterAllTests()。測試超時和暫時跳過某些測試是通過[Test]屬性的參數(shù)來實現(xiàn)的，并沒有單獨為此定義屬性。MbUnit里面非常受歡迎的[RowTes

110、t]和[Row]測試模式也被包括了進來，由[Theory]和[DataViaXxx]實現(xiàn)：xunit.extensions.dll里附帶了對數(shù)據(jù)驅(qū)動測試的支持，被稱為Theory。用[Theory]（代替[Test]）來標記測試，再標記上其中一個[DataVia...]屬性，用來指出數(shù)據(jù)的來源。</p><p>　　XUnit.net中的斷言的數(shù)量也減少了。任何可用基本斷言實現(xiàn)其功能的斷言都被放棄。另外“is”和