毕业论文——面向WinForm Control的自动化测试框架的设计与实现

目录摘要随着控件技术的不断发展，用户对WinForm Control的需求不断增加，使得WinForm Control逐渐产品化，一批以WinForm Control为产品的公司或者部门的建立更加推动了其快速发展。与此同时，也给WinForm Control的自动化测试提出了新的要求。目前，现有的用于WinForm Control自动化测试的自动化测试框架都是单元测试框架，只能用于测试WinForm Control的基本属性、方法和事件，而其他测试只能手动进行，因此，开发一套面向WinForm Control的自动化测试框架是非常有必要的。本文深入研究了WinForm Control的特点，详细分析了WinForm Control自动化测试的原理及过程，对现有的单元测试框架做了简单的介绍，通过研究，在单元测试框架NUnit的基础上，着重处理鼠标和键盘的交互操作，并将GUI测试思想应用到WinForm Control的自动化测试中，将WinForm Control的各个组成部分抽象成一个ComponentGUI，让测试人员可以方便地定位控件并进行自动化测试，最终实现了面向WinForm Control的自动化测试框架。整个框架在设计上充分考虑了代码的可复用性、可移植性和可维护性。目前，该自动化测试框架已经在日本多家控件公司投入使用，达到实用化水平。关键词：WinForm Control 自动化测试 GUI InputAbstractWith the continuous development of control techniques and the increasing demand for WinForm 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. Meanwhile, 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 only be used to test the basic attributes，methods and events of WinForm Control，that is to say，other tests have to be operated manually. Thus，it is very necessary to develop a automatic testing framework for WinForm Control.In this 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 introduced 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 of the interactive operations of keyboard and mouse；and the ideas of GUI based testing are introduced in the automatic testing for WinForm Control：the components of WinForm Control are abstracted to a ComponentGUI，so that the testers can easily locate controls and test them. The proposed framework takes into account the reusability，the portability and the maintainability of codes. At present，this automatic testing framework has been put into practical use in many Japanese control corporations.KeyWords: WinForm Control Automatic Testing GUI Input目录第一章 绪论11.1 研究背景11.2 国内外现状21.3 课题的意义21.4 论文的工作和结构3第二章 WinForm Control及常用单元测试框架52.1 WinForm Control的定义及分类52.1.1 WinForm Control的定义52.1.2 WinForm Control的分类62.2 常用单元测试框架92.2.1 JUnit测试框架原理92.2.2 CppUnit测试框架原理122.2.3 NUnit测试框架原理132.2.4 XU测试框架原理152.3 小结16第三章 WinForm Control自动化测试研究与分析173.1 WinForm Control自动化测试原理分析173.1.1 基本属性、方法和事件的测试173.1.2 鼠标和键盘相关事件的测试203.1.3 GUI测试243.2 WinForm Control自动化测试的流程263.3 WinForm Control自动化测试的优点263.4 小结27第四章 面向WinForm Control的自动化测试框架的设计294.1 GUI测试框架的设计294.2 Input测试框架的设计354.2.1 鼠标输入测试框架的设计354.2.2 键盘输入测试框架的设计384.3 结果比较方法的设计404.4 面向WinForm Control的自动化测试框架的优点414.5 小结42第五章 面向WinForm Control的自动化测试框架的验证455.1 制定测试用例455.2 编写测试脚本465.3 运行测试脚本515.4 生成测试报告535.5 小结54第六章 结束语55致谢57参考文献593第一章 绪论第一章 绪论随着计算机技术的发展，人们对软件产品的质量有了更高的要求，因此软件测试工作在整个软件开发的过程中也越发重要。从繁杂的手工测试到实用性强的自动化测试，从最初只提供简单的捕捉/回放功能的测试工具到功能和灵活性更强的测试脚本工具，自动化测试已经取得了很大的进步2。但随着软件规模的不断扩大，软件类型的不断增多，人们希望自动化测试能够更加高效和简便。自动化测试框架的出现，加速了自动化脚本的生成，提高脚本的可维护性，加速脚本执行效率等，目的是减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。1.1 研究背景2001年后，.NET Framework2.0的诞生，人们将它看作是多年来最重要的新技术。.NET Framework以多种方式对面向组件的开发模式做了强而有力的支持。.NET Framework为开发人员提供了两种控件支持：一种是Web Control，一种是WinForm Control15。其中WinForm Control是目前发展最快，应用最广泛的。.NET Framework使得开发人员可以通过将多个标准WinForm Control组合，而定制出符合用户需求的应用程序。开发人员还可以通过继承某个标准WinForm Control，附加新的功能与业务逻辑满足自己的需要。更高级的开发人员可以直接从.NET Framework提供的Control基类派生出自定义的WinForm Control（Custom Control）20。尽管面向组件的开发模式和.NET Framework的支持，使得WinForm Control的开发人员以及厂商获取了更多的好处，但却给WinForm Control的测试工作带来了很多困难，因为目前市场上并不存在面向WinForm Control的自动化测试框架，因此，对于WinForm Control的测试，除了最基本的属性、方法和事件的测试可以利用目前常用的单元测试框架实现自动化测试以外，其他大部分对于WinForm Control的测试都必须依靠测试人员手动完成。但随着WinForm Control的不断发展，最终用户对WinForm Control的种类、质量、功能以及用户界面的要求也在不断增加，这就推动了市场的壮大，同时促进了一批以WinForm Control为产品的公司或者部门的建立，最终将推动WinForm Control从产品向产业进一步发展，因此，自动化测试WinForm Control也成为一种必然，那么开发一套面向WinForm Control的自动化测试框架是非常有必要的。1.2 国内外现状目前，可用于对WinForm Control的基本属性、方法和事件进行自动化测试的单元测试框架很多，常用的单元测试框架根据开发语言不同，可分为13：1 JUnit：JUnit就是为Java程序开发者实现单元测试提供一种框架，使得Java单元测试更规范有效，并且更有利于测试的集成。此框架是由Alan Ray和Erich Gamma开发的。2 CppUnit：CppUnit是从著名的JUnit框架为C+移植过来的。是由Michael Feathers开发的。3 Microsoft.NET Framework提供的单元测试框架，包括：NUnit、CsUnit、MbUnit和XU。许多.NET开发人员都或多或少有一些使用NUnit的经验，它是.NET的一个最主要的单元测试框架，是由James Newkirk所开发的。虽然NUnit涵盖了.NET应用程序单元测试的大多数必要情景，但MbUnit可以让单元测试更进一步。MbUnit是由Jonathan “Peli” de Halleux首先编写的一个开源单元测试框架。最新推出的单元测试框架为XU，此框架从现有框架中脱颖而出的因素有很多。最重要的一点是，它是由James Newkirk和Brad Wilson构建的。Newkirk是Microsoft负责CodePlex项目的产品经理，曾帮助构建NUnit，他撰写了大量有关于单元测试的书籍。Brad Wilson是thedotguy上的一位资深博客作者，模式和实施方案小组的前成员，还是Microsoft的特别员工。这一全新框架的目标是利用在过去五年内积累的有关单元测试的最佳实践，构建一种能体现并鼓励这些实践的全新框架23。1.3 课题的意义目前，单元测试框架技术一直在不断发展，现有的单元测试框架也一直在被更新和改进，但随着WinForm Control的类型和复杂度不断增加，现有的单元测试框架无法准确定位WinForm Control，尤其是无法获取WinForm Control的各个组成部分信息并进行测试，而且现有的单元测试框架也无法模拟鼠标和键盘的操作，因此无法测试用鼠标和键盘对WinForm Control操作后的结果是否正确，也无法监听鼠标或键盘触发的事件是否正确，验证数据和脚本代码维护也有诸多不便，由此可见，现有的单元测试框架已经无法满足现有WinForm Control的自动化测试需求。本人通过在西安某控件开发公司一年的实习，在NUnit单元测试框架的基础上，设计并实现了GUI测试框架和Input测试框架，最终成功开发了这套面向WinForm Control的自动化测试框架，此框架不仅基本解决了现有WinForm Control自动化测试存在的问题，而且对于面向控件的自动化测试框架的研究具有长远的现实意义。目前，该框架已被很多日本控件公司投入使用，取得了良好的市场反映。1.4 论文的工作和结构本论文选题来自西安某控件开发公司基于面向WinForm Control的自动化测试系统研发项目。本人在WinForm Control自动化测试的研究与设计自动化测试框架的工作经历了四个主要阶段：第一阶段：学习阶段。在原有单元测试框架的理论基础上，进一步对NUnit单元测试框架进行了深入学习，阅读了大量自动化测试及WinForm Control开发技术的书籍，为后续的工作奠定了良好的专业理论基础。同时，为了更好地进行自动化测试框架的设计，学习了C#语言和相关开发工具。第二阶段：研究阶段。对WinForm Control的测试特点进行分析和研究，总结了WinForm Control自动化测试的特点和原理，并给出了WinForm Control自动化测试的流程，为WinForm Control自动化测试框架的设计提供了明确方案。第三阶段：设计阶段。根据目前WinForm Control自动化测试存在的问题，在之前研究方案的基础上，设计了GUI测试框架和Input测试框架，最终实现了面向WinForm Control的自动化测试框架。第四阶段：验证阶段。通过几个典型的测试用例，证明了面向WinForm Control的自动化测试框架的实用性。根据所完成的工作，将论文结构安排如下：第一章 绪论本章首先分析了课题的研究背景，然后通过介绍国内外现有的单元测试框架，分析了现有的单元测试框架无法满足WinForm Control自动化测试需求的原因，阐明了开发一套面向WinForm Control的自动化测试框架的意义，最后对论文的工作进行了总结以及对各章节内容进行了安排。第二章 WinForm Control及常用单元测试框架本章介绍了WinForm Control的定义及分类，并分析了几个常用的单元测试框架的原理。第三章 WinForm Control自动化测试研究与分析本章根据WinForm Control的特点，研究总结了WinForm Control自动化测试的原理，着重研究了鼠标和键盘的事件处理，提出了WinForm Control的GUI测试思想，并给出了WinForm Control自动化测试的流程及分析了WinForm Control自动化测试的优点。第四章 面向WinForm Control的自动化测试框架的设计本章详细描述了如何对GUI测试框架和Input测试框架进行设计实现，以及对结果比较方法的设计实现，并分析了面向WinForm Control的自动化测试框架的优点。第五章 面向WinForm Control的自动化测试框架的验证本章将此框架运用于WinForm Control的自动化测试工作中，根据具体的测试用例，运用此框架编写测试脚本，根据脚本运行的情况及测试结果报告，验证了框架的正确性和实用性。第六章 结束语本章一方面对本文所研究的项目加以总结，另一方面提出进一步改进和完善该项目的方法。希望能有更多更好的面向控件领域的自动化测试框架推出，并投入实际生产当中。17第二章 WinForm Control及常用单元测试框架第二章 WinForm Control及常用单元测试框架2.1 WinForm Control的定义及分类控件（Control）是在图形用户界面（GUI）中屏幕上的一种对象，用户可操作该对象来执行某一行为。 控件是用户可与之交互以输入或操作数据的对象。控件通常出现在对话框中或工具栏上16。WinForm Control是控件的一种，目前，对于WinForm Control的应用非常广泛。2.1.1 WinForm Control的定义.NET Framework为开发人员提供了两种控件支持。一种是Web Control，一种是WinForm Control。顾名思义，Web Control是Web开发所需要的控件产品，而WinForm Control则是在设计和开发Windows应用程序时，用到的控件17。WinForm Control是可重用的控件，它们封装了用户界面的功能，可以在基于Windows的客户端应用程序中使用。“Windows窗体”不仅提供了许多现成控件，还提供了自行开发控件的基础结构。可以组合现有控件、扩展现有控件或创作自己的自定义控件。WinForm Control是从System.Windows.Forms.Control直接或间接派生的类。以下列表描述了开发Windows窗体控件的常见方案9：1 组合现有控件来创作一个复合控件。 复合控件封装有一个可以作为控件重复使用的用户界面。其中的一个示例就是由文本框和重置按钮组成的控件。可视化设计器为创建复合控件提供了有力的支持。若要创作复合控件，请从System.Windows.Forms.UserControl派生。基类UserControl为子控件提供了键盘路由并使子控件可以作为一个组进行工作。2 扩展现有控件，对其进行自定义或为其添加功能。 一个不能更改颜色的按钮和一个具有跟踪点击次数属性的按钮就是扩展控件的具体示例。可以通过从任何Windows窗体控件派生控件并重写或添加属性、方法和事件的方式来自定义Windows窗体控件。3 创作一个不是通过组合或扩展现有控件而形成的控件。在这种方案中，需从基类Control派生控件。可以添加和重写基类的属性、方法和事件。4 WinForm Control的基类提供了客户端基于Windows的应用程序中的可视显示所需的机制。Control提供窗口句柄，处理消息路由，并提供鼠标和键盘事件以及许多其他用户界面事件。还提供了高级布局，并具有特定于可视显示的属性，如ForeColour、BackColour、Height、Width和许多其他属性。此外，它还提供了安全性、线程支持以及与ActiveX控件的交互性。由于基类提供了很多基础结构，使得开发自己的Windows窗体控件变得相对简单。2.1.2 WinForm Control的分类目前，微软已经推出三代控件，分别是：1 ActiveX控件：ActiveX控件是微软公司提供的功能强大的程序设计和开发技术，是COM组件开发技术的重要组成部分。它是OLE的第三个版本，对原先OLE控件的最大扩展是增加了Internet功能，它不仅可以在支持OLE控件的容器中使用，更可以作为一个Internet控件，直接成为网页的一部分。另外，ActiveX控件作为一种可重用的组件，相当于一个封装好的代码模块，它是通过其方法、属性、事件来与应用程序进行通信的，此外，ActiveX控件是与开发语言无关的。用户在使用控件时不必考虑它是VC还是用VB等其它语言开发的，应用程序都是通过COM与控件进行通信的19。可见，任何支持ActiveX控件的软件平台上都可以使用ActiveX控件，它使得不同厂商所开发的控件可以真正地组装在一起，从而令软件的生产过程类似于硬件业的各个插件的装配过程一样，实现了软件的工业化，大大降低了软件的开发成本，极大地提高了软件的生产效率，实现了软件资源的共享。2 COM控件：COM组件是以WIN32动态链接库（DLL）或可执行文件（EXE）形式发布的可执行代码组成，它是遵循COM规范编写的，是一些小的二进制可执行文件，COM控件可以给应用程序、操作系统以及其他组件提供服务。自定义的COM控件可以在运行时刻同其他组件连接起来构成某个应用程序。COM组件可以动态的插入或卸出应用，而且必须是动态链接的，它必须隐藏（封装）其内部实现细节，必须可以在不妨碍已有用户的情况下被升级，且可以透明的在网络上被重新分配位置24。3 WinForm Control：常用的WinForm Control可以分为六大类11，分别是：(1)最根本的父控件Form：这个类别中只包含一种控件：窗体类。这样分类的理由在于：窗体类是所有其他类的父亲（parent），这里的“父亲”你可以作以下的理解。如果这里的“父亲”你理解作“容器”，那么窗体类是所有控件的父类。这就是说，每个控件在视觉上都处在某个窗体中（或者是在别的控件中，例如面板（Panel）控件，面板控件自己还是被包含在一个窗体中的）。 (2)容器控件，常用的有：1) Panel2) TabControl3) TabPage4) FlowLayoutPanel5) GroupBox容器控件用来盛放别的控件。它们没有自己的GUI能力，而是依赖于被包含的控件来做真正的工作。把控件放在一个容器中的真正理由在于，你能够把放在其中的控件做为一个整体进行显示、隐藏、移动等操作。容器控件都能接受鼠标事件，而别的控件类都不能接受原始鼠标输入。对别的控件而言，鼠标消息被转换成特定控件事件，例如Click事件，或者产生一个副作用，例如使控件获得或失去焦点。(3)单项控件，常用的有： 1) Button 2) CheckBox 3) CheckedListBox 4) Label 5) PictureBox 6) RadioButton 7) StatusBar 8) TextBox 9) ProgressBar单项控件通常用来显示和接收单项信息。它们具有用以保存数值的Text属性，并且当这一数值改变时，它们会接收到一个TextChanged事件。举例来说，如果一个用户正在向一个TextBox控件输入文本，那么每一个被输入的字符都会引发TextChanged事件。所有的单项控件都支持一种被称为数据绑定的特性。这个特性使你可以将你的用户界面对象连接到数据对象。这样的连接一旦建立，任何用户界面中的改变都会引起内存中对应对象的自动更新反之亦然。数据绑定使得在此之前的GUI程序员必须手动处理的工作得以自动完成，并且使你的编码工作大大简化。所有的单项控件都使用了同样的数据绑定方法，这种方法被称为简单数据绑定4。(4)复合项控件，常用的有： 1) ComboBox 2) DataGrid 3) DominUpDown4) ListBox 5) ListView 6) TreeView复合项控件可以显示一个列表或是一个数组，并且允许用户从列表中选取某一选项。每一个控件类都允许你通过容器来访问被显示的数据数组或是列表这被作为控件的一个属性得以实现。这些控件使你可以使用面向对象的方式来访问底层数据。对几乎所用控件而言除了DataGrid控件实际的数据都存在于一个对应的底层Win32控件之中。除了DataGrid控件之外，每一个复合项控件都允许你在程序编译时给定一个初始化列表。Visual Studio .NET设计器使你可以通过控件的属性窗口来创建这一列表。（对树形控件（TreeView）而言，用来初始化的集合被称为节点（Node），并且这一集合拥有和其他控件初始集合平面结构不相同的层次结构。）这一为控件设定初始值的能力将使你的工作变得简单，因为除非在运行时（runtime）才知道初始值，设计器都可以提前为你创建初始化所需代码。如果你确实需要在运行时再进行初始化，那么在你开始学习怎样访问初始化集合时，看看设计器所产生的代码是个不错的选择10。为了帮助你将程序中的数据与这些控件的数据在运行时相连接，复合项控件也支持数据绑定。复合项控件实现数据绑定的方法与单项控件的大不相同。这里就不再详细介绍了。(5)命令输入控件，常用的有： 1) ContextMenu 2) MainMenu 3) MenuItem 4) ToolBar 5) ToolBarButton命令输入控件允许用户指定一个操作以便执行，这通常通过直接在控件上的点击完成。每个命令输入控件具有Text属性描述这一操作，还有三个布尔属性Visible，Enabled和Checked来指示控件的状态。当被用户选中时，该控件会接到一个Click事件。(6)背景控件，常用的有： 1) Timer 2) ImageList背景控件没有图形界面，因此它们对用户是不可见的，而且它们只能被包含在窗体控件中，而不能被放置于容器控件中。Timer控件在一定间隔触发Tick事件，这一时间间隔在Interval属性中指定（以毫秒为单位）。这一属性是一个整型值，因此可接收的范围从1毫秒到Int32.MaxValue毫秒，也就是大约23天。一旦被启动并且Enabled属性为真（true）,Timer控件就会不停的触发Tick事件，这使它看起来有点像一个闹钟。一旦被设定，它就每过Interval属性个毫秒报响。你可以通过将Enabled属性设置为假（False）来关掉它。计时器事件的优先级较低。例如在用户点击一个TextBox控件的同时，一个Timer控件也触发了一个事件，那么所有点击触发的事件（例如GotFocus, LostFocus，Validating和Validated）都会在Tick事件提交之前被处理。ImageList控件可以存放一组图像，这通常被用来支持ToolBar按钮。和别的控件一样，你可以在Visual Studio .NET设计器中为ImageList控件设定初始值一组图像10。Visual Studio .NET支持的文件类型范围很广，包括支持位图（bitmaps）、JPEG、GIF、PNG、Icons和Window图元文件（Window metafiles）。2.2 常用单元测试框架目前，专门用于WinForm Control的自动化测试框架并不存在，一般的开发WinForm Control的公司都是用常用的单元测试框架对WinForm Control的基本属性、方法及事件进行自动化测试，其他大部分对于WinForm Control的测试只能依靠测试人员手动完成。目前的最流行的单元测试框架是XUnit系列框架。常用的有JUnit、CppUnit、NUnit以及XU23。2.2.1 JUnit测试框架原理JUnit就是为Java程序开发者实现单元测试提供一种框架，使得Java单元测试更规范有效，并且更有利于测试的集成5。 1 JUnit的优点(1)可以使测试代码与产品代码分开。(2)针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试。(3)易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发。(4)JUnit是公开源代码的，可以进行二次开发。(5)可以方便地对JUnit进行扩展。2 JUnit的编写原则(1)简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写。(2)是使测试单元保持持久性。(3)是可以利用既有的测试来编写相关的测试。3 JUnit的特点(1)使用断言方法判断期望值和实际值差异，返回Boolean值。(2)测试驱动设备使用共同的初始化变量或者实例。(3)测试包结构便于组织和集成运行。(4)支持图型交互模式和文本交互模式。4 JUnit框架的组成(1)对测试目标进行测试的方法与过程集合，可称为测试用例(TestCase)。(2)测试用例的集合，可容纳多个测试用例(TestCase)，将其称作测试包(TestSuite)。JUnit框架是一个典型的Composite模式：TestSuite可以容纳任何派生自Test的对象；当调用TestSuite对象的run()方法是，会遍历自己容纳的对象，逐个调用它们的run()方法。(3)测试结果的描述与记录。(TestResult) 。(4)测试过程中的事件监听者(TestListener)。(5)每一个测试方法所发生的与预期不一致状况的描述，称其测试失败元素(TestFailure)(6)JUnit Framework中的出错异常（AssertionFailedError）。5 JUnit中常用的接口和类(1)Test接口运行测试和收集测试结果Test接口使用了Composite设计模式，是单独测试用例 （TestCase），聚合测试模式（TestSuite）及测试扩展（TestDecorator）的共同接口。它的public int countTestCases（）方法，它来统计这次测试有多少个TestCase，另外一个方法就是public void run（TestResult），TestResult是实例接受测试结果，run方法执行本次测试。(2)TestCase抽象类定义测试中固定方法 TestCase是Test接口的抽象实现，（不能被实例化，只能被继承）其构造函数TestCase(string name)根据输入的测试名称name创建一个测试实例。由于每一个TestCase在创建时都要有一个名称，若某测试失败了，便可识别出是哪个测试失败。 TestCase类中包含的setUp()、tearDown()方法。setUp()方法集中初始化测试所需的所有变量和实例，并且在依次调用测试类中的每个测试方法之前再次执行setUp()方法。tearDown()方法则是在每个测试方法之后，释放测试程序方法中引用的变量和实例。 开发人员编写测试用例时，只需继承TestCase，来完成run方法即可，然后JUnit获得测试用例，执行它的run方法，把测试结果记录在TestResult之中。 (3)Assert静态类一系列断言方法的集合 Assert包含了一组静态的测试方法，用于期望值和实际值比对是否正确，即测试失败，Assert类就会抛出一个AssertionFailedError异常，JUnit测试框架将这种错误归入Failes并加以记录，同时标志为未通过测试。如果该类方法中指定一个String类型的传参则该参数将被做为AssertionFailedError异常的标识信息，告诉测试人员该异常的详细信息。 JUnit 提供了6大类31组断言方法，包括基础断言、数字断言、字符断言、布尔断言、对象断言。其中assertEquals（Object expected，Object actual）内部逻辑判断使用equals()方法，这表明断言两个实例的内部哈希值是否相等时，最好使用该方法对相应类实例的值进行比较。而assertSame（Object expected，Object actual）内部逻辑判断使用了Java运算符“=”，这表明该断言判断两个实例是否来自于同一个引用（Reference），最好使用该方法对不同类的实例的值进行比对。assertEquals(String message，String expected，String actual)该方法对两个字符串进行逻辑比对，如果不匹配则显示这两个字符串有差异的地方。ComparisionFailure类提供两个字符串的比对，不匹配则给出详细的差异字符。(4)TestSuite测试包类多个测试的组合TestSuite类负责组装多个Test Cases。待测的类中可能包括了对被测类的多个测试，而TestSuite负责收集这些测试，使我们可以在一个测试中，完成全部的对被测类的多个测试。 TestSuite类实现了Test接口，且可以包含其它的TestSuites。它可以处理加入Test时的所有抛出的异常。 TestSuite处理测试用例有6个规约（否则会被拒绝执行测试） 1)测试用例必须是公有类（Public） 2)测试用例必须继承与TestCase类 3)测试用例的测试方法必须是公有的（Public） 4)测试用例的测试方法必须被声明为Void 5)测试用例中测试方法的前置名词必须是test 6)测试用例中测试方法无任何传递参数(5)TestResult结果类和其它类与接口TestResult结果类集合了任意测试累加结果，通过TestResult实例传递每个测试的Run()方法。TestResult在执行TestCase时如果失败会异常抛出。TestListener接口是个事件监听规约，可供TestRunner类使用。它通知listener的对象相关事件，方法包括测试开始startTest(Test test)，测试结束endTest(Test test)，增加异常addError(Test test,Throwable t)和增加失败addFailure(Test test,AssertionFailedError t) ，TestFailure失败类是个“失败”状况的收集类，解释每次测试执行过程中出现的异常情况。其toString()方法返回“失败”状况的简要描述。2.2.2 CppUnit测试框架原理CppUnit 是一个单元测试框架，它是从著名的 JUnit 框架为 C+ 而移植过来的。 类似于大多数开源项目，CppUnit 下载下来之后，第一次就是将源代码进行编译（安装），在该下载包的目录中，INSTALL_WIN.txt 详细的讲解了如何在 Windows 上进行编译。如果机器中装有 Visual Studio 6.0 以上，可以在源代码目录中直接打开项目文件，然后使用该集成环境直接进行编译即可14。在CppUnit的lib目录下，包括这些文件： 1CppUnit运行时库，用于撰写单元测试代码。(1)cppunitd.lib：CppUnit 运行时库的静态编译库文件。(2)cppunitd_dll.dll：CppUnit 运行时库编译的动态链接库文件。 (3)cppunitd_dll.lib：CppUnit 运行时库动态链接库的导入库文件。2执行单元测试的程序文件，用于执行撰写的单元测试代码。(1)DllPluginTesterd_dll.exe：命令行可执行文件，指定编译的单元测试代码动态链接库，然后运行并输出。典型的用法：TestPlugInRunnerd_dll a.dll-t。(2)TestPlugInRunnerd.exe：GUI可执行文件，可以打开任何编译的单元测试代码动态链接库，指定需要测试的case, 进行测试并检测测试结果，如果没问题，进度条为绿色，如果有问题，进度条为红色。在CppUnit中，每一个测试用例用一个类表示，该类通常用于测试一个模块，如果该模块是一个类，正好对应这个测试用例。1定义类每个测试用例类都必须要继承自CPPUNIT_NS:TestFixture。如：class SampleTestCase：public CPPUNIT_NS:TestFixture 并且，这个类还需要定义一对宏：CPPUNIT_TEST_SUITE (SampleTestCase)；CPPUNIT_TEST_SUITE_END()；这对宏里面用于定义这个测试类所包含的测试方法。而且，在实现的源程序中也需要定义一个宏来标识该测试类：CPPUNIT_TEST_SUITE_REGISTRATION (SampleTestCase)；除此之外，每个类还可以实现两个方法：setUp()，tearDown()。第一个方法在运行这个类的测试方法之前被调用，而第二个方法则是在运行完这个类的测试方法之后被调用。例如，如果这个测试类需要操作一个文件里的信息，通常在运行测试方法之前，需要打开指定的文件，这些处理则可以放在setUp()中实现。而完成测试之后，又需要将打开的文件关闭，这些操作可以在TearDown()中实现。这两个方法的原型是：void setUp()；void TearDown()；2定义测试方法每个测试方法用于测试一段功能，通常对应于被测试类的某公开方法。例如，在Sample类中有一个foo()方法，在测试类SampleTestCase中也可以声明一个foo()方法。注意，强烈建议使用相同的名称，这样便于维护。每一个测试方法需要在类的CPPUNIT_TEST_SUITE 宏中添加一个定义，以便 CppUnit 能够发现该测试方法，如：CPPUNIT_TEST (foo)；在定义测试方法之后，就可以在该方法内编写单元测试代码了。单元测试框架都采用断言式的测试方式，即编写一个表达式，检查其结果是否为真，真则表示通过。在CppUnit中，用于检验测试是否通过的宏包括：CPPUNIT_ASSERT (expr)：检查表达式expr是否为真，真则通过，假则错误。CPPUNIT_ASSERT_TRHOW (expr, exception)：检查表达式expr是否抛出异常类型exception，如果抛出了指定类型的异常，则通过测试。CPPUNIT_ASSERT_MESSAGE (message, expr)：类似于CPPUNIT_ASSERT, 但在没有通过时输出消息 message。CPPUNIT_FAIL (message)：强制性不通过测试，并输出消息message。2.2.3 NUnit测试框架原理NUnit是一个单元测试框架,专门针对于.NET来写的。NUnit最初是由James W. Newkirk，Alexei A. Vorontsov和Philip A. Craig，后来开发团队逐渐庞大起来，在开发过程中，KentBeck和ErichGamma两位也提供了许多帮助。NUnit是xUnit家族中的第四个主打产品，完全由C#语言来编写，并且编写时充分利用了许多.NET的特性，比如反射，客户属性等等。最重要的一点是它适合于所有.NET语言。在使用NUnit框架时，有很多有用的特性。灵活使用这些特性，将有助于提高测试代码开发的效率3。1 Per-method的Setup和Teardown(1)Setup：用此Attribute指定的方法用于环境的建立，NUnit在调用每个Test方法之前，将调用此特性标记的方法。 (2)Teardown：和Setup一样，只是调用的时机是在每个Test方法完成后， 用于环境的清理。2 Per-class Setup和Per-class TeardownTestFixtureSetup以及TestFixtureTearDown特性和上述的Setup以及Teardown类似，只是其作用于整个TestFixture类而已。可以使用这两个特性标记的方法对整个test class设置和清理环境。3使用Categories分类 Category(“分类名”)用于指定某个测试方法所属的“类型”。用此特性将各个测试方法分类后，可以在NUnit环境中指定需要执行的类型。可以将此特性写在Test特性一起，如：Test, Category(“test_0001”)。也可以分开两行： Test Category(“test_0001”) Category还有一个Explicit属性，可以显式排除该Category的运行（除非在NUnit GUI中指定），写法如：Category(“test_0001”， Explicit=true)4测试预期的异常：ExpectedException 对测试而言有两种异常：从测试代码抛出的异常；由于某个模块错误而引发的异常。第二种异常会在NUnit中捕获并作测试失败处理。而有时我们需要测试被测试方法是否抛出了期望的异常（例如，特意传入的错误参数），就可以用以下方法：ExpectedException(typeof(SomeException) Test,ExpectedException(typeof(SomeException)注意，一旦期望的异常抛出了，剩余的代码就会被跳过。5临时忽略一些测试：Ignore当你写了一些测试代码，但并不打算马上执行时，可以使用Ignore特性。 Test,Ignore(“message”) 这个测试将被跳过，并且在NUnit GUI中给出黄色的状态栏。6 NUint中的断言Assert类的静态方法： 1) AreEquals： Assert.AreEqual(expected, actual,stringmessage)expected：期望值（通常是硬编码的）；actual：实际值（通常是硬编码的）；message：一个可选消息，将会在发生错误时报告这个消息。因计算机并不能精确地表示所有的浮点数，所以在比较浮点数时