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

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

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

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

4、/p><p>　　關(guān)鍵詞：WinForm Control 自動(dòng)化測試 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自動(dòng)化測試

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

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

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

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

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

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

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

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

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

22、來了很多困難，因?yàn)槟壳笆袌錾喜⒉淮嬖诿嫦騑inForm C</p><p><b>　　1.2 國內(nèi)外現(xiàn)狀</b></p><p>　　目前，可用于對(duì)WinForm Control的基本屬性、方法和事件進(jìn)行自動(dòng)化測試的單元測試框架很多，常用的單元測試框架根據(jù)開發(fā)語言不同，可分為[13]：</p><p>　　1 JUnit：JUnit就是為Ja

23、va程序開發(fā)者實(shí)現(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)驗(yàn)，它是.NET的一個(gè)最主要的單元測試框架，是由James Newkirk所開發(fā)的。雖然NUnit涵蓋了.NET應(yīng)用程序單元測試的大多數(shù)必要情景，但MbUnit可以讓單元測試更進(jìn)一步。MbUnit是由Jonathan “Peli” de Halleux首先編寫的一個(gè)開源單元測試框架。最新推出的單元測試框架為XUnit.n

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

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

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

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

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

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

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

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

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

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

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

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

37、2.1 WinForm Control的定義及分類</p><p>　　控件（Control）是在圖形用戶界面（GUI）中屏幕上的一種對(duì)象，用戶可操作該對(duì)象來執(zhí)行某一行為。 控件是用戶可與之交互以輸入或操作數(shù)據(jù)的對(duì)象?？丶ǔ３霈F(xiàn)在對(duì)話框中或工具欄上[16]。WinForm Control是控件的一種，目前，對(duì)于WinForm Control的應(yīng)用非常廣泛。</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è)計(jì)和開發(fā)Windows應(yīng)用程序時(shí)，用到的控件[17]。</p><p>　　WinForm Contro

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

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

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

42、><p>　　在這種方案中，需從基類Control派生控件?？梢蕴砑雍椭貙懟惖膶傩浴⒎椒ê褪录?。</p><p>　　4 WinForm Control的基類提供了客戶端基于Windows的應(yīng)用程序中的可視顯示所需的機(jī)制。Control提供窗口句柄，處理消息路由，并提供鼠標(biāo)和鍵盤事件以及許多其他用戶界面事件。還提供了高級(jí)布局，并具有特定于可視顯示的屬性，如ForeColour、BackCol

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

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

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

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

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

48、<p>　　如果這里的“父親”你理解作“容器”，那么窗體類是所有控件的父類。這就是說，每個(gè)控件在視覺上都處在某個(gè)窗體中（或者是在別的控件中，例如面板（Panel）控件，面板控件自己還是被包含在一個(gè)窗體中的）。 </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能力，而是依賴于被包含的控件來做真正的工作。把控件放在一個(gè)容器中的真正理由在于，你能夠把放在其中的控件做為

50、一個(gè)整體進(jìn)行顯示、隱藏、移動(dòng)等操作。</p><p>　　容器控件都能接受鼠標(biāo)事件，而別的控件類都不能接受原始鼠標(biāo)輸入。對(duì)別的控件而言，鼠標(biāo)消息被轉(zhuǎn)換成特定控件事件，例如Click事件，或者產(chǎn)生一個(gè)副作用，例如使控件獲得或失去焦點(diǎn)。</p><p>　　(3)單項(xiàng)控件，常用的有：</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>　　單項(xiàng)控件通常用來顯示和接收單項(xiàng)信息。它們具有用以保存數(shù)值的Text屬性，并且當(dāng)這一數(shù)值改變時(shí)，它們會(huì)接收到一個(gè)TextChanged事件。舉例來說，如果一個(gè)用戶正在向一個(gè)TextBox控件輸入文本，那么每一個(gè)被輸入的字符都會(huì)引發(fā)TextCh

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

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

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

57、。如果你確實(shí)需要在運(yùn)行時(shí)再進(jìn)行初始化，那么在你開始學(xué)習(xí)怎樣訪問初始化集合時(shí)，看看設(shè)計(jì)器所產(chǎn)生的代碼是個(gè)不錯(cuò)的選擇[10]。</p><p>　　為了幫助你將程序中的數(shù)據(jù)與這些控件的數(shù)據(jù)在運(yùn)行時(shí)相連接，復(fù)合項(xiàng)控件也支持?jǐn)?shù)據(jù)綁定。復(fù)合項(xiàng)控件實(shí)現(xiàn)數(shù)據(jù)綁定的方法與單項(xiàng)控件的大不相同。這里就不再詳細(xì)介紹了。</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>　　命令輸入控件允許用戶指定一個(gè)操作以便執(zhí)行，這通常通過直接在控件上的點(diǎn)擊完成。每個(gè)命

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

77、ite類實(shí)現(xiàn)了Test接口，且可以包含其它的TestSuites。它可以處理加入Test時(shí)的所有拋出的異常。 TestSuite處理測試用例有6個(gè)規(guī)約（否則會(huì)被拒絕執(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é)果類集合了任意測試?yán)奂咏Y(jié)果，通過TestResult實(shí)例傳遞每個(gè)測試的Run()方法。TestResult在執(zhí)行TestCase時(shí)如果失敗會(huì)異常拋出。TestListener接口是個(gè)事件監(jiān)聽規(guī)約，可供TestRunner類使用。它通知listener的對(duì)象相關(guān)事件，方法包括測試開始startTest(Test test)，測試結(jié)束endTest(Test test)，增加異常addError(Tes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

99、一些測試代碼，但并不打算馬上執(zhí)行時(shí)，可以使用Ignore特性。  [Test,Ignore(“message”)] 這個(gè)測試將被跳過，并且在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：實(shí)際值（通常是硬編碼的）；message：一個(gè)可選消息，將會(huì)在發(fā)生錯(cuò)誤時(shí)報(bào)告這個(gè)消息。</p><p>　　因計(jì)算機(jī)并不能精確地表示所有的浮點(diǎn)數(shù)，所以在比較浮點(diǎn)數(shù)時(shí)（float或double），需要指定一個(gè)額

101、外的誤差參數(shù)。</p><p>　　Assert.AreEqual(expected, actual, tolerance[, string message])</p><p>　　tolerance：指定的誤差，即只要精確到小數(shù)點(diǎn)后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>　　驗(yàn)證expected和actual兩個(gè)參數(shù)是否引用一個(gè)相同的對(duì)象。</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>　　使測試立即失??；這種斷言通常被用于標(biāo)記某個(gè)不應(yīng)該被到達(dá)的分支，但實(shí)際中不常用。</p><p>　　7當(dāng)有測試失敗時(shí)，無論如何都不能給原有代碼添加任何的新特性。</p><p>　　2.2.4 XUnit.net測試框架原理</p><p>　　Jim Newkirk和Brad Wilson這兩位XUnit.net

106、的創(chuàng)造者，從NUnit和其他單元測試框架的經(jīng)驗(yàn)中總結(jié)出來以下改進(jìn)：</p><p>　　1為每個(gè)測試方法產(chǎn)生一個(gè)對(duì)象實(shí)例</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可擴(kuò)展的斷言、測試方法以及測試類 </p><p>　　XUnit.net減少了屬性（Attributes）的數(shù)量，屬性被用來

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

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

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