结合使用 Shell 和 STAX 实现 UAT 测试的自动化
 

2009-03-19 作者:乌 晓峰,肖 慧彬,李 夏安 来源:IBM

 
本文内容包括:
文章分析了 UAT 的特性以及在 UAT 中实现测试自动化的重要性,进而提出了一个结合应用 Shell 脚本和 STAX 语言实现的从自动化下载 Build, 安装, 执行测试用例, 生成测试报告的自动化解决方案, 对其中每一个部分进行了具体的分析和实现。

UAT与测试自动化

UAT 全称为 User Acceptance Test, 即用户可接受测试,是IBM产品开发周期的重要一环,

处于产品的构造和功能性测试之间,其目的是验证每天的构造(daily build)的可接受性,即能否在这个 build 上进行后续的功能性测试。由于 UAT 是测试环节的首要步骤,能够尽快给开发人员提供测试结果,所以不管采用传统的软件开发模型,还是使用今天被广泛接受的敏捷开发模式,UAT 在产品开发周期中所扮演的角色均非常重要。

传统的 UAT 测试基本都是人工完成的,如产品的安装,基本的配置,针对各个模块的功能执行测试用例等等。这种人工的测试方法会有很多问题。首先就是会存在大量的重复性劳动。在目前的软件产品开发过程当中,迭代式开发很常见。开发人员很可能会将已经完成部分功能的软件产品交付测试人员测试,而在测试人员测试的过程中根据测试人员的反馈或者用户需求的改变不断完善产品。这样一来一天可能会有3到5个版本的安装文件产生,而测试人员需要针对每个版本的安装文件执行 UAT 一系列操作,也就是说同样的测试步骤可能要被重复执行3到 5次;其次就是对于大型项目而言,UAT 操作很耗费时间,一次UAT测试的时间可能从 2,3 个小时到 7,8 个小时,每天需要多种平台和多重类型的 build,重复性的操作对测试人员来说是个很大的负担。

将 UAT 自动化,一方面无人职守的全自动化测试方案会使得 UAT 测试提供 24*7 的服务成为可能,自动检测 build 的状态,下载并进行安装、配置,执行测试用例, 最后生成测试报告,减少了等待时间,加速了产品的测试过程,缩短了开发周期。另一方面,自动化程度的提高解放了测试人员,使得UAT测试人员可以有更多的时间进行一些提高测试覆盖率,准确性方面的工作,更好的保证了测试质量。本文针对 UAT 的特点,提出了结合使用 Shell Script 和 STAF/STAX 的 UAT 自动化测试解决方案,具有简便、轻量级、开发周期短、灵活性好等特点。结合 shell 脚本对 STAX 任务进行触发并且设计一系列的调度机制使得自动化系统可以对资源进行合理调配,从而使得无人值守的全自动化测试成为可能。另外通过该方案的实施,能够提高软件测试环节中的自动化程度和测试用例的可复用程度,很大程度上提高了测试效率,缩短了测试周期。本文提出并分析了一个一般化的用户可接受性测试包含的各个部分,提出的自动化解决方案适用于所有 web-based 的产品的下载、安装部署、配置、功能测试。作为例子,文中将使用通过此方案在 IBM WebSphere Portal 产品的 UAT 测试当中的应用来对此方案进行分析。

为什么采用 STAF/STAX

STAF(Software Testing Automation Framework)是开源的自动化测试框架,封装了不同平台和不同语言间通信的复杂性,提供了消息、互斥、同步、日志等可复用的服务,使用户可以在此基础上构建自动化测试解决方案。STAX(STAF Execution Engine)是运行在 STAF 之上的可解析、执行 XML 格式任务的一种服务。STAF提供了两种服务,一种是内部服务(Internal Service),即它在内部封装了一系列的常用服务供用户使用, 包括时间操作,文件系统操作,变量操作等;另外一种是外部服务(External Service),STAX 本身就是 STAF 的一种外部服务,可以通过 STAX 规定的 XML 格式来编写 STAX 脚本,实现测试人员的测试步骤。

STAX 与传统的测试脚本,如 Perl,Shell 等,相比较,存在以下优点:

  • STAX 通过 STAF 的支持,能够轻松实现与其他测试机通讯的问题,对用户来说,通讯过程是完全透明的;
  • STAF 本身具有跨平台的特性,可以拓展到不同的平台,而且STAF可以根据测试机的操作系统类型来定义一些在 STAX 脚本当中需要用到的变量,如文件路径分隔符(File Separator)等,这对用户来说十分方便;
  • STAX 脚本具有非常好的兼容性,完全可以在 STAX 脚本当中执行 shell 或者 bat 脚本;
  • STAX 脚本完全是基于 xml 格式的,脚本开发方便;
  • STAX 函数之间可以相互调用,因此能够更加灵活的实现函数的复用;

下面清单所示的代码片段说明了 STAX 任务的基本结构。

清单 1. STAXDemo.xml
 
<function name="listDir" scope="local">
<function-prolog>This function lists entries of specified directory on the target
 machine</function-prolog>
<function-list-args>
<function-required-arg name="target">Hostname/IP address of the target machine
</function-required-arg>
<function-required-arg name="targetDirectory">Target directory </function-required-arg>
</function-list-args>
<sequence>
  <script>cmd = 'LIST DIRECTORY %s' % (targetDirectory) </script>
  <!-- Run the staf list directory command using the supplied arguments -->
  <stafcmd>
    <location>target</location>
    <service>'FS'</service>
    <request>cmd</request>
  </stafcmd>
  <return>STAFResult</return>
</sequence>
</function>

根据上面的代码,我们可以大致看出 STAX 脚本的语法格式:

首先定义此功能模块的名字,在这里是“listDir”,相当于传统语言中的函数名。然后在<function-list-args>元素里面将脚本需要定义的参数列举出来,相当于传统编程语言中仅能够在函数内部使用的局部变量。如果下面还需要用到一些变量的时候,可以通过<script>元素来定义,如“cmd”变量,这里定义为:LIST DIRECTORY %s' % (targetDirectory),LIST DIRECOTRY 是STAF内部服务的一种,相当于DOS系统的dir命令或者linux系统的ls命令。“%s”是通配符,匹配的是后面括号当中的targetDirectory变量的内容,而targetDirectory是在<function-list-args>元素当中定义的。接下来有一个<stafcmd>元素,这个元素有三个子元素:<location><service><request>。其中location元素指的是这个服务应用的目标机器,service元素表示的是该服务的名称,这里“FS”,即File Service,而request元素指的是具体的服务命令字符串,这里是在前面定义过的变量cmd

基于 STAF/STAX 的 UAT 自动化测试解决方案

图 1. UAT 自动化测试解决方案的流程图
UAT 自动化测试解决方案的流程图

通常一个UAT的测试流程包括以下几个部分: 检测Build状态,下载Build,检测测试机状态,进行安装,进行配置,执行一些测试用例来验证各个部件的功能,生成测试报告。为了完全覆盖以上的这几个方面,基于STAF/STAX的UAT自动化测试解决方案主要包括以下几个步骤:

第一步,检测安装文件的状态

通常,对于一个成熟的软件产品,每天都会有一个或者多个版本的build。这些build一旦生成便会被上传到一台专门的服务器上。当生成过程结束之后,测试人员就可以下载这个版本的build进行测试,而UAT测试是整个测试流程的起点。因此,最节约时间的做法就是当文件刚刚生成结束之后就开始UAT测试,所以需要自动化的方法来不断检测build生成过程是否结束,一旦生成结束,就可以马上开始UAT操作。但是对于一个项目而言,UAT测试人员很难立即得到Build过程完成的信息,这有很多因素:

  • 对于合作开发和测试,Build Team和UAT team不一定在同一地理位置,可能处于不同的时区;
  • 对于大的项目,一次Build的时间可能会很长,从几小时甚至长到十几小时;
  • 对于复杂项目,一个Build成功与否存在着很大的不确定因素,经常会存在构建失败的情况;

因此, 测试人员人工来检测Build生成状态有很大的难度。Build Team通常提供一些对外的服务来发布Build的信息,比如维护一个HTTP Server或者FTP Server来让远程用户能直接通过这些服务来获得Build的目录结构以便于下载Build。在UAT的自动化方案中,就可以通过Shell脚本访问这些服务来获得Build的信息。比如对于如下的目录结构。

图 2. Build 目录结构示例
Build 目录结构示例

就可以使用如下的shell脚本来获得最新的Build的版本号:

清单 2. 使用 shell 脚本获取最新 Build 的版本号
 
while [ ! -s "./builds.html" ] 
do
  sleep $sleeptime
  #将所有Build所在的目录存成一个文件待用
  wget $Remote_realese_url -O ./builds.html" >> $LOG_BASEDIR/`date +%Y-%m-%d-%H`.log
done
#从保存的文件中提取最新的Build版本信息,这里使用AWK在文件中来获得最新版本信息
latestversion=`cat builds.html | awk -F"STARTPattern" '{print $2}' | awk -F"EndPattern"
'{print $1}' | grep $VERSIONPATTERN | sort | tail -1`
if [ ! -d "$BUILDS_DIR/$ latestversion " ]; then
#在本地创建当前Build版本的目录
mkdir $BUILDS_DIR/$ latestversion 
fi

第二步,使用 Shell 下载 Build 并开始触发后续 STAX 任务

服务器端 build 生成结束之后,接下来是 build 下载的过程,这部分可以和步骤一结合在一起,一旦检测到 build 正确生成,那么马上开始下载。Build 的下载可以使用shell脚本实时访问,根据 Build 服务器提供的不同服务接口使用不同的检测 build 并下载 build 的方式,常用的有 FTP 方式,HTTP 方式或者 HTTPS 方式。在判断Build存在,创建完相关的本地目录之后,对于一个 Build 需要的所有文件,可以使用相应的命令来进行下载。最简单的有 wget,ftp。 也可以写一些相对复杂的shell脚本加强下载的稳定性,可靠性和灵活性。

检测 Build 状态和下载 Build 都是由 Unix Shell 脚本执行的,而此后的测试机状态检测以及以后的安装都由 STAX 脚本来执行。那么怎样由 Unix shell 来执行 STAX 脚本呢,STAX 的事件机制使得它的任务可以由外部触发,这个触发的方法如下:

清单 3. 使用 shell 脚本促发自动化测试任务
 
#Trigger STAX event
echo "start"
while [ "$parameterFileNumber" != "0" ] 
do
echo "start a STAX event..." 
echo "kick off STAX event, file number is $parameterFileNumber"
let "parameterFileNumber=$parameterFileNumber-1"
STAF STAXServer.cn.ibm.com SEM POST EVENT "$eventName"
sleep 600
echo "a STAX event was triggered successfully!" 
done
echo "Kick off UAT finished!" 

第三步,检测测试机状态

对于一个成熟的企业及软件产品来说,测试环境往往比较复杂,而在测试环境的搭建过程当中任何一个小的问题都有可能导致测试的失败,这并不是软件本身的问题,所以在开始执行测试流程之前如何检测测试环境的正确性是十分重要的。针对这一环节,自动化解决方案如图:

图 3. 检测测试环境流程图
检测测试环境流程图
  • 首先,分别针对不同的测试环境制定测试任务。这些测试任务存放在一个单独的任务队列里面;
  • 当第二步下载build结束之后,马上检测任务队列里面是否有等待执行的任务,如果有的话,马上执行当前测试任务,这里利用STAF的跨平台性,可以将同一个测试任务针对不同的平台分成多个任务,并发执行;
  • 执行测试任务的第一步,就是检测目标测试机的环境及状态,通过 STAX 脚本在目标测试机上收集测试相关的环境信息,如操作系统的类型,版本,服务器,数据库的型号及版本等等;
  • 接下来是对收集到的环境信息加以判断,如果环境符合当前的测试要求,则继续执行下一步;否则生成错误日志,发送测试报告给测试人员,中断测试流程;
  • 测试环境的检测通过之后,则开始执行真正的测试任务;

第四步,安装软件

在 UAT 测试流程当中,当 build 下载过程结束,环境检测通过,接下来的就是软件产品的测试,也是整个测试流程一个真正意义上的“起点”,如果在接下来的测试过程中出现问题,很有可能就是产品本身的问题。

首先,就是软件的安装,一般软件的安装往往分为静默安装和图形界面安装,针对这两种不同的安装方式,自动化测试解决方案如下:

  1. 静默安装:
    1. 静默安装的第一步是准备一个安装过程中的响应文件(response file),这个文件包括了整个安装过程当中所有需要用到的参数,比如路径信息,安装组件的选择等等。在本方案中,这个响应文件是根据用户事先配置的参数通过 STAX 脚本自动生成的,而且用户可以在提交或者修订测试任务的时候灵活的对这个响应文件进行更改;
    2. 接下来,STAX 脚本会自动生成一个命令文件,根据操作系统的不同会分别生成 bat 文件或者 .sh 文件,命令文件的内容为执行安装过程需要的命令;
    3. 然后,执行刚刚生成的命令文件,并将安装过程中一些重要的信息记录在日志文件当中,这些日志文件是以后生成测试报告的重要依据;
    4. 在安装的过程中,STAX 任务会不间断的监测测试机的状态和软件安装的状态,一旦安装过程出现不可逆的异常或者错误,则马上中断测试流程,发送测试报告给测试人员;
  1. 图形界面安装:
    1. 因为STAF/STAX本身并不对任何图形界面的测试提供支持,所以,在执行图形界面安装的过程中首先需要采用其他的工具进行安装脚本的录制或者编写,可以采用的工具有IBM Rational Functional Tester, Auto It等。可以针对不同的环境分别录制多个安装脚本,然后分别存放,这样的好处就是在测试过程中可以根据测试目标机的环境灵活调用安装文件,而且如果环境没有大的改动,完全可以实现安装脚本的重复使用;
    2. 在自动化测试过程当中,首先由STAX脚本根据目标机的环境自动拷贝相应的安装脚本到测试机上,然后执行该安装脚本;
    3. 同静默安装一样,在安装流程开始之后,STAX任务会不间断的进行监控并及时处理出现的问题;

安装软件的STAX脚本片段如下:

清单 4. 安装WebSphere Portal的STAX脚本片断
 
<stax>
<function name="InstallWebSpherePortal">
<function-prolog>InstallWebSpherePortal</function-prolog>
<function-list-args>
</function-list-args>
<sequence>
<!-- Step 1. Mount build server -->
<call function="'mountBuildServer'">target, mountServer, 
remoteMountPoint, localMountPoint</call>
<!-- Step 2. Copy image and create dir-->
<call function="'copyImage'">target,destinyDir,destinyFPDir,destinyFile, 
localMountPoint,buildPuiDir,buildPtfDir,buildPuiNum,buildPtfNum, 
buildZipFileName</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Success copy image files .']</call>
</if>
<!-- Step 3. Stop all servers-->
<call function="'stopAllServers'">target,portalProfileRoot,
WPSUsername,WPSPasswd, WASUsername,WASPasswd</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Stop all servers success !']</call>
</else>
</if>
<!-- Step 4. Start to install-->
<sequence>
<call function="'StartInstall'">target,portalServerDir,
setUpCmdLineDir,destinyDir, destinyFPDir,WPSPasswd,
WASPasswd,portalConfigDir</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Fixpack install finish success !']</call>
</if>
</sequence>
<return>0</return>
</sequence>
</function>
</stax>

第五步,对安装好的软件进行配置

一般来说,在软件安装结束之后需要进行一些基本的配置操作,如软件调优,配置数据库数据源, 配置安全性等。基本上在 IBM 产品中这些操作都有相同的特性,即首先修改配置文件,然后执行配置命令, 中间会涉及到一些停止或者启动服务器的操作。针对不同的软件及操作系统,这些操作都可以结合事先写好的 Shell 或者 Bat 脚本,然后通过 STAX 脚本来触发这些脚本。与安装软件的过程类似,可以通过 STAX 任务实时监控整个过程的状态并及时汇报给测试人员。这一步骤成功结束之后,自动进入下一个测试环节。对于很多产品来说,两个基本的配置工作分别是进行数据库的配置和安全性的配置,例如在 WebSphere Portal 产品中,数据库迁移配置和 LDAP 的安全配置是不可缺少的两个配置步骤,实现这种配置的 STAX 示例脚本如下:

清单 5. Enable Security STAX 脚本片段
 
<stax>
<function name="enableSecurity" scope="local">
<function-prolog>'Enable security for the portal on the target machine'</function-prolog>
<function-list-args>
<!-- Define arguments-->
</function-list-args>
<sequence>
<!-- Step 1. Stop Portal. -->
<call function="'retrieveWasPortalStatus'">[target, portalProfileRoot, wasUserId, 
 wasPassword]</call>
<if expr="STAXResult == 0">
<sequence>
<call function="'writeLog'">[target, 'Portal is already started, begin to stop it...', 
'user1']</call>
<call function="'stopWasPortal'">[target, portalProfileRoot, wasUserId, 
wasPassword]</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Stop Portal successfully.', 'user1']</call>
</if>
</sequence>
</if>
<!-- Step 2. Run task -->
<call function="'runConfigEngineTask'">[target, portalProfileRoot, 
'wp-modify-ldap-security']</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Task wp-modify-ldap-security succeeded.', 
'info']</call>
</if>
<!-- Step 3. Start portal -->
<call function="'startWasPortal'">[target, portalProfileRoot]</call>
<if expr="STAXResult == 0">
<sequence>
<call function="'writeLog'">[target, 'Task EnableSecurity succeeded!', 'pass']</call>
<return>0</return>
</sequence>
</if>
</sequence>
</function>
</stax>

清单 6. DBTransfer STAX 脚本片段
 
<stax>
<function name="DBTransfer" scope="local">
<function-prolog>'Transfer DB'</function-prolog>
<function-list-args>
<!-- Define arguments-->
</function-list-args>
<sequence>
<!-- Step 1. Modify property files -->
<call function="'MergeProperyFilesTool'">
 [target, targetDirectory, targetFileName1, sourceFileName1, MergePropertyScript, 
 domains1, append] 
</call>
<call function="'MergeProperyFilesTool'">
[target, targetDirectory, targetFileName2, sourceFileName2, MergePropertyScript, 
domains2, append] 
</call>
<!-- Step 2. Run task -->
<call function="'runConfigEngineTask'">[target, portalProfileRoot, 
'database-transfer']</call>
<if expr="STAXResult == 0">
<call function="'writeLog'">[target, 'Task database-transfer succeed.', 'user1']</call>
</if>
<!-- Step 3. Start portal -->
<call function="'startWasPortal'">[target, portalProfileRoot]</call>
<if expr="STAXResult == 0">
<sequence>
<call function="'writeLog'">[target, 'Task DBTranfer succeeded!', 'user1']</call>
<return>0</return>
</sequence>
</if>
</sequence>
</function>
</stax>

第六步,执行RFT测试用例

在本文的开头已经对 UAT 做了简要的介绍,UAT 是保证一个新的版本的软件或者软件补丁产生之后,其基本的各个功能模块能够正常运行的测试环节。所以,在软件安装和配置工作结束之后,执行覆盖软件基本功能的测试用例,是很有必要的。

对于基于 Web 的产品,通常用RFT针对不同软件的功能实现写好测试脚本就已经能够单独运行。为了实现 UAT 的全部过程自动化,必须将这一部分同 STAX 脚本进行连接,用 STAX 触发这些测试脚本并实时监控脚本的执行状态。通过 STAX 来触发 RFT 的 web 自动化脚本的任务示例如下:

清单 7. 触发 RFT 自动化测试的 STAX 脚本片段
 
<stax>
<function name="runExampleRFTTest" scope="local">
<function-prolog>Runs a RFT testcase using LA</function-prolog>
<function-list-args>
<!-- Define arguments-->
</function-list-args>
<sequence>
<!-- Run the RFT test on the RFT server -->
<call function="'cafRunRFTTest'">
{
'rftServer' : target, 
'properties' : mySuite, 
'rftProjectArchive' : 'LWPServerGUI.zip', 
'rftScript' : rftScript, 
'rftScriptArgs' : rftArgs, 
'maxExecutionTime': maxTime, 
'browserName': browserType, 
'browserPath': browserLocation, 
'browserCommand': browserCmd, 
'rftExecutionMode' : 'standalone'
}
</call>
<script>(rftRunTestRC,rftRunTestCallResult) = STAXResult</script>
<return>rftRunTestRC</return>
</sequence>
</function>
</stax>

第七步,生成测试报告和日志

在所有的测试步骤结束之后,或者如果中途有环节出现测试错误,可以通过 STAF/STAX 生成一份测试报告并发送给测试人员,测试报告当中包括详细的测试结果,失败原因等等。试想一下,每天早上来上班的时候,一边喝咖啡一边打开邮箱,发现原来需要花费一天时间的工作已经在昨天夜里执行完毕并且有一份完整的测试报告发送到邮箱,难道不是一件很惬意的事情吗?

作为测试报告的来源,日志是自动化测试任务的重要组成部分,一方面测试任务的开发人员可以利用日志来调试脚本,另一方面,日志作为测试报告的一部分使得测试任务的使用者了解测试任务执行结果以及执行过程信息。自动化脚本开发人员通过在脚本中调用 STAF/STAX 提供的 LOG Service 来生成纯文本格式的任务日志,较为方便。但其缺点在于不直观,由于日志本身的层次结构淹没在海量的文本中,测试人员很难快速地找到自己想要了解的信息。针对这一缺点,我们把测试任务的结构自顶向下分为以下三个层次:

  • 测试用例(Testcases):测试任务的顶级层次,描述此次测试任务的主要目标。一个测试任务由一个或者多个测试用例组成,同一个测试任务的多个测试用例可以串行、也可以并行执行。测试用例在任务的执行过程中,有“开始”、“成功”、“失败”等不同的状态;
  • 步骤(Steps):描述了测试用例执行过程中的关键步骤,一个测试用例由多个步骤组成。步骤往往是顺序执行的,也有“开始”、“成功”、“失败”等不同的状态,步骤的执行结果决定了测试用例的结果;
  • 细节(Details):组成测试任务的基本单位,由程序员在测试任务脚本中调用STAF/STAX的LOG服务自行记录,根据STAF对的LOG定义,一条日志信息可以有“info”、“debug”、“warning”、“error”等不同的类型;

这样,在任务执行的过程当中会有一份更加友好的日志生成,包括各个步骤的执行情况,测试用例的通过情况等,日志的概述结果就可以当作测试报告发送给测试者。生成的测试报告格式如下图,这是一个基于HTML格式的报告。

图 4. HTML 格式的任务报告
HTML 格式的任务报告

下面所示的STAX代码片断提供了记录日志的函数writeLog,它接受日志内容、日志状态、日志类型等参数,向该任务的日志目录下的日志文件中追加一条日志。

清单 8. 自定义STAX函数writeLog
 
<function name="writeLog" scope="local">
<function-list-args>
<function-required-arg name="content"></function-required-arg>
<function-optional-arg name="level" default="'info'"></function-optional-arg>
<function-optional-arg name="type" default="'detail'"></function-optional-arg>
<function-optional-arg name="state" default="'start'"></function-optional-arg>
</function-list-args>
<sequence>
<script>
displayLogName = 'Automation Runtime Text Output Log'
#the actual name of the text log file. 
logFileName = '%s.txt' % STAXJobID
#if content contains multiply lines, separate it
from string import *
lines = split(content, '\n') 
</script>
<iterate in="lines" var="line">
  <sequence>
    <if expr="type == 'testcase'">
     <sequence>
        <script>line = '*TESTCASE %s:%s' % (state, line)</script>
     </sequence>
    <elseif expr="type == 'step'">
        <script>line = '*STEP %s:%s' % (state, line)</script>
    </elseif>
    </if>
    <call function="'cafAppendJobOutputLog'">[target, 'local', line
   displayLogName, logFileName]</call>
  </sequence>
</iterate>
</sequence>
</function>

值得注意的是,为了进一步解析生成 HTML 日志,我们把日志的类型和状态信息通过固定的标签写入了日志之中:

*TESTCASE	 STATE	TestcaseName
*STEP STATE StepName

对于一个确定的测试用例或者步骤,上述的标签总是成对出现的,这样才能保证能够正确的解析到它们的边界。LogHelper为一个 Python 类,它封装了从文本日志中解析层次信息后生成 html 格式日志的细节,下图为LogHelper类图。

图 5. LogHelper 类图
LogHelper 类图

下面的代码片断为LogHelper类的核心方法parserLog方法。

清单 9. 使用 Python 构建的 LogHelper 类的 parseLog 方法
 
def parseLog(self, logTxtFile): 
"""
Parse the txt log file, information of testcases and steps will be assigned to
the data field of this class.Translate the common txt lines to html and assign
it to the htmlContent field. 
"""
    try: 
        self._txtLogFileName = logTxtFile
        fp = open(self._txtLogFileName, 'r') 
    except IOError, e: 
        return (1, 'Open file %s failed' % logTxtFile) 
    #use stacks to contain the parsed entries
    testcases = []
    steps = []
    for line in fp.readlines():
        #remove the timestamp
        logInfo = line.strip().split('\t', 1)[-1] 
        if logInfo.startswith('*TESTCASE') or logInfo.startswith('*STEP'): 
        #it is a tag
            type,name = logInfo.split(':', 1) 
            type,state = type.split(' ', 1) 
            if type == '*TESTCASE': 
                if state == 'start': 
                    testcases.append(name) 
                    self.addTestcase(name) 
                else: 
                    testcases.pop()
                    try: 
                        self.closeTestcase(name, state) 
                    except EntryNotFoundException, e: 
                        return (1, e.msg) 
            else: 
                if state == 'start': 
                    steps.append(name) 
                        try: 
                            self.addTestcaseStep(name, testcases[-1]) 
                        except EntryNotFoundException, e: 
                            return (1, e.msg) 
                else: 
                    steps.pop()
                    try: 
                        self.closeTestcaseStep(name, testcases[-1], state) 
                    except EntryNotFoundException, e: 
                        return (1, e.msg) 
    fp.close()
    return (0, '')

代码下载 (code downloads)

单击下载logHelper.py代码

通过以上的步骤描述看出,测试人员所有的工作仅仅是制定测试任务,查看测试结果,而且测试任务仅仅需要制定一次就可以通过加入任务队列的方式来重复执行,可见,这种基于STAF/STAX的UAT自动化测试解决方案极大程度上减少了测试人员的工作量,节约了测试人员宝贵的时间。

总结

以上阐述了基于STAF/STAX并结合使用Shell Script的UAT自动化解决方案,并且结合本团队负责测试的逐个步骤进行了分析。根据UAT测试人员给予的反馈信息,这样的一套全自动测试平台可以节约测试人员约80%的测试时间,极大提高了工作效率。同样的方法结合使用shell脚本和STAX脚本可以实现很多日常工作中的自动化工作,在这方面,我们正在进行更多的尝试。

参考资料

  • Software Testing Automation Framework (STAF) 是一个开源的、多平台、多语言框架,详细内容请参考 http://staf.sf.net
  • 更多有关 Software Testing Automation Framework (STAF) 内容,请参考软件测试自动化专题
  • 访问 developerWorks Open source 专区,获得丰富的 how-to 信息、工具和项目更新,帮助您用开放源码技术进行开发,并与 IBM 产品结合使用。

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织