第一章      前言

为 了提高测试效率和准确性，越来越多的测试工作引入了自动化测试的思想和方法，随着自动化测试工具的发展，自动化测试更加容易实现更高效。实践证明，软件自 动化测试技术帮助软件开发和测试人员在更短的时间内开发出更高质量的产品，通过代替频繁重复的手工测试从而节省了大量的时间开支。同时，自动化测试技术也避免了手工测试出现的人为错误，完成了许多手工测试无法实现的工作。

自动化测试相较于手动测试有许多明显的优势，执行高效率、测试数据覆盖面大、结果可信。但同时自动化测试也存在着一些限制。简单的录制/回放测试工具本省无法提供高效的测试。依靠捕捉产生脚本的维护需要耗费大量的时间。在项目需求不稳定或页面频繁变动的阶段，自动化测试的效率将非常低下。

面对自动化测试的这种尴尬，关键字驱动的自动化测试可有效地提高自动化测试脚本的维护效率。关键字驱动的自动化测试搭建了一个自动化测试框架，测试框架脚本与业务、数据分离，节省了大量对脚本的维护工作。本文对关键字驱动的自动化测试做具体介绍。

第二章      自动化测试工具存在的问题

基本的录制/回 放自动化测试具有简单易用、快速上手的特点，但在实际应用过程中存在很多问题。最常见的一个问题是对程序界面进行测试时，一旦界面有任何改动，都需要我们 去手工修改已录制的相应测试脚本，或者重新进行一次录制。这需要消耗很大的工作量，尤其对于程序中各模块都要使用的公共程序部分（如登陆页面），他的改动 会引起大量脚本的返工。如在使用Rational Robot录制的点击按钮操作的脚本：测试工具通过按钮的名字、显示文本来识别这个按钮。可以想象，当其中任何一个部分发生变化时都会对脚本造成影响，维护如此的脚本将很可能花费大量成本。

另一个问题是移植风险大。被测试软件转换平台，或转变自动化测试工具都可能造成测试用例被破坏，很可能要对现有脚本进行大量修改或重新录制。因此转换平台或转换工具可能对自动化测试带来毁灭性影响。

第三章         自动化测试的发展

3.1自动化测试框架的发展

一 个自动化测试框架就是一个由假设、概念以及为自动化测试提供支持的实践的集合。自动化测试框架可以减少测试脚本实现和维护的成本，使测试人员把精力集中在 测试用例的设计上。自动化测试框架的好坏直接影响到自动化测试的成功与否。一个优秀的自动化测试框架应该满足以下特点：

1) 测试框架与被测应用程序独立。虽然测试的应用程序不一样，但被测应用程序之间却会有相同的地方，测试框架应聚焦在不同测试应用程序中共同的部分，把与具体应用程序有关的部分从框架中移除。

2) 测 试框架应易于扩展、维护。测试框架应被高度模块化，这样可以提高框架的维护性。各个模块之间相互独立，对模块内部的修改不应该影响其他模块。除此之外，系 统应该有充足、详细的文档，与软件开发一样，这也是必不可少的。设计文档可以帮助开发人员扩展、维护测试框架，而使用文档则可以告诉用户要怎么使用该框 架。

3) 测试脚本所使用的测试语言应该是与框架独立的。不同的测试框架可能在不同的应用领域有不同的表现，有些适用于Java应用程序的测试， 有些可能适用于Web应用程序的测试，如果测试脚本所采用的语言是私有的、与测试框架绑定的，那么当需要从一个测试框架迁移到另外一个测试框架时，所有的测试脚本都需要重写。

4) 测 试框架不应该让框架的复杂性影响到测试人员。在大多数情况下，测试人员就是测试人员而不是开发人员，甚至有的时候，他们不是专业的测试人员，可能只是具有 很少软件开发经验的某个应用领域的专家。对于这些使用者来说，测试框架的使用要简单、测试语言要易于理解，这样可以使他们专注于业务相关内容的编写。

基于界面的软件自动化测试框架和工具的发展大致经历了三个阶段：

1）简单的录制／回放：由工具录制并记录操作的过程和数据形成脚本，通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起，几乎一个测试用例对应一个脚本，维护成本很高。而且即使界面的简单变化也需要重新录制，脚本可重复使用的效率低。

2）数据驱动 （data driven）的自动化测试：从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离，脚本的利用率、可维护性大大提高，数据的覆盖率也较高，但受界面变化的影响仍然很大。

3）关键字驱动（keyword driven）的自动化测试：关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。 主要关键字包括三类：被操作对象（Item）、操作（Operation）和值（value），依据不同对象还有其他对应参数。关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。数据驱动的自动化测试框架在受界面影响方面，较数据驱动和录制/回放有明显的优势，可根据界面的变化更新对应的关键字对象，而不用重新录制脚本。

关键字驱动的自动化测试系统与数据驱动的系统相比，主要的不同有两点：第一点是数据文件 的设计方法不同，数据驱动系统中数据文件存储的是测试输入数据，脚本中仍然存在业务逻辑，这样业务的变化会引起脚本的更改，而关键字驱动系统数据文件的设 计将业务和测试输入数据都集成在数据表格中，虽然设计复杂，但当业务发生变化时，无需更改测试所用的脚本，从而提高了测试的效率。第二点是与数据驱动系统 相比，由于关键字驱动系统中数据文件的设计包含了业务信息，因此，将测试所进行的操作封装为关键字支持脚本。由动作封装的关键字支持脚本不包含任何的数据和业务信息，其重用性得到了极大的增强。

3.2自动化测试脚本的发展

相应地，软件测试自动化脚本的类型也依据脚本框架的演进在不断发展，从低到高的发展层次是：

1)   线性脚本：通过录制直接产生的线性执行的脚本，类似于宏录制。

2)   结构化的脚本：具有顺序、循环、分支等结构的脚本。

3)   共享的脚本：可以被多个测试用例使用，被其它脚本调用的脚本。

4)   数据驱动的脚本：数据和流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本。

5)   关键字驱动的脚本：脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是它描述一个测试事例做什么, 而不是如何做，测试脚本调用测试用例再具体执行。

第四章  关键字驱动的自动化测试框架

4.1基本原理

关键字驱动的自动化测试框架是对数据驱动的逻辑扩展，用关键字的形式将测试逻辑封装在数据文件中，测试工具只要能够解释这些关键字即可对其应用自动化，它的核心思想可以概括为三个分离。

1）界面元素名与测试内部对象名的分离 在被测应用程序和录制生成的测试脚本之间增加一个抽象层，它可以将界面上的所有元素映射成相对应的一个逻辑对象，测试针对这些逻辑对象进行，界面元素的改变只会影响映射表，而不会影响测试。

2）测试描述与具体实现细节的分离，把测试描述和测试的具体实现细节分离开来。测试描述只说明软件测试要做什么以及期待什么样的结果，而不管怎样执行测试或怎样证实结果。这样做是因为测试的实现细节通常与特定的平台以及特定的测试执行工具有着密切的联系。这种分离使得测试描述对于应用实现细节是不敏感的，而且有利于测试在工具和平台间的移植。

3）脚本与数据的分离 最后，可以把测试执行过程中所需的测试数据从脚本中提取出来，在运行时测试脚本再从数据存放处读取预先定制好的数据，这样脚本和数据可以独立维护。

以上这三个分离各司其职、互相独立，最大程度地减少相互之间的影响。从关键字驱动的思想可以看出，该种测试框架不仅实现了将数据和脚本相分离，而且实现了测试逻辑和数据的分离，大大提高了脚本的复用度和维护性，从而更大限度地实现了测试工具的自动化。

例如在一个登陆页面输入用户名，用一个测试表（表格1）来表示：

图表 1 登陆测试表

这个测试表的含义是在LoginPage窗口的UserID文本框中输入“admin”。其中InputText是关键字，当测试程序读取它的时候，就会调用相应的处理函数，处理脚本动作。

 关键字驱动测试模型

图 1 关键字驱动模型

测 试首先由初始脚本开始，把高层测试表传递给高层驱动器，高层驱动器在处理这些表的过程中，遇到中层测试表就调用中层驱动器，中层驱动器处理中层表。当低层 驱动器处理低层表的时候，他试着使应用与测试保持同步。当低层驱动遇到某一成员的关键字指令时，它调用相应的函数模块来处理关键字的动作指令。所有这些元 素都要依靠映射表中的信息，踏实自动化模型和应用间的桥梁。

应用映射表

映射表是关键字驱动自动化测试中的关键组件之一。映射表是对应用中的每一个对象定义一套命名规范，并利用映射表把这些名字和自动化工具识别的对象名联系起来，是工具能准确定位和操纵对象，我们的脚本只需进行单点维护。

映射表的建立有许多种，简单的就是 通过自动化测试工具进行自动捕获，将捕获的对象信息存储于指定的数据表格或数据库之中。如果是自动捕获可以分类记录尽可能多的对象的属性，使得测试脚本更 方便地标识对象。另一种就是采用人工录入，即对于自动化软件测试需要用到的对象信息采用手工识别的方式录入数据文件或数据库之中。这种方式通常是挑选最能 达到测试效果的一组对象属性即可。对于结构复杂的软件可以根据软件的不同层次或是软件界面的不同区域划分对象库。例如对于窗口空间，我们可以将窗口命名为 上下左右主几个部分，将位于不同窗口区域的控件信息保存到相应的窗口名称之下，这样当软件升级或者是GUI界面发生变化时，对于增加的窗口或者是控件，只需要使用测试工具捕获其标识属性，并人工填充到映射表内即可。这样就为测试脚本提供了对象识别的仓库。

成员函数

成员函数是实现用户对界面对象操作指令的函数，一个成员对象的类型对应一个成员函数库。例如对以一个文本框对象，可对它进行多种操作：输入文本、验证文本框的值等，实现这些操作行为的函数就被放在文本框的成员函数库中。一般的测试工具都提供了这样的函数。

成员函数相当于在应用和自动化工具之间提供了一个隔离层，如果没有这个隔离层，自动化工具本身的改变会影响到已有的脚本。有了隔离层，当测试工具发生变化时，可以在成员函数库中增加一段修补代码来适应变化。

测试表和核心驱动程序

测试表分低层、中层、高层。低层测试表指定了测试的每一步指令语句，这些指令都是直接作用在界面对象上的，是无法再锌粉的指令。中层测试表把低层表组装起来执行任务，形成测试用例。高层测试表把中层表组装起来，利用循环完成不同的中层测试，形成测试集。

例如打开网页、登陆、关闭页面这三个动作可以用三个低层表来表示（如表），每个表定义了实现相应动作的具体步骤，所以低层表示又叫做步骤表。低层表中使用了映射表中定义的对象名，和成员函数库定义的底层关键字库。

图表 2 “登陆”步骤表

这个“登陆”动作的低层表可能出现在“验证正确登陆”，“验证错误登陆”和“验证空白登陆”等中层用例表中，这些中层表合起来构成了“验证权限”高层表。

假定你有一个活，需要构建许多自动化测试用例来测试这个应用程序。当你对这个应用程序完成自动化测试后，你对自己创建脚本应该有什么期望吗？你难道不想要-

• 脚本应该按照预期的来执行而且没有发生任何问题
• 脚本和流程应该会被很容易的理解
• 脚本是容易维护的

所有以上观点需要一个合适的自动化测试框架才能被实现

一个自动化测试框架是一个规范或者是约束，你需要让测试脚本遵从一些规则来完成上面提到的3点内容，这些规则或者纲要如下，比如

• 指定一些目录结构用来存储对应的测试用例，函数库，对象库和数据表格
• 决定数据表格格式，比如数据表个应该怎么组织，脚本是怎么访问这些数据表格的
• 遵循正确的代码标准，并且要在代码里有备注，以便别人能看懂你的代码
• 尽可能把一些能复用的代码封装成为函数，以便在发生变化的时候只需要修改很少的一部分

在创建测试脚本的时候始终遵循你设置的准则，这样可以创建一个包含所有你曾经有针对性的功能的自动化测试框架

框架的类型分别如下：

2. 在QTP使用的不同类型的框架

3. QTP里的线性框架

线性框架是你一步一步在测试流程里写测试脚本。在这样的框架类型中，你不需要创建任何函数，所有的测试步骤都是从上到下线性的顺序来写。假如你有一个测试用例，它是按照 Login->Create->Order->Logout的流程来走，那么测试脚本就会按照如下图所写一样：

3.1 在线性框架里的组件和工作流

以下图形展示了关于QTP线性框架的组件和典型的工作流

在这里每个测试用例都有它自己的对象库并且脚本里的数据都是hardcode

3.2 线性框架的优势：

• 不需要自动化的专业知识，你只需要录制和回放的方法就能用来创建脚本
• 快速和容易的方式来创建测试脚本
• 由于脚本是按照从上到下的顺序来写的，所以框架流程理解起来比较容易

3.3 线性框架的缺点：

• 重用代码的唯一方式是不断的复制和粘贴，从而导致大量冗余的代码
• 由于脚本里数据都是hardcode，同一个测试用例不能被不同的测试数据所驱动
• 由于代码在许多地方都是重复的，所以一旦有地方发生变化就需要修改很多地方

4. 关于QTP的模块框架

模块框架就是把所有的测试用例首先要分析下找出可以复用的流程的一个方法。然后把所有可以复用的流程放进函数里封装起来存储在外部文件中，当需要的时候可以在脚本里调用这些函数。考虑以下2个测试用例。

a)Login>Create Order>Logout.

b)Login>Search Order>Logout.

在这里登录和登出是可以复用的流程。那么这些流程就被封装起来保存在外部函数库里。测试脚本应该看起来像这样

4.1 模块框架的组件和工作流

为了可以使用外部库文件里的函数，库文件首先需要和测试用例关联起来。这样测试用例就可以调用库文件里的函数了

4.2 模块框架的优点：

• 由于复用的函数只需要创建一次，测试脚本就只需要调用所需要的函数，而不需要重新再写一遍函数里的内容，那么创建起来就快一点
• 由于代码的复用，创建测试用例所花的功夫也会缩短
• 如果复用的函数里发生任何改变，只需要改变一个地方就会影响到调用它的所有测试用例，因此维护起来也会很容易

4.3 模块框架的缺点：

• 由于脚本里的数据还是hardcode，所以还是不能实现不同的测试数据运行同一个脚本
• 需要花费额外的时间来分析测试用例识别出那些是可以复用的
• 创建和维护函数库需要好的编程知识

5. QTP的数据驱动框架

在数据驱动框架里，测试脚本里的数据不在是hard-code。相反，数据是被存储在一些外部文件里。测试脚本需要首先连接到外部数据源，然后从数据源里解析这些数据。大部分时间，我们一般都会使用Excel表格用来存储数据。其它的经常使用的外部数据源是：文本文件，XML文件，数据库以及一个外部文件以上的组合

5.1 数据驱动框架的组件和流程

5.2 数据驱动框架的优点：

• 由于数据与测试脚本是分离的，可以实现同一个脚本用不同的数据可以运行多次
• 测试数据的更改不会影响到测试脚本，反之亦然

5.3 数据驱动框架的缺点：

• 连接到数据源并读取里面的数据是需要额外的努力和相关专业的知识
• 需要用额外的时间来选择使用那种外部数据源，并且要决定外部数据源里的数据应该怎么被存储或是组织

 6. QTP的关键字驱动框架

在关键字驱动框架里，你可以创建一些关键字以及相关联的一些方法和函数。然后你创建一个函数库，它里面包含一个读取关键字的逻辑，然后调用相关的动作。

关键字驱动框架有许多不同的形式，其中一个解释如下：

6.1 关键字驱动框架的组件

• 数据表格或者Excel表格包含了关键字和需要执行特定流程或者动作的步骤

• 一个函数库里包含一些函数，这些函数可以读取Excel里每行数据，然后把他转换为QTP可以识别的格式（也就是QTP脚本），然后最终执行它。比如，函数库读取Excel里的第一行数据，然后把他转化为----Browser(“Title”).Page(“Title”).WebEdit(“UserName”).Set “user1”
• 对象库在这个框架里不是必须的，如果你不想用对象库的话，可以用描述性编程

6.2 关键字驱动框架的工作流

6.3 关键字驱动框架的优点：

• 关键字和函数库变成完全通用的，因此对于不同的应用可以很容易的被重用
• 所有复杂的逻辑都添加到函数库里了。一旦库文件被准备好，在Excel表格里写测试脚本将变得很容易

6.4 关键字框架的缺点：

• 需要花很多时间在初始化创建函数库上，关键字驱动框架的优势只有在它被长时间使用的时候才能被充分体现出来
• 创建复杂的关键字函数库需要很强的编程技术
• 对于新人想快速理解框架是有点困难

7. QTP的混合框架

混合框架的意思是上面提到的一些框架的组合，基于需求，你可以合并以上框架的任何功能来组合成你需要的混合框架的版

有许多不同的方式来创建混合框架。让我们一起看看混合框架中其中一种的结构和工作流程

7.1 关键字驱动框架的组件

• 驱动脚本：它是一个VBS脚本文件，他是运行测试脚本的入口点
• 批处理表格：批处理表格包含了有已经自动化的所有测试用例列表，并且还包含一个叫做Execute的列名，它的值是"Yes"和"No".驱动脚本会读取这个表格，然后执行被标记为"Yes"的测试用例

• 每个测试用例是被分割成不同的业务流程。因此当这个用例包含的业务流程都被执行时候，这个用例才算被完全的执行

• 上面所说的是构成混合框架的主要组件，像函数库，数据表，对象库，配置文件等其它一般的组件也是混合框架的一部分

7.2 混合框架的工作流

7.3 混合框架的优点：

• 这个框架最大优点就是你可以用到其他框架最好的功能

7.4 混合框架的缺点：

• 该框架是非常复杂的，需要具备很好的编程知识和经验来从头到尾的构建混合框架

8. QTP的业务流程测试(BPT)框架

把测试用例分成多个流程，每个流程都用业务流程组件(Business process component)来脚本化的一个框架。当一个具体的测试用例所包含的组件都已经准备好以后，你可以在QC里按照你们的业务逻辑来连接这些组件从而组成一个BPT的测试用例，然后就可以执行它

8.1 BPT框架的组件：

• 应用程序区域：它作为一个容器用来存储业务流程组件和其他相关的项，比如函数库，对象库等等。
• 业务流程组件：就像Action和函数是用来存储可以复用的脚本一样，BPT框架有业务流程组件，该组件包含了一个动作所对应的脚本
• 以上提到的2个组件在BPT框架里是非常有用的，而其它就是一些标准的组件，比如函数库，对象库，数据表等等。这些所有组件组成了BPT框架

8.2 BPT框架的工作流

8.3 BPT框架的优点：

• BPT可以让非技术业务专家可以使用业务组件快速创建测试用例
• 许多功能，比如组件链接&数据参数化，这些都是来自BPT内置的功能。有了这些功能，你不需要花费额外的时间来写实现这些功能的代码

8.4 BPT框架的缺点

• BPT框架只能在QC里使用
• 如果你想为了你的测试脚本用BPT框架，需要为该框架支付额外的费用

前言

Coded UI Test是Visual Studio 2010对于Testing Project(测试工程)提供的关于UI自动化测试的框架，支持Win32/Web/WPF等UI的自动化测试，在介绍它之前，先简单介绍一下持续集 成。大家如果对持续集成不感兴趣的话，可以直接跳到第3节。

1：持续集成

持续集成由软件工程大师Martin Fowler提出，他对技术集成下的定义是：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着 每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

按照持续集成的思想，代码可以也应该能够在一天里可以多次通过“构建”，从而能在一天之内提供多个可供测试的版本。

这里面讲的构建不单单是代码的编译通过，它应该包含下面的步骤：

• 所有最新代码从配置管理工具中取出.
• 所有的代码从干净的状态开始编译。
• 将编译结果链接并部署，以备执行。
• 执行部署的应用并运行测试套件。

如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，才认为这是一次成功的构建。

对于第4步而言，如果应用程序是一个需要安装到桌面的UI应用，那么就需要保证它可以成功的部署，这样才能提供可以测试的环境。

2：我的持续集成实践

我公司使用敏捷开发，使用CruiseControl进行代码控制，当代码被Check In 后， 会自动编译，并生成一个压缩后的exe文件，然而而当需要测试该exe文件时，需要手工从文件服务器下载，然后手工卸载已有的程序，再运行该exe安装新 的程序，确保安装后的程序/服务正确运行后，方能进行软件的测试。

也就是说，我们已经实现了前三步的自动化，而最后一步，由于涉及UI界面、服务卸载，一直没有能够自动化，这其中的一个难点就是该exe是一个较庞 大且复杂的压缩程序，在安装时可以使用十分灵活多样的配置，每一样配置都会导致不同的安装结果，如果要把所有常用的安装方式自动化，编程的代价比较大。

在了解了Visual Studio 2010提供的Coded UI test功能后，以上问题初步得以解决，从而在技术层面，使用较小的C#代码就完成了UI界面安装、服务卸载等问题，从而将上述第四步与前面的三步串联起来，初步满足了持续集成的要求。

最后形成的大致步骤是

1：开发人员提交代码

2：编译服务器开始编译，并在文件服务器上生成installer，并发出通知

3：C#程序去文件服务器下载installer，拷贝至测试服务器

4：C#程序卸载测试服务器上的原程序/服务

5：C#程序根据测试需要/测试参数安装installer，直到完成部署进行

6：C#程序调动自动化脚本(QTP/SilkTest/Seleium)，进行自动化测试

7：检查测试结果

第3-6步都是由一个C#程序完成的，下面我主要介绍一下第5步，也就是软件自动安装的实现原理，在掌握了自动安装之后，第4步，也就是软件的自动卸载也就同样得到解决了。

3: Coded UI test使用

Coded UI Test是对UI进行的测试，使用方法和很多支持UI自动化测试的工具（QTP、SilkTest）一样，都支持UI的录制、回放、识别、断言，与这类工具相比，它主要还有如下的好处：

1：基于.Net framework，且同时支持Win32/Web/WPF，利于代码的扩展和复用

2：可以编译成exe文件，脱离Visual Studio运行。

3：除了支持Web/Win应用外，还支持WPF（很多自动化工具对WPF的支持并不是太好）。

3.1 录制一个Coded UI test测试

一个复杂的installer，除了有复杂的安装配置之外，UI界面往往也比较复杂，在不了解Coded UI test这个办法之前，如果专门为installer写一个控制安装程序会是一件比较费时费力的工作，特别是当这个installer有多个设置窗口和控 件时。而使用Coded UI test则可以非常轻松的解决这些问题，代码也便于扩展。

下面以notepad++这个大家常用的小工具的安装来说明如果建立一个Coded UI Test（由于我的Visual Studio 2010是英文版的，所以只能提供英文截图和英文名称），在进入下文之前，建议大家再实际下载、运行一下notepad++的安装程序，体验它每一个窗口 的功能，以及支持的多种参数设置，并思考如果不使用自动化工具，如何编程实现程序的安装。

我在示例中使用的版本是5.9.6，大家可以去其官方主页http://notepad-plus-plus.org/ 下载5.9.6的版本npp.5.9.6.Installer.exe。

下面是具体的步骤

1：打开Visual Studio 2010，新建一个类型是Test的工程，如下图

2：删掉自动生成的第一个默认类

3：右击工程，选择Add，然后选择Coded UI Test，这时会弹出一个窗口，在此选择第一项“录制一个新测试”，点击OK按钮

4：此时，在窗口的右下角会弹出一个名为Coded UI Test Builder的窗口，点击第一个红色圆形按钮后，便可以进行一个UI测试的录制，如下图

5：在资源管理器中运行notepad++的安装程序，任意设置安装参数，逐个点击Next按钮，最后直至安装完成。

6：点击窗口右下侧Coded UI Test Builder窗口中第4个按钮，在弹出的窗口中将方法名称修改为DoInstall，然后点击Add and Generate按钮，稍等片刻后，整个程序便会生成了，这时可以关闭Coded UI Test Builder窗口。

7：生成后的工程结构如下图所示：

其中CodedUITest1.cs是测试类，而UIMap.uitest则包含了notepad++每个窗口的声明，以及安装的具体步骤，例如DoInstall的主体部分便是具体的每一步操作：

// Click 'OK' button Mouse.Click(uIOKButton, new Point(40, 10));// Click '&Next >' button Mouse.Click(uINextButton, new Point(40, 7));// Click 'I &Agree' button Mouse.Click(uIIAgreeButton, new Point(40, 7));// Click '&Next >' button Mouse.Click(uINextButton, new Point(40, 7));// Click '&Next >' button Mouse.Click(uINextButton, new Point(40, 7));// Select 'Create Shortcut on Desktop' check box uICreateShortcutonDeskCheckBox.Checked = this.DoInstallParams.UICreateShortcutonDeskCheckBoxChecked;// Click '&Install' button Mouse.Click(uIInstallButton, new Point(40, 10));// Clear '&Run Notepad++ v5.9.6' check box uIRunNotepadv596CheckBox.Checked = this.DoInstallParams.UIRunNotepadv596CheckBoxChecked;// Click '&Finish' button Mouse.Click(uIFinishButton, new Point(41, 6));

8：如果现在按F5，程序无法运行，原因是这段代码里没有运行notepad++安装程序的代码，只是假设安装程序已经运行了，所以我们要在第一个Click动作前面加上下面的代码

string installer = @"c:\share\npp.5.9.6.Installer.exe"; ApplicationUnderTest InstallerWindow = pplicationUnderTest.Launch(installer);

现在再按F5试试？应该可能运行一个完整的安装了。

程序说明：

1：在录制第一个操作时，系统已经自动将每一个涉及到的UI界面及其包含的元素加以识别，并记录每一次的操作（点击、键入等），当生成代码时，会把这些东东全部输出下来。

要想查看每一个界面元素的定义，大家可以选择任意一个元素，然后按F12，查看它的声明，并进一步查看它所成的窗口的定义。

例如第一个被点击的按钮uIOKButton,它位于UIInstallerLanguageWindow中，而UIInstallerLanguageWindow则是依靠SearchProperties属性具体定位的。

2：我们点击按钮、选中CheckBox，对应的操作就是Mouse.Click或者某CheckBox.Checked，如果我们有复杂的安装需求，可以按照这样的思路进行定制。

3：在实际的安装或者参数的设置时，往往有某些控件不可见/不可用，只有满足了某种条件才会可见/ 可用。就象本文的例子中，对于正在进行安装的窗口，其Next按钮是不可用的，见下图：

该按钮会在安装完成后可用，如果程序在这时要点击这个Next按钮，会导致程序报错，这时怎么办呢？

按照很多人的编程习惯，往往会用sleep(5)来解决，但这也有问题，不同的计算机性能不同， 在一台计算机上设置好的时间，在另外一台上可能过短，如果把时间设足够长，又会导致效率下降。
Coded UI Test提供了一系列方法处理这类问题，如下：

WaitForControlCondition（）:控件满足某种条件后再往下执行 WaitForControlEnabled（）:控件有效后再往下执行 WaitForControlExist（）:控件可以被找到后再往下执行 WaitForControlNotExist（）:控件不存在时再往下执行 WaitForControlPropertyEqual（）:控件的某个属性等于等值后再往下执行 WaitForControlPropertyNotEqual（）:控件的某个属性不等于等值后再往下执行 WaitForControlReady（）:控件准备就序后再往下执行

这样，对上同样例子中的倒数第二行代码，在程序安装时，由于要花费一定的时间，uIRunNotepadv596CheckBox所处的窗口还没有 显现，uIRunNotepadv596CheckBox自然还无效，因此，对于性能较的计算机，执行到这句话时可能出错，为了保险，可以在之前增加一行 代码：

uIRunNotepadv596CheckBox. WaitForControlReady（）;

然后再执行后面的：

uIRunNotepadv596CheckBox.Checked = this.DoInstallParams.UIRunNotepadv596CheckBoxChecked;

就可以保证该控件是在有效的情况下执行后面的操作了。        

4：控件的名称、窗口的名称都是程序自动生成的，如果觉得命名不好，可以用Visual Studio 提供的重构-改名功能进行替换。

5：程序的入口是public void CodedUITestMethod1()，默认是无参数的，如果需要在安装中设置复杂的参数，以及把安装程序的路径传递进去，可以在此增加参数，然后把参数传递到具体的执行方法DoInstall()

3.2 让程序脱离Visual Studio执行

以上的代码只能Visual Studio中运行，要想让它脱离Visual Studio也能运行，需要做如下操作。

1：增加一个类，假设名称是TestMagager，加入如下代码

public static void Init() {     if (!Playback.IsInitialized)     {         Playback.Initialize();     } }

2：新建另一个工程（可以是Windows,也或以是类库），引用上述的测试工程，然后在代码先中调Init()，然后直接调用安装的主程序，如下：

TestMagager.Init();  CodedUITest1 t = new CodedUITest1(); t.CodedUITestMethod1();

3：这个新建的工程编译成功后，理论上调用上述的代码可以进行软件的安装，但此时会报错误，提示所需要的DLL文件不存在，其原因是：

对于Test类工程，Visual Studio 可以找到依赖的DLL文件，然而被引用由其它的程序调用后，便不能找到这些文件，只要手工把它们拷贝到一个统一的目录，然后引用到新建的工程就可以了，这些文件是：

Microsoft.VisualStudio.QualityTools.CodedUITestFramework.dll Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml Microsoft.VisualStudio.TestTools.TestSettings.Common.dll Microsoft.VisualStudio.TestTools.TestSettings.dll Microsoft.VisualStudio.TestTools.UITest.CodeGeneration.dll Microsoft.VisualStudio.TestTools.UITest.CodeGeneration.xml Microsoft.VisualStudio.TestTools.UITest.Common.dll Microsoft.VisualStudio.TestTools.UITest.Common.xml Microsoft.VisualStudio.TestTools.UITest.Extension.dll Microsoft.VisualStudio.TestTools.UITest.Extension.IE.Communication.Interop.dll Microsoft.VisualStudio.TestTools.UITest.Extension.IE.dll Microsoft.VisualStudio.TestTools.UITest.Extension.MSAA.dll Microsoft.VisualStudio.TestTools.UITest.Extension.Uia.dll Microsoft.VisualStudio.TestTools.UITest.Extension.xml Microsoft.VisualStudio.TestTools.UITest.Framework.dll Microsoft.VisualStudio.TestTools.UITest.Playback.dll Microsoft.VisualStudio.TestTools.UITest.Recorder.dll Microsoft.VisualStudio.TestTools.UITesting.dll Microsoft.VisualStudio.TestTools.UITesting.dll

在Visual Studio的安装目录下搜索，可以找到这些文件，它们分别存储在\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies和

\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies目录下，把它们拷到一个目录中，然后在应用中全部引用，便可以运行新建的这个工程了。

3.3 示例程序

Coded UI Test程序地址是：点击这里

解压缩后，一共有两个文件夹，第一个是Coded UI Test工程，第二个是Winform对它的调用。

因为偷懒，所有Project的文件全是系统默认的，生成的代码也没有重构，Coded UI Test工程用硬代码的方式运行Notepad++的安装程序(c:\share\ npp.5.9.6.Installer.exe),建议大家以参考代码结构为主，自己动手来建立一个类似的运行程序。

如果大家真的要运行示例程序，需要c:\share\ npp.5.9.6.Installer.exe这个程序存在,而且在安装Visual Studio 2010时，安装对测试工程的支持。

最后再说明，我已经把英文Visual Studio 2010的dll文件拷贝到了WindowsFormsApplication1的bin\debug目录下，并且在XP环境下测试通过。

使用上面的思路，还可以实现程序的自动卸载。

后记：按照上述方法，我实现了几个应用程序（包括服务）的自动安装、卸载，从而实现了上文提到的自动部署、测试，初步实现持续集成。

转自：http://www.cnblogs.com/gannan/archive/2012/02/07/2341961.html

测试对象模型是一大组对象类型或类，比如WebElement、WebList，QTP用这些对象类型和类来表示Web页面中的对象。每个测试对象类都有一个可以唯一标识对象的属性列表以及可以录制的方法，这个属性列表和方法列表是可以设置的，见图：

在Object Identification对话框中设置的属性录制完后都可以在Object Repository中查看。属性的具体分类见下一小节。

QTP里的对象分两个概念，一个是Test Object（简称TO）测试对象，一个是Runtime Object（简称RO）运行时对象。

这两个概念从字面上不大好理解，也容易混淆。

但从实际作用上来看，应该说TO就是是仓库文件里定义的仓库对象，RO是被测试软件的实际对象。

QTP识别对象，一般是要求先在对象仓库文件里定义仓库对象，里面存有实际对象的特征属性的值。

然后在运行的时候，QTP会根据脚本里的对象名字，在对象仓库里找到对应的仓库对象，

接着根据仓库对象的特征属性描述，在被测试软件里搜索找到相匹配的实际对象，最后就可以对实际对象进行操作了。

仓库对象TO一般在录制/编写脚本时加入仓库文件，它不仅可以在录制编写时进行修改，

也可以在运行过程中进行动态修改，以匹配实际对象。

和TO、RO相关的几个函数有：
　　GetTOProperty():取得仓库对象的某个属性的值
　　GetTOProperties():取得仓库对象的所有属性的值
　　SetTOProperty():设置仓库对象的某个属性的值
　　GetROProperty():取得实际对象的某个属性的值

理解了TO的含义，你就可以自由的用SetTOProperty()定义TO，以灵活的操作RO

比如有个测试任务，窗口上有很多待检查的记录，每条记录右边都有一个Check按钮，用来检查各条记录。
记录个数不定，所以Check按钮个数也就不定，只有一个Edit显示记录个数。
我们要对每条记录进行检查，也就是要点击每个Check按钮。
但是Check按钮个数不定，不好录制，而且个数可能也很多（上百个），即使能一一录制，那也很麻烦。

那我有一个好办法，只录制一个按钮对象，它设有两个特征属性 label=OK, index=0
然后用下面的脚本，就可以完成测试
buttonNum = CInt(JavaWindow("Test").JavaEdit("Record Num").GetROProperty("value"))
For buttonIndex = 0 to buttonNum - 1
JavaWindow("Test").JavaButton("Check").SetTOProperty("index", buttonIndex)
JavaWindow("Test").JavaButton("Check").Click
Next

或者窗口上有New、Modify、Delete、Check等好几个按钮，要把这几个按钮一一按过去
我在对象仓库里只设置一个按钮对象AnyButton，label特征属性值填任意值，然后用下面脚本执行测试
JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "New")
JavaWindow("Test").JavaButton("AnyButton").Click

JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Modify")
JavaWindow("Test").JavaButton("AnyButton").Click

JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Delete")
JavaWindow("Test").JavaButton("AnyButton").Click

JavaWindow("Test").JavaButton("AnyButton").SetTOProperty("label", "Check")
JavaWindow("Test").JavaButton("AnyButton").Click

脚本描述定义访问对象

如果Web对象没有被添加到对象库中，或者通过该Web对象的标识QTP无法识别,即对象库中没有该对象，那么可以用另一种方式：在脚本中用描述性编程来定义访问对象

常规语法为：

TestObject("PropertyName1:=PropertyValue1","PropertyName2:=PropertyValue2"...)+具体操作

如

Dim buttonIndex

buttonIndex = 1

JavaWindow("Test").JavaButton("label:=check","index:="+CStr(buttonIndex)).Click

属性详解（转载）

QTP通过三类属性来识别对象：

a）Mandatory;

b）Assistive;

c) Ordinal identifiers。

大部分情况下，通过对象的一些特定属性值就可以识别对象（类型a）。这些属性可以通过Tools->Object Identification 定义。每个测试对象类拥有一系列用于唯一确定对象的属性，这就是在这个Object Identification里查看。比如我看了一下WebEdit空间的识别方式，发现它就是通过type，name和html tag来识别。

在这里列出了所有QTP能识别的控件，以及控件的识别方式。你可以给他添加X、Y坐标进行识别。或更明显的，列表中的信息，不按名称识别，而是按ID识别。这个修改可以解决一些问题，想动手试试，但是不知道从何下手……

1. Smart Identification:

智能识别机制主要工作于测试脚本运行时(对象允许智能识别为真)，当对象 库中对象的强制属性（或辅助属性）与被测应用程序中对应对象的属性不一致时，智能识别机制将会启动。其主要原理为：先选择某个基本属性进行比较，若对象多 于一个，再继续添加属性筛选；若添加的对象属性造成无对象匹配，则淘汰该属性，应用该方法直至找到唯一对象并对该对象执行操作。(若所有属性的添加或淘汰 都无法识别唯一对象，QTP将应用ordinal identifier去识别对象。)

以上是原话，然后我的理解是：比如要识别页面上的一个webedit控 件，然后这个空间有那么多的属性，qtp会根据他的属性，然后从objectidentification里的强制属性和辅助属性里找，假如一致，就可以 识别到他就是identification机制里定义的webedit了，假如还是识别不到，就用智能识别。再不行，就用index。

在界面中可看到各种标准Windows控件对应的对象识别方法，例如，对 于Dialog控件，使用的是“is child window”、“is ownedwindow”、“nativeclass”和“text”这四个控件对象的属性来区别出一个唯一的Dilalog控件对象。可以单击 “Add/Remove”按钮，选择更多的控件属性来唯一识别控件。

以下这篇帖子有部分qtp官方文档的原话，我觉得理解起来更加权威些：
When you run a test, QuickTest searches for the object that matches the
description it learned (without the ordinal identifier). If it cannot find any
object that matches the description, or if it finds more than one object that
matches, QuickTest uses the Smart Identification mechanism (if enabled) to
identify the object. In many cases, a Smart Identification definition can help
QuickTest identify an object, if it is present, even when the learned
description fails due to changes in one or more property values. The test
object description is used together with the ordinal identifier only in cases
where the Smart Identification mechanism does not succeed in narrowing
down the object candidates to a single object.

The Object Identification dialog box also enables you to configure new
user-defined classes and map them to an existing test object class so that
QuickTest can recognize objects from your user-defined classes when you
run your test.

智能识别可是在三个层面设置可是启用：

a. 类，即Object Identification对话框中

b. 对象，即Object Repository对话框中

c. 测试中，即Run Testing对话框中

2. Ordinal Identifier:

QTP中设置共享对象库（转载）

很多时候我们总是觉得管理QTP的脚本比较烦.因为除了要对代码的管理之外，还要保证QTP对象库的完整．每一个用例脚本的生成，同时又都会生成一个对象库．那么是不是可以做一个公共的对象库来给各个用例脚本调用呢？接下来，我们就来实现共享对象库的应用．　　

第一步：把需要加到共享对象库中的各个用例脚本的对象库，分别导出成．tsr文件．
　　操作方法:先用QTP打开已经录制完毕的脚本后，选择Resources－－＞ Object Repository ．
　　然后file-->export Local Objects导出tsr文件

第二步：把需要加入到共享对象库中的各个用例脚本的对象库，合并对象及对象属性，形成一个大的共享对象库．（可选）
　　操作 方法:打开Resources－－＞Object Repository Manager．找到Tools菜单，然后选择打开ObjectRepository mergetool.选择两个要合并的对象库文件，进行对象合并．一次只能合并两个．所以如果这里你要合并多个对象库文件的话，先合并两个后，保存成一个 新的．tsr文件．然后再重复上面的操作，选择这个新的．tsr文件和另一个准备好的对象库合并．合并的时候，你会发现，在两个对象库文件中，相同的对象 合并成一个，不同的对象，全部被完整增加进去．然后形成一个大的对象库．现在只要保存这个共享对象库．如果以后有新增的对象，可以重复上述操作．

第三步：调用上面保存好的共享对象库．给新的脚本使用．
　　在任意test中，都可以依照操作步骤：Resources－－＞Associate Repository．选择上面保存好的共享对象库的．tsr文件．加入到Associate Repository中．

　　完成这一步后，其实整个共享对象库的操作已经完成．你在对象库中可以看到以后的对象．在录制新脚本的时候，如果对象已经存在，就不会再被记录，只有在这个对象库中没有的对象才会被记录进去．回放脚本，对象识别成功．

      QTP主要采用的是使用GUI模拟人的操作。它在模拟人的操作时会记录操作的对象及所做的操作和顺序，然后在回放时按记录顺序操作这些对象。而在这个模拟的过程中，最重要的莫过于界面对象（控件）的识别，那QTP是怎么做的呢？下面就举一个小例子来说明：

比如我们要测试内网论坛http://172.16.1.3:8080/bbs/index.php用正确的用户名和密码是否能成功登录。登录界面如下：

测试步骤大概如下：

1.      要先识别用户名输入框、密码输入框、登录按钮控件

2.      在用户名输入框中输入正确的用户名

3.      在密码输入框中输入正确的密码

4.      点击登录按钮

5.      验证是否登录成功，要验证是否成功登录，那就得知道成功登录与失败登录的区别。成功登录后的页面如下：

我们可以通过验证红色框中的内容或验证绿色框中的内容来标识登录是否成功，然后记入测试报告。

      以上只是一个小例子，从中可以看出识别对象是一个很重要的问题也是一个很困难的问题，毕竟现在的控件类型越来越多（包括第三方插件或自己开发或定义的控件）。那QTP是怎么来识别对象的呢，下面通过讲解QTP识别以上小例子中的控件的方法来说明一下：

      首先，QTP是通过记录控件的属性来标识对象的（当然具体用哪一些属性，QTP是有默认的，也可以配置）。假设QTP使用“html tag”和“name”属性来识别对象，QTP是怎么处理的呢？请先看下图：

      在使用QTP录制时，QTP会把对象存储到对象库中。而对象是按如上图的方式存储于对象库中。即，QTP会默认给录制的对象取一个名字（这个名字可以自己改，只要在脚本中使用到此对象时保持和此名字一样就可以了），然后把识别此对象的属性和属性值存储到对象库中，我们可以先把识别对象的属性集合认为是一个属性包，接着就是把识别此对象的属性包与定义的对象名进行关联，也叫做对象映射。这样一个对象就存入对象库了。

      接着来说明QTP是如何调用这个对象的。例如，在“用户名输入框”中输入“a用户”，伪代码如下：

WebEdit(“用户名输入框”).Set “a用户”

现在分析一下这个语句：

      首先，QTP会通过“用户名输入框”这个名字到对象库的对象名中查找，会找到以下这个对象名：

      然后通过找到的对象名，找到对象名映射的属性包，如下图：

      接着QTP就会通过这个属性包来匹配页面上的控件的属性，如果在页面上找到一个唯一与此属性包匹配的控件，那QTP就会认为此控件为要找的控件。

      然后QTP根据“WebEdit”来确定控件的类型，并调用QTP对于此类控件内置的操作方法“Set”把“a用户”赋予了控件

      至于其他控件的识别和操作，基本原理和上面一样。检验登录是否成功，也是通过比对登录成功后的页面特有的控件的属性值来判断。

      QTP还提供描述性编程，从而可以不使用对象库，如在“用户名输入框”中输入“a用户”，可以使用以下伪代码：

WebEdit(“Html tag:=INPUT”,”Name=username”).Set “a用户”

      细心的朋友可能已经发现，上面只是把识别对象的属性包中的属性和属性值按一定规则直接写到了“WebEdit()”的括号内了。这时QTP将不通过对象库，而是直接使用括号内的属性和属性值到页面上去找匹配项。然后操作与使用对象库的操作一样。

      当然，QTP还提供了一些其他的功能，比如参数化，划分模块（Action）呀。但最重要的还是对象的识别。本次到此结束，希望对大家理解自动化能有所帮助。