关于 SQAGetProperty 的使用

发表于:2007-4-06 14:26

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:苏扬    来源:本站原创

分享:

【摘要】随着软件测试的发展,越来越多的人开始使用自动化测试工具帮助进行软件的测试,其中用的比较多的是Rational Robot和Winrunner。由于Rational robot在测试Web方面比Winrunner有优势,所以许多人使用robot进行网站的测试。由于经常需要根据网站的一些信息来判断,决定脚本的运行情况,所以属性读取函数SQAGetProperty的使用很频繁。本文结合实际介绍了SQAGetProperty函数的用法。

【关键字】软件测试  自动化测试  Rational Robot  SQAGetProperty

• 序言:

由于经常有人在论坛上询问有关如何读取网站上的信息,如何得到网页的返回值等等。所以想在这里全面介绍SQAGetProperty函数的用法,以及一些注意事项。

• SQAGetProperty函数介绍

SQAGetProperty是用来抓取控件的属性的,脚本中可以根据所抓取的值来判断运行情况,然后执行不同的步骤。它的语法是status% = SQAGetProperty(recMethod$, property$, value)。

recMethod$是如何读取你所要获得的控件的值的方法。在recMethod$中,经常需要使用Type=来区分控件的类型,或者是使用符号来表示控件所在的层次关系。

property$是你所要读取的属性的名称,它是区分大小写的。

value是个变量,是用来存放你读取的控件的属性值。

这条语句可以写成SQAGetProperty “recMethod”, “property”, value

也可以写成Result=SQAGetProperty(“recMethod”, “property”, value)

我是倾向于用后一种方法,因为方便调试。可以将断点设在该语句上,调试的时候打开Variable window就可以看到Result的值了。

常用的Result值有:

Result=0,表示SQAGetProperty语句正确,能够成功读取属性的值。

Result=1002,表示recMethod的语法是错误的,需要改正你的语法。

Result=1003,表示你所要读取的控件没有找到,说明recMethod部分的语法还是对的。这种情况经常出现在抓取含有网页层次关系的控件中。如果网页层次关系没有表示好,就会出现找不到控件的错误。

Result=1005,表示你要读取的属性没有找到。可能是你想抓取的值并不是控件的属性,也可能是在区分控件前的“\”丢失了。

SQAGetProperty函数的应用范围

用SQAGetProperty函数所读取的控件的值,是要可以用Object Properties读取出来的,否则是不能通过工具直接抓取控件的值的。

对于那些直接写在<body></body>里的文字,如HTMLDocument是无法用该函数抓取的。

比如 <html>

<head></head>

<body>Hello</body>

</html>

这个Hello就没办法用SQAGetProperty抓取出来,它也没有办法用Object Properties抓出来,因为它并不包含在HTMLDocument的属性值中。

如何判断一个内容是否可以用SQAGetProperty抓取出来呢?建议使用robot本身的辅助工具——insqector进行分析。

打开inspector,选取你希望取出的内容进行分析,可以得到控件的列表。

抓取上面所说的Hello,所得如图:

  

由图可见,该Web页面只有一个HTMLDocument,它的Index为1。而Hello两个字只是在Contents里的。可是HTMLDocument只有Properties里的属性才能用Object Properties抓取出来,而只有那里面的属性才能用SQAGetProperty读取出来。也就是说如果robot可以取到该对象属性,那么说明robot提供的函数sqagetproperty也可以取到该属性的。这是判断SQAGetProperty是否能够成功的依据之一。

• 举例说明SQAGetProperty函数的用法

由于SQAGetProperty函数主要取决于recMethod$部分的书写结构,下面我将以是否含有网页的层次关系,举例具体的说明recMethod$部分的书写方法。

• 对于不含网页层次关系的控件属性的读取

对于这类控件,recMethod$部分很简单,可以仿照帮助里的例子。

比如:

Result = SQAGetProperty("Type=CheckBox;Text=Match case", "State", CheckState)

就是将类型是CheckBox的,内容是Match case的控件,将他的State属性读取出来,放置在CheckState这个变量里。

我们拿一个实际的例子来说:

51Testing论坛登陆成功后,会出现当前用户的名称。我们可以读取HTMLTable的信息来验证是否出现了该用户名。

首先用Object Properties抓取所需要的控件。抓取后显示如下:

Window SetTestContext, "Caption=51Testing软件测试论坛---软件测试,软件质量工程师的家园 - Microsoft Internet Explorer", ""

Result = HTMLTableVP (CompareProperties, "Index=2", "VP=Object Properties")

Window ResetTestContext, "", ""

可以查看验证点,得知所要取的值在innerText里,如图:

  

用inspector工具同样可以知道所要获取的值的属性,并且可以确切的了解所要获取的控件是否含有层次结构。

如图:

  

由图可见,所要获取的控件是HTMLTable类型,它没有层次关系,并且innerText属性是在Properties中的,是能够用SQAGetProperty函数读取出来的。

编写脚本,可得

Sub Main

Dim Result As Integer

Dim varStr as String

Window SetTestContext, "Caption=51Testing软件测试论坛---软件测试,软件质量工程师的家园 - Microsoft Internet Explorer", ""

'Result = HTMLTableVP (CompareProperties, "Index=2", "VP=Object Properties")

'Window ResetTestContext, "", ""

Result=SQAGetProperty("Type=HTMLTable;Index=2","innerText",varStr)

End Sub

此时读出的varStr值为:“? 司空公子:退出 | 短消息 | 控制面板 | 系统设置 | 搜索 | 统计 | 帮助”

这样只需要再通过其它一些函数比如Left$、Right$之类的对该字符串进行加工,就可以得到所需的用户名。

一点说明:不能将Window SetTestContext给注释掉,否则会导致robot无法定位到所需的网页上,也就无法读取到控件。返回错误为1003,找不到控件。

• 对于含有网页层次关系的控件属性的读取

大部分网页没有复杂的层次关系,但对于很多软件的Web客户端,尤其是使用了struct之类架构的Web客户端来说,网页层次关系就比较复杂了。此时使用SQAGetProperty函数来抓取控件的属性时,就必须要注意recMethod$部分的写法是否清楚的表示了网页的层次关系。

很多人之所以用这个函数无法取出数值,都是因为recMethod$中的层次关系没有表示清楚。我们可以通过inspector工具查看一个控件的具体的层次关系。

我们可以借用PCL兄在《請問Robot 如何快速使用座標定位》中所构建的框架结构来说明这个问题。

首先搭建框架代码。

Frame.htm:

<html>

<head>

<title>新建网页 2</title>

</head>

<frameset rows="64,*">

<frame name="header" scrolling="no" noresize target="main" src="hello_world.htm">

<frame name="main" src="new_page_3.htm">

<noframes>

<body>

<p>此网页使用了框架,但您的浏览器不支持框架。</p>

</body>

</noframes>

</frameset>

</html>

 

Hello_world.htm:

<html>

<head>

<title>Hello World</title>

<base target="main">

</head>

<body>

<p>Hello World</p>

</body>

</html>

 

new_page_3.htm:

<html>

<head>

<title>新建网页 3</title>

<SCRIPT FOR="B3" EVENT="onClick" LANGUAGE="VBScript">

MsgBox "上传文件!"

</SCRIPT>

</head>

<body>

<form method="POST" action="--WEBBOT-SELF--">

<input type="button" value="上传" name="B3">

<input type="submit" value="提交" name="B1">

<input type="reset" value="重置" name="B2"></p>
  

加入我们想获取“上传”这个按钮上的字符,可以使用inspector工具查看,如图:

  

可以看出,这个框架包含两层。

  

表示层次关系时用“;\;”来划分。

比如想读取“上传”这个按钮的内容,可以首先用Object Properties抓取这个button。

得结果为:

Window SetTestContext, "Caption=新建网页 2 - Microsoft Internet Explorer", ""

Browser SetFrame,"Type=HTMLFrame;HTMLId=main",""

Browser NewPage,"HTMLTitle=新建网页 3",""

Result = PushButtonVP (CompareProperties, "Type=PushButton;Name=B3", "VP=Object Properties")

Window ResetTestContext, "", ""

然后可以使用SQAGetProperty函数编写脚本为:

Result = SQAGetProperty("Caption=新建网页 2 - Microsoft Internet Explorer;\;Type=HTMLFrame;HTMLId=main;HTMLTitle=新建网页 3;\;Type=PushButton;Name=B3", "Value", StateString)

分析recMethod$部分。“Caption=……”表示最外面的一层框架,让robot首先定位到“新建网页2”这个页面。紧接着“;\;”表示层次的划分。“Type=HTMLFrame;HTMLId=main;HTMLTitle=新建网页3”使robot定位到main这个框架里。最后的“Type=PushButton;Name=B3”定位到所需抓取属性的button上。

如果在调试过程中发现始终有1003的错误,可以在SQAGetProperty语句前加

Window SetTestContext, "Caption=新建网页 2 - Microsoft Internet Explorer", ""

Window ResetTestContext, "", ""

进行定位。

• 总结

本文着重介绍了SQAGetProperty函数在网页控件属性方面的抓取,以及如何通过Object Properties和inspector工具在区分网页的层次结构,使得能够比较方便的写出正确的SQAGetProperty语句。

本文关于SQAGetProperty函数的使用介绍到此结束,希望大家能有个满意的答案。要想掌握好这个经常使用的函数,必须要多做实验,掌握在各种情况下的语法形式。

如果还有什么疑问,或者是希望对robot的其它部分进行讨论的,可以联系我。我的MSN是Arnold_Qian@MSN.Com

• 参考文献

1. Rational Robot User Guide

2. 论坛帖子《請問Robot 如何快速使用座標定位》、《robot如何取页面输入域的文本内容》、《如何让combox自动选取它的子项》

【摘要】 本文在分析市场上已有的商用的性能测试工具实现原理和体系架构的基础上,提出了利用现有的开源代码构建开源的性能测试工具思路。

【关键词】 性能测试、 Vugen 、 Conductor 、 Player 、 Analysis

• 性能测试的意义

追求更高的质量和更高的性能是人类的天性。 “ 更高,更快,更强 ” 的奥运会是对人类自身运动能力的测试。同样,人类也在追求我们工作生活中不可或缺的 IT 系统能够提供更快更强的服务。目前 IT 系统已经称为各个企业运转业务时最重要的系统之一。对 IT 历史稍微有所了解的人都知道, IT 系统经过早年的一个人使用的单机系统时代,几十个人使用的局域网中的客户机服务器系统时代,到现在服务成千上万用户的跨广域网的庞大系统时代。 IT 系统发展中的最明显的特征之一就是所谓的 “ 数据大集中 ” ,即数据越来越集中到后台的服务器中,系统同时为成百上千,乃至上万的用户提供服务。这样的例子在银行、保险、电信公司中随处可见。随着企业业务量的加大,其 IT 系统承载的负荷越来越重,系统性能的好坏严重影响了企业对外提供服务的质量。对 IT 系统的性能进行测试和调优越来越引起企业的重视。

目前,典型的企业 IT 系统的架构如下所示:

 

这样的系统由客户端、网络、防火墙、负载均衡器、 Web 服务器、应用服务器 ( 中间件 ) 、数据库等等环节组成,根据木桶原理,即木桶所能装的水的量取决于最短的那块木板,整个系统的性能要得到提高,每个环节的性能都需要优化。在这样的 IT 系统中,每个环节的都是一个很复杂的子系统,对其调优都是一门专门的技能。 Oracle 数据库的调优就需要专门的技能和多年的经验。对于整个 IT 系统的调优,其复杂程度更是急剧增加。因此 IT 系统性能测试调优是一个复杂的项目,需要拥有各种专门技能的专家组成小组来完成。这些专家包括操作系统专家、网络专家、数据库专家、应用服务器专家、应用软件和业务专家等等。

虽然性能测试是一项很复杂和专业的工作,但是由于企业 IT 系统的重要性,保证其性能的稳定对于企业对外提供优质服务越来越得到企业的重视。性能测试服务的市场正在快速发育中。研究系统性能测试越来越有意义。

要保证性能测试项目的高质量,必需依赖两个重要的因素:人和工具。具有多年经验的高素质的专家小组是保证性能测试的最重要的因素。另一方面,功能全面、使用灵活的性能测试工具对于加速性能测试,提高测试质量和效果也是必不可少的。

现在有很多种性能测试工具,从功能简单单一的开放源码的软件到昂贵的商业性能测试工具。本文论述了性能测试工具的一般体系架构和技术要点,并探讨了利用已经存在的开放源码的软件整合出一套开源的优质的性能测试工具的可行性。

• 性能测试工具综述

性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加压,研究被测系统在不同压力情况下的表现,找出其潜在的瓶颈。因此,一个良好的性能测试工具必需能做到以下几点:

•  提供产生压力的手段

•  能够对后台系统进行监控

•  对压力数据能够进行分析,快速找出被测系统的瓶颈。

产生压力的手段,主要是通过编写压力脚本,这些脚本以多个进程或者线程的形式在客户端进行运行,来模拟多用户对被测系统的并发访问,以此达到产生压力的目的。由于一台普通的 PC 机可以轻易产生几百乃至上千个进程或线程,通过使用若干台 PC 机,就可以轻易模拟出成千上万个并发用户。压力脚本执行的功能和被测系统客户端软件执行的功能应该一样,从而产生真正的业务压力。 编写压力脚本的工作实际上就是重新编写客户端软件。为了快速达到编写脚本的目的,采用的最有效的方式是通过性能测试工具录制客户端软件和服务器之间的通讯包,自动产生脚本,然后在自动生成的脚本的基础上进行少量修改,如:关联动态内容,指定批量测试数据等。根据经验,压力脚本的准备工作往往占据整个性能测试项目的 50% 的时间和工作量。 因此,能否提供录制和自动产生脚本的功能是性能测试工具最主要的评价指标之一。

压力脚本的方式给我们提供了模拟各种压力状况的有力手段,通过人为制造各种类型的压力,我们可以观察被测系统在各种压力状况下的表现,从而定位系统瓶颈,作为系统调优的基础。因此,提供丰富的对后台系统进行监控的手段是性能测试工具第二个最主要的评价指标。监控应该不在被测系统上安装任何软件,否则的话,为了监控而引入的 “ 代理 ” 之类的小软件将给被测系统引入新的可变因素,一方面造成了测试结果的不准确,另一方面会给用户的系统的稳定性可能造成影响,从而导致用户的反感和拒绝。目前,各种监控手段大都采用所谓 “ 无代理 ” 的方式,即不在被测系统上安装任何软件,仅仅通过改变被测系统的配置,就可以对被测系统进行监控。需要监控的部件多种多样,包括操作系统、数据库、中间件、应用系统、安全模块、网络、防火墙等等。

一组压力测试运行完毕后,我们会得到详尽的性能数据。这些数据包括最终用户的响应时间,后台系统各个部件的运行数据。这些数据的量非常大,往往包括几千个变量的运行曲线,大小可能达到上 G 的规模。靠人工去分析这些数据几乎是不可能的,性能测试工具必需提供数据分析工具,帮助性能测试人员去阅读、解读和分析数据,辅助测试人员定位系统的瓶颈。数据分析工具是保证最终测试成果的手段,因此它是性能测试工具中最重要的部分之一。

目前已经存在的性能测试工具林林总总,数量不下一百种,从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测试工具 ab 到大而全的商业性能测试软件如 MercuryLoadRunner 等等。任何性能测试工具都有其优缺点,我们可以根据实际情况挑选用最合适的工具。

前面已经指出,性能测试是一项复杂的工作,一个性能测试项目的质量如何,测试人员的素质、能力和经验是最关键的因素。拥有世界上最先进的 CT 扫描仪并不能让你成为一个优秀的医生。不过, “ 工欲善其事,必先利其器 ” , 拥有一套自己非常熟悉,功能全面、质量可靠的性能测试工具对于从事性能测试的人员非常有吸引力。在商业性能测试软件中,大多价格非常昂贵。由于大多数性能测试工具是按照并发用户数收取费用,因此要获得大的并发量的价格是很高的。虽然存在很多免费的性能测试工具,但其功能不足,彼此不成系统,不能灵活搭配使用。

一套功能全面的性能测试工具的开发工作量是非常大的,这也是为什么商业性能测试软件价格昂贵的主要因素之一。由于互联网和开放源码运动的发展,性能测试工具的各种功能都以各种形式的开源软件存在了。如果我们设计出一套合理的架构,在统一的架构下整合各种缺乏系统性的开源工具软件,使之能够彼此配套,搭配出一套功能全面、质量可靠,而且是开放源码的性能测试工具是完全有可能的。

本文的下面部分具体论述性能测试工具的基本框架和技术要点,希望热爱编程,希望对开放源码运动有所贡献的读者能从本文的论述中获得一些启发,沿着作者的思路继续往前行。

• 性能测试工具的体系架构

作者对性能测试工具 LoadRunner 比较熟悉,通过对 LoadRunner 的了解和评估,作者设计的性能测试工具体系架构如下图所示:

性能测试工具的组成部分有如下几个:

•  虚拟用户脚本产生器 Vugen(Virtual User Generator)

•  压力调度和监控系统 Conductor

•  压力产生器 Player

•  压力结果分析工具 Analysis

通常,进行性能测试项目的一般步骤如下:

•  用户确定需要录制的交易,通过用户操作和 Vugen 的录制,记录并生成自动化脚本。

•  修改脚本,确定脚本能够回放成功。

•  Conductor 是一个集中控制平台,它和压力产生器 player 互连,指定脚本在 player 上的分配,并控制 player 向被测系统的加压方式和行为。

•  Conductor 同时负责搜集被测系统的各个环节的性能数据。各个 Player 会记录最终用户响应时间和脚本执行的日志

•  压力运行结束以后, Player 将数据传送到 Conductor 中, Conductor 负责将数据汇总。

•  数据分析工具 Analysis 读取压力测试数据,进行分析工作,确定瓶颈和调优方法。

•  针对性地进行系统调优,重复进行压力测试,确定性能是否得到提高。

•  重复以上 3-7 步,逐步提高系统的性能。

鲁制脚本的工具虚拟用户产生器 Vugen 实际上是一套开发调试工具。 Conductor 是一个框架程序和监控程序,它负责将 Vugen 开发的脚本以多进程 / 多线程的方式在 Player 机器上运行。为了产生更大的压力, Conductor 必需支持集群功能,理论上 Conductor 可以和任意多台 Player 机器互连,以便产生足够大的负载压力。 Conductor 同时实现无代理方式的监控功能,可以监控各种主流的软件,并且提供对不支持的软件进行监控的二次开发的手段。 Analysis 实际上是一个数据分析工具,用于事后的数据分析,它可以安装在任何 Windows 平台的机器上。下面我们论述每个部件的技术要点。

• 虚拟用户产生器Vugen

虚拟用户产生器通过录制客户端和后台服务器之间的通讯包,分析其中的协议,自动产生脚本。用户在自动产生的脚本的基础上进行修改,从而快速开发出一个逻辑功能和客户端软件完全一样的压力脚本程序。

录制的技术主要是通过 proxy 的方式来实现的,如下图所示: 

Vugen 根据对捕获的数据的分析,将其还原成对应协议的 API 组成的脚本。由于 Proxy 源程序的获得非常容易, Vugen 的主要的技术要点是如何根据捕获的数据包来反解析成对应的网络协议。通常捕获的数据包为 TCP 数据流,我们可以很容易的生成 socket 层次的脚本,类似如下示例:

int main( int argc, char** argv)

{

char buf[BUF_MAX_LEN];

int socket = 0;

socket = connect(“IP=192.168.52.65”, “Port=3200”, TCP);

getbuffer(buf, “trace.dat”, 1, SEND);

send(socket, buf);

receive(socket, buf);

getbuffer(buf, “trace.dat”, 3, SEND);

send(socket, buf);

receive(socket, buf);

……

close(socket);

}

其中 trace.dat 包含着录制时捕获的数据包,按照 “ 发 - 收 - 发 - 收 - 发 - 收 ” 的顺序排放。

毫无疑问,这样的脚本按照记录的收发过程来回放,但是它的最大的缺点是处于太底层。要分析和修改 socket API 的脚本以及数据包的具体内容将是一个繁重而且烦人的工作,进行关联的工作的难度也将大大提高。客户端程序往往是利用更高层的应用协议 API 编写的,客户端软件的编写者也不一定对 socket-API 组成脚本进行修改。因此,Vugen应该尽可能地产生更高层网络协议的脚本,方便用户的阅读和修改工作。

以 Tuxedo 应用为例,对于 Tuxedo 应用,一次典型的 Tuxedo 业务调用的序列为:

tpinit(….) // 和后台建立连接

tpcall(….) // 向后台发起交易请求

tpterm(…) // 断开和后台的连接

这三次 api 调用将产生 TCP 层的 7 次收发动作, Vugen 必需根据这 7 次的收发,还原产生 Tuxedo-API 的调用序列。

由于对于不同的应用层协议,只能分别开发,因此, Vugen 支持的网络协议的多少是衡量性能测试工具的主要指标之一。

当然, socket 方式是一切应用层协议的基础, socket 脚本是一种通用的方式。对于 Vugen 不支持的应用层协议只能通过 socket 层次来录制。因此 Vugen 能生成 socket-API 脚本是其最基本的功能。

VuGen 产生的脚本应该应该是跨平台的,因此它应该提供 C/Java 两种语言的方式,支持各种平台的 C/Java 编译器。脚本可以在 Windows/Unix/Linux 上运行, Player 运行的机器既可以是 Windows 平台,也可以是 Linux, FreeBSD, Solaris, AIX 和 HP-UX 等平台,这样会方便用户选择机器作为 Player 。这一点非常重要。

由于 Vugen 支持的每种应用层协议必需单独开发,在设计 VuGen 的软件体系架构时,应该采用插件的方式来设计网络协议的解析器。这部分的设计借鉴了 Apache 的 module 设计思想,可以让任何对开发协议解析器感兴趣的开发者在一个统一的框架下开发。

VuGen 的体系结构如下图所示:

 

Vugen 的体系结构分为三部分:

•  第一部分为底层 proxy 录制器 , 负责捕获客户端和服务器之间通讯的数据包,这样的软件在开放源码的世界里面随处可见,而且非常成熟。 我们只要移植过来就可以使用。

•  第二部分是界面部分,提供脚本编辑、调试和运行功能,这部分可以用 Visual C++/MFC 实现 Windows 平台版本和 Java/AWT 实现 Unix 版本。

•  第三部分是以插件的形式提供的分析各种网络协议的解析器。开发这类插件的强有力的开发工具为 lex 和 yacc 。

• Proxy二次捕获的问题

Vugen 的 Proxy 方式需要解决的一个问题是二次捕获数据包的问题。

早期的网络服务器程序对外提供一个固定端口,客户端仅仅和这个端口通讯就可以了。这对于 proxy 录制非常容易。但是现在很多服务器程序为了提高对客户端并发量的支持,采用两个端口通讯的方式。如下图所示:

 

整个通讯的过程如下:

•  第一步:客户端将请求发往 Proxy 录制器。

•  第二步: Proxy 录制器将请求发往真正的服务器的指定端口,即图中的 3200 端口。

•  第三步:服务器机器的 3200 端口返回数据包给 Proxy 录制器。该数据包中包含了下一次通讯的目的地址,形式为 IP:Port 。很显然,这里的 IP 数据为真正服务器的 IP 地址。

•  第四步, Proxy 录制器把请求返回给客户端。

•  第五步,客户端根据提供的 IP:Port 信息直接把请求发往真正的服务器,不再经过 Proxy 录制器。

•  第六步:以后的通讯只是客户端和服务器之间的通讯了, Proxy 录制器是无法捕获这些通讯包了。

因此一般的 Proxy 录制器只能捕获头两个收发的数据包。 这个问题更一般的情形的例子是 HTTP 的 redirection 功能。第二次通讯可能发往另外一台机器了。 Proxy 录制器必需解决这个问题。

• 关联的问题

客户端和服务器之间的通讯,有一部分是数据是动态的,每次通讯都不一样。 Proxy 录制器在录制的时候是无法区分哪些是静态的信息,哪些是动态的信息,所有的信息都以 hard-coded 的方式记录下来。但是在回放的时候,如果有些信息不改变,那么脚本是不能执行成功的。考虑如下情形:

 

如上图所示,用户 jojo 以 jojo/bean 的账号 / 口令登录某一 web 服务器,查询某产品的信息,由 Vugen 录制交易的全部通讯包。 web 服务器返回给 jojo 一个动态的会话 ID: SessionID@12345 ,作为这次登录的会话标识。由于 Vugen 无法知道哪些信息是动态的,它会照单全收的方式,把所有的数据就记录下来。接着 jojo 根据 Web 服务器告诉他的 SessionID 去查询产品列表,交易可以正常执行下去。

我们会观察到,当 Vugen 根据捕获的通讯包生成 http 脚本的时候, SessionID 是 Hard-coded 的,即 “ 写死 ” 在程序里面的。当我们不加修改的回放该脚本的时候,会出现什么问题呢?如下图所示: 

按照录制时候的脚本, jojo 以 jojo/bean 登录后, Web 服务器返回给 jojo 一个动态会话 ID: SessionID@23456 ,这个值已经不是录制时候产生的 SessionID@12345 了,而是新的值: SessionID@23456 。那么脚本根据记录的 SessionID 的值,仍然会使用 SessionID@12345 去执行下面的查询交易。由于会话 ID 是有时效性的,用户退出系统后,其 SessionID 会失效,那么,服务器会给出一个 “SessionID 失效 ” 的错误,从而导致脚本无法正常执行下去。

对于上面的问题的通用解决方法如下图所示:

 

在第一次从服务器得到 SessionID 的时候把其放在一个变量 <session_id> 里面,在后面脚本访问服务器的语句里面,把所有的 ”SessionID@12345” 替换为变量 <session_id> 就可以圆满解决这个问题。

这种问题在任何系统都是非常常见对外问题。其通用的模式是: “服务器返回给客户端一些动态变化的值,客户端使用这些值去访问服务器的时候,不能把这些值写死在脚本里面,而应该存放在一个变量里面。” 这就是关联的概念。

关联的工作往往占据开发脚本的大部分时间,因为我们必需针对每一个具体的系统进行细致的分析,确定其需要关联的动态信息。为了快速开发脚本, Vugen 必需提供帮助我们关联的手段,最好做到自动关联。自动关联的方法有三种:

•  在录制之前设定辨别规则,录制完毕,产生脚本的时候根据规则识别出需要关联的动态内容,从而产生正确的脚本。

•  录制完毕回放一遍,把回放结果与录制结果进行自动对比,确定动态信息,进行自动关联。

•  录制两个一模一样的脚本,对比其中的差异来确定需要关联的动态信息,然后进行关联。

自动关联的功能是否完整可靠,关系到我们能否借助 Vugen 快速开发出符合要求的脚本,因此关联也是 Vugen 中非常重要的功能。

• 脚本的问题

Vugen 产生的最终结果是以源程序方式存在的脚本。为了编译该脚本,用户可以选用对应的编译器,这不是 Vugen 的功能。建议 Vugen 产生脚本的时候应该生成对应的 Makefile 和 build.xml ,允许用户以流行的 make 和 ant 命令来编译 C 和 Java 的脚本。关于 make 和 ant ,读者可以在互联网上查询相应的内容。

Vugen 自动产生的脚本应该支持两种语言, C / Java 。很显然, Vugen 不可能产生一个脚本运行的全部的代码,它需要额外的函数库的支持。譬如,通过录制 Tuxedo 协议产生的脚本应该是以 Tuxedo-API 的形式出现的。为了能够编译运行脚本,必需把 Tuxedo 的函数库连接到脚本里面。目前动态库的技术应用非常广泛,因此为了运行 Tuxedo 脚本,必需在 Vugen 和 Player 机器上安装相应的 Tuxedo 客户端软件,因为它包含相应操作。其它网络协议也存在这个问题。对于 http 协议,已经有很多函数库。 Vugen 产生的 http 脚本应该支持主流的函数库。这样带来的好处是我们不需要自己开发 http 函数库,可以直接引用已经经过实践证明了的质量可靠的函数库。选择支持何种函数库,需要慎重选择,我们应该选择应用最广泛的函数库。例如:关于 http 函数库,可以采用 www.w3c.org 提供的 libwww ,该函数库是开源的,质量可靠,远胜于我们自己开发。

• ConductorPlayer部分

Conductor ,我们称为 “ 指挥家 ” ,它是整个压力测试的核心。 Player 是产生压力的负载产生器,它们以进程或者线程的方式运行由 Vugen 生成脚本。 Player 如何运行脚本,由 Conductor 来决定。这好比一个交响乐队在演奏。 Player 就是各种管弦乐演奏者, Conductor 是指挥者。

Conductor 和 Player 实际上是一套框架程序。具体执行什么功能,是由脚本来完成的。 Conductor 和 Player 的体系结构如下图所示:

 

如上图所示, Conductor 上面有若干进程 / 线程。每种进程的作用如下:

•  Center 进程是整个调度的核心进程,它负责联系和用户界面打交道的工作。

•  Agent 进程负责和远端的 Player 机器中对应的 Agent 进程通讯。负责把编译好的脚本传送到 Player 机器上。在脚本运行的时候,定期从 Player 机器上获取 Player 的运行状态,每个虚拟用户运行的日志。

•  Monitor 进程负责对被测试系统的各个环节进行监控,并把监控的内容一方面写入 Conductor 机器的本地磁盘,另外一方面把监控的内容传送给 Center 进程,实时地显示在用户界面上。

Player 的进程有两种,一个是 Agent 进程,一个是 Player 进程。 Agent 负责和 Conductor 机器通讯,它根据 Conductor 的指示,在本机器上派生出指定数目的 Player 进程,这些 Player 进程负责具体执行相应的脚本。 Player 进程个数就是虚拟用户的个数。

Player 需要解决的一个问题是 IP 问题。为了防止黑客的攻击,某些后台的负载均衡设备一旦发现来自某一个 IP 的请求特别频繁时,就会拒绝为该 IP 提供服务。这样的功能造成的结果是 Player 无法把真正的压力加到后台系统中。解决方法就是在 Player 机器上伪装多个 IP 地址发送请求。这项技术称为 IP 欺骗 (IP Spoofling) 。 Conductor 和 Player 必需实现该项功能。

• ConductorPlayer的技术要点

关于 Conductor 和 Player 的技术要点有哪些,目前我还没有做深入的研究工作,但是我认为其技术要点主要涉及多进程 / 线程的编程,网络编程技术。可能这里面最大的难点是监控问题。当把被测系统的各个环节都监控起来,需要监控的参数会有成百上千个。如果采用集中式监控的方式,采集数据本身就对系统造成很大的影响,所以必需支持分布式监控方式。由于采集的数据是来自不同机器上的,由于各种的延迟,数据之间的时间同步将是一个重大的问题。

关于监控,还需要进一步的研究。

由于 Player 是没有界面的,是后台运行的程序,为了保持其可移植性,建议采用 Java 语言开发。

Player 和 Conductor 之间的网络协议不一定重新开发,可以使用成熟的 Http 1.1 ,方便在性能测试时调试 Player 和 Conductor 之间可能出现的通讯问题。

• 数据分析工具Analysis

该工具是一个纯数学工具软件,目前市场上已经存在了大量负责数据处理的软件,如 Matlab 等。可以将压力产生的数据直接导入其中进行处理。所以只要提供开放的数据接口就可以了,无需自己开发独立的性能数据分析软件。

即使 Analysis 需要开发,应该开发一些知识分析的功能。譬如,我们搜集了很多 Oracle 的数据信息,这些数据之间往往有固定的联系。如果将这些联系的知识融入到 Analysis 当中,将会更好。但是这有点类似人工智能的意味,比较难。

• 结束语

本文是对性能测试工具的一般性论述,讨论了性能测试工具的基本功能和可能出现的技术要点。由于性能测试工具涉及的内容太多,作者只是大致论述。其中涉及细节当中仍然会有很多技术要点没有论述。只是希望本文对希望了解性能测试工具的读者有一个入门的帮助。

一套功能全面的性能测试工具就象水管工经常携带的工具箱,里面充满各种工具,这些工具经过组合可以完成任何复杂的机械工作。完全从头开发这套工具箱,工程浩大,靠业余的编程爱好者是很难完成的。但是我们应该吸取 Unix“ 小而灵活 ” 的哲学思想,在一个大的框架下面开发或者利用已经存在的开源工具软件制造出一个个灵活的部件。当把这些部件组合起来以后,就是一个功能完整、质量可靠的性能测试工具箱。

【摘要】本文主要对软件测试的和第三方测试的调查结果进行系统分析,得出一些软件测试外包市场相关的结论,提供给业内人士参考。

【关键字】软件测试、 外包、 第三方测试

• 软件测试现状

软件测试包括测试技术、测试方法和测试管理。软件测试是软件质量的核心。

对信息化依赖程度不断加深的社会,必然会对软件质量提出全方位的要求---安全、稳定可靠、方便灵活。软件测试正是控制软件产品质量的重要手段, 控制软件产品质量的重要手段就是通过权威机构的软件测试。国外软件厂商极为重视软件测试。为打造windows2000,微软用了250多个项目经理、1700多个开发人员,而测试人员则用了3200人!几乎是开发人员的两倍。而且,每修改一个错误,都要花费大量时间确保没有新错误产生。

目前,我国软件业的质量保证体系还很不完善。相比之下,在国外许多国家的软件公司,软件测试工作已经逐渐演变成一门独立的科学,囊括了配置方案,测试机制,跨平台策略和产品性能,稳定性等独立区域的知识模块。

长期以来,我国软件企业产品开发时,测试成本却常常是最容易被压缩,甚至被完全“砍”掉。这导致我国软件产品质量低下,无法创出自己品牌,走向世界。在国际上,开发成本中的30-50%用于软件测试。而国内有的开发成本远远达不到这个百分比。上海市计算机软件评测重点实验室的评测报告显示,在2002到2003年评测的560多项软件产品中,一半以上的软件文档质量不规范。与此同时,只是有少数的软件企业设立了专门的测试部门。因此,在当前不断加深于对外合作的环境下,除了优秀的软件开发团队,具备良好的软件测试环境也是软件市场与国际接轨的必不可少的重要部分。

目前国内的软件测试一般有下列几种形式:

  1. 软件公司内部的功能性测试,目的是检查设计的功能能否完成;在软件开发管理规范的软件公司,软件测试比较全面规范,质量工作可以说完成的比较好。在软件开发管理比较薄弱的公司,测试是由开发人员或者抽调同公司别的部门的人员进行的。或者干脆不做测试。
  2. 用户测试,大量的用户一起寻找使用中遇到的错误。发现的问题多集中在用户使用方面,及可用性方面问题。用户测试,因为用户没有系统的计算机知识,对产品的测试结果也只是片面的,不能全面对软件产品进行评价。
  3. 第三方测试,就是运用专业软件测试管理机制,专业的测试人员运用一定的测试方法、工具对软件的质量进行全面检测。其形式更多的为:软件本地化企业组织测试人员到大型软件公司的软件开发现场进行测试。这是大多数软件本地化企业不愿意接受却又实际采用的模式,主要是因为软件开发商保证新项目信息保密安全,便于监控软件测试的进度和质量。
  4. 据介绍,国际上软件开发人员与测试人员的比例大都在1∶1,软件测试收入占软件总产值的20%,而国内软件产业尚未形成这种状态。截至2002年底,软件企业中通过ISO9000认证的企业仅占总数的7.5%。不过令人高兴的是,国内大中型软件企业开始认识到软件质量的重要性。很多企业已经配备质量保证体系,以及企业内部的测试队伍。

目前,国内已拥有的第三方测试机构很少。但在软件业较发达国家,绝大多数的软件产品的认定,都需要第三方测试的介入,软件测试行业产值几乎占了软件行业总产值的1/4。与之相比,国内的软件测试行业实在微乎其微。空白同时意味着机遇,潜力也许就在其中。

市场调查数据

那么在目前的情况下,国内软件企业对软件测试的重视程度和对软件第三方测试认知程度又是什么样的呢?

笔者在最近的几个月时间里,通过网络对目前的软件测试和第三方测试服务的现状做了相关的调查。通过反馈回来的数据我们可以看到国内目前的现状。

• 调查内容

在本次调查中,调查的问题包括:

  1. 公司规模:a、10人以内;b、10~50人;c、50~100人;d、100以上。
  2. 开发队伍人数:a、10人以内;b、10~50人;c、50~100人;d、100以上。
  3. 是否有测试人员:a、是;b、否。
  4. 测试队伍人数:a、0;b、10人以内;c、10~50人;d、50~100人。
  5. 公司对采用测试过程后,感觉是:a、很好,软件产品质量有很大提高;b、一般,没什么太大变化;c、很糟糕,还不如不测试;d、从没有测试过,不了解。
  6. 是否听说过测试外包服务:a、是;b、否。
  7. 贵公司是否需要测试外包服务:a、是;b、否。
  8. 如果需要测试外包服务,您希望的方式是:a、服务方全部负责测试全过程;b、协助本公司完成部分测试工作既可;c、其它(请说明)。
  9. 是否有完善的测试管理机制:a、是;b、否。

• 调查目的

本次市场调查的主要目的

  1. 国内不同规模软件企业对软件测试的重视程度;
  2. 测试队伍和完善测试管理体系的普及率;
  3. 国内不同规模软件企业对软件测试外包服务方面信息的了解程度,和企业是否愿意接受软件测试外包服务的情况;

• 调查数据图表

1)公司规模(图见下页)

  

2) 开发队伍现状

  

3) 公司是否有测试人员

  

4) 测试队伍现状

  

5) 公司采用测试后对测试的感受

  

6) 是否听说过外包测试服务

  

7) 外包服务需求

  

8) 外包服务需求形式

  

9) 是否有完善的管理机制

  

10) 不同规模公司的外包测试需求

  

11) 不同规模公司的外包测试形式

  

12) 不同规模公司对测试的感受

在本次调查中,来自全国各地的130多家软件企业参与了调查。其中员工人数在100人以上的软件企业在这次调查中数量最多,占57%左右。其次是员工人数在150人以下的小型软件企业,占25%左右。

通过网上的调查数据表明,目前国人的软件企业有近91%左右已经配备了测试队伍,更多的企业通过软件测试来提高自身的软件产品质量。总体上,认为通过测试后软件质量得到很好提高的占69%左右,认为一般的占22%左右。在不同规模的软件企业对软件在测试后质量提高的认同比率都是非常高的,认为软件测试后对软件质量提高作用甚微的比率很小不足1%。但我们还看到。在调查的所有企业中仍有近8%左右企业根本没有对软件产品进行过测试。在所有的调查企业中,即便是在软件开发过程中通过软件测试方式来提高软件产品质量,但对于测试过程的控制还是重视不够。在测试管理方面具有完善的管理机制的仅占15%左右。这个比例还是比较低。

外包测试服务的调查数据表明,在国内,外包测试服务的概念已经广泛的流传,也被许多企业熟识,有近85%左右的调查企业了解外包测试。但是,虽然很多企业了解外包测试的形式,但愿意采用外包测试服务的企业并不多,仅占25%左右。在愿意采用外包测试服务的公司中,从公司规模上看,10人以下的软件企业愿意采用外包测试服务的需求最高。其次100人以上的软件企业比例稍大一些,约占30%左右。

在所有的调查企业中,假设采用外包测试服务的前提下,采用“协助本公司完成部分测试工作既可”这种形式的最多,占64%左右。而同意采用“服务方全部负责测试全过程”仅占26%左右。对于不同规模的软件企业普遍认同采用“协助本公司完成部分测试工作既可”这种形式,调查数据显示的百分比都超过60%。该形式成为软件企业不愿意接受却又实际采用的模式,出现这种现象的原因是因为软件开发商保证项目信息保密安全,便于监控软件测试的进度和质量。

通过调查数据显示,国内软件企业已经逐渐重视软件测试在开发中的重要地位。但是因为处于发展阶段,在质量控制方面并没有找到很好的途径,有的还处于摸索阶段。很多企业没有很好的相应管理模式。在质量保证的实施方面,还处于“自力更生”阶段。对采用外包服务的模式,还没有被广泛的接受。

• 现状分析

•  软件质量保证

在软件开发过程中,测试应占有很重要的地位。但为什么在实际的软件开发过程中测试的成本被压缩呢?根据国内目前的现状,分析原因有以下几点:

  1. 国内软件用户(企业)对计算机使用率普遍低,即使在计算机设备比较普及的企业中,员工对计算机的了解大多数处于初级阶段,对软件测试的认识更少。
  2. 计算机使用的范围受限,必然限制软件的推广使用,用户对于软件质量的认同标准不高,普遍认为能够使用即可,出了些问题也可以接受。正是由于客户的这种心理,使得软件开发企业敢于压缩测试成本。
  3. 软件企业规模小,软件开发过程不完整。重开发,轻测试。有的软件公司根本没有测试队伍。
  4. 软件企业在压缩测试成本的同时,对开发相关的支持文档也不重视。这为企业的发展带来很多不利的影响。
  5. 软件企业对软件质量要求的认同存在差距,同时也缺乏有效的改善措施。有些软件企业,即使有测试队伍,但缺乏有效的测试管理,使得企业内部的测试工作效率低下。
  6. 某些企业因为受到资源的限制,虽然想提高软件质量,但由于缺乏资金、人员等方面的资源,没有能力去做质量管理方面的工作。
  7. 软件质量保证工作需要相关的人力资源、硬件资源、管理体系、软件测试工具等。

虽然,目前很多软件企业都配备了专门的质量保证部门或软件测试队伍,但软件测试的重要性还没有得到普遍的认同。但随着软件企业和软件用户群的质量意识不断提高,用户对软件测试服务的需求增大。提供软件测试服务还是有比较大的前景和市场。

•  测试服务

目前,在国际上软件业较发达的国家,绝大多数的软件产品的认定,都需要第三方测试的介入,软件测试行业产值几乎占了软件行业总产值的1/4。而国内在测试服务方面,软件测试服务的还处于起步和摸索阶段。专业的第三方测试机构还非常少。通过借助第三方测试完成软件开发的企业更少。

第三方测试机构都希望通过拓展市场,来扩大自己的生存空间。虽然,国内的测试服务市场还不够成熟,但在未来测试服务市场肯定会有很大的发展空间。在目前还存在以下的问题:

  1. 软件测试服务的对象不清晰。
  2. 如何提高客户对软件测试服务的需求。
  3. 如何提高测试机构的业务和技术水平?
  4. 软件测试服务应该包括那些具体的内容?
  5. 第三方测试机构服务与软件公司的内部测试相比,有哪些优势?

• 期待解决的问题

针对目前在测试服务方面存在的一些问题,笔者认为认清以上面提到的几个问题。

•  软件测试服务客户

软件测试服务的发展要依托于广大的客户群。那么,哪些客户应成为软件测试服务的对象呢?目前,针对国内软件的发展状况,软件测试服务的客户主要有以下几种:

  1)大型的软件企业。

这种类型企业有着规范的软件开发过程控制,深知软件质量的重要性。在软件开发中,比较重视软件测试这个阶段,肯于花费必要的资源、资金去做质量保证工作。在这样的企业中,有专门的质量保证部门,在各开发部同时存在一定数量的测试人员。同时有着良好的过程管理模式。在测试方面它们会采取两种方式:自己的内部测试;外包给其它测试机构。

  2) 中型软件企业。

中小型软件企业类型中,企业的种类比较复杂。归纳下来有以下几种:

软件开发过程比较规范。具有完善的过程管理机制,组织部门齐全。

软件开发过程规范,公司有专门的测试队伍,但缺乏合理的测试管理。

软件开发过程不规范,公司没有专门的测试队伍,测试是由开发人员或者抽调同公司别的部门的人员进行的。或者干脆不做测试。

  3) 小型软件企业。

由于企业规模小,企业组织结构不完整。这样的企业基本上没有转门的测试队伍,更没有完善的测试管理机制。

企业级的软件最终使用用户。

在我国,大中型企业普及管理信息化是必然趋势。在这类企业中,各种用于企业管理的软件产品或项目数量都非常巨大。但由于这类企业没有专业的计算机质量保证人员,无法有效的验收软件产品或项目。

根据调查数据显示,目前软件测试服务的客户主要集中是大中型软件企业。而主要的合作形式为:协助本软件企业完成部分测试工作。为在质量管理薄弱的企业提供优秀的管理模式也存在很大的市场,主要客户集中在中小型软件企业。同时企业级的软件最终使用用户也是软件测试服务的重要群体。

•  唤起客户的质量意识

随着计算机使用的普及,各行各业对计算机使用的不断提高,企业对员工的计算机水平的要求也不断提高。这样,势必会不断提高软件使用企业对软件产品的质量要求。同时,由于软件使用企业在过去的软件项目实施时,对项目验收把关不严格。在后来的使用过程中发现质量不高的软件产品为企业管理带来诸多不便。在某些行业里,因为软件的错误给企业带来的损失是巨大的。这些原因都使得软件使用企业对软件质量的要求发生变化,对软件产品的质量要求越来越高。

对于软件企业,越来越认识到软件产品的质量是企业的生命线。软件产品质量不能得到保证,会造成软件项目的失败,企业失去客户的信任,给企业带来巨大的经济损失。

软件企业和软件用户双方都对软件质量提出了高的要求。软件测试服务在这样的环境下,有着很大的发展空间和很多的商业机遇。作为软件测试服务机构应该抓住这个良好的发展机会,大力推广软件测试服务业务。

近年来,国内的软件行业内一直提倡中国的软件靠出口来发展自己。希望通过获得更多的软件外包项目来扩展生存空间。但现实的问题是,中国技术整体水平不高,软件外包讲究的是,低成本和高质量,管理比技术重要得多,而国内软件开发管理与国际先进水平相比还有一定差距。外包对软件企业管理水平、维护能力,以及商务、法律的国际接轨都有相当的要求。而我国软件企业相对松散,质量管理也处于弱势,很多还是作坊式的研发。质量管理的薄弱,使得国内的软件行业难有很强的竞争优势。现实也要求国内的软件行必须提高质量意识。

作为软件测试服务机构要广泛宣传软件质量的重要性,唤起客户的质量意思。同时提高自身业务素质和技术水平。

•  软件测试服务结构

为了更好的服务于客户,软件测试服务结构应具有完善的管理机制;一流的计算机硬件设备;先进的软件测试工具、测试方法和测试管理体系;众多优秀的技术人材。具有丰富的软件产品项目经验,建立常见应用管理软件的测试用例库,提高软件测试的复用性,提高质量和效率。

•  软件测试服务内容

软件测试服务机构的业务包括以下几方面:

  1. 为软件企业提供第三方测试服务。
  2. 为软件企业提供优秀的质量管理模式。包括:ISO、CMM、CMMMI、SJ/T11234、SJ/T11235和测试管理模式。
  3. 质量管理的咨询服务。
  4. 为软件企业提供多种的测试服务:登记测试、鉴定测试、质量测试、验收测试、系统功能测试、安全测试和性能测试等。
  5. 为软件使用企业提供软件项目的验收测试服务。

•  软件测试服务的优势

专业软件测试机构具有成熟的测试流程和测试方法。可以为软件企业节约成本,包括人力资源成本和购买测试工具等。另外,专业软件测试机构专门从事测试工作,在软件测试方面具有很多知识和经验等方面的积累,更利于挖掘更多软件中的缺陷,避免思维定式。为质量管理薄弱的软件企业提供优秀的管理模式。同时为软件使用企业提供良好的技术支持。

• 小结

软件测试在国内的发展过程,同样会反映在第三方测试服务上。虽然还存在很多的问题,但软件测试和第三方测试服务将成为具有广阔发展前景的领域。软件测试和第三方测试服务的兴起意味着更多的机会。通过提供软件测试服务,国内软件本地化企业可以扩展服务业务范围,扩大企业发展规模,完善企业管理等。

【摘要】测试是软件开发的一个重要环节。本文论述了软件测试自动化测试的实施。从自动测试的好处. 影响软件测试自动化实施的因素产生原因等几个方面出发.总结软件自动化测试的方案。

【关键字】软件测试  软件自动化测试

软件测试自动化,已经成为国内软件工程领域一个众所周知的课题;不言而喻,软件测试从业者都意识到软件测试这项工作走向成熟化、标准化的一个必经之路就是要实施自动化测试。也许您认为实施自动化测试不是必须,也许您认为测试的思想是开展该工作的精髓、而工具只是辅助,那么我要告诉你我的想法:从计算机这一庞大学科发展至今,它最根本的意义是解决人类手工劳动的复杂性,成为替代人类某些重复性行为模式的最佳工具;我们不可推翻测试思维在测试工作中的指导思想地位,但如何将思想转化成可操作的方案,本文也许会给您一些启示。

以前听过北京中软的一个业内专家讲一句话,觉得挺经典:凡是说既是科学又是艺术的学科,就是说明它是不成熟的学科!他将软件工程和建筑行业做类比,让我们深深体会到软件工程走向成熟化的任重与道远。而软件测试,更是一个新兴的领域,虽然近几年得到了快速发展,也随着该领域从业者数量的与日俱增,培养了一批高级的人才;但是依然有多少企业和个人工作在迷茫中:这种困惑是因为工程师们手中的测试工作与理想的测试模式造成的强烈反差,这种无奈是因为他们和开发人员一样的努力却有不同的待遇,这种迷茫是因为测试工作者不知道这个领域里是否还有自己的发展空间和人生价值的体现!笔者认为:如今的软件测试行情,正处在群雄逐鹿的混战岁月,每个人、每个有测试部门或从事测试业务的企业,都该发扬百花齐放、百家争鸣的精神,多多借鉴国内外先进的测试经验,参考业界流行的行业标准,找到适合自己团队的测试方法和模式,创造更大的社会价值,发挥更大的人生价值。

• 实施软件测试自动化的理由分析

首先,测试人员的工作比以往任何时候都更加困难,因为公司和组织希望以更快的速度和更低的成本开发出高质量的应用程序。

此外,在很多项目中,测试人员的所有任务实际上都是手动处理的,而实际上,有很大一部分重复性强的测试工作,是可以独立开来自动实现的。

还有,在大型项目中测试团队和其他的团队之间没有足够的合作,无法促进彼此的工作。

最后,从个人角度来说,测试人员通常很难花费大量时间来学习新技能;这是目前国内测试从业者的现状,太多的企业为了节约成本而将刚刚走出校门的毕业生作为测试工程师,他们每日做着繁忙的重复工作,又基于自身技能的不深,虽怀博览群书的心愿却不知从何出入手。所谓光阴似箭,因为一转眼我们就说到未来的5年、10年后,我们这些技能不深的测试工程师能做什么呢?而软件测试自动化,也是未来测试工程师或即将成为测试工程一项强有力的工作技能。

可以说,实施测试自动化是软件行业一个不可逆转的趋势,如果在这个领域走在了前列,无论从企业的核心竞争力还是个人的工作技能来说,都有巨大的优越性,而国内众多的软件厂商也的确在纷至沓来的着手开展着这项工作。

• 当然国内软件测试自动化实施现状分析

随着众多具有了一定优秀实施自动化测试经验的企业陆续出现,也伴随着很多组织对这项工作依然是丈二的和尚-摸不着头脑。对当前国内软件企业实施或有意向实施测试自动化时面临的主要问题,按实施的不同层次来说:

——干脆认为测试自动化是个遥不可及的事情,我们这样的小公司不必实施,人员、资金、资源都不足,以后再说吧!

——热血沸腾的实施测试自动化,购买了工具,推行了新的测试流程;几个月后,工具放在那里成了共享资源,测试流程又涛声依旧,回到原来的模式。

——公司实施了自动化测试;然而开发与测试之间,甚至与项目经理之间矛盾重重,出了事情不知如何追究责任;虽然还在勉强维持的自动化测试,但实施的成本比手工测试增加了,工作量比从前更大了,从而造成项目团队人员怨声载道,更怀念起那段手工测试的悠闲岁月,唉!那一场风花雪月的事,既然要结束又何必开始…

——自动化测试实施相对比较成功,但或多或少还有些问题,比如工具选择不准确,培训不到位,文档不完备,人员分配不合理,脚本可维护度不高等等,造成一种表面上的自动化测试流程,是一幅空架子,如同山间竹笋,嘴尖皮厚腹中空。

• 国内软件测试自动化实施不成功原因分析

——公司高层意识不到软件测试自动化的重要性;殊不知,其他竞争对手们都大张旗鼓的开展这方面研究和策划的时候,自己还对此持漠视态度,等到整个行业都提高到一个新的层次,那时再着手做,可能就是热锅上的蚂蚁了。

——所谓凡事预则立,不预则废。一个软件企业实施测试自动化,绝对不是拍脑袋说干就能干好的,它不仅涉及测试工作本身流程上、组织结构上的调整与改进,甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。

——软件开发是团队工作,在这一领域要尤其注重以人为本;所以人员之间的配合、测试组织结构的设置非常重要,每个角色一定要将自己的责任完全担负起来,这也是减少和解决前述团队矛盾的必要手段。

——对开展自动化测试的监督和评估相当重要,也包括对工作产品的检查和人员的考核。一定要将自动化测试全面深入的贯彻到测试工作中,不能敷衍了事,不能做表面工作。这项工作在CMM三级里规范的很好,只可惜我们的很多公司对CMM真的只是“过级”!

•  正确认识国内未实施软件测试自动化的根源

目前国内的软件公司,很多还是处于获取资本的原始积累阶段,我们不能说公司领导完全不重视测试,而是测试整体行业都没有被重视起来,这是其一;其二是公司高层有更需要重视的环节,例如寻找客户签订单,或者开发,这些是直接关系公司存亡的命脉性东西。

即便企业重视测试,如果公司做一番比较全面的评估(在后续的测试自动化引入入条件里,再详细说明),也不一定非要实施自动化测试。笔者认为一些中小软件公司在大刀阔斧推行自动化测试之前,在测试流程管理、测试缺陷流程、测试人员技能培训等方面做工作,这样可以用比较少的成本投入来获取相对较大且长期的收益回报。

最后,针对普通测试工程师的一些建议,在这样的公司里,其实有着很多意想不到的优越性:

(一)这样的公司测试如果不正规,那么你就有更大更多的发挥空间。

(二)你可以单独学习自动化测试技术,自己先试着应用到日常工作的软件项目中。

(三)你可以直接和开发人员沟通,甚至向他们学习开发技术,这对将来的自动化测试中开发脚本很有好处。

(四)每个优秀测试工程师的成长都是个循序渐进的过程。我遇到很多测试界的新手向我发牢骚,很惭愧我没有什么可以告诫他们的,只是希望这样的新人克服浮躁情绪,稳扎稳打练好基本功,想成为优秀的测试专家,就要经历这个阶段。

• 软件测试自动化的引入条件

如果你的测试部门有意向引入自动化测试,那么首先要从思想上统一认识。

自动化测试能大大降低手工测试工作,但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标,实际上想要达到 100% 的自动化测试,不仅代价相当昂贵,而且操作上也是几乎不可能实现。一般来说,一个 40-60% 的利用自动化的程度已经是非常好的了,达到这个级别以上将过大的增加测试相关的维护成本。

测试自动化的引入有一定的标准,要经过综合的评估,绝对不能理解成测试工具简单的录制与回放过程。实际上,从实现成熟度来说,自动化测试分五个级别:

级别
说明
优点
缺点
用法
一级
录制和回放自动化的测试脚本能够被自动的生成,而不需要有任何的编程知识拥有大量的测试脚本,当需求和应用发生变化时相应的测试脚本也必须被重新录制当测试的系统不会发生变化时,实现小规模的自动化
二级
录制、编辑和回放减少脚本的数量和维护的工作需要一定的编程知识;频繁的变化难于维护回归测试时,用于被测试的应用有很小的变化
三级
编程和回放确定了测试脚本的设计,在项目的早期就可以开始自动化的测试要求测试人员具有很好的软件技能,包括设计、开发大规模的测试套件被开发、执行和维护的专业自动化测试
四级
数据驱动的测试能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据软件开发的技能是基础,并且需要访问相关的测试数据大规模的测试套件被开发、执行和维护的专业自动化测试
五级
使用动作词的测试自动化测试用例的设计被从测试工具中分离了出来需要一个具有工具技能和开发技能的测试团队专业的测试自动化将技能的使用最优化的结合起来

自动化测试能提高测试效率,快速定位测试软件各版本中的功能与性能缺陷,但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑,要求测试设计者将测试中各种分支路径的校验点进行定制;没有定制完整,即便事实上出错的地方,测试工具也不会发觉。因此,制订全面、系统的测试设计工作是相当重要的。

自动化测试能提高测试效率,但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大,将企业级自动化测试框架应用到一个项目中也要评估其合适性,因此决不能盲目的的应用到任何一个测试项目中,尤其不适合周期短的项目,因为很可能需要大量的测试框架的准备和实施而会被拖跨。

实施测试自动化必须进行多方面的培训,包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的,引入自动化测试只会给软件组织或者项目团队带来更大的混乱;如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化测试,那将肯定会以失败告终。

如果软件企业有意向实施自动化测试,那么应该具备什么样的条件才可以引入自动化测试呢,才可以最大可能的减少引入风险,并能够可持续性的开展下去呢?

•  对企业自身现状的评估分析

第一,从企业规模上来说,没有严格限制。无论公司大小,都需要提高测试效率,希望测试工作标准化,测试流程正规化,测试代码重用化。所以第一要做到的,就是企业从高层CTO开始,直到测试部门的任何一个普通工程师,都要树立实施自动化测试的坚定决心,不能抱着试试看的态度。一般来说,一个这样的软件开发团队可以优先开展自动化测试工作:测试-开发人员比例合适,比如1:1到1:1.5;开发团队总人数不少于10个。当然,如果你的公司只有三五个测试人员,要实施自动化测试绝非易事;不过可以先让一个、两个测试带头人首先试着开展这个工作,不断总结、不断提高,并和层层上司经常汇报工作的开展情况,再最终决定是否全面推行此事。

第二,从公司的产品特征来说,一般开发产品的公司实施自动化测试要比开发项目的公司要优越些。原因很简单,就是测试维护成本和风险都小。产品软件开发周期长,需求相对稳定,测试人员可以有比较充裕的时间去设计测试方案和开发测试脚本;而项目软件面向单客户,需求难以一次性统一,变更频繁,对开发、维护测试脚本危害很大,出现问题时一般都以开发代码为主,很难照顾到测试代码。但决不是说做项目软件的公司不能实施自动化测试,当前国内做项目的软件公司居多,有很多正在推行CMM等级标准,这是好事情;只要软件的开发流程、测试流程、缺陷管理流程规范了,推行自动化测试自然水到渠成。

第三,说说标准化的开发和管理流程。不管是CMM还是ISO,不管是开发流程、测试流程还是缺陷管理流程,这里不能一一阐述,可以参考RUP(Rational Unified Process, Rational 统一过程),可以参考很多业界文献,我只说明一点,也是我们IT从业人员甚至任何从业人员一个很好的工作原则:

  1. 把你想做的写下来(计划管理)
  2. 按照你写下来的去做(行为管理)
  3. 把做的事情记录下来(报告管理)
  4. 出现的问题要设法解决(跟踪管理)

在测试流程里,这几个要点都一一有所落实;如果你的软件开发团队据此开发软件,那么完全具备实施自动化测试的条件。当然,也许一些公司的测试管理比较混乱,出了问题不知道谁负责,测试人员或开发人员整日碌碌却无为,软件缺陷不胜枚举,那么笔者认为还是首先从管理角度来规范一下公司的开发流程和测试流程吧!

第四,从测试人员个人素质和角色分配来说,除了有一个CTO级人物做后盾外,还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管,不仅在技术方面,更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员,当然也可以是开发工程师,负责编写测试脚本、开发测试框架;他们不需要对产品业务了解深刻,但要具有将软件业务逻辑转化成可测试逻辑的分析能力,属于自动化测试设计者。还有一些测试执行者,他们要对软件产品业务逻辑相当熟练,配合测试设计者完成设计工作,并在执行自动测试时,敏锐的分析和判断软件缺陷。如果你的测试团队具有这样的人员角色雏形,那么具备了实施自动化测试的又一条件。

综合分析上述四个条件,企业可以决定是否推行自动化测试;但是为了减少实施风险,我们还要预测到其他潜在的风险,做好事先解决思路。

•  对企业推行自动化测试的风险分析

其一是资金风险。虽然你的公司具备实施自动化测试的条件,但如果企业效益不好,还是先扭亏为盈吧。一款正版的测试工具价格庞大,企业要首先考虑资金是否允许购买正版的测试工具软件,所以进行测试工具的成本估算,以及引入自动化测试后组织结构调整等方面的成本估算是很必要的。如果你的公司处在如同前面所言的自动化测试试验阶段,可以使用试用版测试工具。当然具有实力的公司可以按照自身的工作流程自主开发测试工具,本文不考虑这种情况。

其二是自动化测试对软件功能类型的切入点的风险。企业开发的产品业务和功能是否需要自动化测试,包括白盒自动化测试、功能自动化测试和性能自动化测试。比如一些公司开发单机版软件,只需要做功能测试,那便不必考虑第三种;有的公司开发简单界面之类的软件,例如搜索引擎,也可不必考虑第二种;而大多数国内公司开发的软件,由于各种原因,一般都不考虑第一种。也有可能公司开发的软件特殊性很强,市场上根本没有支持它的自动化测试工具,此时要另辟蹊径。这种评估相当重要,要根据自身的产品功能特征来综合评估。针对不同阶段采用自动化测试的种种优势,我引用一个表格供读者参考:

测试阶段
描       述
备    注
单元测试/组件测试
这个测试工作通常是开发人员的职责,很多不同的方法能够被使用,比如"测试先行",它是一个测试框架,开发人员在编写代码前编写不同的单元测试,当测试通过时,代码也被完成了。通过使用正式的单元测试,不仅能够帮助开发人员产出更加稳定的代码,而且能够是软件的整体质量更加的好。
集成测试
这里的测试工作集中在验证不同的组件之间的集成上。这种类型的测试通常是被测试系统的更加复杂测试的基础,大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试
这种测试是通过执行用户场景模拟真实用户使用系统,以证明系统具有被期望的功能。这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的,因为系统的环境是恒定不变的。
其它两种非常重要的测试
回归测试
回归测试实际上是重复已经存在的测试,通常如果是手工完成的化,这种测试只在项目的结尾执行执行一到两次。这里完全有潜力应用自动化的测试,你能够在每次构建完成后执行自动化的回归测试,以验证被测试系统的改变是否影响了系统的其他功能。
性能测试
性能测试包括以下不同测试形式:
- 负载测试
- 压力测试
- 并发测试
-.....
如果没有自动化的测试工具,你将不能执行通过模拟用户的负载实现的高密集度的性能测试。

其三是软件自动化测试切入方式的风险。正如前面所言,一定要记住将自动化测试与手工测试结合起来使用,不合理的规划会造成工作事倍功半。首先,对于自动化测试率的目标是 10/90 (10% 的自动化测试和 90% 的手工测试)。当这些目标都实现了,可以将自动化测试的使用率提高。对于何种测试情况下引入自动化测试,何时依然采用手工测试,我们分开阐述。

一般这样的测试条件下使用自动化测试:

  1. 项目没有严格的时间压力
  2. 具有良好定义的测试策略和测试计划(知道要测试什么,知道什么时候测试)
  3. 对于自动化测试你拥有一个能够被识别的测试框架和候选者
  4. 能够确保多个测试运行的构建策略
  5. 多平台环境需要被测试
  6. 拥有运行测试的硬件
  7. 拥有关注在自动化过程上的资源

如下条件下是宜采用手工测试:

  1. 没有标准的测试过程
  2. 没有一个测试什么、什么时候测试的清晰的蓝图
  3. 在一个项目中,你是一个新人,并且还不是完全的理解方案的功能性和或者设计
  4. 你或者整个项目在时间的压力下
  5. 在团队中没有资源或者具有自动化测试技能的人
  6. 没有硬件

其四是企业软件的开发语言风险。当前业界流行的测试工具有几十种,相同功能的测试工具所支持的环境和语言各不相同,这里笔者总结了当前国际上流行的几个软件测试工具生产厂商及一些主要IDE产品,读者可根据参考网址去了解列举工具和更多工具的详细资料。

生产厂商
工具名称
测试功能简介
         
网址链接

Mercury

Interactive

Corporation

winrunner功能测试

    http://www.mercury.com/us/products/

        
Loadrunner性能测试
QuickTest Pro功能测试
Astra LoadTest性能测试
testdirector测试管理

IBM

Rational

Rational robot功能测试和性能测试

   http://www-900.ibm.com/cn/software/rational/

                      
products/index.shtml
Rational xde tester功能测试
Rational testmanager测试管理
Rational purifyplus白盒测试
compuware corporationQARun功能测试    http://www.compuware.com/products/
QALoad性能测试
QADirecto测试管理
DevPartner  Studio Professional Edition白盒测试
Segue softwareSilkTest功能测试    http://www.segue.com/products/index.asp
SilkPerformer性能测试
SilkCentral  Test/Issue Manager测试管理
Empirixe-Tester功能测试

    http://www.empirix.com/Empirix

    /Web+Test+Monitoring/T

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017