2006年以前,Mercury Interactive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
http://www.cnblogs.com/nckiki/articles/242876.html
可以用WinRunner为所测试应用程序的GUI,功能和回归测试创建自动化脚本。
主要包括如下6个阶段:
1). 创建GUI Map文件:WinRunner可以通过它来识别被测试应用程序中的GUI对象。
2). 创建测试脚本:通过录制,编程,或两者的组合创建。在录制测试脚本时,在你想检查被测试应用程序响应的地方插入验证点。
3). 调试脚本:用调试(Debug)的模式运行测试脚本以确保它们可以平稳地运行。还可以使用WinRunner提供的Step, Step Into, Step out功能来调试脚本。
4). 运行测试:用验证(Verify)的模式运行测试脚本来测试你的应用程序。当WinRunner在运行中碰到验证点时,它会将被测应用程序中的当前数据和以前捕捉的期望数据进行比较,如果发现了任何不匹配,WinRunner将会把目前的情况捕捉下来作为真实的结果。
5). 检查结果:确定测试脚本的成功或是失败。在每次测试脚本运行结束之后,WinRunner会将结果显示在报告中。它描述了所有在运行中碰到的重要的事件,例如验证点,错误信息,系统信息或是用户信息。如果发现在运行中有任何不匹配的验证点,你可以在测试结果窗口中查看期望的和实际的结果。
6). 提交缺陷:如果一个测试脚本是由于所测试应用程序中的缺陷而导致失败的,你可以直接从测试结果窗口中提取缺陷的相关信息。
WinRunner利用GUI Map文件来识别应用程序中的对象。它将学习到的窗口或对象信息储存在GUI Map文件中。当WinRunner运行测试脚本时,它利用GUI Map来定位对象。它从GUI Map文件中读取对象的描述并且在被测应用程序中寻找具有相同属性的对象。
在GUI Map文件中的每一个对象都有一个逻辑名称(logical name)和一个物理描述(physical description)。对象的逻辑名称是由其类决定的。在大多数情况下,我们可以将逻辑名称看成是显示在对象上的标签。你可以修改已分配的逻辑名称当它不是十分具有描述性或太长的时候。当对象的属性发生改变时,你必须要修改其物理描述。
GUI Map文件的扩展名是".gui"。
GUI Map文件分为两种类型:
· 全局GUI Map文件:一个为整个应用程序使用的GUI Map文件
· 每个测试脚本的GUI Map文件:在每个测试脚本创建之后,WinRunner会自动为其创建一个GUI Map文件。
我们可以通过工具菜单中GUI Map Editor来查看当前载入的GUI Map文件及其内容。GUI Map Editor 显示多个已创建的GUI Map文件和认识到的带有逻辑名和物理描述的窗口和对象。
在录制脚本时,WinRunner会自已学习对象和窗口,并将它们储存在临时的GUI Map文件中。我们可以在General选项中指定是否需要每次都载入这种临时GUI Map。
当我们载入一个GUI Map文件时,关于窗口和对象的信息连同其逻辑名称和物理描述都载入到内存中。因此当WinRunner在一个特定的窗口上运行脚本时,它可以用这些在内存中的信息识别对象。
WinRunner的脚本语言是Mercury Interactive’s Test Script Language (TSL),这是一种类C的脚本语言。你可以通过增加另外的TSL函数和编程元素(例如Windows API)或WinRunner的虚拟编程工具(函数生成器(Function Generator))来增强你录制的脚本。
在WinRunner中,有两种不同的录制模式:
· 环境判断录制(Context Sensitive recording):通过识别GUI对象录制你在被测应用程序中执行的操作。
· 模拟录制(Analog recording):录制键盘的输入,鼠标的点击,和鼠标指针在屏幕上精确的x,y轴
在WinRunner中,有三种不同的运行模式:
· 验证Verify:使用这种方式来检查你的应用程序
· 调试Debug:使用这种方式来帮助你识别测试脚本中的bug
· 更新Update:使用这种方式来更新测试脚本的期望结果或创建一个新的期望结果文件夹
载入Add-Ins实际上是将在Add-In中的特殊的函数装载到内存中。当创建测试脚本时,只有这些选中的Add-In中的函数会列在函数生成器中,在运行脚本时,只有那些在载入的Add-In中的函数可以被执行,否则WinRunner将会给出一个不能识别函数的错误信息。
验证点可以把被测应用程序的当前行为和早前版本的行为进行比较。
在WinRunner中有4种验证点:
· GUI checkpoints:验证GUI对象的信息。例如,你可以检查一个按钮是否可用或查看在一个列表中哪一个选项被选中。
· Bitmap checkpoints:给窗口或所测试应用程序的部分做快照,并把它和早先版本中捕捉的图像做比较。
· Text checkpoints :在GUI对象或位图中读取文字,使你可以验证它们的内容。
· Database checkpoints:基于你创建在数据库的查询,检查一个结果集的内容和列、行的数量
Checklist文件包含了我们正在验证的对象的属性和相关信息 。gui*.chk文件包含了期望的结果,并储存在exp文件夹中。
同步点使你可以解决预期的在测试脚本和你应用程序之间的时间问题。例如,如果你创建一个打开数据库应用程序的测试脚本,你可以增加一个同步点以让测试脚本等待直到数据库中的记录载入到屏幕上。
对于模拟测试(Analog testing),你也可以使用一个同步点来确保WinRunner在一个指定的位置重新放置窗口。当你运行一个测试脚本时,鼠标指针沿着准确的坐标行进。重新放置窗口使鼠标指针接触到窗口中正确的元素。
编译模块实际上也是一种脚本,只不过它包含了一个可以被其它的测试脚本频繁地调用,用户自定义函数集的库文件。当你载入一个编译模块时,它的函数将自动的被编译并保存在内存中。其它的测试脚本可以直接调用它们。
编译模块可以改进脚本的组织和性能。由于你在使用它们之前已经调试过编译模块,因此你的测试脚本只需要少量的错误检查。另外,调用一个已经编译的函数明显地比解释测试脚本中的函数快得多。
当编译模块用来储存可重用的函数时,测试脚本包含了在WinRunner中的可执行文件。编译模块是不可执行的。
在保存为编译模块时,WinRunner会自动执行一次预编译。
默认情况下,包含TSL代码的模块的属性是“main”。主模块可以在其他的模块中被调用执行。除了当WinRunner识别到一个“call”语句时,主模块会被动态地被编译为机器代码。例如:
call cso_init();
call( "C:\\MyAppFolder\\" & "app_init" );
编译模块被载入到内存中以便其他模块引用。
reload ("C:\\MyAppFolder\\" & "flt_lib") 或load ("C:\\MyAppFolder\\" & "flt_lib");
当你测试你的应用程序时,你或许想检查它如何执行有着大量数据集的相同操作。你可以用一个运行10次的循环来创建一个数据驱动测试:每次循环运行时,它由不同的数据集驱动。为了使WinRunner 能够使用数据来驱动测试,你必须将数据连接到所要驱动的测试脚本。这就叫参数化(parameterizing)你的测试。数据存储在一个数据表格(data table)中。你可以手工执行这些操作,或使用DataDriver Wizard来参数化你的测试脚本并储存数据在数据表格中。
数据驱动测试的步骤如下:
· 创建一测试脚本
· 转换为数据驱动的测试脚本并准备一个数据库
· 运行测试脚本
· 分析测试结果
12. 无法识别GUI对象的原因
WinRunner会由于以下多种原因导致不能识别GUI对象。
· 不是标准的Windows对象
· 没有安装所需的Add-In
· 如果所使用的浏览器和WinRunner的版本不兼容,GUI Map编辑器将不能认识在浏览器窗口中显示的任何对象
。。。
12. 无法识别GUI对象的原因
WinRunner会由于以下多种原因导致不能识别GUI对象。
· 不是标准的Windows对象
· 没有安装所需的Add-In
· 如果所使用的浏览器和WinRunner的版本不兼容,GUI Map编辑器将不能认识在浏览器窗口中显示的任何对象
。。。
13. 启动文件(start up file)
在General Options ->Environment-> Startup文本框中,选择或输入你希望作为启动文件的 测试脚本
14. 输入测试脚本的相关信息
在创建一个测试脚本之前,你可以在Test Properties-> General和 Description中输入和脚本相关的信息,如被测功能的类型,测试脚本的详细描述,引用的相关功能说明书文档
15. 如何处理定制对象(custom objects)?
定制对象是不属于WinRunner所使用的标准类之一的任何GUI 对象。WinRunner学习此类的对象为generic "object"类。WinRunner利用obj_mouse_语句来记录在定制对象的操作。
如果定制对象和一个标准的对象很相似,你可以映射它为标准类别之一。你也可以在环境判断测试(Context Sensitive testing)时配置WinRunner用于识别定制对象的属性。
16. 什么是虚拟对象(virtual object)并且如何使用它们?
应用程序可能会含有一些外观和行为和GUI对象相似的位图。WinRunner利用win_mouse_click语句来记录操作。通过定义一个位图对象为虚拟对象,当你录制并运行测试时,你可以教WinRunner将它象一个GUI对象一样对待。
Bochs是一个x86硬件平台的开源模拟器。它可以模拟各种硬件的配置。Bochs模拟的是整个PC平台,包括I/O设备、内存和BIOS。更为有趣的是,甚至可以不使用PC硬件来运行Bochs。事实上,它可以在任何编译运行Bochs的平台上模拟x86硬件。通过改变配置,可以指定使用的CPU(386、486或者586),以及内存大小等。一句话,Bochs是电脑里的“PC”。根据需要,Bochs还可以模拟多台PC,此外,它甚至还有自己的电源按钮。
Bochs是一个开源的虚拟机。它可以实现vpc和vmware的大部分功能。你也可以像使用vmware一样的在Bochs里面安装操作系统。但是,由于它是全模拟的。所以,速度要远远慢于vmware.这样看来Bochs好像没有什么优势.是这样吗?在应用方面的确如此。
但是,在其他一个方面它是处于绝对优势的。那就是它具有调试功能!这是一个让人振奋的功能。这个功能在你调试操作系统或者其他一些在裸机上运行的程序时候,会让你有一种在写windows下运行的应用程序的感觉。有时候它是我们的救命稻草。没了它,也能活,但是肯定要糟糕的多。好了我们开始切入正题。
http://hi.baidu.com/ywg728/item/d29a7d1599634b701109b56f
一、 配置Bochs
实际上配置Bochs是很简单的,为什么很多人不会配置呢?我觉的就是因为他使用和配置方式和普通程序不一样——配置文件。实际上配置文件是和ini文件、bat文件类似的。Bochs没有给我们提供图形界面的配置工具。这就需要我们自己来修改配置文件。
简单的配置就可以让你的操作系统在Bochs里面跑起来。用Bochs跑完整的linux和windows是不现实的。实在是太慢了。一般我们也只能把他当成调试器来使用。现在,我们先看一下如何让dos在他里面跑起来。如果你细心的话你会发现在Bochs文件夹里面有一个Bochsrc-sample.txt的文本文件。里面包含了所有了Bochs参数的信息。这个是官方的教程。可惜是英文的,而且我也没有找到有中文的教程(不然也没有我这篇文章)。在这里我们仅仅介绍最简单的配置选项。好了,废话就不多说了。我们现在就开始。
我们以一个例子来说明,这个例子是我用来跑dos以及我自己的小操作系统的。下面就是我们要用到的最基本的选项:
# 在一行的最前面加上“#”表示这一行是注释行。
# 内存,以MB为单位,对于dos来说最大可以访问16MB
# 的内存,所以我就给了他16MB,你可以根据自己的机器来调整
megs: 16
# 下面两句一般是不可以改的,至于干什么用的就不用我说
# 了。从他们的文件名就可以看出来。
romimage: file=../BIOS-Bochs-latest, address=0xf0000
vgaromimage: file=../VGABIOS-lgpl-latest
# 这个还用说吗?当然是软驱了,我想我们写操作系统肯定是先
# 把操作系统放在软盘(或映像)里面吧?在Bochs里面是可
# 以使用任意大小的软驱映像的。可以是1.44或2.88,我一般使
# 用2.88。还有就是Bochs里面可以使用两个软驱。不过好像
# 我们并不经常这样做。
floppya: 2_88=test.img, status=inserted
#floppyb: 1_44=floppyb.img, status=inserted
# 下面是硬盘,很简单,还有就是Bochs也是可以支持多个硬
# 盘的。那么,硬盘文件是怎么生成的呢?我们可以发现硬盘是
# img格式的。你注意没有在Bochs文件夹里有一个工具叫
# bximage.exe,我想你应该猜出来了。他就是用来生成这个硬盘
# 文件的工具。我在这儿还想说的是硬盘分三种格式的,最好选
#用growing类型。这种有一个好处就是节省硬盘空间,不过使用
#这种类型的硬盘还需要在下面加上mode = growing这个选项。
ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14
ata0-master: type=disk, path="dos.img", cylinders=306, heads=4, spt=17
# 下面这个就是光驱,没什么好说的。如果你想使用物理光驱,
# 只要让path=E:(我们假设E盘是光驱)
ata0-slave: type=cdrom, path="dos.iso", status=inserted
# 这个是启动设备,可以使用cdrom(光驱)、c(硬盘)或floppy(软
# 驱)。
#boot: cdrom
boot: c
#boot: floppy
# 这一句可以不要,他只是指定用来保存日志的文件。如果不指定的
# 话他就会输出到命令控制台上。
log: Bochsout.txt
# 这一句是设置在开机时是否激活鼠标,Bochs对于鼠标的控制不是# 很好。建议如果不是特别需要的话不要激活他。在运行期间也可以点窗口右上角的鼠标图标来激活他。
mouse: enabled=0
以上这些设置就可以让你的DOS或自己的小操作系统在Bochs里面跑起来了。至于其他的一些高级支持,你可以查看Bochsrc-sample.txt里面的说明。不要害怕他,其实很简单。关键是抛弃恐惧。
二、 启动Bochs
配置文件已经写好了,硬盘文件等也都已经弄好了。那么我们如何来启动Bochs呢?很简单,你右击一下上面写的那个配置文件(例如myos.bxrc,注意:扩展名要是.bxrc。)选择“运行”或双击即可。不过我一般都不这样做,我一般是写一个批处理文件。
很简单,如下所示:
cd "d:\Bochs-2.2.1\dos"
..\Bochs.exe -q -f Bochsrc.bxrc
这样做的好处就是无论这个启动脚本放在哪儿都是可以使用的。那么,我们如何进入调试状态呢?下面我们就来讨论这个问题。
三、 调试功能
新建一个批处理文件,写入一下内容:
cd "d:\Bochs-2.2.1\dos"
..\Bochsdbg.exe -q -f Bochsrc.bxrc
运行这个批处理文件,你就可以进入调试状态了。不过你会发现,程序卡住了。没有想普通运行状态一样进入你的dos操作系统。为什么?因为调试在等待你的命令。你只有给他一个命令他才会继续。我们输入“c”,然后回车。是不是dos已经可是运行了?
如果没有运行说明你输入的窗口不对,你不会把c输入到那个没有光标的窗口了吧?如果真是那样我真是服了你了。真的!但是,dos运行起来了,如何在返回调试状态?很简单,按ctrl+c。什么你正在运行的程序被结束了?谁让你在操作系统窗口中按了,我是说在调试窗口按。至于哪个是调试窗口,哪个是操作系统窗口,我就不说了。如果你不知道你就干脆别使用Bochs了,也不要写什么程序了,更不要开发什么操作系统了。为什么?因为你不可能成功。从这儿就可以看出来。最好是找块豆腐撞死,这样你会很幸福的死去,不然你就会成为教育后代的典范——看到了吗XXX是怎么死的,笨死的。呵呵!开个玩笑。你真要不知道
千万不要来找我,找我我也不告诉你。不好意思,我也不知道。那么,在调试状态下我们可以干哪些事呢?你用过debug吗?它能做的Bochs都能做,它不能做的Bochs也可以做。下面就是一些常用的调试命令。
help
我最想告诉大家的是这个指令,因为他可以告诉我们一切。古语说:“授之以鱼,不若授之以渔”。我觉的很有道理。但是,有些人就是不想学这种一劳永逸的方法。所以,我还要继续写下去。
输入help,回车。你会得到以下信息:
help - show list of debugger commands
help 'command'- show short command description
-*- Debugger control -*-
help, q|quit|exit, set, instrument, show, trace-on, trace-off,
record, playback, load-symbols, slist
-*- Execution control -*-
c|cont, s|step|stepi, p|n|next, modebp
-*- Breakpoint management -*-
vb|vbreak, lb|lbreak, pb|pbreak|b|break, sb, sba, blist,
bpe, bpd, d|del|delete
-*- CPU and memory contents -*-
x, xp, u|disas|disassemble, r|reg|registers, setpmem, crc, info, dump_cpu,
set_cpu, ptime, print-stack, watch, unwatch, ?|calc
需不需要我翻译一下前两句?那好吧。
help - 现实调试命令列表
help '命令' - 显示某条命令的详细用法。
命令分为哪些?很明显,四类:调试控制,运行控制,断点管理,CPU和内存控制。我不想在这儿一一介绍了。没有必要,我只介绍一下最常用的就可以了。
c:继续,前面我们已经用过了。
s:单步执行。他还有一个扩展用法。
s n :执行n步。
b 0x7c00:在内存0x7c00处设置一个断点.当程序执行到0x7c00处就自动进入到调试状态.后面的这个数指的是内存的线性地址
。也可以使用10进制的数,但是好像没有人会这样做。
x /20 0x7c00: 以16进制的形式从内存的0x7c00开始显示20个字的数据。这个是很常用的命令,但是需要注意的是他的显示顺序和16进制编辑器中的显示顺序有一点小的区别。他的显示是以字为单位的,而且在字中是从低到高显示的.不过也没有什么大不了的。你只要稍微注意一下就可以了。
dump_cpu:这个是我最长用的三个指令之一。他的功能是显示现在的寄存器的状态,详细内容类似于:
eax:0x00000000, ebx:0x00000000, ecx:0x00000000, edx:0x00000683
ebp:0x00000000, esp:0x00000000, esi:0x00000000, edi:0x00000000
eip:0x0000fff0, eflags:0x00000002, inhibit_mask:0
cs:s=0xf000, dl=0x0000ffff, dh=0xff009bff, valid=1
ss:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
ds:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
es:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
fs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
gs:s=0x0000, dl=0x0000ffff, dh=0x00009300, valid=1
ldtr:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0
tr:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0
gdtr:base=0x00000000, limit=0xffff
idtr:base=0x00000000, limit=0xffff
dr0:0x00000000, dr1:0x00000000, dr2:0x00000000
dr3:0x00000000, dr6:0xffff0ff0, dr7:0x00000400
cr0:0x00000010, cr1:0x00000000, cr2:0x00000000
cr3:0x00000000, cr4:0x00000000
u /20 0x7c00 :反汇编内存0x7c00处,反汇编的长度是20。你想不想知道dos的引导程序是什么样子的?执行一下这个命令就可以了。你还可以使用这样的命令 u /20 cs:0x120a,至于什么意思,我也不说了。
现在,我们已经介绍了6条命令了。够了。对于日常应用已经完全够用了。如果你想了解其他命令的用法只要执行一下help “命令名”就可以了(注意,命令上要带有引号)。好了。现在已经把Bochs的基本功能介绍完了。你是不是感觉Bochs很简单?对于简单的应用来说,确实如此。但是,想让他支持一些高级功能就有点麻烦了。毕竟它是全模拟的虚拟机,所以在有些方面实现起来并不容易。但是,向网络之类的功能还是可以支持的。你只要看一下Bochsrc-sample.txt就知道了。我在这儿就不说了。我还要说的是Bochs不仅仅可以调试操作系统,还可以调试dos下的程序。我们知道dos没有多少好的调试器。那么我们完全可以使用Bochs来调试。你知道在程序的开头输出一下程序的段地址和偏移地址,然后暂定一下,在虚拟机里面设置一下断点就可以了。我一般都是在在程序里面潜入一句汇编:
jmp $
这样在程序死循环的时候在调试窗口按下ctrl+c就可以看到他的段地址和偏移地址了。然后,在去掉这一句,设置一下断点,运行这个程序。是不是在指定位置中断了?