数据驱动测试一用变量取代在脚本代码中固定的名字、地址、数据等，通常通过变量从外部(文件、电子表格、数据库等)读取数据的测试，数据驱动自动化测试通常是开发自动化测试工具的最终目标。［1］

映射一(1)识别在不同组，或相同组内对应项的过程。(2)是(1)的一个表示。(3)一个关联的多元性。(4)在数学上，将每个定义域集合元素(输入)均指派为值域集合上某个元素(输出)的函数。一个一对一映射将每个定义域元素均指派为值域中一个唯一元素。可能存在未被映射的值域元素。一个到上映射将每个域元素至少指派为一个定义域元素。几个定义域元素可映射为同一个值域元素。一个双映射同时为一到一和到上的。每个定义域元素被确切映射为值域上的一个元素，而每个域元素至少被影射为定义域上的一个元素。［2］

脚本一以文件形式保存，具有正规语法的数据和／或指令，通常用于测试执行自动工具中。测试脚本可以实现一个或多个测试用例、导航、设置或清除设置及比较。用于手工测试执行的测试脚本为策划过程。［3］

录制／回放一某些测试执行工具的一种功能，将测试输入记录(捕获)为脚本，然后执行软件时可以回放这个脚本。［3］

随着软件规模和复杂程度的增加，在软件测试工作需要更多时间的同时，项目周期却比以前大大缩短，如何在有限的时间内完成软件测试工作，尽最大的可能暴露软件中隐含的缺陷，是软件测试工作中亟待解决的问题，而软件测试自动化将是获取可接受的测试覆盖率的一种有效途径，也是软件测试发展的必然趋势，然而，"工欲善其事必先利其器"，成功的自动化测试离不开一个合适的测试工具，自动化测试工具的购置涉及资金、资源和人员等多方
面的因素，是一项系统工程(1)。一般而言，自动化测试工具的选择与购置大致遵循下面的程序：

评估与选择是自动化测试工具购置活动的主要环节之一，前四个阶段主要是定义需求并确定侯选工具集，本阶段要对工具的各个功能特性进行逐一比较和综合评估，从候选工具中找出质量和性能价格比等方面综合评分最佳的工具。
测试自动化是一项长期的努力，测试工具的选择应从长远发展的角度出发，综合全面考虑工具的特性。

1 录制/回放(Record and Playck)

在自动化测试工作中，该功能是绝大多数专业测试人员开始自动化测试尝试的第一步，他们通常会先录制一个简单的脚本(这类似MicrosoftWord中录制宏一样)，然后回放、阅读和研究这些脚本。在日后的测试中逐渐会减少直接的录制／回放，而改用直接编写脚本或用工具内置功能测试对象、数据库等，但这是自动化测试所走的第一步，如果工具不能识别应用程序对象而无法进行对手工测试的录制和回放，日后测试自动化的实现将会遇到巨大困难而导致失败。在评估中应认真考虑工具的这一功能，主要从以下几个方面评价录制／回放功能：

(1)录制／回放一个手工测试是否简单容易?

(2)是否支持底层捕获，如鼠标拖动、精确屏幕定位等：

(3)在录制／回放中能否正确地识别对象?

(4)录制形成的脚本是否易于阅读与理解?

2 Web测试

网络的快速发展．使基于WEB的应用越来越多，而且已经成为应用程序开发的一种趋势，从长远发展的角度考虑，测试工具应提供基于WEB的测试功能而不仅仅只提供基于C／S模式的功能。C／S应用程序与基于WEB应用程序的测试有很大的差别：C／S应用程序其客户都是已知并定义好的，而且网络操作系统也是已知的，但测试基于WEB的应用程序却远远不同：客户可能来自不同的地方(如美国、中国乃至非洲等)，使用不同的浏览器，不同的屏幕分辨率，不同的语言，不同的连接速率和不同的操作系统(Mac、L,inux、Windows等)，因而建立一个基于WEB应用的测试环境成本远远高于C／S模式。在评估测试工具时，需要考虑工具是否支持超文本表格、框架页面、I)COM、不同平台的浏览器、网站映像和连接等，在评估中，以下几个特性要考虑在内：

(1)工具能否提供页面装载的提示信息?

(2)是否可以设置工具让其等待页面图片装载完毕?

(3)能否判定测试页面中的超连接是否存在?

(4)能否测试WEB页面对象功能，如对象的使能状态、是否包含数据等?

(5)是否允许按标题去查找WEB页面上的某一种类型对象或定位到特定的对象?

(6)能否从页面上提取数据?如标题，隐藏的表格单元元素等。

3数据功能

一般而言，应用程序都有接收和存储数据功能。为了测试这些应用程序，我们需要设计和产生这些数据输人到应用程序中。在自动化测试中，若工具提供这个功能，则在测试中我们可以定义数据产生规则，让工具自动产生大量这些数据对应用程序进行测试，该功能在测试数据库应用程序尤其有用。在另一方面，该功能在日后创建可用于多个开发项目的，基于数据驱动的自动化测试脚本库时非常有用，因而自动化测试工具应能产生和操纵这些数据，其需要或应该满足的特性如下： (1)能自动地产生测试数据；

(2)数据可以指定数据类型；

(3)能否从其他文件或电子数据表中创建和读取数据：

(4)可以随机存储这些数据。 4对象映射(Object Mapping)功能

如果软件工程师在开发软件时所用的都是一些标准而非定制的对象，就不需要自动化测试工具提供这一功能，但实际上几乎每个应用程序都包含一些非标准的控件或对象，目前市面上的多数工具都能支持应用程序中使用的标准控件，如Pushbut-tons、Edit boxes、Checkboxes、Radio buuons等，但对一些定制的控件却无能为力，如果工具提供对象映射功能，则当一个定制控件表现类似于一个标准控件时，可以通过映射功能，让其归类为这一类控件。对象映射功能的实现通常考虑以下问题：

(1)指定一个定制控件行为或表现类似与某一类标准控件，能否映射成该类控件?

(2)映射的控件是否支持该类标准控件的所有方法?

(3)能否增加定制控件到工具的控件集里? 5图像测试

一般而言，这功能不是测试工作的主要组成部分，但却不能缺少，有时必须要测试一个位图或类似的图片，在多数的Windows应用程序中会带有一些绘图控件，而在GIS(地理信息系统)应用软件的测试中，这一功能作用尤为重要。

(1)工具是否提供OCR(optical character recog-nition)功能?

(2)是否支持图像之间的比较?

(3)图像比较速度如何?

(4)在进行比较时，能否屏蔽特定的区域?

6 测试/错误恢复能力 测试／错误恢复总的来说是自动化测试中最困难的部分，但对自动化测试工具而言是必备功能。而自动化测试工具的这一功能一般决定于它本身能捕获错误的数量，可以识别的错误类型以及如何从错误中恢复等等。这功能的实现一般可以从解决以下问题上得到体现：

(1)如果测试过程中程序崩溃了怎麽办?

(2)如果一个程序功能接收不到应该出现的提示或信息怎麽办?

(3)如果出现错误信息怎麽办?

(4)如果访问一个网站但返回一个错误信息怎么办?

(5)如果无法连接数据，如何略过有关的测试?7对象命名映射

自动化测试工具一般能录制对象的交互活动，测试工具对这些对象的识别是通过屏幕坐标或一个唯一的对象识别标志，如标签、对象ID、索引或名字等进行识别的。

一旦已经针对应用程序建立了几十乃至上百个对这些对象测试的脚本，如果应用程序发生改变，特别是对象名字或位置、大小发生改变时，测试工具一般不提供对这些对象识别的自动修正。虽然每个工具都提供脚本字符的查找和替换功能，但逐一对脚本进行修改却非易事，如果工具提供集中式数据库，将对象识别信息存放在数据库中，那样的话只需要在数据库中对识别标志进行一次性修改就可以了，但目前几乎找不到提供该功能的测试工具，折中的方法是是用变量存放对象识别标志，并使这些变量在所有测试这些对象的脚本中都能够使用，这类似于C语言中的头文件，将一些公用信息放在一个头文件中，然后在每个需要使用这些信息的脚本前加一句代码包含该头文件即可。

换句话说，对象命名映射就是是否允许将工具给出的对象名字用其他方式的识别标志代替，如变量等。

8对象识别能力

测试工具识别对象一般通过析取对象内部的信息，然后给出对象名字、ID等等，通过这些识别标志在函数调用中定位这些对象。

测试工具通常会提供一些可以唯一的标志识别对象或窗体有关属性的详细信息，也应该提供一种通过鼠标选定对象，就可以了解该对象有关信息的关联显示或通过某种方式去浏览所有对象ID和属性的方法。大部分测试工具都提供能识别应用程序中的对象并将识别结果用一个目录树来显示的功能，一般而言只是识别能力或效率等的差别而已。

9脚本语言拓展功能

在自动化测试中会经常遇到的一个问题就是：工具不是万能的，有些测试利用工具目前提供的功能无法实现测试怎麽办?这涉及测试工具的拓展功能，如果测试工具的脚本语言无法实现这些方面的测试，能否可以使用其他编程语言如C、C++、DEPHI、VB等创建DLL，然后通过脚本调用这些DLL来实现，或者通过调用API等其他方法实现。这个问题一般只会在熟练使用测试工具并将工具的内在功能都已挖掘完毕才会提出，但这需要测试工具支持脚本语言拓展功能才可以。注意一点就是：有些工具提供一些扩展函数的功能，如创建用户自定义函数、方法、类，这只是已有数据类型和函数的组织与集成，而不是这里所说的脚本语言拓展功能。

10环境支持

测试工具能应用于何种类型的开发语言?是否支持最近的JAVA版本，支持哪个Oracle等，是否支持Windows和IJnix等操作系统?应尽可能选择语言和操作系统覆盖面比较广测试工具。

这是一个关键的问题．如果测试工具不支持你的开发环境或应用程序，自动化测试将遇到巨大的困难，甚至失败，将不得不又回到手工测试。

11 与其他工具的综合

随着自动化测试的逐渐建立，自动化测试管理将显得越来越重要。自动化测试工具供应商一般都提供各自的一整套解决方案：从测试需求的定义到测试设计、测试结果管理与处理的配套工具，但各个供应商提供的工具功能各有所长。自动化测试中有可能会有针对性地购买不同供应商的不同模块应用于同一个项目中，测试工具如能解决工具之间的综合问题，则对可以对测试发现的BUG信息进行集中的分析和管理，实现不同工具、不同项目的数据共享，节省投资和提供效率。考虑问题如下：

(1)工具的测试脚本是否可以在其他管理工具中运行?

(2)是否可以将一个BUG信息写入到其他管理工具中?

(3)是否能提供与WORD、EXCEl或其他工具的接口?

12 费用

价钱是目前国内很多公司采购工具都比较看重的因素。但相对而言，测试工具的价格大体上相差不大，即使有差别在功能上也有对应的差别。价格的差异会体现在功能的差别上，例如Visula Test就可能比Rational Robot、Win．Runner和QA Run便宜好几倍，但是功能上也会有比较大的差异，一般而言，"一分钱一分货"。

在资金投入上，除了购买工具外，还需要每年支付工具价钱10％到20％的技术服务费。有些工具可能价钱比别的工具价钱稍微便宜，但技术服务费却高一点，从长远来看。其总投入可能不比其他便宜或甚至能更高。 13易用性

这是一个非常主观的问题，国外曾经有人做过比较：用不同水平的测试工程师分成两个组，通过逐一和随机地选择和使用测试工具，结果是在大多数情况下，测试者对工具的易用性都没有统一的结论。随着测试者的经验累积和考虑问题的出发点(可拓展性、脚本可维护性、与其他工具的综合能力、数据驱动等)不同会得出不同的答案。值得注意的是，一般机构得出评价结论往往是在接触或试用工具三个月左右，在这期间上述因素还没有得到充分的考虑，此外易用性评价还应包括功能支持、调试能力、屏幕输出、在线帮助和用户手册等等。 综合评估上述论各个因素时可以将每一个因素进行评分排序，评分结果分1～n个等级，评价最高为n分，最低为1分。对每个评估因素，可以根据对公司本身对其侧重性加一个加权系数，评价表的右侧空白列添加其他的评估因素，得出上面的评分表，最终评价总分最高者为最优。其中评分依据如下：

5分：工具有这一功能而且非常强：

4分：工具的这一功能比较强或别的工具比它强：

3分：工具的这一功能一般或只提供一些基本功能支持：

2分：工具本身没有该功能，但可以通过调用Windows的API函数或第三方的插件实现：

1分：完全不支持该功能。

自动化测试工具综合评估表可以为机构提供一种快速的工具评估途径，在现实中有比较好的应用效果。