自动化测试范文
时间：2023-02-28 02:43:32
自动化测试范文第1篇
关键词：自动化测试；单元测试自动化；更大规模测试自动化；Tcl
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)05-11355-03
1 引言
软件测试是软件生存期中的一个重要阶段，是软件质量保证的关键步骤。软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。测试自动化通常借助测试工具来执行，测试工具可以进行部分的测试设计、实现、执行和比较的工作[1]。通过运用测试工具，可以达到提高测试效率的目的。本文首先介绍了自动化测试的概念及怎样实现自动化测试，接着介绍主流自动化测试软件及其自动化测试框架的构造，最后介绍用自动化测试脚本语言Tcl(Tool Command Language)实现一硬件系统中主备板间自动切换的测试用例。
2 自动化测试简介
软件测试跨越整个软件开发流程，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。测试应当有意制造错误从而确定是否漏过预期应当发生的事件，或者发生了预期不该发生的事件，测试的目的是检查错误。经验表明，测试人员多数的时间花在对系统逻辑流程和控制流程的理解（白盒测试），测试覆盖路径的确认，同一测试用例对不同程序修改版本的测试结果验证和手工填写测试报告上等场合，这些领域适当采用测试工具可以提高测试效率和测试正确性[2]。为此我们引用自动化测试。
测试自动化可理解为测试过程自动化和测试结果分析自动化。测试过程的自动化指的是不用手工逐个的对用例进行测试。测试结果分析自动化指的是不用人工一点点去分析测试过程中的中间结果或数据流。适合于软件测试自动化的场合：
(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；
(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；
(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；
(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。
常规情况下，软件的自动化测试能够发现10%-15%的软件错误。手工测试能够发现80%左右软件错误，由于自动化测试和手工测试存在重合的错误发现，因此尚需有5%-10%的错误需要通过两者结合和采取其它途径进行发现。
3 测试自动化实现方法
3.1 单元测试自动化
单元测试自动化是最轻量级的测试，它的测试目标是特定模块的函数或者代码块。通常单元测试是由开发工程师自己来做的，因为进行这种测试涉及到程序内部设计和代码实现的细节。对于单元测试，我们希望能像使用编译程序器编译一样，每次修改代码后，即可运行编译器进行编译，如果没有错误，完全可不用去看编译报告，当有问题时编译器才会发出警报，并给出一定的线索。我们用编译器来检查语法错误，用单元测试来检查语义错误[3]。单元测试适合于充分的测试代码片断，它的前提是对代码的具体实现非常了解。
3.2 更大规模测试的自动化
下图自动化是一个典型的测试环境
在这测试环境中，被测系统看作一个整体，它接受到外界的输入后，会产生一些相应的输出。而外部环境是由用户界面和测试工具组成。用户界面就是用户使用被测系统的接口。测试工具这里指的是外部支持系统，可能是一个关联子系统，也可能是一些驱动库，这些系统可能是真实的系统，也可能是专为测试做的模拟系统。一般情况，相对测试系统来说，用户界面是主动的，由它发起对某个功能点的测试，而测试工具是被动的，它接收到由被测系统发出的消息后，发回相应的响应。
我们需要编程序来完成用户界面以及测试工具的动作，我们把上图的外部环境分为三种类型来讨论：用户界面，模拟外部子系统和真实外部子系统。这里只考虑模拟外部系统的测试工具，对于真实的外部子系统，它的动作是不用测试者设定，然而某些情况下我们还是需要观察它与被测系统间交互的消息，确认其中的某些检查点。可采用脚本语言来实现测试自动化。脚本语言的特点首先它自动逐条执行语句，并可以方面的修改源代码来设定一系列的动作，另外，脚本语言一般都有非常强大的字符串处理能力，这对于我们实现测试自动化以及结果分析都非常有利。
3.2.1 测试过程自动化
一般来说，用户界面和模拟外部子系统的测试工具功能比较简单，主要是收发短消息或涉及鼠标键盘操作，其中没有复杂的逻辑和算法，可被认为是一个一个的消息触发器组成的，而且每个触发器的动作都是预先设定好，接收到消息A则发送消息B，因此用脚本语言很容易模拟它们的动作。在用脚本语言实现过程自动化的时候，可以通过在脚本中设置控制点，控制脚本的执行。当脚本运行到控制点时，将等待用户输入，然后根据输入进行进一步的动作。这样可逐段执行脚本，便于调试。通过构建自动化测试平台进行过程自动化测试，大大减少了测试过程中所需做的重复性工作，降低了人性的弱点对程序质量的威胁。
3.2.2 结果分析自动化
构建好自动化测试平台后，我们可对测试结果进行自动化分析了。对某一个功能点的测试往往包含用户界面，被测系统和测试工具的多次消息交互，通过查看这些消息的内容和顺序是否与预期一致来判断一个测试用例是否通过，形成自动分析案例。对于某个测试用例，可预先编制一个目标文件，其中包含所有完成这个用例所需交互消息，包括用户界面与被测系统间的消息，以及被测系统与测试工具之间的消息。
在自动测试平台中，加入一些控制，在收发消息的同时将消息依次存入到一个文件中，当测试用例完成后，可将两文件做对比，如果匹配的话说明测试成功，如果不匹配，则给出最先不匹配的位置信息。编写目标文件不一定要包含所以消息，有时候可能只需要比较某个测试工具接受的消息就可以判断是否正常，那么在脚本中只需将该测试工具所接受的消息存入文件即可。这样手工编写目标文件容易，比较速度也快。比较文件时所用的匹配算法也可根据自己的需要加以调整，可以是精确匹配，也可以只是检查目标文件中的消息是否在当前生成的文件中依次出现。一些脚本语言，例如TCL具有很强的字符处理能力，可方便的实现某些匹配算法。
通过用脚本来实现测试过程与测试结果分析，可形成维护一个测试用例库。每次代码集成的时候都可以通过运行这些脚本对程序进行回归过程测试，整个测试过程不需要人工干预[4]。当出现问题时，会生成相应的测试报告，给出错误信息。这个测试用例库在整个软件的生命周期中都可重复利用。
4 主流自动化测试工具介绍
4.1 工业标准级负载测试工具LoadRunner
Mercury Interactive 的 LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的周期。LoadRunner 支持广范的协议和技术，为特殊环境提供特殊的解决方案。
4.2 全球测试管理系统TestDirector
TestDirector是业界第一个基于Web的测试管理系统，它可以对全球范围内的测试进行管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库TestDirector能消除组织机构间、地域间的障碍。
4.3 WinRunner
Win Runner是Mercury Interactive公司推出的一种企业级自动化测试工具。通过自动录制、检测和回放用户的应用操作，来帮助测试人员自动完成应用程序的功能性测试。可提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障及长期稳定运行。用WinRunner进行自动化测试主要分为5步：
(1)创建GUI Map文件。WinRunner可以通过它来识别被测试应用程序中的GUI对象。
(2)创建调试测试脚本。通过录制，编程，或两者的组合创建并调试测试脚本。
(3)运行程序。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。
(4)结果分析。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。
(5)维护测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用测试环境。
4.3.1 WinRunner自动化测试框架构造
根据类和封装的思想,将WinRunner中的类提取来进行封装。所有的类全部封装于函数（ExecuteCase）中，针对每一类，均有具体的行为与之对应，根据配置文件中传入参数的所属类,ExecuteCase会将相应的接口进行处理。如果有新类或特殊类，也可以将ExecuteCase函数进行扩充，从而满足不同的测试需求。
5 硬件主备板间自动切换软件的自动测试事例
Tcl(Tool Command Language)是一种可运行在 Unix，Windows 和 Macintosh 等各种平台上的自动化测试脚本语言。具有良好的扩展性，以便用户为其增添新的功能模块。Tcl语言将程序设计概念高度抽象，真正地把程序设计与操作系统底层结构隔开，因此不依赖于任何平台，具有良好的可移植性[5]。下面简单介绍用Tcl实现一硬件系统中主备板间自动切换的测试事例。
5.1 对active_boards的切换
proc operation_on_active
{action i_pairmode}{
global print_fsm_1
global print_fsm_2
global board_info_1
global board_info_2
global active_board_1
global standby_board_1
global active_board_2
global standby_board_2
global id
#wait_state_normal //当boards的状态为normal的时候才切换
mode $id A#
if { $i_pair==1 } {//当只有一对boards的时候
log_out "HA_operation: $action $active_board_1(chassis)
$active_board_1(slot)
$active_board_1(board) "
gsend "oam $action $active_board_1(chassis)
$active_board_1(slot)
$active_board_1(board) $mode\n"
expect -i $id timedout {timedout "on prompt"}
-re "Successfully"
after 5000
} elseif { $i_pair==2 } { //当有两对boards的时候
log_out "HA_operation:
$action $active_board_2(chassis)
$active_board_2(slot)
$active_board_2(board) "
gsend "oam $action $active_board_2(chassis)
$active_board_2(slot)
$active_board_2(board) $mode\n"
expect -i $id timedout
{timedout "on prompt"} -re "Successfully"
after 5000}}
4.2 对standby_boards的切换
proc operation_on_standby { action i_pair mode } {
global print_fsm_1
global print_fsm_2
global board_info_1
global board_info_2
global active_board_1
global standby_board_1
global active_board_2
global standby_board_2
global id
#wait_state_normal //当boards的状态为normal的时候才切换
mode $id A#
if { $i_pair==1 } {//当只有一对boards的时候
log_out "HA_operation:
$action $standby_board_1(chassis)
$standby_board_1(slot) $standby_board_1(board) "
gsend "oam $action $standby_board_1(chassis)
$standby_board_1(slot)
$standby_board_1(board) $mode\n"
expect -i $id timedout
{timedout "on prompt"} -re "Successfully"
after 5000
} elseif { $i_pair==2 } {//当有两对boards的时候
log_out "HA_operation:$action
$standby_board_2(chassis)
$standby_board_2(slot)
$standby_board_2(board) "
gsend "oam $action $standby_board_2(chassis)
$standby_board_2(slot)
$standby_board_2(board) $mode \n"
expect -i $id timedout
{timedout "on prompt"} -re "Successfully"
after 5000}}
6 结束语
软件测试跨越整个软件开发流程, 软件生存期中的一个重要阶段，是软件质量保证的关键步骤. 运用主流自动化测试工具，构建自动化测试平台及自动化测试框架，可提高测试效率和准确性。自动化测试脚本语言的应用更为软件自动化测试提供了有利的支撑。
参考文献：
[1] 张克东. 软件工程与软件测试自动化教程[M]. 电子工业出版社, 2002.4.
[2] Elfriede Dustin. 自动化软件测试―入门、管理与实现[M]. 清华大学出版社, 2003.8.
[3] 朱菊, 王志坚. 基于数据驱动的软件自动化测试框架[J]. 计算机技术与发展, 2006,16(5).
[4] 张毅坤. 面向对象软件测试的特点及方法[J]．西安理工大学学报，2002,18(4).
[5] Brent B. Welch. Tcl/Tk编程权威指南[M]. 中国电力出版社, 2002.6.
自动化测试范文第2篇
不过，我们回过头来思考最开始的一个问题――自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。
因为我做过很多项目的每日版本构造，对FinalBuilder比较熟悉，同时也意识到FinalBuilder可以弥补我们框架在这方面的缺陷。很自然地，我将这个软件引入到我们整个系统中来。
这个软件在业界是非常有名的，很多人都很熟悉其用法。不过原来都是开发人员在使用，测试人员不是很熟悉。所以有必要对参与自动化测试的测试人员进行简单的培训。
考虑到这篇文章的部分读者也是测试人员，所以我在这里也简单的介绍一下FinalBuilder。
FinalBuilder解决的是任务流的问题。就像我们以前的D0s系统的大部分程序一样，没有界面交互部分，一次输入，直接返回最终处理结果。这点和我们的自动化目标不谋而合。
在FinalBuilder中，最本质的就是一个任务的执行。任务的执行包括两部分：执行环境加上执行数据。
执行环境往往包括Windows系统自带的一些程序，包括Copy、XCopy等Shell命令，也有系统中已经安装的程序，如Delphi、VC、SVN等。而执行数据，则是指我们的输入。由于我们要实现在执行中不存在界面交互，那么就必然要求我们将所有需要交互的信息一次性地输入。与此同时，我们的环境程序，也必须同时支持此种模式(一般情况下，这种模式称为命令行模式)。
对于使用FinalBuilder人来讲，就有必要了解相关程序的命令行调用方式。这样有助于我们使用和编写任务。如果是我们自己研发一个程序，那么因为要使用到FinalBuilder中来，也有必要支持命令行模式。
在FinalBuilder中，最主要的还是顺序流程，当然它也支持条件、分支、循环。最新的版本还有多线程协同，不过在使用初期，主要还是以顺序流程为主。
最关键、最基础的就是Run DoSCommand和Execute Programe两个任务了。有了这两个，几乎可以完成任何事情。当然，FinalBuilder还提供了很多现成的控件，使得你可以通过配置(而不是命令行)来编写任务，这大大降低了使用难度。不过，不可避免的会有一些需求需要我们自己编写命令行，因此这两个任务必须掌握。
FinalBuilder的自动执行，是使用Windows的计划任务来完成的。在其菜单中有生成计划任务的功能。顺便说一句，FinalBuilder本身也一样支持命令行模式，因此多个FinalBuilder之间，可以互相调用。这对我们的自动化非常有利。
在经过简单的介绍后，我们发现，使用FinalBuilder确实可以帮助我们解决问题。
那么，我们需要解决哪些问题呢？下面是我按照顺序列出的一份清单：
卸载已经安装的目标软件；
删除所有目标软件的相关目录，保障干净环境；
从服务器获取并复制目标软件的安装程序；
从源代码服务器获取自动化测试脚本和框架程序；
安装目标软件；
安装自动化测试框架，
执行目标软件；
执行与目标软件配套的自动化测试脚本，如：冒烟测试；
生成自动化执行日志，分析结果；
发送邮件通知自动化负责人。
所有需要完成的功能，其实上面这些都已经做好了。因为我们通过手工确实可以走到最后。但是要做到覆盖全过程的自动化的想法，还需要各个工具软件互相协调。
首先是软件的安装和卸载，这需要软件能提供命令行模式的安装运行(安装和卸载都是需要人工交互的)，由于我们自身的安装程序支持这个模式，自然省去了很多麻烦。对于网络上流行的免费的和收费的安装软件，也都是支持安全模式的，这些只要多查查资料就可以了。
复制文件就简单多了，FinalBuilder和Windows都已经提供了很多命令。
关于工作流程的自动化执行，那就是我们的自动化测试框架。针对这个需求，我花费了很多工夫才加进去。主要是程序的协同性问题。必须等到目标软件的主窗体完全启动完毕。另外，需要对中途的意外退出做出严格的防范，保障自动化测试能够有始有终。这里面增加了一个超时的概念，可以保障最后程序的退出。
分析日志更是重要。事实上，没有日志的自动化测试没有人愿意去做。目前还是先根据一些简单的需求，做了一些统计，相信以后还会增加的功能是版本日志对比，这样可以看到系统的稳定性变化趋势。
而自动化最重要的就是完成从电脑到人的连接。将报表按照分类发送到相关人员信箱中，他们就可以继续根据测试结果进行处理。
说到底，FinalBuilder就是帮助我们解决了工作流的问题。将自动化测试的流程固化在脚本中。最关键的是，这个流程的管理，我们可以使用现成的方案，而不需要再去自己造一个新的轮子。这样符合我们系统架构的基本原则。
当然，FinalBuilder不是唯一的选择。事实上有很多开源软件也都可以完成这样的功能，最简单的就是直接使用批处理BAT文件。同时，专业的软件，可以提供更多的调试和辅助功能。
OK!我们的自动化测试框架，在使用FinalBuilder之后，已经初步将一个完整的自动化测试过程构建起来。正如博文的一位读者所说的，下面要重点关注脚本的方案设计了。
当自动化测试的脚本编辑器完成之后，根据使用者反馈，编辑器确实大大提高了工作效率，并且代码的管理确实变得有效而可控。而且现在此项目已经开始向另一个管理类软件系统尝试应用。可以预计，会有一些新的功能加入。
不过，我们回过头来思考最开始的一个问题――自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。
因为我做过很多项目的每日版本构造，对FinalBuilder比较熟悉，同时也意识到FinalBuilder可以弥补我们框架在这方面的缺陷。很自然地，我将这个软件引入到我们整个系统中来。
这个软件在业界是非常有名的，很多人都很熟悉其用法。不过原来都是开发人员在使用，测试人员不是很熟悉。所以有必要对参与自动化测试的测试人员进行简单的培训。
考虑到这篇文章的部分读者也是测试人员，所以我在这里也简单的介绍一下FinalBuilder。
FinalBuilder解决的是任务流的问题。就像我们以前的D0s系统的大部分程序一样，没有界面交互部分，一次输入，直接返回最终处理结果。这点和我们的自动化目标不谋而合。
在FinalBuilder中，最本质的就是一个任务的执行。任务的执行包括两部分：执行环境加上执行数据。
执行环境往往包括Windows系统自带的一些程序，包括Copy、XCopy等Shell命令，也有系统中已经安装的程序，如Delphi、VC、SVN等。而执行数据，则是指我们的输入。由于我们要实现在执行中不存在界面交互，那么就必然要求我们将所有需要交互的信息一次性地输入。与此同时，我们的环境程序，也必须同时支持此种模式(一般情况下，这种模式称为命令行模式)。
对于使用FinalBuilder人来讲，就有必要了解相关程序的命令行调用方式。这样有助于我们使用和编写任务。如果是我们自己研发一个程序，那么因为要使用到FinalBuilder中来，也有必要支持命令行模式。
在FinalBuilder中，最主要的还是顺序流程，当然它也支持条件、分支、循环。最新的版本还有多线程协同，不过在使用初期，主要还是以顺序流程为主。
最关键、最基础的就是Run DoSCommand和Execute Programe两个任务了。有了这两个，几乎可以完成任何事情。当然，FinalBuilder还提供了很多现成的控件，使得你可以通过配置(而不是命令行)来编写任务，这大大降低了使用难度。不过，不可避免的会有一些需求需要我们自己编写命令行，因此这两个任务必须掌握。
FinalBuilder的自动执行，是使用Windows的计划任务来完成的。在其菜单中有生成计划任务的功能。顺便说一句，FinalBuilder本身也一样支持命令行模式，因此多个FinalBuilder之间，可以互相调用。这对我们的自动化非常有利。
在经过简单的介绍后，我们发现，使用FinalBuilder确实可以帮助我们解决问题。
那么，我们需要解决哪些问题呢？下面是我按照顺序列出的一份清单：
卸载已经安装的目标软件；
删除所有目标软件的相关目录，保障干净环境；
从服务器获取并复制目标软件的安装程序；
从源代码服务器获取自动化测试脚本和框架程序；
安装目标软件；
安装自动化测试框架，
执行目标软件；
执行与目标软件配套的自动化测试脚本，如：冒烟测试；
生成自动化执行日志，分析结果；
发送邮件通知自动化负责人。
所有需要完成的功能，其实上面这些都已经做好了。因为我们通过手工确实可以走到最后。但是要做到覆盖全过程的自动化的想法，还需要各个工具软件互相协调。
首先是软件的安装和卸载，这需要软件能提供命令行模式的安装运行(安装和卸载都是需要人工交互的)，由于我们自身的安装程序支持这个模式，自然省去了很多麻烦。对于网络上流行的免费的和收费的安装软件，也都是支持安全模式的，这些只要多查查资料就可以了。
复制文件就简单多了，FinalBuilder和Windows都已经提供了很多命令。
关于工作流程的自动化执行，那就是我们的自动化测试框架。针对这个需求，我花费了很多工夫才加进去。主要是程序的协同性问题。必须等到目标软件的主窗体完全启动完毕。另外，需要对中途的意外退出做出严格的防范，保障自动化测试能够有始有终。这里面增加了一个超时的概念，可以保障最后程序的退出。
分析日志更是重要。事实上，没有日志的自动化测试没有人愿意去做。目前还是先根据一些简单的需求，做了一些统计，相信以后还会增加的功能是版本日志对比，这样可以看到系统的稳定性变化趋势。
而自动化最重要的就是完成从电脑到人的连接。将报表按照分类发送到相关人员信箱中，他们就可以继续根据测试结果进行处理。
说到底，FinalBuilder就是帮助我们解决了工作流的问题。将自动化测试的流程固化在脚本中。最关键的是，这个流程的管理，我们可以使用现成的方案，而不需要再去自己造一个新的轮子。这样符合我们系统架构的基本原则。
当然，FinalBuilder不是唯一的选择。事实上有很多开源软件也都可以完成这样的功能，最简单的就是直接使用批处理BAT文件。同时，专业的软件，可以提供更多的调试和辅助功能。
OK!我们的自动化测试框架，在使用FinalBuilder之后，已经初步将一个完整的自动化测试过程构建起来。正如博文的一位读者所说的，下面要重点关注脚本的方案设计了。
当自动化测试的脚本编辑器完成之后，根据使用者反馈，编辑器确实大大提高了工作效率，并且代码的管理确实变得有效而可控。而且现在此项目已经开始向另一个管理类软件系统尝试应用。可以预计，会有一些新的功能加入。
不过，我们回过头来思考最开始的一个问题――自动化的问题。这是我们最终的目的。虽然说自动化测试框架能够解决软件本身的执行问题，但是一次完整的测试，必然是要覆盖全过程的。很显然，我们的框架不能解决这个问题。
因为我做过很多项目的每日版本构造，对FinalBuilder比较熟悉，同时也意识到FinalBuilder可以弥补我们框架在这方面的缺陷。很自然地，我将这个软件引入到我们整个系统中来。
这个软件在业界是非常有名的，很多人都很熟悉其用法。不过原来都是开发人员在使用，测试人员不是很熟悉。所以有必要对参与自动化测试的测试人员进行简单的培训。
考虑到这篇文章的部分读者也是测试人员，所以我在这里也简单的介绍一下FinalBuilder。
FinalBuilder解决的是任务流的问题。就像我们以前的D0s系统的大部分程序一样，没有界面交互部分，一次输入，直接返回最终处理结果。这点和我们的自动化目标不谋而合。
在FinalBuilder中，最本质的就是一个任务的执行。任务的执行包括两部分：执行环境加上执行数据。
执行环境往往包括Windows系统自带的一些程序，包括Copy、XCopy等Shell命令，也有系统中已经安装的程序，如Delphi、VC、SVN等。而执行数据，则是指我们的输入。由于我们要实现在执行中不存在界面交互，那么就必然要求我们将所有需要交互的信息一次性地输入。与此同时，我们的环境程序，也必须同时支持此种模式(一般情况下，这种模式称为命令行模式)。
对于使用FinalBuilder人来讲，就有必要了解相关程序的命令行调用方式。这样有助于我们使用和编写任务。如果是我们自己研发一个程序，那么因为要使用到FinalBuilder中来，也有必要支持命令行模式。
在FinalBuilder中，最主要的还是顺序流程，当然它也支持条件、分支、循环。最新的版本还有多线程协同，不过在使用初期，主要还是以顺序流程为主。
最关键、最基础的就是Run DoSCommand和Execute Programe两个任务了。有了这两个，几乎可以完成任何事情。当然，FinalBuilder还提供了很多现成的控件，使得你可以通过配置(而不是命令行)来编写任务，这大大降低了使用难度。不过，不可避免的会有一些需求需要我们自己编写命令行，因此这两个任务必须掌握。
FinalBuilder的自动执行，是使用Windows的计划任务来完成的。在其菜单中有生成计划任务的功能。顺便说一句，FinalBuilder本身也一样支持命令行模式，因此多个FinalBuilder之间，可以互相调用。这对我们的自动化非常有利。
在经过简单的介绍后，我们发现，使用FinalBuilder确实可以帮助我们解决问题。
那么，我们需要解决哪些问题呢？下面是我按照顺序列出的一份清单：
卸载已经安装的目标软件；
删除所有目标软件的相关目录，保障干净环境；
从服务器获取并复制目标软件的安装程序；
从源代码服务器获取自动化测试脚本和框架程序；
安装目标软件；
安装自动化测试框架，
执行目标软件；
执行与目标软件配套的自动化测试脚本，如：冒烟测试；
生成自动化执行日志，分析结果；
发送邮件通知自动化负责人。
所有需要完成的功能，其实上面这些都已经做好了。因为我们通过手工确实可以走到最后。但是要做到覆盖全过程的自动化的想法，还需要各个工具软件互相协调。
首先是软件的安装和卸载，这需要软件能提供命令行模式的安装运行(安装和卸载都是需要人工交互的)，由于我们自身的安装程序支持这个模式，自然省去了很多麻烦。对于网络上流行的免费的和收费的安装软件，也都是支持安全模式的，这些只要多查查资料就可以了。
复制文件就简单多了，FinalBuilder和Windows都已经提供了很多命令。
关于工作流程的自动化执行，那就是我们的自动化测试框架。针对这个需求，我花费了很多工夫才加进去。主要是程序的协同性问题。必须等到目标软件的主窗体完全启动完毕。另外，需要对中途的意外退出做出严格的防范，保障自动化测试能够有始有终。这里面增加了一个超时的概念，可以保障最后程序的退出。
分析日志更是重要。事实上，没有日志的自动化测试没有人愿意去做。目前还是先根据一些简单的需求，做了一些统计，相信以后还会增加的功能是版本日志对比，这样可以看到系统的稳定性变化趋势。
而自动化最重要的就是完成从电脑到人的连接。将报表按照分类发送到相关人员信箱中，他们就可以继续根据测试结果进行处理。
说到底，FinalBuilder就是帮助我们解决了工作流的问题。将自动化测试的流程固化在脚本中。最关键的是，这个流程的管理，我们可以使用现成的方案，而不需要再去自己造一个新的轮子。这样符合我们系统架构的基本原则。
当然，FinalBuilder不是唯一的选择。事实上有很多开源软件也都可以完成这样的功能，最简单的就是直接使用批处理BAT文件。同时，专业的软件，可以提供更多的调试和辅助功能。
自动化测试范文第3篇
【关键词】软件测试；软件自动化测试；实施方案
随着信息技术的飞速发展，使软件产品应用到社会的各个领域，软件测试是是软件质量保证的关键步骤。软件测试一般分为手工测试和自动化测试。软件规模的扩大给测试工作带来了很多问题，手工测试的速度太慢，效率太低。自动化测试可以高效的完成一些重复性测试；降低了人为因素对测试过程的干扰；排除了测试的随机性和盲目性；软件测试技术的自动化是软件测试的发展趋势，它相对于手工测试可以完成难以实现的测试。正确、合理地实施自动化测试，能够快速、彻底地对软件进行测试，可以缩短测试周期，增强对软件性能方面的测试能力等，从而达到保证软件质量的目的[1]。
1.软件测试自动化简介
谈到自动化测试，一般就会提到测试工具。许多人觉得使用测试工具就是实现了测试自动化，这种理解是不对的，至少是片面的。的确，测试工具的使用是自动化测试的一部分工作，但“用测试工具进行测试”不等于“自动化测试”。
自动化为测试而存在的，所以自动化测试的真正含义可以理解为“一切可以由测试是相对手计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行”。它包含了下列3层含义：
“一切”，不仅仅指测试执行的工作——对被测试的对象进行验证，还包括测试的其它工作，如缺陷管理、测试管理、环境安装、设置和维护等。
“可以”，意味着某些工作无法由系统自动完成，如脚本的开发、测试用例的设计，需要创造性，其工作需要手工处理。
即使由系统进行自动化测试，还少不了人的干预，包括事先安排自动化测试任务、测试结果分析、调试测试脚本等。
严格意义上，“自动化测试(Automated Testing)”不等于“测试自动化(Test Automation)”。自动化测试，模拟手工测试步骤，通过执行程序语言编制的测试脚本自动地测试软件，自动地实施软件的单元测试、功能测试、负载测试或性能测试等。自动化测试集中体现在实际测试执行(test execution)的过程，也就是由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。自动化测试，强调借助工具(不仅仅是工具，有时包括策略和工件)来完成测试的执行，也就是用工具来帮助或辅助测试，这个执行过程可能是全自动的，也可能是半自动的。
测试自动化的要求高得多，侧重说明将测试用自动化设计和实现的过程，即所有的测试工作都能有计算机系统自动完成，包括：测试环境的搭建和设置，如上载安装包到服务器；脚本自动生成，如根据UML状态图、时序图等生成可运行的测试脚本；测试数据的自动产生，例如自动产生数据负载测试所需要的大量数据；测试操作步骤的自动执行，包括测试执行过程的控制；测试结果分析，实际输出和预期输出的自动对比分析；测试流程的自动处理，即测试工作流的自动实现，包括测试计划复审和批准、测试任务安排和执行、缺陷生命周期等流程的自动化处理。测试报告自动生成功能等[2]。
这样，测试自动化意味着测试全过程的自动化和测试管理工作的完全自动化，是测试工程师所追求的一种理想境界，但是很难实现的。
自动化测试方案选择需要考虑的方面：
从图1可见，自动化测试和手工测试都不影响测试的有效性和仿效性，自动化测试只是对测试的经济性和修改性有影响，自动化测试通常要比手动测试经济得多，自动化测试的方法越好，长期使用获得的收益就越大[3]。
2.采用什么样的自动化测试方案，需要考虑以下几个方面的因素
1）项目的影响：自动化测试能否帮助你的项目进度、覆盖率、风险，或者让开发更敏捷？
2）复杂度：自动化是否容易实现，包括数据和其他环境的影响。
3）时间：自动化测试的实现需要多少时间？
4）早期需求和代码的稳定性：需求或早期的代码是否能证明是在范围内变化的？
5）维护工作量：代码是否能长期保持相对稳定？功能特性是否会进化？
6）覆盖率：自动化测试能否覆盖程序的关键特性和功能？
7）资源：测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动化测试。
8）自动化测试的执行：负责执行自动化测试的小组是否拥有足够的技能和时间去运行自动化测试。
3.适合自动化测试的场景主要为
1）测试任务明确，不会频繁变动。2）每日构建后的测试验证。3）回归测试、压力测试、性能测试。4）软件系统界面稳定，改动较少。5）需要在多种平台上运行相同的测试案例、组合遍历型的测试、大量重复的测试任务。6）软件维护周期长。7）待测软件系统开发比较规范，能够保证系统的可测性。8）项目进度压力不大。9）具备大容量的自动化测试平台。10）测试人员具备较强的编程能力。
4.软件测试自动化的实施步骤
我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。本文介绍自动化测试的6个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计(design for sustainability)，有计划的部署等。
首先了解下几个使自动化测试项目陷入困境的原因：
1）自动化测试时间不充足。
2）缺乏经验：尝试测试自己的程序的程序员经常采用自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。
3）更新换代频繁(High turnover)：当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。
4）不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。自动化工程师不参与到软件测试的具体活动中。
5）关注于技术：如何实现软件的自动化测试是个技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。
在自动化测试开发过程中遵守已经建立的软件开发规则，按照在软件开发项目中采用的标准步骤，实现测试自动化：
步骤一：改进软件测试过程。
采用列有产品特性的列表，然后对照列表检查。回归测试检查列表可以告诉应该测试哪些方面。在开始测试之前，需要完善回归测试检查表，并且确保已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。
步骤二：定义需求。
应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。
步骤三：验证概念。
尽可能快地验证采用的测试工具和测试方法的可行性，站在产品的角度验证所测试的产品采用自动化测试的可行性。需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。
验证概念的试验主要有：
回归测试：回归测试是最宜采用自动化测试的环节。
配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？那么采用自动化测试是有帮助的。
测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。
非GUI测试：实现命令行和API的测试自动化比GUI自动化测试容易的多。
步骤四：支持产品的可测试性。
软件产品一般会用到下面三种不同类别的接口：命令行接口(command line interfaces，缩写CLIs)、应用程序接口(API)、图形用户接口(GUI)。
无论你需要支持图形界面接口、命令行接口还是API接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，你很可能成功。
步骤五：具有可延续性的设计。
自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，将进一步迈向成功的自动化测试。主要从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。
步骤六：有计划的部署。
需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。
5.结束语
最后，我们还不得不承认，自动化测试和手工测试往往交织在一起，相互补充，工具执行过程往往需要人工分析，手工测试时也可以借助工具处理某些数据、日志或显示某些信息。也就是说，不是试图用自动化测试来代替所有的手工测试，而应该在尊重手工测试的同时，遵守已经建立的软件开发规则，按照在软件开发项目中采用的标准步骤，实现测试自动化。
参考文献
[1]张丽波.软件自动化测试的设计与实施[J].佳木斯大学学报(自然科学版),2004,22(4).
[2]张克东.软件测试自动化技术[M].北京:电子工业出版社.
[3]吴高峡,王芙蓉.单元测试的自动化实践[J].计算机与数字工程,2007,35(1).
自动化测试范文第4篇
关键词：软件测试；自动化；框架；测试用例
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）12-2923-03
软件测试作为软件质量保障的重要手段，其存在于软件开发生命周期的每一个过程。在整个软件项目的开发过程中，测试人员必须对所开发的软件进行不断测试，以保证软件的正常运行。统计数据表明：软件项目中超过一半的预算投入到软件测试中，所以软件测试代价高昂。缺陷发现的越晚，修正缺陷的代价也越高，给企业造成的损失也越大。
随着软件规模的增加，测试工作量的增大，需要投入大量的人力，原本的手工测试逐渐暴露出诸多缺陷，例如，覆盖率量化困难、重复测试效率低下、不一致性和可靠性低、依赖人力资源等。软件自动化测试技术正是在这种情况下产生的。其根本目标是使所有的测试行为包括测试用例的设计、驱动、结果检查、缺陷定位和移除等都尽可能实现自动化。事实证明，正确、合理的实施自动化测试，能够对软件生命周期的各个阶段进行快速、全面的测试，提高软件测试效率，保证软件的质量，节约软件的开发成本，缩短软件的开发测试周期。但实际上，并非所有的自动化测试技术都可以达到测试活动的预期目标，诸多软件开发机构在实施软件自动化测试的过程中通常存在无法正确找准测试自动化的切入点、程序开发过程和测试自动化过程相互独立、软件测试脚本的质量低劣、测试自动化过程对测试用例的依赖程度过高等方面的负担造成工期延误和成本浪费，甚至最终被完全放弃等问题。
自动化测试技术要想有效地解决测试质量与效率、降低测试自动化的投入、提高其产出等问题间的矛盾，必须形成一套系统的自动化测试体系，在质量保障方面有所作为。因此，深入研究软件自动化测试技术和方法，保障软件质量，已经成为国内外软件行业和相关机构的研究热点。
1 自动化测试的设计原则
软件自动化测试是相对于手工测试而存在的，自动化测试可以被理解为使用一个商业通用测试自动化工具编写一个软件来发现其他软件的缺陷。开发测试脚本以执行键盘、鼠标动作和后台进程并验证应用程序响应和行为。一个良好的自动化测试体系在设计时，需满足以下条件：可维护性 - 使测试更新跟上软件升级的步伐；高效性-实现效率最大化；可靠性 - 使测试结果准确而且可重现；兼容性-允许测试用例为不同的测试目标而以不同的方式组合；可用性-测试人员或用户容易掌握定制或更改测试用例的方法；健壮性-可以处理意外情况而不退出或终止；可移植性 - 测试脚本可以在不同环境中运行测试。
2 自动化测试框架的选取
自动化测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。自动化测试框架的好坏对自动化测试的成功有直接影响。目前业界公认的自动化测试框架，主要有四种：数据驱动框架、测试脚本模块化框架、测试库架构框架和关键词驱动框架。
1）数据驱动框架
测试驱动引擎从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例，数据驱动脚本将测试脚本（执行步骤）和数据分离，将测试输入数据存储在独立的数据文件中，而不是直接存储在脚本中[1]。在脚本中引入变量，执行时通过变量来读取数据文件中的数据。通过数据驱动脚本，同一个脚本可以测试不同的输入数据，提高了脚本的重用率和可维护性。其缺点是初始建立的开销较大，由被测试应用程序的变化所导致的工作量在所有架构中是最多的，因此维护成本是相当高的。
2）测试脚本模块化框架
测试脚本模块化框架的测试脚本中包含了各功能点的控件识别和业务逻辑操作，其中包含调用外部测试数据。框架结构如图1所示。图中箭头方向代表的是调用关系。负责自动化测试脚本维护的开发工程师必须了解自动化编程和业务逻辑。负责为花测试数据的工作由测试工程师完成。它的优点是控件和业务逻辑一旦发生变化，底层的测试脚本就要进行修改和维护（这比没有任何抽象封装的自动化测试程序稍好一点）。缺点是几乎所有大的变更导致的工作量都要交给自动化测试开发工程师来完成；控件识别和业务逻辑本身属于不同的领域，
没有很好进行抽象封装。
3）测试库构架框架
所有的针对测试系统本身的控件识别和支持的操作将被封装在测试库中；通过测试脚本调用测试库的同时传递外部的测试数据；自动化测试开发工程师在编写测试库的同时（无需了解业务），还需要负责控件的变更和维护；对业务比较熟悉的自动化测试开发工程师编写测试脚本，并负责业务逻辑的变更和维护；测试工程师则只需要维护测试数据（无需了解自动化开发）。框架结构如图2所示。其优点是在被测试系统中，无论是哪一层的变化，其需要的变更维护工作只需要交给相应人员即可；这从根本上实现了控件识别操作和业务逻辑的抽象分离。其缺点是由变更引起的工作量还是附加在自动化测试开发工程师身上。
4）关键词驱动框架
自动化测试范文第5篇
[关键词]AdobeFlex自动化框架测试SilkTest
中图分类号:TP3文献标识码:A文章编号:1671-7597(2009)1120059-01
任何长期的软件项目的测试工作最终都会进入自动测试阶段。软件开发的过程中在不断的更新旧的功能增加新的功能,在此基础上必须保证不影响原有的正常功能。自动化测试的引入使测试人员从繁重而枯燥的工作中解放出来,同时还能保证精确性。
随着Adobe Flex编程技术的流行,基于Flex的软件项目应运而生。然而,其美观的界面却相应带来了测试的复杂性,它不同于数据驱动测试只顾输入输出,也不同于事件驱动测试只关注行为与结果,Flex产品与Flash一样可作出动态的美丽的外观效果,在事件处理上也及其复杂,这对测试带来一些极大的挑战。本文将介绍基于Flex的自动化测试框架。
一、自动化测试框架
首先让我们看一下自动化测试框架,如图1:基于自动化测试工具的测试过程不外乎三步:自动化测试初始化;自动化录制;自动化回放。即测试工具能够识别Flex的控件,通过录制用户的操作步骤模拟用户操作,生成测试脚本,回放录制的步骤,检测结果,以达到自动化测试的效果。
二、Flex与测试工具交互框架
然而自动化测试工具如何能够识别用户各种操作并进行模拟呢?让我们再来看一下Flex事件流框架(如图2):
Stage相当于树的根部为枝叶输送养份而服务的,一个事件的触发必须首先通过这个平台进入,在对象的显示列表中找到基类,再顺延找到子类,在相应的地方去实现一个事件的处理程序。所有的显示对象都有一个Stage的属性用于指向应用平台。每当事件触发时,都会经历从Stage到目标节点再从目标节点返回Stage的过程:抓获阶段,这个过程会抓获在Stage上的所有节点的父节点;目标阶段,查找到目标子节点;浮出阶段,将查获的子节点通过其父节点返回至Stage平台上。
自动化测试工具对Flex事件的支持便是按照其事件流处理框架的标准来实现的,首先必须能够找到所谓的Stage,然后识别Stage上的所有对象,进而找到那个唯一的子对象去获得它的属性及事件处理方法,自动化测试工具通过记录用户UI上的操作然后触发事件流达到自动化操作的过程,再由用户添加检查点以达到测试的目的。因而,测试工具要模拟用户操作必须要求能够识别对象,而且用户操作的事件流也必须按照如上图所示的事件流来操作,即必须通过一个Stage平台到Flex对象。
Flex在技术上又是如何与自动化测试工具交互的呢?为了支持Flex的自动化,Flex特提供了一个重要的包,即Adobe Flex自动化包(mx。automation。*):这个包为开发者创建Flex测试案例提供了自动化编程的接口。此包包含了:自动化库-automation。swc与automation_agent。swc这两个库用于帮助实现Flex框架的组件的派生类。Automation_agent。swc文件以及与其相关的包提供普遍的机制。,如SilkTest,是建立在这些库之上的。有了这些支持才便于测试工具去模拟Flex处理机制。而对于自动化工具本身也提供了支持Flex的接口,以达到自动化工具与Flex的通信与交互。如SilkTest也提供一个支持自动化的SDK,它是基于Flex自动化的API的。SDK以与Flex的AutomationAPI同样的方式为Flex组件提供自动化支持。SilkTest的开放(Open Agent)使用了Adobe的Flex自动化库。FlexTechDomain。swc文件即包含了SilkTest的具体实现实现方法。
Flex测试工程的准备工作与其它项目类似:开启支持Flex应用程序测试的接口;创建可测试的Flex应用程序;编译Flex容器(相当上面提到的Stage);使Flex事件与组件工具化(目的是为了使测试工具能够识别Flex对象,并模拟其事件处理程序)。
三、测试维护框架
为了提高自动化测试套件的可维护性,还需要采取一些措施。推荐采用测试脚本模块化框架。通过创建独立的脚本来代表被测试应用程序的模块、对象或函数,利用抽象和封装的原则将过程对象与源应用脱离开来,增强测试脚本的重用性,可维护性,降低由源代码的改变而带来的脚本大量的变动、失效。由此,才得以更为有效的提高自动化测试的效率与可用性。例如,SilkTest将一项工程分为四类文件来管理,即测试计划文件(.pln),由测试脚本与参数构成,类似于Function的一个实例,可用于分类管理测试案例;测试脚本文件(.t),可分类管理各类各个测试案例的过程描述;包含文件(.inc),可用于管理各种封装后的函数;配置文件(.ini)。这种规划管理一个复杂的工程项目得以有序清晰方便的进行管理。
四、结束语
由此,回顾整个过程,二个方面是我们在实现自动化测试的过程不可不关注的,它是自动化支持的瓶颈,是开启自动化的钥匙,即被测应用程序与测试工具的相互支持及测试脚本的有效维护。
参考文献:
[1]《Programming ActionScript 3.0》,2008 Adobe Systems Incorporated.
[2]《Borland SilkTest 2008 Help》,Borland Software Corporation.
[3]《Design,Automation and Test in Europe》,Nice Acropolis,France April 16-20,2007.
自动化测试范文第6篇
自动化测试的定义
首先，我们来谈谈什么是自动化测试，它的实现方法是用机器代替人的手工操作，完成一系列的测试过程。从原理上看测试自动化也是一个标准的操作流程。
测试自动化实际上是在模拟人的手工操作，在现阶段手工测试在很多公司是一种艺术行为，同样一个模块不同的测试员会发现不同的问题，这与测试员的直接能力成正比，同时还与测试员的心情有直接关系，这实际上是一种无序的操作行为，这种现象的最大问题是随着人员的变动产品质量也在进行相就应的波动。
用一个比较形象的比喻，每次我们对产品实施测试就好象是织一张网，然后用网去捕虫，但是我们每次织网的方法都不一样，网也就会不一样，有时密有时疏，这就导致了有时我们会抓到好多的虫，有时又抓不到虫。如果我们每次织的网是一样的，那么抓到虫的数量也是基本不变，同时我们对网进行不断的改进，将疏的地方加密，这样就能抓到更多的虫。
测试自动化是代替人的手工操作，自动的发现产品中的问题，这就好比自动织网自动捕虫，我们所要做只是不断的补网，但如果没有标准操作，我们就不能补网，不知道要在哪里进行修补。这会出现两种情况:网抓不到虫，这样这张网就没有任何意义;每次都要做一张新网，可以捕到虫了，但成本太高。
让测试自动化真正发挥出强大的威力，就要对这张进行不断的修补。如果我们每次的操作都是相同的，再通过对结果的验证和补充，不断的完善，这样才能将发挥自动化的强大的力量。
通常，软件测试的工作量很大（据统计，测试会占用到40%的开发时间;一些可靠性要求非常高的软件，测试时间甚至占到开发时间的60%）。而测试中的许多操作是重复性的、非智力性的和非创造性的，并要求做准确细致的工作，计算机就最适合于代替人工去完成这样的任务。
计算机大师布鲁克斯曾在1986的一篇题为《没有银弹》的文章中列举了人们对于软件工程技术发展的一些期望，并与现实进行了对比。他的论点归纳如下:没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性
布鲁克斯鼓励我们将技术和方法视作一种演进手段，而并非革命。将自动化技术引入测试工作时，我倾向于支持相同的观点。
在与自动化测试产品和解决方案的客户打交道的过程中，其间碰到了许多“银弹”思维方式。它们总以类似这样的设想出现:
1、所有的测试都能够实现自动化。
2、既然自动化测试能如此显著地提高生产率，我们就能以更少的人员完成所有的测试。
3、自动化测试如此简单，我们无需任何培训。
4、自动化方法将缩减整体测试工作量。
5、我们无需制订任何测试方案。
6、有了自动化测试，测试人员不就成了“过时的”或“多余的”的人。
7、以前的那种耗时的测试设计工作不再必要了。
尽管我不愿打破人们美好的幻想，但总觉得有责任帮助他们理解，实施自动化测试和得到梦寐以求的神兵利器之间的区别。通常这意味着解释自动化测试的真正含意，和自动化测试工具和解决方案的实际功能。
自动化测试不是银弹吗？
正是此意。自动化测试，或者说自动化测试策略及工具的实现，只是测试人员工具箱里的一件利器。注意我强调它是一个工具，位于工具箱中。我有意避免将自动化测试和试员人员等同起来，本来它也无法取代测试人员的地位。尽管如此，自动化测试仍然毫无疑问地具有强大功能，它能在测试效率和彻底性方面使我们获益匪浅。关键在于确定发挥其功效的最佳时机及方式。我们提出另一个问题来具体阐述一下。
有足够的时间测试每件事情吗？
我想人们会异口同声地回答“没有！”。总有更多的东西可以测试，或者在另一个平台上或以其他配置再试一次。但是随着最终期限和产品交付日期的日益迫近，分配给每个测试周期的时间缩短了。那么，软件开发项目经理和测试团队如何处理这种情况呢？通常，他们削减软件前每一个测试周期的测试量。您经历过这种情形吗？理想情况下需要做一些基于风险的分析，以便决定排队哪些风险。然而更常见的情况是，测试团队只是将整个测试周期的注意力集中到验证已修复的缺陷上。更有甚者，连这样的缩减之后的测试计划也没有足够时间来完成。
多少产品是在完整测试之后交付的？这种情况我所知不多。开发团队往往根据其他因素做出是否交付软件的决定:
1、时间到了吗？
2、预算超了吗？
3、资源用尽了吗？
4、还有比萨和啤酒吗？
图1:自动化测试生存周期方法学结构
不幸的是，由于测试工作被任意删减，开发团队无法完全清楚地知道产品的总体质量，他们面临所交付的软件带有严重问题的风险。借助于自动化测试的力量我们能够摆脱这种困境吗？我们接着探讨一下。
自动化测试如何帮助我们？
在计划实施自动化测试之前，您需要理解自动化测试的定义。换句话说，它对您意味着什么？这里有一些我听到的其他人对自动化测试的描述:
1、完全无人干预的测试。
2、测试脚本。
3、测试工具。
4、不清楚。
有时人们将自动化测试的概念理解得过于狭窄，只关心由工具或编程产生的测试脚本。实际上自动化一词包含了更为广阔的含义。看看一个Quality Engineering团队在构建一套自动化测试准则时对自动化测试的这个定义:在我们的环境中，"自动化"指的是对策略、工具和工件的使用，它增加或减少了手工或人为参与或干预非技巧性、重复或冗长工作的需要。除该定义之外，准则还为该团队提供了应用自动化方法的例子。
现在，定义自动化对于您和您的团队意味着什么是至关重要的。然后您就可以使用该定义开始构建一套自动化准则，从而团队中的每个人都可以使用相同的方法、快速评诂一项任务是否适合应用自动化。
让测试自动化真正发挥出强大的威力，就要对这张进行不断的修补。如果我们每次的操作都是相同的，再通过对结果的验证和补充，不断的完善，这样才能将发挥自动化的强大的力量。
软件测试实行自动化进程，绝不是因为厌烦了重复的测试工作，而是因为测试工作的需要，更准确地说是回归测试和系统测试的需要。
将测试的操作标准化不是简单的写个用例就可以解决，它要包括很多详细的内容，要包括数据的准备，系统环境的准备，标准的操作流程，以及结果的标准判断方法。最佳实践效果就是一个只要会操作计算机的人都可以执行测试，并且结果是相同。那么，这时实施自动化才能够发挥最大的功效。
从上面可以看出测试自动化的实现成本较高,我们不能单纯的出于技术的目标而实施自动化,自动化的实施只有在产品的被测试部分相对稳定后才可以实施自动化.在业界暂时还没有通用的判定标准。
合理的运用自动化测试可以大大提高工作效率,反之则会是无何止的噩梦.无论测试自动化多么强大,在现阶断仍然是以手工测试为主.我想不需要人工设计的测试自动化只有在斯皮尔伯格的“人工智能”实现后才会真正的出现。
现在您已知道什么是自动化测试以及它能胜任哪些工作，我希望您能运用这些知识为您的产品进行更多更好的测试。尽管自动化测试不是银弹，但它仍不失为一件优秀工具;如果能够将其应用于适合的工作，将为您带来巨大收益。
自动化测试的好处
自动化测试范文第7篇
自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，其目的是降低测试的劳动量，达到提高软件质量的目的。涉及到测试流程、测试体系、自动化化编译、持续集成、自动测试系统以及自动化测试等方面。
一、 软件测试自动化的概念
软件测试自动化就是执行用某种程序设计语言编制的自动测试程序，控制被测软件的执行，模拟手工测试步骤，进行全自动或半自动测试。全自动测试指在自动测试过程中，根本不需要人工干预，由程序自动完成测试的全过程。半自动测试指在自动测试过程中，需要由手工输入测试脚本或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试。
为保证软件的质量，必须按照软件工程的方法，在软件生命周期的各个阶段进行有效的管理和度量，软件测试是软件生命周期的重要阶段。目前软件测试普遍采用传统的测试方法，即白盒测试和黑盒测试。在测试工具上大多采用手工测试，或编制一些简单的测试程序进行测试，既耗时间又不规范。更大的隐患在于当将软件分发给用户使用时，常常会发生问题，严重时导致系统瘫痪。自动测试技术目的在于消除手工测试中人为的错误，加快测试循环，有效利用资源，提高工作效率。同时，使测试具有一定的规范性，提高测试的可重复性。
二、软件测试与自动化的联系
测试是一种技术。根据IEEE的定义，软件测试是使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果和实际结果之间的差别，尽可能发现存在的缺陷。它的目标是以较少的测试用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
自动测试也是一门技术，但与测试技术有很大不同。自动化测试是利用策略、工具以及产出等，减少人工介入到非技术性、重复性、冗长的测试活动里，从而达到无人监守完成测试，并自动产生测试报告，分析测试结果等一系列活动。自动化测试的目标是对被测试系统进行自动测试。总的来说，自动化测试的目的就是用较少的开销，获得彻底的测试，并提高产品的质量。
软件测试是由一系列有序活动组成的，始于测试计划，着重测试开发。软件测试自动化是针对这一系列活动及其管理的自动化，包括软件测试过程规范管理的自动化和软件测试活动的自动化。
无论自动测试还是手工测试都不影响测试的有效性，即测试的有效性和测试方式无关。测试脚本的设计与选择和测试质量有着直接关系，好的测试脚本方案应该可以以有限的数量发现软件中的大部分缺陷。因此选择何种测试脚本进行测试十分重要。实验和经验表明随机选择测试脚本并不是测试的有效方法，好的测试方法应该是开发好的测试脚本。
什么样的测试脚本是好的测试案例？有四个特性可以描述测试脚本的质量，它们分别是有效性，可拓展性，经济性和可维护性。监测软件缺陷的有效性是最重要的一个方面。好的测试脚本应该是可拓展的。可拓展性的意思是，这个测试脚本可以测试多项内容，这样就有效减少了测试脚本的数量。另外还应从成本出发去衡量一个测试脚本的经济性，包括测试脚本的执行、分析和调试是否经济，以及测试案例的可维护性，即每次软件变更后修改测试脚本的成本。
通常对这四个方面要进行平衡。例如，一个测试脚本可以覆盖到很多的测试内容，但要其执行和调试的成本可能很大。可能在每次软件变更后需要对测试脚本进行大量的维护。一次高拓展性可能导致经济性和可维护性比较低。因此测试技术不仅要保证测试脚本具有发现缺陷的高可能性，而且还要保证测试脚本的经济性，避免过高的执行、分析和维护成本。
对于手动测试脚本来说，无论测试执行的次数是多少，其经济性和可修改性都不会发生变化。然而对于自动化系统测试来说，在该测试第一次被执行时，其经济性和可维护性都比手动测试脚本要低，但伴随着测试的持续反复执行，自动测试的经济性迅速增长，可维护性也伴随着提高，当一个测试需要被重复执行时，自动化系统测试开始显示它的价值。自动测试的方法越好，长期使用获得的收益越大。
三、 测试自动化的现状
目前对于软件自动化测试主要有如下几种方法：
1、手写静态测试自动化方法 该方法应用静态的测试脚本和固定的测试脚本在被测应用的GUI上运行。这种自动化实际上只是体现在测试执行过程中，并且脚本需要反复调试，健壮性差。
2、随机输入自动化测试方法 这种方法的原理是让计算机模拟真实用户去进行各种GUI操作，只不过是测试过程本身涉及的行为是随机产生的，顺序也是随机产生的，它虽然可以发现一些测试人员无法发现的缺陷，但机会是很偶然的，因为测试程序本身并不知道对于它所产生的每一步操作及被测软件系统应该是如何反应的。
3、基于捕获/回放（C/P）机制的测试自动化方法 这种方法的本质是由测试人员与包含被测GUI的软件系统进行交互，基于C/P的工具负责将交互过程的场景和GUI操作捕获，生成测试脚本，再将这些操作进行回放。其优点是脚本生成相对容易；但是缺点也很明显，交互过程对测试人员的操作要求极高，并且脚本的可重用性非常差，对于回归测试过程无法提供有效支持，这些缺点使得该方法无法完美解决GUI测试的主要问题。
4、基于模型描述的自动化方法 这种方法的关键是对被测系统的行为进行形式化表述，形成模型，然后采用有穷状态机FSM （ Finite State Machine）从模型中产生测试脚本。通过这种方法产生的测试脚本可以有效的测试系统的具体行为是否满足系统设计要求，同时可以根据测试标准有选择地进行测试脚本生成和运行，但是缺点在于目前的系统规模越来越大，对于系统行为的模型描述越来越困难。这也是为什么这种方法一直无法在业界推广的一个主要原因。
四、测试自动化的挑战
伴随着开发及软件所使用的技术的更新，软件测试正面临新的机遇与挑战，图形用户界面GUI、分布式处理和庞大的分散网络就是这些新技术的代表。
不仅技术是新的，而且它们比传统软件更加难于测试，因为这些软件更加复杂。用户界面更加丰富。其中客户服务器（C/S）应用构成了重要表现的一类软件，且已成为主流。它们采用了较多的新技术，在C/S软件体系结构中，处理被分散在客户机和服务器上，其中客户机处理在专门的PC机上实施并提供图形用户界面和一些本地处理，而服务器处理在共享机上实现并为客户机提供特定的服务，如数据库管理及通信。通常客户机软件具有一个GUI界面，并且可以运行在相对便宜的PC机上；服务器软件需要具有多用户能力和较高的性能。在这种环境下应用系统的测试面临着新的挑战。
自动化测试范文第8篇
测试自动化的目标是对被测试系统进行自动测试，提高测试的效率和客观性。自动化测试过程中主要涉及的内容有下面几个方面。自动测试输入：工具录制测试者所做的所有操作,并将这些操作写成工具可以识别的脚本。测试脚本技术：用于自动测试过程中存放测试步骤、测试数据等相关内容。测试结果的自动比较：将预期输出与程序运行过程中的实际输出进行比较。自动测试执行：工具读取脚本并执行脚本命令，可以重复测试者的操作。在执行脚本过程中可以完成测试结果的自动比较。
2自动化测试系统的设计
通过对低速无线传感器网络协议的深入研究，分析软件测试、通信协议测试和自动测试等相关理论知识，本文提出将通信协议测试和自动测试相结合的方法，实现对测试过程自动执行和测试结果的自动分析，是本系统的创新点。如图2所示，虚线框内测试步骤可以实现测试的自动执行，其中可视化用例设计器、测试用例生成器完成测试用例的自动生成工作，测试用例的自动生成是测试自动执行的关键部分。测试结果分析器则对测试结果进行自动分析。测试用例的设计和生成是协议测试的关键和难点，如何生成最能发现被测协议存在问题的测试用例，如何用最少的测试用例实现足够大的覆盖率，是协议一致性测试的目标和难点。本文提出利用测试用例的自动生成来解决这一问题。测试用例自动生成主要依靠测试用例自动生成器是来完成，是实现测试自动执行的核心。其体系结构如图3所示，其中用例设计描述是文本文件，描述测试用例的特性，选择的算法不同，描述方式也会有所不同。如采用“基于形式规格说明的方法”用Z，VDM，OBJ，LARCH等语言描述，采用“组合覆盖方法”则用XML脚本描述，因为XML脚本的可扩展性比较强，所以在目前的自动化测试系统中得到较多的使用。算法适配器为算法提供接口，向上提供算法支持服务给描述解析器，向下兼容多种算法，兼容多种算法能增强体系结构的扩展性和适用范围。描述解析器在算法适配器基础上分析用例设计描述，将用例描述转换成用例生成器可识别的内部描述形式，并传递给用例生成器。用例生成器获得来自描述解析器的内部描述，根据描述自动生成可执行测试用例。可执行的测试用例支持多种形式存储，如内存存储、文本存储、数据库存储等，具体的存储格式随着测试执行的需求变化。
3一致性自动化测试系统的实现
为了验证体系结构的适用性和有效性，搭建了基于MicrosoftVS2010、SQLServe2005、“分类树方法”、GDI+(GraphicsDeviceInterface)来实现无线传感器网络协议一致性测试的自动化系统。其中GDI+完成系统中的可视化用例设计器工作，它是一个语法可控制的、可视化、图形化的编辑器，帮助我们更加有效地使用分类树方法进行测试用例的设计。分类树方法是黑盒测试中的一种部分测试方法，是一种有效的功能测试方法。分类树方法的基本思想是：首先逐层划分测试对象的输入域，然后将划分的独立的类结合为无冗余的测试用例，这些测试用例覆盖了整个输入数据域。算法适配器、描述解析器、用例生成器、分类树方法均使用MicrosoftVS2010实现。SQLServer2005降低了管理数据基础设施和发送观察和信息给所有用户的成本，并具有可信任，高效，智能的特点。因此本文将测试系统及被测试网络信息存储在SQLServer2005数据库中，用来在自动执行测试用例时调用并存放测试结果信息。自动化测试系统在实际应用时，首先用GDI+构建测试用例设计，也就是生成XML语言描述的用例说明，然后描述解析器解析该用例说明并生成测试用例模板（系统内部格式），由用例生成器生成可执行的测试用例，调用SQLServer2005中存放的测试网络信息和测试配置信息执行测试用例并生成测试报告。本系统中人工只参与第一步，即用GDI+技术构建测试用例设计，其余部分均自动完成，提高了测试工作的效率和客观性。该实现已应用于国家科技重大专项“信息汇聚传感器网络综合测试与验证评估环境”中，限于篇幅测试过程不再赘述，经过测试发现了一些隐藏的无线传感器网络协议一致性测试问题，提高了一致性测试有效性和客观性，也证明了本文所提出的一致性测试自动化方法的有效性和实用性。
4结语
在分析了现有协议一致性测试和自动化测试理论后，本文提出了一致性测试的自动化方法，并基于这个方法设计实现了一致性测试系统，在实际应用本系统时发现了一些隐藏的无线传感器网络协议一致性问题，提高了无线传感器网络协议一致性测试的有效性和客观性，证明了该方法的有效性和实用性。
自动化测试范文第9篇
关键词：自动化测试；测试工具；测试指标；缺陷
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）02-0298-03
1 介绍
“自动化测试”是利用一种适当的测试工具，自动运行测试的过程。使用自动化测试工具最有效的目的是使回归测试自动化。这就意味着对可重复的详细测试用例要有或者要开发出一个数据库，每一次这个测试用例运行时，会有一个应用上的改变去确认这种变化不会产生意料之外的结果。
自动化测试反映的是经济性和可操作性。一旦实施，自动化测试通常更经济。同其他类型的测试相比，自动化测试的优点表现在：回归测试经常和快速地进行、能更好地利用资源、更容易测试属性。
尽管有这些优点，但自动化测试也有局限性。自动化测试不能取代手工测试的一些功能，因为有一些操作用手工测试来完成会更容易一些。由于软件开发的局限性，自动化测试不能提高效率。测试工具不具有想象力，也就是说测试工具只是一个软件。测试工具只会服从使用说明，但是一个测试者在测试工具运行的时候，可以发挥自己的创造性和想象力来提高这种测试，或者是背离计划或者是标注一些附加情况，以便在以后能更好地测试。
图形用户界面的手工测试有难度而且浪费时间，但是由于用户界面的广泛应用和控制组件（按钮，下拉菜单，工具栏等）的数量使它在今天的软件系统中更受欢迎，更有用。因此，GUI软件成为自动化测试的目标。
2 计算机辅助软件测试工具（CAST）
2.1工具介绍
工具是以一种更好的方式完成某些事情的手段或者自动化系统。“更好的方式”意思是：工具可以使开发更精确，更有效率或者更有生产力，可以提高产品的最终质量。在自动化测试领域内，有各种计算机辅助软件测试工具，依靠工具所结合的不同行为，工具可以分成不同的类型。
1）回顾和检查工具
这些工具帮助形成回顾，浏览和需求规格，功能设计和代码。这种要求回顾和检查支持的工具是：：
复杂性的分析工具：这些工具帮助识别高风险和复杂领域。软件的复杂度以程序内决定的数量为基础，这对于测试者来说是非常重要的，因为它提供了一个测试总量的必要的说明，从而在实践中避免缺陷。
代码理解工具：这种工具帮助用户理解不熟悉的代码。用于识别受到特殊关注的区域，比如说检查区。
语法和语义分析工具：这些工具进行广泛地错误检查，发现编译器可能遗漏的错误。这些工具是独立的语言，可以分析代码，保存错误清单，提供构造信息。
2）测试计划工具
测试计划为全部测试过程提供基础，确定测试活动的来源和测试时间表。测试计划工具包括：测试计划文档的模板、测试进度和人员评估、复杂性分析员。
鉴别复杂领域的工具也可以用来定位那些影响额外测试计划的领域（这些额外测试以基本风险管理为基础）。通常最大的帮助来自于软件测试文档的IEEE/ANSI标准，它描述了测试计划的目的，轮廓和测试计划的内容。
3）测试设计和开发工具
在测试计划之后将会进入一个新的过程，叫做测试设计过程。在此过程中，所有测试计划中的测试方法将会更详细。测试设计过程识别和重视相关的测试用例。测试开发是将测试设计转换成特殊测试用例的过程。应当提出的是，这一阶段，从测试工具，尤其是测试设计中是得不到太多帮助的。测试设计和测试开发所要求的工具如下：
测试数据生成工具：这种工具使基于用户自定义格式的测试数据的生成自动化。当大量的测试需要输入数据时，这些工具就很有用。
以需求为基础的测试设计工具：这些工具为需要规范化方法的用户准备，用于设计测试用例，以确保实现的系统达到了需求文档指定的格式。
4）测试执行和评估工具
测试执行和评估是执行测试用例和评估结果的过程。这些工具被用于自动运行选择的可执行的测试用例，和用来计算这种工作的有效度。自动测试执行工具对于解决大量的测试是必要的。测试执行和评估所需的工具如下：
抓取和播放工具：这些工具抓取测试输入，数据和包括键盘、鼠标活动在内的动作，同时也能够执行自动化播放，因此测试在稍后的时间内可以很容易地重复进行。这能让手工测试者从反复的手工测试中解脱出来。差异被报告给测试组，同时抓取的数据帮助测试组追踪差异，直到找出最初的原因。使用抓取/播放工具的问题就是：实现这些测试的自动化需要某些稳定性。自动化测试的关键就是可维护性。这一工具的另一个问题是：使用这一工具是非常昂贵和费时的。
覆盖分析工具：在测试已经执行的情况下，这些工具测量那些没有被覆盖，需要更多测试的产品部分。这种测量可在模块或者子系统平台上执行。为保持对覆盖信息的追踪，这些类代码使源代码进入预处理程序。新的代码资源要比旧资源大的事实导致目标模块尺寸的增长。然而，即使结构测试覆盖率100%，也不能确保测试完成。
记忆测试工具：这一工具的作用就是发现存储的问题。错误在它们变得明显和引发严重问题之前能够被识别。记忆测试工具往往是语言和特殊的平台。这种工具使用简单，定价也合理。
模拟器工具：模拟器工具模拟被测试系统的运行环境。它被用来测试那些贵重的，危险的，或者是在真正的环境中不可能测试的软件。比如说测试航空或者核反应堆的控制软件。
执行工具：执行工具决定系统的执行能力。这些工具使产生，控制和分析客户应用系统的测试变为可能。
2.2工具选择
为了使自动化测试有效，或者提高软件的质量，应当特别注意对测试工具的选择，选择的测试工具最好适合测试需要。选择测试工具时应当考虑下列因素：
兼容性：选择能够自动化测试的测试工具，也就是说，测试工具必须支持系统中的平台有效。为了测试结构有效，管理测试数据和脚本，测试工具必须具有所有必需的关键特性。同样测试工具也应该支持设备建立测试用例，例如创建目录和删除文件。
维护性：与改变软件相比，维护测试用例更容易。维护工作的减少，不仅依靠定义明确的程序，而且也依靠测试工具的功能性。例如有些工具与其他工具相比，对软件类型的频繁改变不太敏感，这就让基础脚本的编辑更容易。
学习性—实用性：这就要求掌握这种工具不能花费太多时间。工具应当是容易使用的，或者它的特性不应该是麻烦的和困难的。文档，脚本语言和测试工具的界面就是影响实用标准的因素。
可靠性—连续性：确保工具能够正常的工作，因为有些工具开发商并没有进行很好的测试，从而导致失败可能会经常发生。
3 GUI软件的自动化测试
在使用GUI的情况下，为了创建自动化测试用例，需要测试工具和测试对象。该文选择Telelogic Tau公司的MSC编辑器（version3.4）作为测试用例。
3.1测试工具选择
GUI最好的测试工具看起来是抓取/播放工具，因为研究的目的就是关注GUI测试问题。为了选择好的抓取/播放工具， 对比了三种不同的工具。这些工具是：Software Research Inc.的TestWorks，Vermont Creative Software的HighTest和Mercury Interactive Inc.的WinRunner/XRunner。
在选择工具之前，有些测试已经在Microsoft Notepad上完成。当产生测试和用测试工具辅助执行时，有些因素必须纳入考虑范围：平台支持，测试用例准备，维护性，错误校正，测试管理，调试，学习曲线和可靠性/可用性。
由TestWorks提供的功能是非常有限的，而鼠标的活动是不能忽视的。使用这一工具的另一个问题是：没有好的文档记录。
HighTest有好的文档记录，而且功能要比TestWorks更强，但是HighTest的主要问题是：错误报告分析起来比较困难，同时也不支持Unix平台。
最好的选择就是WinRunner/Xrunner，它提供了广泛的功能，也有很好的文档记录。WinRunner/XRunner的错误报告使分析和定位错误更容易，而且也支持所有的平台。这种工具对于Telelogic公司来说是最适当的选择，但是在这些工具中，它也是最贵的一个。
3.2测试用例产生
通过WinRunner为MSC编辑器创建测试用例时，有些问题也就随之出现了。创建测试用例时，遭遇了第一个问题，它可能按照目前的编辑器状况，来检查菜单项目的可选择性或者模糊度。这些测试用例不能够按照所需求的那样工作。
创建菜单测试时产生了另一个问题：当主要构造改变时，更新一个单一的表格要比编辑大量的测试用例更容易。WinRunner的作用主要用于储存信息。
此外，在编辑器的弹出菜单中没有生成测试用例。它可能需要花去一些时间，来产生需要进入弹出菜单的功能，因为WinRunner并不支持弹出菜单的测试。
3.3 测试指标收集
进行案例研究时，指标包括创建，运行和更新测试用例的时间以及发现的缺陷的数量。案例研究开始之前，手工测试的相应指标的收集已经完成。
1）时间
参考文献：
[1] Pqul C Jorgensen.Software Testing[M].北京：机械工业出版社，2005：2-11.
[2] 郑人杰，殷人昆，陶永雷.实用软件工程[M].北京：清华大学出版社，1997： 203-207.
[3] 华涛，李红红，李束祥.一种低代价的图形用户界面回归测试框架[J].计算机工程，2011（14）：39-40.
自动化测试范文第10篇
（赛宝软件评测中心，广东 广州，510610）黄茂生
摘要：本文探讨了Visual Basic 6.0在测试自动化中应用的可能性，并列举了一些在实际工作中应用的例子
关键词：Visual Basic；测试工具；测试自动化；GUI；对象
Using Visual Basic 6.0 To achieve Automation Testing Huang mao-sheng
(CEPREI Software Testing Center，510610，Guangdong Guangzhou,510610,China)
Abstract: The paper discusses the possibility to use Visual Basic 6.0 in Automation Testing, and use several simple examples to show how it is used in our tasks。
Keyword: Visual Basic；Test tool；Automation Testing；GUI；Object
一 现有自动化测试工具的不足
当前，一个摆在软件测试自动化面前的一个很明显的事实是目前可用的工具并不能做一切我们想要它们做的事情；指望任何一种工具能够完全支持众多不同应用的测试自动化是不现实的。由于很难找到一个能完全满足测试自动化需要的测试工具，而且测试自动化工具都十分昂贵，所以常用的做法是使用一种主要的自动化测试工具，然后用传统的编程语言如Java, C++ 和 Visual Basic编写自动化测试脚本以弥补该工具的不足之处。
二 Visual Basic 应用于自动化测试的优点和局限性
利用Visual Basic之所以能实现一些比测试自动化工具更好的功能的原因在于它毕竟是针对实际的项目而编写测试脚本，而且，事实上Visual Basic确实存在比其他编程语言更明显的优点可应用于测试自动化项目。
众所周知，Visual Basic 不是一种测试工具，但它是一种非常流行的软件开发语言；使用Visual Basic最大的好处是它是一种非常流行的语言，它简单、易学易用和有非常广泛的懂得Basic语言的用户群基础，即使对不熟识Visual Basic 的测试工程师，要熟悉它也可以轻易找到大量有关的出版物和资料。
Visual Basic本身拥有一些能支持测试过程的特性，例如，它具有返回有关测试平台和被测应用程序的重要信息的功能。Visual Basic 的Shell函数和SendKeys函数可以启动一个应用程序和操作它的图形用户界面，用Visual Basic可以编写所需要的一些脚本程序，例如，装载一个测试应用程序。Visual Basic中集成的可视化数据管理器可以直接连接一个数据库并查看它的数据结构。此外，Visual Basic 还可以用来测试一些后台操作的应用程序，例如，可以编写一些脚本存取初始化文件（.ini文件）和Windows注册表。从Visual Basic 中访问Windows 的应用程序接口（API）对操纵受测应用程序和报告一些重要信息都是非常有效的，而且Visual Basic语言比当前其他的编程语言花更少的时间去掌握和有更高的编程效率，适合要求快速建立测试脚本的测试自动化工作需要。
由于Visual Basic不是一种专业的测试工具，因而有其局限型，首先它不包含目前已经成熟的自动化测试工具所具有的大部分的功能，例如，Visual Basic本身不提供缺陷报告、测试设计和文档管理等功能；它还缺乏录制功能和任何自动化测试设置，要在Visual Basic 测试代码中包含这些功能，需要手工编写这部份功能代码，而且目前大部分有关Visual Basic 的出版物和资料都是针对开发者而不是测试者。虽然如此，依然有一些不需要很多的投入而使Visual Basic应用于自动化测试项目的基本方法。
三 Visual Basic 中支持测试自动化的工具集
Visual Basic 6.0 包含一套不需任何编码就能支持测试的工具集，包括丰富的向导，可视化数据工具和对象浏览器等。
1向导和模板 在Visual Basic 中有众多的向导可以使用。其中一个对测试人员非常有用的向导是数据窗体向导，它可以创建一个能连接Access或ODBC数据库的数据窗口，该数据窗口可以设置成单独地查看单个记录或者用表格形式批量浏览数据记录，因而可以实现一个能快速定制而又易于使用的用来检查数据库内容的测试工具。
窗体模板不但可以快速创建一个标准的窗口，而且能同时伴随着这些窗口产生源代码，这些自动产生的代码可以部分或全部应用到为测试而定制的窗口中，这对提高测试效率是非常有效的。
此外，一些其他的向导如数据对象向导，ActiveX 控件窗口向导都可以实现花费最少的编码工作量去创建和配置一些有用的测试对象。
2 可视化数据管理器
可视化数据管理器可以快速地连接到ODBC或OLEDB数据源，去查看数据库结构，数据表，视图和其他基本的对象。通过它去检查后台数据库实现数据库应用程序测试。也就是说如果被测应用程序包含一个在SQL Server，Sybase ，Oracle和 Access的数据库，则可
以通过可视化数据管理器去检查所有的这些数据库而不需要分别登录DBMS界面。通过Visual Basic作为一个通用的前台数据库管理器去管理一个用ODBC或OLEDB存取的后台数据库，可以节省测试工程师的测试时间和可能花在熟悉这些数据库产品而花的培训时间。可视化数据管理器通过数据库输入和测试SQL语句支持白盒测试。利用它可以修改后台数据，甚至创建新数据对象如数据表，存储过程和数据视图。一些被用来测试数据的SQL语句（通常用来检索重复的数据行和暴露有关完整性的缺陷）甚至必要时可以在这里创建和执行。
3 Object Browser对象浏览器
对象浏览器是另一个非常有用的Visual Basic工具，通过它去检查对象输出的属性和方法以及各种必要的参数；测试人员可以利用这些信息创建这些对象的验证性和功能性的测试，特别是对面向对象测试，非常有用而且非常有效的。