一、提高回归测试的覆盖率,提高测试质量
对于功能已经完整和成熟的软件,每次发布一个新的版本,其中大部分功能和界面都和上一个版本相似或完全相同,这部分功能特别适合于自动化测试, 从而可以让测试达到测试每个特征的目的。通过 AutoRunner 来编写回归测试的测试用例,并且再每次发布版本的时候通过执行所有的测试用例来进行回归测试,能够覆盖大量的功能——人工测试无法进行测试的功能。
二、 每日测试的高效率
DCC 版本的发布周期往往比较短,也就是开发周期只有短短的几个月,而在测试期间是每天/每 2 天都要发布一个版本供测试人员测试,一个系统的功能点有几千个上万个,人工测试是非常的耗时和繁琐,这样必然会使测试效率低下。AutoRunner 通过高效率的自动执行测试用例,允许每天对版本进行测试,提高测试效率。
三、具有一致性和可重复性
由于每次自动化测试运行的脚本是相同的,所以每次执行的测试具有一致性, 人是很难做到的. 由于自动化测试的一致性,很容易发现被测软件的任何改变。
四、 更好的利用资源--周未/晚上
理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了开发和测试之间的等待。
五、 解决测试与开发之间的矛盾
通常在开发的末期,进入集成测试阶段,由于每次发布一个版本的初期,测试系统的错误比较少,这时开发人员有等待测试人员测试出错误的时间. 事实上在迭代周期很短的开发模式中,存在更多的矛盾, 但自动化测试可以解决其中的主要矛盾。
六、将烦琐的任务转化为自动化测试。
大量重复的测试是非常繁琐的,并且需要消耗大量的人力才能够完成。自动测试能够很好的解决这个问题,不需要繁琐的劳动,不需要大量的人员。
七、 增加软件信任度
只有经过大量测试用例测试过的版本才是可靠的 ,而只有使用自动测试才能够保证在段时间内完成大量的测试用例。
八、系统体系结构特性要求
8.1、系统要求
8.1.1、操作系统环境:
WindowsXP~win10;winserver2008~winsever2012
8.1.2、测试用例数据格式:
XML;EXCEL
注:理论上支持 jdbc 接口的数据库。
8.1.3、AutoRunner 是一个自动化的功能测试工具,它可以和测试管理工具、缺陷跟踪工具一起来使用,可以将自动化测试的设计和结果统计分析纳入到测试管理平台,给企业以最客观的测试过程分析和结果统计以达到更好的效果:
AutoRunner
测试管理工具
缺陷跟踪工具
测试需求管理
测试用例管理
测试计划
测试执行
测试结构设计
测试脚本录制、
编写、调试
查看测试结果
查看缺陷
查看缺陷跟踪报告
8.2 系统性能
AutoRunner 针对与系统的功能测试自动化,对性能要求不高:自动测试的脚本执行速度,超过人工执行的速度。
8.3 、扩展能力
8.3.1、扩展验证点:
所谓的验证点,就是用来验证被测试系统返回数据或者状态是否和预期一
致的点。AutoRunner 提供了完整的验证点功能,用来验证字符串、bitmap
文件是否正确,对字符串可以验证是否符合定义的“正则表达式”。当然,由
于验证往往是非常复杂的,例如:当我们使用一个功能向 database中增加
一条记录后,通过 jdbc 来查看该记录是否已经被增加。这就需要用户根据
具体的数据库来编写一个功能来实现特殊的校验点。
系统提供了基本的校验方法,允许用户自己来通过编写一个特殊校验的类,
或者一个特殊的方法来定义特殊的校验点(调用的结果如果希望反映的标
准的测试报告中,就需要调用系统提供的基本方法),最终实现对验证点
功能的扩展。
8.3.2、自动录制时候的针对用户自定义组件的识别
根据国外测试人员的经验,编写脚本的工作中,大量的工作都被用户的自
定义组件消耗了。
由于很多的测试工具本身支持一组标准的控件,在自动录制的时候,系统
能够根据这些组件来生成测试脚本,并且允许回放这个脚本来执行测试。
当用户自定义了一个组件之后,用户定义的组件是基于基本组件的,系统
就往往无法自动识别这些组件,导致测试人员录制脚本的时候非常复杂 :
名称不同、识别困难、运行时刻同步点错误。
AutoRunner 提供了对组件的定义功能:所有的组件类型必须被定义,并且
只有最上层的已定义类型组件被识别,其他的组件都不会被识别。如果用
户定义了自己的组件,那么他只需要把他自己定义组件的:类名、
contexttype增加到组件定义文件中就可以了。
AutoRunner 的这个功能大大增强了对用户自定义组件的支持,使得测试人
员能够录制正确的脚本、编写正确的脚本,减少差错。
8.3.4、对第三方测试管理工具的支持
AutoRunner 提供了对第三方测试管理工具的支持:通过数据文件或者数据
库,就可以传递测试用例信息、测试用例数据信息。
AutoRunner 提供了命令行的支持,支持用户在远程启动和调用,这就为第
三方的测试管理工具提供了一个执行调用接口。
8.3.5、对第三方缺陷跟踪工具的支持:
同样的,AutoRunner 可以提供针对缺陷跟踪工具的 API 的调用,和第三
方缺陷跟踪工具达到“无缝连接”。
8.4 可靠性和可用性
8.4.1、系统的可用性和可靠性由几个指标来衡量:
第一, 系统的出错处理能力。也就是,当系统出现错误之后,
是否能够提供完善的错误处理机制,跳过错误,继续执行允许执行的下一
个功能点测试。
第二, 系统执行过程中工具不会出现异常,导致测试无法正常执行。
第三, 测试脚本出现异常,提供强大的调试功能。
第四, 当 AutoRunner 升级之后,原有测试脚本能够兼容,继续使用。
具体到 AutoRunner,如下:
系统的出错处理能力:
对所有的测试用例来说,每一个测试用例都是一个继承自 class TestCase
的子类,在测试过程中的动作都是调用父类 TestCase中的方法来实现的 ,
如:setWindow(),setValue(), getValue(), setProperty(), getProperty()等。这
些方法在 出错的时候(一 般都是同步点错误 ),会抛出 一个异 常
syncException。
用例只有一个主要的测试过程类:test() throws syncException。当 test()执
行的时候,如果出现异常,就会抛出一个 syncException,外部的方法会
catch 到这个 syncException,然后使用一个通用的方法来处理错误。
测试人员只需要编写一个标准的错误处理方法就可以完成这些所有的工
作。
当然,这个测试人员需要对 java 有一定的了解和熟悉,但是这样的人员只
需要一个就可以了,因为出错处理程序只需要一个,它用来处理所有的错
误,并且使得下一个测试用例可以被执行。
8.4.3、IDE 的稳定性
在一个大量的测试用例被执行的时候,实际上 IDE 并没有工作,它只是在
等待响应。
执行测试的过程,就是执行 java 各个不同的类的过程。而 TestCase 是一
个非常健壮的类,不会导致系统出现异常。因此,IDE 从理论上是非常坚
固的。
另外基于 java 的系统一般而言,稳定性都非常好。特别是所有的测试用例
基本上都是继承自 class TestCase。
8.4.4、产品升级
当产品升级的时候,对原有测试用例影响最大的就是 TestCase类的变化。
classTestCase实际上只是一个 abstract,只实现了一个基本的 interface,实
际的功能都是由底层的组件来实现的,这个组件在 IDE 启动的时候被
load,跟测试人员自己编写的测试用例没有任何直接关系。
因此当底层的类发生变化的时候——系统升级可能会带来底层类的变化
——对测试脚本没有影响。
8.5 国际支持
支持多种语言 Unicode 编码形式;
用户可以选择中英文界面的版本。
系统对语言编码的识别是由系统自动完成,用户不必考虑选码的问题。
9. 系统基本功能
9.1 测试用例创建与录制
创建测试用例
用户能够创建一个测试用例。创建的测试用例脚本是空的,需要用户自己
来加入包的名字、类的名字等等。
创建测试用例可以在项目浏览器中使用右键菜单或者系统的菜单。
如果用户是一个非常熟悉测试用例的测试人员,就可以自己手工
来编写测试用例的代码了。但是,由于资源文件不存在,所以如
果希望自己编写的测试用例能够执行的话,还需要手工编写对应的 xm l
资源文件。
创建测试用例的过程一般是从录制开始的。
通过录制创建测试脚本
当你从菜单或者工具条启动“录制”命令,系统开始记录你的所有操作 ,
并且在记录过程中把生成的脚本文件显示在编辑器上面。
录制的结果是,你得到了:1)一个可以被执行的测试脚本文件;2)测试
脚本相关的资源文件,这个资源文件用来记录所有脚本中用到的窗口、组
件的属性(如:名称、位置、tabindex、类型等)。
9.2 测试用例编辑
测试用例的结构
测试用例是具有结构的,它能够运行,首先要符合 java 的语法和主程序入
口。并且它需要使用测试基本类提供的功能来完成测试。
测试用例编辑
AutoRunner 提供了强大的测试用例编辑功能:第一,提供了 java 脚本的
关键字识别技术,能够识别系统的关键字,避免语法错误;第二,提供了
实时语法分析的功能,在编辑过程中动态分析语法,并且对语法错误动态
报警,尽量避免编译时刻再出现错误。
9.3 测试用例参数化
什么是数据驱动?
录制完成测试用例之后,你就得到了一个测试脚本。如果这个测试脚本只
能够被执行一组数据,并且数据是固定不变的,那么你每一次的测试就只
能够执行很简单的功能了。
边界条件、路径覆盖,需要使用一个脚本、很多组数据输入才能够完成 ,
固定的数据无法满足要求。
数据驱动就是指能够把需要输入(和验证)的数据参数化,通过脚本执行
不同的数据,就实现了数据驱动,也就是数据与脚本分离。
AutoRunner 实现了脚本与数据分离:脚本使用 java 的脚本,在脚本执行
的时候,从数据源中读取数据。
AutoRunner 使用了 DataSource这样一个接口来实现参数化。
DataSource 通过外部定义的组件实现对外部数据源的操作功能,从外部获
取数据。
DataSource 本身就是通过插件来实现的,IDE 只定义了 interface,外部插
件决定系统的行为。通过加载不同的插件,用户可以使用不同的数据源来
访问数据。如:excel、xml、db 和其他。
测试用例参数化
AutoRunner 在自动录制完成之后,可以通过菜单“参数化”,AutoRunner
会弹出所有的对象树,提供给用户勾选,选中部分进行自动参数化。参数
化的结果:1)脚本变为参数化脚本;2)数据池自动增加了选择的参数列
表。
在测试用例参数化之后,用户仍然可以手工来修改,实现进一步的参数编
辑工作。
创建外部数据源
只有访问数据源的脚本,没有外部数据源,那么所有的脚本访问都会失败 。
用户需要创建外部的数据源。
有两种方式创建数据源:
第一,自动通过 IDE 创建。在脚本文件中,选中该脚本的右键菜单中的“创
建/维护脚本”,IDE 会自动查找所有的 datasource 操作,并且更新数据源。
第二,通过手工创建。需要在外面手工编辑文件。
9.4 增加同步点和验证点
同步点的概念
在进行输入输出之前,就需要对系统进行同步,使得输入和输出能够针对
正确的窗口或者组件,以免出现异常和错误。如果同步条件没有出现,系
统就需要等待一段时间,来满足运行系统的要求,使得需要操作的组件能
够显示出来。
自动同步和手工同步点
所谓的自动同步点,是只在操作过程中,由于本身需要执行操作,如对某
个组件输入一串字符,而需要等待这个组件出现,这种同步点是系统在操
作过程中自动加入的,我们称为“自动同步点”。
也有一些情况,需要手工增加一些同步点,当系统执行到一定时候,需要
等待一个条件出现再继续执行,这种同步点我们称为“手工同步点”。
用户需要关心的是手工同步点,例如:需要等待一个 image 能够正确显示 ,
然后再继续下面的工作。它不是单纯的等待,而是每间隔一段时间就去查
看是否满足同步条件,如果满足系统就继续执行,如果不满足而系统超时
时间没有达到,就继续等待。如果出现超时,那么就抛出 SyncException。
验证点
测试的目的是看执行一个过程,结果是否和预期结果一致。
验证的方法就是查看结果是否一致,这个点我们称作“检查点”。
验证成功则继续执行,验证不成功也需要继续执行,并且把结果写入测试
报告。
AutoRunner 的验证点需要手工加入——AutoRunner 不知道用户需要检查
那些内容。
增加验证点
用户可以使用编辑器来增加检查点,AutoRunner 提供了方法让用户来增加
验证点。
9.5 测试用例执行
测试用例执行
当测试用例只有能够被执行才有意义。在 AutoRunner 里,测试用例是一
个 java 的类(特殊的 java 类)。
这个类首先被编译,然后执行。通过菜单上的“执行”项,你可以执行这
个测试用例。
如果编译出现错误,则会在信息栏中提示错误。
执行支持标准输出,并且把标准输出显示在 AutoRunner 下面的输出框里面。
多次执行
当测试用例被执行的时候,AutoRunner 会提示,需要用户输入当前测试脚
本被参数化之后,需要使用的数据列表的行号范围。输入之后,会多次执
行这个测试脚本,每次使用一行的数据,达到一个脚本中执行多次的目标。
测试跟踪调试
测试脚本本身也可能出错,也可能由于被测试对象的变化(如缺少了一个
对象)而出现错误。
因此,定位和排除错误的方法,我们使用了跟踪调试。AutoRunner 使用了
java 作为测试脚本,并且每个测试脚本都是一个 java 的类。因此
AutoRunner 实现了 java 的跟踪体系结构:JDA。
AutoRunner 允许用户设置断点、查看本地变量值、查看指定的变量的值 ,
并且提供了单步执行的各种模式。
10.AutoRunner 的特点
10.1、评估自动测试工具的关键在于:
第一,很高的建立测试用例的生产率;
第二,降低用户的二次开发成本;
第三,便于维护使用;
第四,便于测试案例的数据驱动扩展;
第五,测试用例资源的延续性;
第六,扩展性。
下面,我们就 AutoRunner 在这几个方面的特点简要介绍:
AutoRunner 具有很高的生产率。自动测试工具建立一个测试用例脚本的
时间成本为手工测试一次的 3-10 倍,可见建立自动测试的起始是需要一
定的成本的。
如何降低建立测试用例的成本,是自动测试工具的关键。AutoRunner 的优
势在于:首先,优秀的自动识别组件功能。脚本能够在录制完成之后直接
使用,能够自动适应出现的各种情况,如:窗口位置、title、大小等的变
化,组件位置、名称的变化。通过自动识别能够识别处组件,从而降低对
编写脚本的要求,提高了自动录制的可用性。第二,提供了数据驱动框架 。
很多测试工具虽然支持参数化的功能,但是需要手工完成数据驱动框架 ,
才能够实现数据驱动:从指定的文件中获取数据。AutoRunner 自动定义标
准的数据驱动模式,定义了标准的数据驱动格式,降低了增加测试用例的
成本。虽然建立一个测试脚本需要一定的时间,但是在测试脚本建立之后
增加一组数据的时间却非常短。
10.2、模糊识别。AutoRunner 对每种组件定义了标准的模糊识别指标。在录制
测试用例之后,系统的资源文件就会根据系统的配置文件生成确定识别权
重的指标。在测试脚本被执行的时候,通过权重算法来进行模糊识别和匹
配。
10.3、关键字驱动。AutoRunner 提供了领先的关键字驱动技术,支持脚本编写
使用专家视图,不熟悉脚本的用户使用关键字视图,并且实现在脚本视图
与关键字视图之间的相互转换,既提升了效率,也提升了易用性,既能够
给熟悉脚本的测试工程师提供高效的工作平台,也能够给不熟悉测试脚本
的测试工程师使用方便。
用户可以对系统配置文件的识别参数进行调整,达到修改整个录制脚本识
别参数权重的目标,便于提高整个项目中脚本开发的效率。
在用户录制完成脚本之后,可以对对应的资源文件的权重属性进行修改 ,
使系统能够定制具体的模糊识别对象,对脚本组件识别算法作特殊处理。
通过模糊识别算法,能够极大地提高脚本执行的可靠性,对于由于类似组
件位置、大小等变化之下的脚本执行,能够起到非常良好的效果:用户不
需要因为界面小的修改而导致来修改测试脚本。
10.4、便于维护使用。用例完成之后,随着应用系统的修改、应用系统版本的提
升,同样需要维护这个测试用例库,因此维护使用是非常重要的功能。
维护方便性主要体现在几个方面:简洁的框架、容易理解的脚本、方便的
调试功能。
10.5、AutoRunner 提供了针对测试用例的框架,这个框架包括:用例层次划分
(AutoRunner 的用例由 Action 组成,每个 Action 包含对一个 Window 的
所有操作,AutoRunner 允许在用例之间共享 Action 来提高系统的可维护
性)、数据驱动框架、自动同步、数据校验模式等。使用这些框架能够非
常容易的维护测试用例库。
10.6、AutoRunner 采用了 java 的语法,测试人员使用的语法非常简单,便于理
解和使用。并且,由于系统提供了关键字驱动的框架,所以对一般的维护
而言,根本不需要了解 java,只需要知道最基本的操作就可以。
AutoRunner 遵守 JDA 的标准,提供了最强大的系统调试功能:从设置断
点、单步执行、变量查看、表达式查看等方面提供支持,便于测试人员容
易排除错误。
10.7、另外,AutoRunner 提供了强大的编辑器,在一般编辑器能够动态识别语法
关键字的基础上,还能够同时提供语法检查——在编辑的时候从事语法检
查,对错误的语法实时提示。这个编辑器对于比较缺乏编程经验的程序员
来说非常重要。
10.8、测试用例资源的延续性和扩展性。测试用例库本身也是一种资源它和应用
版本是对应的关系,随着应用系统版本的升级,用例库也会升级,那么回
归测试的效果才能够最大化。
对于自动化测试工具来说,要保证这个资源,就需要保证:测试脚本的兼
容性 。另外由于随着应用的发展,测试工具的功能需要大幅度的提升,
因此工具的可扩展性也需要保证才能够保证测试用例资源的延续性。
AutoRunner 使用了 java 语言作为基础,并且实现了 java 调试功能,可
以随着 java 的发展不断的发展,扩展自己的功能。
采用 java 语言是一个巨大的优势,比测试工具自己使用一种语言要方便的
多。从根本上说,AutoRunner 不是采用了哪种语言的语法,而是从根本上
就是 java 语言。这和采用 vbscript 或者 c 语言语法的工具是截然不同的。
在扩展外部功能方面,由于 AutoRunner 使用了 java 语言,允许使用外部
的包,也就是说可以任意增加脚本本身的功能而不受语法的限制和工具本
身是否支持外部包的限制——在最大程度上提高了扩展性。