面向WinForm Control的自动化测试框架的设计与实现.docx

面向WinForm Control的自动化测试框架的设计与实现.docx

《面向WinForm Control的自动化测试框架的设计与实现.docx》由会员分享，可在线阅读，更多相关《面向WinForm Control的自动化测试框架的设计与实现.docx（64页珍藏版）》请在冰豆网上搜索。

面向WinFormControl的自动化测试框架的设计与实现

摘要

随着控件技术的不断发展，用户对WinFormControl的需求不断增加，使得WinFormControl逐渐产品化，一批以WinFormControl为产品的公司或者部门的建立更加推动了其快速发展。

与此同时，也给WinFormControl的自动化测试提出了新的要求。

目前，现有的用于WinFormControl自动化测试的自动化测试框架都是单元测试框架，只能用于测试WinFormControl的基本属性、方法和事件，而其他测试只能手动进行，因此，开发一套面向WinFormControl的自动化测试框架是非常有必要的。

本文深入研究了WinFormControl的特点，详细分析了WinFormControl自动化测试的原理及过程，对现有的单元测试框架做了简单的介绍，通过研究，在单元测试框架NUnit的基础上，着重处理鼠标和键盘的交互操作，并将GUI测试思想应用到WinFormControl的自动化测试中，将WinFormControl的各个组成部分抽象成一个ComponentGUI，让测试人员可以方便地定位控件并进行自动化测试，最终实现了面向WinFormControl的自动化测试框架。

整个框架在设计上充分考虑了代码的可复用性、可移植性和可维护性。

目前，该自动化测试框架已经在日本多家控件公司投入使用，达到实用化水平。

关键词：

WinFormControl自动化测试GUIInput

Abstract

WiththecontinuousdevelopmentofcontroltechniquesandtheincreasingdemandforWinFormControl，WinFormControlisgraduallycommercializedinrecentyears，andtheestablishmentofagroupofcorporationsordepartmentstakingWinFormControlastheirproductfurtherpromotesitsrapiddevelopment.Meanwhile,newrequirementsofautomatictestingofWinFormControlhavebeenarisen.Atpresent，existingautomatictestingframeworksforWinFormControlareallunittestingframeworks，whichcanonlybeusedtotestthebasicattributes，methodsandeventsofWinFormControl，thatistosay，othertestshavetobeoperatedmanually.Thus，itisverynecessarytodevelopaautomatictestingframeworkforWinFormControl.

Inthisarticle，thefeaturesofWinFormControlarefirstlyintroduced，then，theprinciplesandproceduresofautomatictestingforWinFormControlarediscussedindetailandexistingunittestingframeworksarealsointroducedbriefly.Finally，anewautomatictestingframeworkforWinFormControlisintroduced.Thenewframeworkismainlybasedonthefollowingideas：

onthebasisoftheunittestingframeworkNUnit，focusingonthehandlingoftheinteractiveoperationsofkeyboardandmouse；andtheideasofGUIbasedtestingareintroducedintheautomatictestingforWinFormControl：

thecomponentsofWinFormControlareabstractedtoaComponentGUI，sothatthetesterscaneasilylocatecontrolsandtestthem.Theproposedframeworktakesintoaccountthereusability，theportabilityandthemaintainabilityofcodes.Atpresent，thisautomatictestingframeworkhasbeenputintopracticaluseinmanyJapanesecontrolcorporations.

KeyWords:

WinFormControlAutomaticTestingGUIInput

第一章绪论

随着计算机技术的发展，人们对软件产品的质量有了更高的要求，因此软件测试工作在整个软件开发的过程中也越发重要。

从繁杂的手工测试到实用性强的自动化测试，从最初只提供简单的捕捉/回放功能的测试工具到功能和灵活性更强的测试脚本工具，自动化测试已经取得了很大的进步[2]。

但随着软件规模的不断扩大，软件类型的不断增多，人们希望自动化测试能够更加高效和简便。

自动化测试框架的出现，加速了自动化脚本的生成，提高脚本的可维护性，加速脚本执行效率等，目的是减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。

1.1研究背景

2001年后，.NETFramework2.0的诞生，人们将它看作是多年来最重要的新技术。

.NETFramework以多种方式对面向组件的开发模式做了强而有力的支持。

.NETFramework为开发人员提供了两种控件支持：

一种是WebControl，一种是WinFormControl[15]。

其中WinFormControl是目前发展最快，应用最广泛的。

.NETFramework使得开发人员可以通过将多个标准WinFormControl组合，而定制出符合用户需求的应用程序。

开发人员还可以通过继承某个标准WinFormControl，附加新的功能与业务逻辑满足自己的需要。

更高级的开发人员可以直接从.NETFramework提供的Control基类派生出自定义的WinFormControl（CustomControl）[20]。

尽管面向组件的开发模式和.NETFramework的支持，使得WinFormControl的开发人员以及厂商获取了更多的好处，但却给WinFormControl的测试工作带来了很多困难，因为目前市场上并不存在面向WinFormControl的自动化测试框架，因此，对于WinFormControl的测试，除了最基本的属性、方法和事件的测试可以利用目前常用的单元测试框架实现自动化测试以外，其他大部分对于WinFormControl的测试都必须依靠测试人员手动完成。

但随着WinFormControl的不断发展，最终用户对WinFormControl的种类、质量、功能以及用户界面的要求也在不断增加，这就推动了市场的壮大，同时促进了一批以WinFormControl为产品的公司或者部门的建立，最终将推动WinFormControl从产品向产业进一步发展，因此，自动化测试WinFormControl也成为一种必然，那么开发一套面向WinFormControl的自动化测试框架是非常有必要的。

1.2国内外现状

目前，可用于对WinFormControl的基本属性、方法和事件进行自动化测试的单元测试框架很多，常用的单元测试框架根据开发语言不同，可分为[13]：

1JUnit：

JUnit就是为Java程序开发者实现单元测试提供一种框架，使得Java单元测试更规范有效，并且更有利于测试的集成。

此框架是由AlanRay和ErichGamma开发的。

2CppUnit：

CppUnit是从著名的JUnit框架为C++移植过来的。

是由MichaelFeathers开发的。

3Microsoft.NETFramework提供的单元测试框架，包括：

NUnit、CsUnit、MbUnit和XU。

许多.NET开发人员都或多或少有一些使用NUnit的经验，它是.NET的一个最主要的单元测试框架，是由JamesNewkirk所开发的。

虽然NUnit涵盖了.NET应用程序单元测试的大多数必要情景，但MbUnit可以让单元测试更进一步。

MbUnit是由Jonathan“Peli”deHalleux首先编写的一个开源单元测试框架。

最新推出的单元测试框架为XU，此框架从现有框架中脱颖而出的因素有很多。

最重要的一点是，它是由JamesNewkirk和BradWilson构建的。

Newkirk是Microsoft负责CodePlex项目的产品经理，曾帮助构建NUnit，他撰写了大量有关于单元测试的书籍。

BradWilson是thedotguy上的一位资深博客作者，模式和实施方案小组的前成员，还是Microsoft的特别员工。

这一全新框架的目标是利用在过去五年内积累的有关单元测试的最佳实践，构建一种能体现并鼓励这些实践的全新框架[23]。

1.3课题的意义

目前，单元测试框架技术一直在不断发展，现有的单元测试框架也一直在被更新和改进，但随着WinFormControl的类型和复杂度不断增加，现有的单元测试框架无法准确定位WinFormControl，尤其是无法获取WinFormControl的各个组成部分信息并进行测试，而且现有的单元测试框架也无法模拟鼠标和键盘的操作，因此无法测试用鼠标和键盘对WinFormControl操作后的结果是否正确，也无法监听鼠标或键盘触发的事件是否正确，验证数据和脚本代码维护也有诸多不便，由此可见，现有的单元测试框架已经无法满足现有WinFormControl的自动化测试需求。

本人通过在西安某控件开发公司一年的实习，在NUnit单元测试框架的基础上，设计并实现了GUI测试框架和Input测试框架，最终成功开发了这套面向WinFormControl的自动化测试框架，此框架不仅基本解决了现有WinFormControl自动化测试存在的问题，而且对于面向控件的自动化测试框架的研究具有长远的现实意义。

目前，该框架已被很多日本控件公司投入使用，取得了良好的市场反映。

1.4论文的工作和结构

本论文选题来自西安某控件开发公司基于面向WinFormControl的自动化测试系统研发项目。

本人在WinFormControl自动化测试的研究与设计自动化测试框架的工作经历了四个主要阶段：

第一阶段：

学习阶段。

在原有单元测试框架的理论基础上，进一步对NUnit单元测试框架进行了深入学习，阅读了大量自动化测试及WinFormControl开发技术的书籍，为后续的工作奠定了良好的专业理论基础。

同时，为了更好地进行自动化测试框架的设计，学习了C#语言和相关开发工具。

第二阶段：

研究阶段。

对WinFormControl的测试特点进行分析和研究，总结了WinFormControl自动化测试的特点和原理，并给出了WinFormControl自动化测试的流程，为WinFormControl自动化测试框架的设计提供了明确方案。

第三阶段：

设计阶段。

根据目前WinFormControl自动化测试存在的问题，在之前研究方案的基础上，设计了GUI测试框架和Input测试框架，最终实现了面向WinFormControl的自动化测试框架。

第四阶段：

验证阶段。

通过几个典型的测试用例，证明了面向WinFormControl的自动化测试框架的实用性。

根据所完成的工作，将论文结构安排如下：

第一章绪论

本章首先分析了课题的研究背景，然后通过介绍国内外现有的单元测试框架，分析了现有的单元测试框架无法满足WinFormControl自动化测试需求的原因，阐明了开发一套面向WinFormControl的自动化测试框架的意义，最后对论文的工作进行了总结以及对各章节内容进行了安排。

第二章WinFormControl及常用单元测试框架

本章介绍了WinFormControl的定义及分类，并分析了几个常用的单元测试框架的原理。

第三章WinFormControl自动化测试研究与分析

本章根据WinFormControl的特点，研究总结了WinFormControl自动化测试的原理，着重研究了鼠标和键盘的事件处理，提出了WinFormControl的GUI测试思想，并给出了WinFormControl自动化测试的流程及分析了WinFormControl自动化测试的优点。

第四章面向WinFormControl的自动化测试框架的设计

本章详细描述了如何对GUI测试框架和Input测试框架进行设计实现，以及对结果比较方法的设计实现，并分析了面向WinFormControl的自动化测试框架的优点。

第五章面向WinFormControl的自动化测试框架的验证

本章将此框架运用于WinFormControl的自动化测试工作中，根据具体的测试用例，运用此框架编写测试脚本，根据脚本运行的情况及测试结果报告，验证了框架的正确性和实用性。

第六章结束语

本章一方面对本文所研究的项目加以总结，另一方面提出进一步改进和完善该项目的方法。

希望能有更多更好的面向控件领域的自动化测试框架推出，并投入实际生产当中。

第二章WinFormControl及常用单元测试框架

2.1WinFormControl的定义及分类

控件（Control）是在图形用户界面（GUI）中屏幕上的一种对象，用户可操作该对象来执行某一行为。

控件是用户可与之交互以输入或操作数据的对象。

控件通常出现在对话框中或工具栏上[16]。

WinFormControl是控件的一种，目前，对于WinFormControl的应用非常广泛。

2.1.1WinFormControl的定义

.NETFramework为开发人员提供了两种控件支持。

一种是WebControl，一种是WinFormControl。

顾名思义，WebControl是Web开发所需要的控件产品，而WinFormControl则是在设计和开发Windows应用程序时，用到的控件[17]。

WinFormControl是可重用的控件，它们封装了用户界面的功能，可以在基于Windows的客户端应用程序中使用。

“Windows窗体”不仅提供了许多现成控件，还提供了自行开发控件的基础结构。

可以组合现有控件、扩展现有控件或创作自己的自定义控件。

WinFormControl是从System.Windows.Forms.Control直接或间接派生的类。

以下列表描述了开发Windows窗体控件的常见方案[9]：

1组合现有控件来创作一个复合控件。

复合控件封装有一个可以作为控件重复使用的用户界面。

其中的一个示例就是由文本框和重置按钮组成的控件。

可视化设计器为创建复合控件提供了有力的支持。

若要创作复合控件，请从System.Windows.Forms.UserControl派生。

基类UserControl为子控件提供了键盘路由并使子控件可以作为一个组进行工作。

2扩展现有控件，对其进行自定义或为其添加功能。

一个不能更改颜色的按钮和一个具有跟踪点击次数属性的按钮就是扩展控件的具体示例。

可以通过从任何Windows窗体控件派生控件并重写或添加属性、方法和事件的方式来自定义Windows窗体控件。

3创作一个不是通过组合或扩展现有控件而形成的控件。

在这种方案中，需从基类Control派生控件。

可以添加和重写基类的属性、方法和事件。

4WinFormControl的基类提供了客户端基于Windows的应用程序中的可视显示所需的机制。

Control提供窗口句柄，处理消息路由，并提供鼠标和键盘事件以及许多其他用户界面事件。

还提供了高级布局，并具有特定于可视显示的属性，如ForeColour、BackColour、Height、Width和许多其他属性。

此外，它还提供了安全性、线程支持以及与ActiveX控件的交互性。

由于基类提供了很多基础结构，使得开发自己的Windows窗体控件变得相对简单。

2.1.2WinFormControl的分类

目前，微软已经推出三代控件，分别是：

1ActiveX控件：

ActiveX控件是微软公司提供的功能强大的程序设计和开发技术，是COM组件开发技术的重要组成部分。

它是OLE的第三个版本，对原先OLE控件的最大扩展是增加了Internet功能，它不仅可以在支持OLE控件的容器中使用，更可以作为一个Internet控件，直接成为网页的一部分。

另外，ActiveX控件作为一种可重用的组件，相当于一个封装好的代码模块，它是通过其方法、属性、事件来与应用程序进行通信的，此外，ActiveX控件是与开发语言无关的。

用户在使用控件时不必考虑它是VC还是用VB等其它语言开发的，应用程序都是通过COM与控件进行通信的[19]。

可见，任何支持ActiveX控件的软件平台上都可以使用ActiveX控件，它使得不同厂商所开发的控件可以真正地组装在一起，从而令软件的生产过程类似于硬件业的各个插件的装配过程一样，实现了软件的工业化，大大降低了软件的开发成本，极大地提高了软件的生产效率，实现了软件资源的共享。

2COM控件：

COM组件是以WIN32动态链接库（DLL）或可执行文件（EXE）形式发布的可执行代码组成，它是遵循COM规范编写的，是一些小的二进制可执行文件，COM控件可以给应用程序、操作系统以及其他组件提供服务。

自定义的COM控件可以在运行时刻同其他组件连接起来构成某个应用程序。

COM组件可以动态的插入或卸出应用，而且必须是动态链接的，它必须隐藏（封装）其内部实现细节，必须可以在不妨碍已有用户的情况下被升级，且可以透明的在网络上被重新分配位置[24]。

3WinFormControl：

常用的WinFormControl可以分为六大类[11]，分别是：

（1）最根本的父控件Form：

这个类别中只包含一种控件：

窗体类。

这样分类的理由在于：

窗体类是所有其他类的父亲（parent），这里的“父亲”你可以作以下的理解。

如果这里的“父亲”你理解作“容器”，那么窗体类是所有控件的父类。

这就是说，每个控件在视觉上都处在某个窗体中（或者是在别的控件中，例如面板（Panel）控件，面板控件自己还是被包含在一个窗体中的）。

（2）容器控件，常用的有：

1）Panel

2）TabControl

3）TabPage

4）FlowLayoutPanel

5）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）DominUpDown

4）ListBox

5）ListView

6）TreeView

复合项控件可以显示一个列表或是一个数组，并且允许用户从列表中选取某一选项。

每一个控件类都允许你通过容器来访问被显示的数据——数组或是列表——这被作为控件的一个属性得以实现。

这些控件使你可以使用面向对象的方式来访问底层数据。

对几乎所用控件而言——除了DataGrid控件——实际的数据都存在于一个对应的底层Win32控件之中。

除了DataGrid控件之外，每一个复合项控件都允许你在程序编译时给定一个初始化列表。

VisualStudio.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毫秒