发布新日志

  • 【转载】利用 STAF 实现程序更新包的自动部署测试

    2010-04-19 14:54:23

    文档选项
    '); //--> '); //-->
    将打印机的版面设置成横向打印模式

    打印本页

    将打印机的版面设置成横向打印模式

    打印本页

    将此页作为电子邮件发送

    将此页作为电子邮件发送

    将此页作为电子邮件发送

    将此页作为电子邮件发送


    级别: 中级

    崔 俊涛 (cuijunt@cn.ibm.com), 软件工程师, IBM

    2007 年 10 月 25 日

    如今软件开发依赖于集体的开发和测试。对于部署和测试人员来说,如何从集中的代码管理工具来获取源代码或者代码的编译包并且自动部署和测试变得非常重要。本文借助于 STAF(STAX) 和 FTP 以及 CVS 工具介绍如何自动从 FTP 或者 CVS 下载程序的更新包,并且部署到测试环境中。本文首先对自动化测试框架Software Test Automation Framework (STAF)和Software Test Automation eXecution Engine (STAX)进行简要的介绍,然后简单介绍如何安装和配置STAF(STAX)。其次本文将结合一个场景重点介绍STAF(STAX)如何利用CVS和FTP工具进行源代码的下载、编译、分发、部署和测试。最后本文列出了使用STAF(STAX)的经验和教训。

    读者可以从本文了解到 STAF(STAX) 的基本概念和用法。本文适合 STAF 的初学者。

    1.STAF(STAX)

    Software Test Automation Framework (STAF) 是开源、跨平台、支持多语言并且基于可重用的组件来构建的自动化测试框架。它为自动化测试建立了基础,并且提供了一种可插拨的机制支持不同的平台和语言。STAF 采用点对点的实现机制,被用来减轻自动化测试的工作负担,加快自动化测试的进程。在 STAF 的环境中,所有的机器都是对等的,没有客户端和服务器的区分。

    Software Test Automation eXecution Engine (STAX)是基于 STAF 的执行引擎。它在 STAF 的基础上,帮助用户实现测试用例的分发、部署、执行以及结果分析。STAX 使用了三种技术:STAF, XML 和 Python。简单来说,STAX 在 STAF之 上提供了一些接口,方便用户来操纵STAF进行自动化测试的实现。

    我们将简要介绍一下 STAF 和 STAX 中所用到的概念和机制。

    1.1 Services (服务)

    STAF 基于可重用的组件来构建自动化测试框架,这些可重用的组件就是 Services(服务)。STAF 中所有的组件都是服务。服务是一系列功能的集合。STAF 本身是一个后台程序 (STAFProc),提供一种轻量级的分发机制,负责把请求转发给这些服务。

    STAF 中的服务分为两种:internal (内部服务)和 external(外部服务)。内部服务被集成进 STAFProc 中,提供一些关键性的功能,比如数据管理和同步。外部服务由 STAFProc 动态装入,通过共享库(shared libraries)来访问。

    STAF 提供了如下几种常用服务:

    • 程序调用服务(Process Service):内部服务,利用此服务,STAF 可以调用外部程序。
    • 文件系统服务(FileSystem Service):内部服务,利用此服务,STAF 可以对文件系统进行操作,比如复制,删除,查看等操作。
    • 日志服务(Log Service):外部服务,帮助用户进行日志的记录和查看。
    • 资源池服务(ResPool Service):外部服务,提供了对于资源池的管理和操作,如查看,创建和删除操作。
    • 监控服务(Monitor Service):外部服务,提供对于 STAF 运行时的监控功能。
    • 信号量服务(Sem Service):内部服务,提供了两种信号量的操作,mutex 和 event。
    • 压缩服务(Zip Service):外部服务,提供了压缩和解压的功能。
    • Ping服务(Ping Service):内部服务,类似于操作系统的 ping 功能,用于检测远程的 STAF 是否运行。
    • 变量服务(Var Service):内部服务,提供对于系统或者用户级别的环境变量的操作。
    STAF 还提供了延迟(Delay Service), 帮助(Help Service), 跟踪(Trace Service)等服务,这里不一一列举。

    1.2 请求-响应格式

    每个服务都定义了它能接受的请求格式。STAF 通过请求来调用服务的功能,每个请求都以字符串的形式发送,这样可以保证 STAF 能够跨平台的运行。 每个请求都有三个参数,以系统-服务-参数的形式出现。第一个参数表示此请求需要被发送到的 STAF 系统,这个参数被 STAFProc 解析以便确定请求应该被本地处理还是发送到其他的 STAF 系统。 当这个请求被发送到需要处理的 STAF 系统后,STAFProc 解析第二个参数来判断哪个服务会被调用。最后,STAFProc 会把第三个参数转发给需要调用的服务,服务处理这个请求。

    当处理完请求后,服务会返回两种数据:返回码和特定于请求的信息。返回码表示服务处理的结果。特定于请求的信息表示服务返回的具体数据,如果请求成功返回,这些信息将包括这次请求所请求的数据,如果请求出现错误,这些信息将包含额外的诊断信息。

    完全使用字符串作为请求响应格式可以简化 STAF 的很多方面,包括与其他语言的接口,服务之间的通信,跨平台的操作等。 其他语言只需要通过一个接口 STAFSubmit() 来请求 STAF 的服务,并且只需传递三个字符串参数。服务之间也只需要通过字符串发送接收请求。

    1.3 STAX

    STAX 是基于 STAF 的执行引擎,它提供了一种 XML 格式的工作流语言。用户可以编写 XML 的脚本文件来通过 STAX 调用 STAF 的服务已完成自动化测试。用户可以不需要和编程语言打交道就可以开发出自己的自动化测试环境。STAX 提供如下的功能:支持并行运行,用户自定义的运行控制粒度,嵌套测试用例,控制运行时间,支持现有的 Java 和 Python 模块等。STAX 还提供了一个图形化的监控工具,通过这个工具,用户可以清晰的看出测试运行的位置,状态和出错信息等。 下面我们将通过与 FTP 和 CVS 的协作完成自动化部署来展示 STAF 和 STAX 的功能。

    2.STAF(STAX) 安装配置

    STAF 的安装文件可以从STAF 的网站下载。对于不同的平台和 JVM 环境有不同的安装文件,请选择合适的文件下载。如果下载的是 jar 文件,要确保需要安装 STAF 的机器上已经安装有相应的 JRE,然后运行如下命令安装 STAF:java -jar STAF安装文件.jar。 如果下载的是可执行文件,则直接运行即可。

    STAF 的安装比较简单,只需要按照向导提示进行操作即可。安装完毕后,可以通过 STAFProc 命令启动 STAF。关闭 STAF 可以用如下的命令: staf local shutdown shutdown。从这条命令我们可以看出上面提到的 STAF 的命令格式。local 表示 STAF 的本地系统,shutdown 表示服务, 此服务提供了 STAF 的关闭操作。第二个 shutdown 表示传递给服务的参数,指示 STAF 把本地的 STAF 服务关闭。

    STAX 的安装文件也可以从STAF 的网站下载。STAX 本身不需要安装,只需要更改 STAF 的配置文件以便 STAF 在启动的时候能够加载 STAX 服务。 从这个角度来说,STAX 是 STAF 的一种外部服务,可以根据需要来决定是否加载它。

    下载完 STAX 后,将其解压到 $STAF_Install_Directory\services\stax 目录中,然后更改 STAF 的配置文件 STAF.cfg。此文件在 $STAF_Install_Directory\bin 目录下。 在 STAF.cfg 文件末尾加上如下的代码,然后重启 STAF。
    代码1:STAX配置

                        
    SERVICE STAX LIBRARY JSTAF EXECUTE \
      {STAF/Config/STAFRoot}/services/stax/STAX.jar  OPTION J2=-Xmx384m
    SERVICE EVENT LIBRARY JSTAF EXECUTE \
      {STAF/Config/STAFRoot}/services/stax/STAFEvent.jar
    SET MAXQUEUESIZE 10000
            

    STAF重启之后,运行命令staf local service list,查看输出结果,如果显示有STAX和EVENT,如图1所示,则说明STAX已经成功加载。


    图 1. STAF 服务列表
    STAF服务列表

    SERVICE STAX LIBRARY JSTAF EXECUTE {STAF/Config/STAFRoot}/services/stax/STAX.jar通知STAF在启动时以名字STAX(这样在STAF服务列表中,我们看到的STAX的服务名字就叫做STAX)来加载STAX.jar,也就是STAX服务。 传递的参数J2=-Xmx384m表示更改JVM的堆栈大小。如果STAX会出现OutOfMemory错误,则需要调整这个参数,增加JVM的堆栈大小。 建议在加载STAX时总是指定这个参数,并且根据系统环境来调整参数大小。

    SERVICE EVENT LIBRARY JSTAF EXECUTE {STAF/Config/STAFRoot}/services/stax/STAFEvent.jar通知STAF在启动时以名字EVENT来加载STAFEvent.jar。

    如果需要在运行STAX的机器上运行STAX Monitor (STAX任务的监控工具),则需要设置MAXQUEUESIZE,以保证STAXMonitor能够正确运行。

    2.1 STAF Java 代码示例

    代码2所示的是STAF Java代码示例。


    代码2:STAF Java代码示例
                    
    STAFHandle handle = null;
    try {
      handle = new STAFHandle("Java_Sample_Test");
    } catch (STAFException e) {
      System.exit(1);
    }
    
    STAFResult result = handle.submit2("Linux1", "process", 
      "start command ls parms -l wait stdout /root/lsjava.log");
    if (result.Ok != result.rc) {
      System.out.println("Error starting the process ls, RC:  " + result.rc);
    } 
    
    result = handle.submit2("Linux1", "fs", "copy FILE /root/lsjava.log 
      TODIRECTORY C:/STAF TOMACHINE windows' % machineName");
    if (result.Ok != result.rc) {
      System.out.println("Error coping file, RC: " + result.rc);
    } 
          

    在调用STAF服务之前,首先需要注册STAFHandle,所有的STAF服务调用都要通过这个句柄来进行,因此一般把这个句柄设置成静态的。通过handle.submit2()函数可以向STAF服务发送请求并且接收处理结果。

    2.2 STAX脚本示例

    STAX为我们简化了调用STAF服务的过程,因此我们通过STAX脚本来调用STAF服务。本节将根据一个简单的示例来简要介绍STAX脚本的语法。


    代码3:STAX脚本SampleScript.xml示例
                    
    1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    2 <!DOCTYPE stax SYSTEM "stax.dtd">        
    3 <!-- sample1.xml - Sample of a job definition file for STAX
    4 Job Description:
    5   This job executes some STAF commands and sends messages to the STAX Job Monitor.
    6 -->
    7  <stax>
    8   <script> LinuxMachine = ['Linux1', 'Linux2'] </script>
      
    9   <defaultcall function="ListDirectory">
    10   </defaultcall>
      
    11   <function name="ListDirectory">
        
    12     <paralleliterate var = "machineName" in="LinuxMachine">
    13       <testcase name = "'listDirectory'">
    14         <sequence>
              
    15           <stafcmd>
    16             <location>'%s' % machineName</location>
    17             <service>'process'</service>
    18             <request>'start command "ls" parms "-l" wait stdout /root/ls.log'</request>
    19           </stafcmd>
              
    20           <if expr="RC == 0">
    21             <sequence>
    22               <tcstatus result="'pass'"/>
    23               <log message="1">'List directory successfully on %s' % machineName</log>
    24             </sequence>
    25             <else>
    26               <sequence>
    27                 <tcstatus result="'fail'"/>
    28                 <log message="1">'Error in listing directory on %s' % machineName</log>
    29               </sequence>
    30             </else>
    31          </if>
    
    32           <stafcmd>
    33             <location>'%s' % machineName</location>
    34             <service>'fs'</service>
    35             <request>'copy FILE /root/ls.log TOFILE ls%s.log TODIRECTORY C:/STAF 
                        TOMACHINE windows' % machineName</request>
    36           </stafcmd>
    
    37         </sequence>
    38       </testcase>
    39     </paralleliterate>	
    40   </function>
    41 </stax>
          

    这个示例调用两台Linux机器上的ls命令,将结果输出到文件,根据命令返回的结果判断调用是否成功,然后复制文件到另外的STAF机器中。为了方便描述,为脚本加上行号。

    STAX采用现在流行的XML语言作为其脚本语言。第一行是XML语言的标准格式,第二行表示此XML文件使用stax.dtd样式表进行验证。所有的STAX脚本文件都应该保留这两行。

    3-6行是XML的注释,用来描述这个脚本的功能。

    第7行是STAX脚本命令的开始符,所有STAX脚本内容都要用它起始。第8行中script类似于编程语言中的定义变量的语句,在这里定义一个长度为2的数组LinuxMachine,其值为Linux1和Linux2。

    第9-10行指定STAX脚本运行时调用的函数。第11-40行是函数的定义体。11行指定函数名为ListDirectory。

    第12-39行定义一个循环,类似于Java中的for,但是这个循环是并行的。var="machineName" in="LinuxMachine" 表示此循环从LinuxMachine数组中获得输入,并且赋给machineName变量。

    13行定义测试用例,在STAX脚本的运行中,可以根据运行结果来决定测试用例的结果,方便用户查看。

    第14-37行表示其中的STAX脚本是顺序执行的。15-19行执行具体的STAF命令,其中location指定需要运行STAF命令的机器,可以由变量来动态指定,比如'%s' % machineName。 service表示需要调用的服务,在这里为process进程服务。request为需要传递给服务的参数。进程服务的参数分为几部分,首先是需要调用的命令"ls",parms指定需要传递给"ls"的参数"-l"。 wait表示需要等待这个命令结束才能返回。stdout表示将命令运行的结果输出到文件中去。

    20-31行判断上个命令的返回结果,并根据返回结果的值设定测试用例的状态,并且记录日志以及将消息发送到STAFMonitor。expr="RC==0"判断返回结果是否为0。 RC表示上个命令的返回结果,0表示命令执行成功。<tcstatus result="'pass'"/>设置测试用例状态为通过,fail则表示测试用例失败。<log message="1"> 表示不仅将消息记录到STAX的日志中,而且将其发送到STAFMonitor(如果STAFMonitor处于运行状态)。

    32-36行是STAF的文件拷贝命令。fs表示文件系统服务,copy FILE指定复制文件操作,TOFILE指定目标文件的名字,STAX会用命令后面的参数% machineName替换%s,因此目标文件的名字为lsLinux1.log和lsLinux2.log。 TODIRECTORY指定目标文件夹,TOMACHINE指定目标机器。

    上述STAX脚本可以用staf local stax execute file SampleScript.xml wait执行,或者通过java -jar STAXMon.jar启动STAXMonitor来调用。





    回页首


    3.自动部署更新包


    图2. STAF(STAX)环境拓扑
    STAF环境示意图

    图2是本节将要介绍的简化的场景图。软件开发分为两部分,一部分是在CVS上的最新的软件源码,另外一部分是在FTP服务器上的执行脚本。在STAF(STAX)自动部署更新包的过程中,STAX需要同时从CVS和FTP上下载最新的代码和安装脚本。 测试环境中,测试机器上都装有STAF,并且在从CVS和FTP下载代码的机器上安装有STAX。

    STAX下载完代码后,将代码拷贝到用于编译的服务器上。因为代码的编译需要特殊的环境,比如需要WAS (WebSphere Application Server) 的环境,因此我们把STAX服务器和编译服务器分开。 编译服务器编译好源码之后,将其分发到部署和测试服务器上。部署服务器负责向应用程序服务器部署程序,而测试服务器则用来进行自动化测试。

    本节根据这个场景介绍如何通过STAF(STAX)来实现部署和测试的自动化。

    3.1 FTP脚本

    STAF(STAX)实现了自动化测试的框架,但并没有实现具体的常用功能,比如FTP, CVS。因此我们需要借助FTP命令来完成FTP源码的下载。自动化下载一般通过命令行实现,因此我们使用Windows自带的FTP命令来完成。

    FTP命令提供了一个参数-s,可以指定一个FTP脚本文件来存放将要执行的FTP命令。因此我们把需要执行的FTP命令存放到某个文件,然后通过STAX调用FTP命令实现FTP上源码的自动下载。


    代码4:FTP脚本(ftpSample.conf)示例
                    
    open ftp.ibm.com
    username
    password
    binary
    prompt
    cd /code/latest/unix
    lcd C:\latest\unix
    mget *
    bye
          

    这个FTP脚本表示以用户名username,密码password访问ftp.ibm.com,设置传输方式为binary,然后下载/code/latest/unix下的文件到本地目录C:\latest\unix。可以通过ftp -s:ftpSample.conf来运行此脚本。

    调用ftp命令的STAX脚本如下所示:


    代码5:调用FTP命令的STAX脚本
                    
    <process>
      <location>'local'</location>
      <command>'ftp'</command>
      <parms>'-s:ftpSample.conf'</parms>
      <workdir>'C:/STAF'</workdir>
    </process>
          

    process标签表示调用STAF的进程服务(process),location表示请求被发送的目标机器,command表示需要执行的进程,而parms表示传递给进程的参数,workdir表示进程运行的工作目录。

    通过FTP脚本和STAX脚本,我们可以控制STAX来自动下载FTP上的源代码。

    3.2 CVS下载

    和FTP类似,CVS源码下载也使用命令行的方式,但由于CVS服务器使用的协议不同,对CVS客户端的要求也不同,因此我们在这里不再介绍如何使CVS客户端工作的内容。假定我们能够使用如下的命令更新CVS代码: cvs -d :ext:username@cvs.ibm.com:/cvsroot/ checkout -d directory modulename.

    根据这个CVS命令,调用此命令更新CVS代码的STAX脚本如下:


    代码6:调用FTP命令的STAX脚本
                    
    <process>
      <location>'local'</location>
      <command>'cvs'</command>
      <parms>'-d :ext:username@cvs.ibm.com:/cvsroot/ checkout -d directory modulename'</parms>
      <workdir>'C:/CVS'</workdir>
      <stdout>'C:/CVS/cvsupdate.log'</stdout>
    </process>
          

    与代码 5 不同的是,代码 6 使用了stdout 标签,此标签表示将进程 cvs 的输出重定向到 cvsupdate.log 中,以便于我们查看 cvs 命令执行的状态和结果。

    3.3 拷贝编译源码

    从 CVS 和 FTP 上下载源码之后,需要将源码拷贝到编译服务器上。本节介绍如何使用 STAF 的文件传输命令以及 STAX 的循环指令。


    代码 7:传输文件的 STAX 脚本
                    
    <script> directoryList = ['CVSDirectory', 'FTPDirectory'] </script>
      <iterate var = "directory" in="directoryList">
        <testcase name = "'sourceCopy'">
          <sequence>
            <stafcmd>
              <location>'local'</location>
              <service>'fs'</service>
              <request>'copy DIRECTORY C:/Source/%s TODIRECTORY /root/build/%s TOMACHINE 
                buildserver RECURSE KEEPEMPTYDIRECTORIES'  % directory % directory</request>
            </stafcmd>
          </sequence>
        </testcase>
    </iterate>
          

    代码 7 拷贝 CVS 和 FTP 源码到编译服务器中。script. 标签定义了一个数组 directoryList,这个数组有两个值,分别表示 CVS 源码目录和 FTP 目录。iterate 定义了一个顺序循环,分别从 CVS 目录和 FTP 目录拷贝文件到编译服务器中。 stafcmd 标签调用 STAF 命令,此处我们调用的是 FS(文件系统)服务。copy DIRECTORY 表示我们需要拷贝整个目录到编译服务器中。 如果编译服务器已经有原来的代码,为了正确起见,可以在拷贝之前使用 fs delete entry 命令来删除原有的文件。

    拷贝文件后,需要通知编译服务器对更新后的源码进行编译。假定在编译服务器上存在用于编译源码的脚本文件 /root/build/build.sh,则调用此脚本文件编译源码的 STAX 脚本如代码 8 所示。


    代码 8:编译源码的 STAX 脚本
                    
    <stafcmd>
      <location>'buildserver'</location>
      <service>'process'</service>
      <request>'start command "/root/build/build.sh" username "root" password "password" 
        workdir "/root/build" wait stdout /root/build/build.log'</request>
    </stafcmd>
          

    代码 8 指定以用户 root 的身份来运行编译脚本 build.sh,并且将输出重定向到文件 build.log 中,以便分析编译运行的过程和结果。另外如果编译脚本 build.sh 用到某些和路径相关的命令,比如相对路径,则需要指定工作目录。 workdir 指定工作目录为 build.sh 所在的目录,这相当于在 /root/build 目录中运行 build.sh 命令。

    3.4 部署测试

    更新包编译完成后,需要将编译之后的更新包分发到部署服务器和测试服务器,然后部署服务器部署程序,测试服务器调用测试程序来测试更新包。将更新包分发到部署和测试服务器的 STAX 脚本如代码 9 所示。


    代码 9:更新包分发
                    
    <script> serverList = ['deployServer', 'testServer'] </script>
    <iterate var = "server" in="serverList">
      <testcase name = "'buildCopy'">
        <if expr="server != 'deployServer'">
          <stafcmd>
            <location>'buildserver'</location>
            <service>'fs'</service>
            <request>'copy DIRECTORY /root/build/result TODIRECTORY /root/build/result 
              TOMACHINE %s RECURSE KEEPEMPTYDIRECTORIES'  % server </request>
          </stafcmd>
        <else>
          <stafcmd>
            <location>'buildserver'</location>
            <service>'fs'</service>
            <request>'copy DIRECTORY /root/build/result TODIRECTORY C:/build/result 
              TOMACHINE %s RECURSE KEEPEMPTYDIRECTORIES'  % server </request>
          </stafcmd>
        </else>
        </if>
      </testcase>
    </iterate>
          

    代码9使用了判断语句来判断目标机器的平台,根据目标机器的平台选择不同的文件路径。当只有两台机器时,使用 if-else 的好处并不明显,甚至还不如分别向 windows 和 linux 机器上单独拷贝方便。 但考虑如下的情况,环境中有大量的部署服务器和测试服务器,这时一台一台的拷贝显然很难维护,而使用 if-else 加上循环的方式则要方便的多。

    部署测试的 STAX 脚本如代码 10 所示。


    代码 10:部署测试
                    
    <sequence>
      <stafcmd>
        <location>'deployServer'</location>
        <service>'process'</service>
        <request>'start command "C:/build/deploy.bat > deploy.log" username "Administrator" 
          password "password" workdir "C:/build" wait '</request>
      </stafcmd>
      <stafcmd>
        <location>'testServer'</location>
        <service>'process'</service>
        <request>'start command "/root/build/runtest.sh" username "root" password "password" 
          workdir "/root/build" wait stdout /root/build/runtest.log'</request>
      </stafcmd>
    </sequence>
          

    代码 10 中在 Windows 和 Linux 平台运行命令的方式有细微的区别,在 Windows 中我们使用> deploy.log来重定向输出,而在 Linux 中我们使用 stdout 来重定向输出。具体的原因将在经验教训中说明。

    至此,我们已经完成了更新包下载、分发、编译、部署和测试的整个过程,根据本节提供的示例代码,读者应该能够根据自己的环境编写出适合环境的STAX脚本。 另外,读者也可以自定义一些附加的操作,比如在更新代码之前,先把原有的代码删除;在测试完毕后,把分散于各个服务器上的日志汇总到一台集中的机器上;甚至和 CruiseControl 结合实现定时或者基于 CVS 上的代码更新来运行,以及将测试的日志发布到某台服务器上。





    回页首


    4.经验教训

    虽然现在 STAF(STAX) 已经比较完善,但在实际使用的过程中,我们还是发现了一些问题。本节介绍这些问题以及解决或者避免这些问题的方法,使读者在碰到这些问题时能够及时的解决它们。

    4.1 使用 STAFCMD 的 process 服务,不要使用 STAX 的 process 标签

    为了编写 STAX 脚本方便,STAX 定义了 process 标签用来调用 STAF 中的进程(process)服务。但在使用过程中,发现 STAX 的 process 标签在某些情况下存在着一定的问题,其所调用的进程不能返回。 代码 11 的 STAX 脚本就是这样一个例子。


    代码 11:process 标签不能返回
                    
    <process>
      <location>'linuxServer' </location>
      <command>'ls'</command>
      <parms>'-l'</parms>
    </process>
          

    代码 11 调用 Linux 机器上的 ls 命令,并且传给 ls 命令 -l 参数。使用 STAXMonitor 执行此脚本,任务始终无法返回。因此推荐使用 stafcmd 标签直接调用 STAF 服务,如代码 12 所示。


    代码 12:修改后的任务
                    
    <stafcmd>
      <location>'linuxServer'</location>
      <service>'process'</service>
      <request>'start command "ls" parms "-l" wait '</request>
    </stafcmd>
          

    4.2 在 Windows 平台上不要使用 STDOUT 重定向输出

    STAF 使用 STDOUT 来为启动的进程重定向输出,类似于>参数,比如 ls -l > ls.log。但在 Windows 平台使用中,我们发现使用 STDOUT 会带来一些问题。 如果调用的进程为批处理文件,并且此批处理文件中包含某些特定的功能,比如 xcopy,则 xcopy 将不会工作。另外一些检查目录和文件的命令也不能与 STDOUT 共存。 在 Linux 环境中并不存在这样的问题。因此,如果需要在 Windows 平台中使用重定向输出的功能时,建议使用>来重定向输出。

    4.3 使用 STAXMonitor 监控任务的执行情况

    对于 STAF 和 STAX 新手来说,尽可能使用 STAXMonitor 来监控 STAX 任务的执行情况。STAXMonitor 为我们提供了足够详细的信息,比如测试用例的执行结果,任务执行的消息,当前执行的命令。 使用 STAXMonitor 有助于我们对正在进行的任务进行分析并且监控其执行情况和结果。

    STAXMonitor 在 STAX 安装文件中,可以用java -jar STAXMon.jar来启动 STAXMonitor。STAXMonitor 的界面如图 3 所示。


    图3. STAXMonitor 运行界面
    STAXMonitor 界面

    STAXMonitor 会显示当前正在运行的 STAX 任务,任务号,任务名字,功能,开始时间,执行时间以及结果。Monitored 表示是否正在使用 STAXMonitor 来监控任务。 右键单击任务,然后选择 Start monitoring,将出现如图 4 所示的监控界面。


    图 4. STAXMonitor 监控界面
    STAXMonitor监控界面

    监控界面会显示正在运行的进程或者STAF命令,命令的详细信息,比如开始时间、进程或者命令的参数,状态等。另外还显示测试用例的状态。通过STAXMonitor,我们可以很好的监控STAX任务的执行情况。

    4.4 将 STAF 注册为 Windows 平台上的服务

    STAF 并没有提供开机自动启动的功能,在 Windows 平台上,只有当某个用户登录后,才会启动 STAF。这对于自动化测试的环境来说不是一个好消息。 因此我们需要自动启动 STAF 的功能,这在 Linux 上比较简单,只要在 /etc/rc.d/rc.local(如果是 SuSE Linux,就是 /etc/rc.d/boot.local)中加入 STAF 的启动命令/usr/local/staf/bin/STAFProc &就可以了。 Windows 平台上就没有那么方便,因此本小节介绍如何将 STAF 注册为 Windows 的服务,以便能开机自动重启。

    1. 首先使用 instsrv 命令注册一个基本的服务 STAF:instsrv STAF c:\winnt\system32\srvany.exe
    2. 打开注册表编辑器(regedit),找到键值 My Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\STAF。在 STAF 下创建一个键,名字为 Parameters。
    3. 在 Parameters 键下面,创建一个字符串值(String Value),名字为 Application,值为 STAFProc 的完整路径,比如 C:\STAF\bin\STAFProc.exe。
    4. 使用命令services.msc启动Windows服务窗口,找到STAF,右键选择属性,然后定位到登录窗口,选择“允许服务与桌面交互”。
    5. 使用命令net start staf或者重启机器来启动STAF服务。
    6. 使用命令staf local service list来验证STAF是否已经成功启动。





    回页首


    5.总结

    STAF提供了一个自动化测试的平台,帮助我们进行自动化测试的更新、编译、部署和测试。STAX为STAF提供了一个执行引擎,帮助加快STAF程序的开发和部署。 因此利用STAF和STAX可以减少测试的工作量和复杂度,加快软件测试的流程,缩短测试周期。

    本文仅代表作者本人观点,不代表IBM公司观点。



    参考资料

    学习

    获得产品和技术

    讨论


    关于作者

    崔俊涛是 IBM 上海全球实验室的软件工程师。在SAL_FIT部门工作,现正致力于自动化测试的开发和研究。他感兴趣的技术有 SOA, EAI。你可以通过邮件 cuijunt@cn.ibm.com 与他联系。



    崔俊涛是 IBM 上海全球实验室的软件工程师。在SAL_FIT部门工作,现正致力于自动化测试的开发和研究。他感兴趣的技术有 SOA, EAI。你可以通过邮件 cuijunt@cn.ibm.com 与他联系。

  • [转载]自动化测试ROI分析

    2008-12-03 10:52:41

    1.   介绍

    很多领导将自动化测试视为银弹。他们认为自动化测试能解决诸如测试规划、测试成本、缺陷报告等很多问题。自动化测试在很多方面会带来积极的效果,并且已经有很多成功的案例能使人们认为自动化测试能节省成本和解决一些测试方面的问题。但是,同样存在很多恐怖的故事,失望大于期望、过程的痛苦,甚至出现在某些获得了收益的案例里。我就曾经遇到过很多自动化测试项目最终不幸失败的案例。这些项目进行了巨大的投入,最终都舍弃了花费数年的时间开发出来的自动化测试成果。

    本文的目的就是基于有实际意义的指导,使人们能够理解和计算进行自动化测试工作所需的投入和可能获得的回报。它描述了在建设自动化测试的过程中将会遇到的诸如商务、组织和管理、以及测试工作方面的影响。

    在规划自动化测试的时候,要从多方面来考虑。例如,自动化测试将会改变测试的复杂性,也将会改变从测试设计到测试运行的测试组织和管理方法。它通常在组织管理方面带来广泛的影响,诸如任务执行、测试方法、甚至在产品的特性上。

    在考虑自动化测试的收益和能力上,我们可以将影响因素分为有形的和无形的两类。

    在自动化测试的前后可以用现有的测量技术(例如代码覆盖分析)来评估和计算测试的效果。自动化测试可以达到非常有效的程度,可以增加代码覆盖的程度,可以提供一个新的角度来观察被测软件。同时,自动化测试为我们提供了一种手工测试无法实现某些特定测试的解决途径。自动化测试可以产生无数的指令和组合方式,仅仅受限于电脑的能力和可用来运行测试的时间而已。这些测试可以在覆盖了100%的代码基础上去发现缺陷。自动化的探针程序可以看到程序的内部,诸如中间处理的结果、内存中的数据、内部程序的状态,从而能判断被测软件是否能完成期望的功能。

    2.   管理的观点

    我们需要在多个方面设置管理上的期望值:无形成本和收益、不切实际的收益期望、手工测试和自动化测试的共同因素、组织的影响。我们也要注意测量和计算的方法。

    无形成本是非常难于合理的计算的。在可衡量它们的点上,当我们确定它们的财务上的价值时会存在很大的变数。在衡量自动化测试能带来多大的改变时也很难计算实际的数值。通常情况下,有的无形成本是绝对的,有时是相对的,但是绝大部分是无法区分的,这要取决于一个人的观点和处理的方式。基于这个理解,建议在大多数的案例中,尽量将这些无形成本从投入回报比的计算中省去。

    一些无形成本的例子:

    1              无用户干预的测试。尽管人的成本很容易计算,但是附加的计算机控制行为的成本是很难量化的。

    2              测试机构的经过改良的方法。这一点通常能提高生产力,但随之而来的是自动化测试所需的新规则和新任务。

    3              测试机构的可观察到的骤然生产力的降低。这个观察一般基于测试工作启动后人员开始逐渐增加时出现了停滞的现象,安装测试工具和创建自动化测试脚本的延迟。

    4              并非所有测试组里的人都期望改变。自动化测试会迫使个人习惯产生很大的改变,甚至某些测试人员在仍需继续执行手工测试时,还得进行自动化测试。

    5              发布前软件产品测试循环的次数。自动化测试能对产品的构建(Build)进行快速确认,并能鼓舞人们多次使用。但是往复循环虽然能提高生产力和提高质量,也可能导致人员的懒散、关注力逐渐降低、和质量逐渐降低的情况。

    6              测试覆盖率。既能增加测试覆盖率,也可能反之,主要取决于手工测试的效率,自动化的测试工具,和自动化的测试。

    a)        某些测试只能用自动化测试来实现

    b)        测试覆盖率改变的数值难于测量

    c)        好的探索性的测试或许比一般的自动化测试更能发现一些不同寻常的情况

    d)       手工测试可能使得某些情况或者环境难于进行自动化

    自动化测试管理的期望值往往在设定上受到媒体、会议、厂商的大肆宣传、相关书籍上对自动化优点的宣扬。部分信息是准确的和可适用的,但是大部分信息是出现在某些特定的环境下,适用于某些特定的项目,并且被过分的强调了成功这个字眼。自动化测试不是一个银弹。它不能解决所有的测试方面的问题,需要进行小心细致的规划。不正确的期望会最终导致一个获得了收益的自动化测试变成了失败的案例。

    例如:

    1所有的测试都要自动化。这是不切实际和可望不可即的。

    2从自动化测试获得立即的回报。某些自动化测试可能能看到立即的效果,例如Build测试,但通常情况下,回报总是在投入一段时期后才能看到。需要花费很多的时间和努力来创建大多数的自动化测试内容,而收效总是在一遍又一遍的测试运行之后才能获得。

    3零启动时间。将测试自动化是要花费时间的。要选择测试工具、搭建、安装,而规划和实现自动化测试则要花费数倍于手工测试的功夫。

    4自动化所有测试规划的内容。自动化测试工具无法做所有的事情。

    5使用录制/回放进行回归测试。这种情况仅适用于被测软件非常稳定,即将来只有极少的测试案例会发生改变。这种情况非常少。

    6自动缺陷报告(无需用户干预)。这通常会给测试的组织或开发带来很大的问题。包括判断是否与已有缺陷重复,错误的失效原因探测,一个错误引起多个测试的失效,无法重现的错误等等。

    组织管理方面的影响包括设计自动化测试和执行自动化测试所需的技能、自动化测试工具、自动化测试环境。开发和维护自动化测试与手工测试之间是有很大的区别的。在建设自动化测试时,工作技能变了、测试方法变了,甚至测试本身也发生了变化。自动化测试还会对被测的产品、开发过程和发布过程产生潜在的影响。我们不得不仔细考虑和分析这些影响中的积极和消极的因素。

    自动化测试若想成功,要从管理上设置合理的期望值,要正确地认识到将要从自动化测试中获得哪些益处。关键是要牢记自动化测试的目标是要在某些方面将测试做的更好。自动化测试仅仅是一个手段,借助这个手段来完成我们的任务测试一个软件产品。在管理测试工作和向测试工作进行投入方面,成本/收益的分析向我们提供了非常有用的信息。

    我们也要看到,不同的自动化测试实施行为将会带来好处,也会带来问题。例如,自动化测试将会减少测试所需的人力资源,从而节省运行测试过程中的人力耗费。但是,自动化测试也可能会产生各种各样的结果,需要耗费更多的人力进行分析,从而产生比手工测试更多的人力成本耗费。通常情况下,获得自动化测试的结果后,需要更长的时间去分析和隔离所发现的缺陷。

    3.   投入回报比的影响要素

    投入回报比(ROI)通常用获得的收益除以投入成本来计算。如果我们开始一个新的项目,我们就用测试的价值除以测试的成本来计算测试的投入回报比。有时,自动化测试的引入发生在手工测试已经完成的一段时间之后。

    自动化测试的经济成本通常可以描述为固定成本或者可变成本。固定成本包括设备、工具、培训等。固定成本不受自动化测试的成果数量和运行次数的影响。而可变成本随着所开发出来的自动化测试的成果数量以及自动化测试的运行次数而增加或者减少。

    自动化测试固定成本的例子:

    1硬件

    2应用软件的许可证

    3应用软件的技术支持

    4自动化测试环境的设计和搭建

    5自动化测试环境的维护

    6脚本开发工具软件

    7脚本开发工具的许可证

    8测试工具的培训

    9测试工具的引入和启动

    自动化测试可变成本的例子:

    1自动化测试用例的设计

    2自动化测试用力的实现

    3自动化测试的维护

    4自动化测试用例的执行

    5自动化测试结果的分析

    6缺陷的报告

    7测试结果的报告

    8测试执行数据的保存

    9自动执行的测试

     

    手工和自动化测试具备一些共同的要素。

    共同要素的例子:

    1被测软件的分析

    2测试的规划

    3基础测试的设计

    4缺陷的报告

    5测试结果的报告的管理

     

    我们在计算自动化测试的经济要素时,可以将它与两个事物进行比较:手工测试或不进行测试(接受未知的风险而不进行测试)。

     

    在计算回报时,我们需要选定计算的时间周期(t)。通常情况下,可以根据一个项目的里程碑来确定计算的时间周期。而且,自动化测试的回报是发生在新版本发布之后的,也可以基于版本的发布来确定计算周期,同时要与下一个版本发布、下下一个发布保持一致。以这两种计算周期来计算自动化测试的回报,可有助于我们非常清楚的了解长期和短期的自动化测试收益。

    自动化测试的固定成本不是绝对值。这些成本需要在他们的有用生命周期内进行阶段性的分配,并且用时间周期(t)来调整。t的值要基于管理因素进行选择,例如产品发布之间的时间间隔、ROI的计算、对工具使用寿命的期望、对测试的寿命的期望等等,以达到使t值被计算时的合理性、有用性和简易性。这些成本的分配是以成本乘以t 查看(662) 评论(0) 收藏 分享 管理

  • [转载]自动化测试实施时的关键概念

    2008-12-03 10:44:03

    在进行自动化测试实施时,由于要涉及软件开发方、业务方、手工测试方、自动化测试方、测试管理方等不同的机构或单位,尤其是业务方的人员和软件测试的人员对软件测试的认识处于不同的理解层次,因此,需要自动化测试的实施组事先对自动化测试中要使用的一些概念向各个机构或单位普及,才能使大家在脑海中建立相同的概念范畴,使得自动化测试的实施事半功倍。

      我把曾经在建立自动化测试体系的过程中规定的一些主要的自动化测试名词分享给大家,以期参考:)

    (1)测试需求:

      是指在一定的测试策略前提下,对应于验证某个系统的业务需求或功能需求的测试要求


      对应于不同的测试目的,分为验证业务过程的流程类测试需求和验证功能点的功能性测试需求


      对于功能性测试需求的业务规则是指测试功能点的属性描述,包括数据规则、业务逻辑规则、用户操作(输入和输出)的约束规则等;

      对于流程性测试需求的业务规则主要是指业务流程分支条件,及其对应的流程处理逻辑规则。


      在自动化测试体系中,测试需求按照树型结构进行组织,树上存在叶节点和非叶节点

    (2)交易分支:

      基于确定的交易,是交易执行中一个不可再分顺序路径。


      一般而言,一个交易被执行的时候,存在多个执行路径。例如:对于活期续存,信用卡续存、借记卡续存就是不同的执行路径。


      一个交易分支,就是一个交易的栏位的输入执行序列,包括在什么位置、输入数据的类型、限制约束、有效条件、格式要求等。

    (3)业务组件:

      一种易于维护且可重复使用的单元,该单元包含执行特定任务的一个或多个步骤。


      一个业务组件一般映射到一个交易分支,是自动化测试体系中颗粒度最小的工件


      定义业务组件的目的是为了封装固定的测试执行步骤,在测试过程中以“引用”的方式进行调用和复用,以减少测试过程设计开发的工作

      在自动化测试系统中,业务测试过程对业务组件的一次“引用”也是业务组件的一次实例化过程


      业务组件是一系列执行步骤,可以在不同测试过程中因为不同的目的(如边界值,无效等价值,有效等价值)使用不同组的数据完成输入,得到不同的业务组件实例。


      业务组件可能需要来自外部源或其他组件的输入值,并可向其他组件返回输出值

    (4)业务过程:

      业务过程是对业务流的实现


      业务过程是一组交易分支的序列,不是一个孤立的行为,如一次任务,一次输入或一次输出,而是以为用户带来附加值的输出或结果告终的一系列活动。


      例如:以开户交易开始,然后存款到相应的账户,最后能查询到此笔存款结束。


      一个业务过程对应于相应业务流中的一条“路径”即一个业务规则
    需要注意的是,业务过程是不存在由于业务逻辑不同而产生的分支的,如果在业务流程中存在分支,则应该拆分为不同的业务过程

    (5)业务测试过程:

      每个业务测试过程完成一个对流程类测试需求叶子节点的具体验证。

      每个业务测试过程是独立的,不允许嵌套,并且之间没有关系,业务测试过程原则上是可以独立执行的完整“业务流”。


      业务测试过程之间的关系是间接的,通过测试需求组合在一起的。


      业务测试过程由关联在一起的一系列业务组件组成,这些业务组件都需要在业务测试过程中指定明确的执行时输入、输出数据,以及业务组件和业务组件之间的数据依赖关系、顺序依赖关系、时序依赖关系等关联。
    可以说,业务测试过程是一组具有依赖关系的业务组件,和执行时数据的集合。

    (6)测试运行计划:

      主要描述为完成系统的测试,按照测试方案的设计思想,参照业务测试过程,如何对业务测试过程进行组织,以及执行时的先后组合操作顺序及业务测试过程间的关联数据


      (原则上不建议按照测试过程间有关联来设计测试)。

      如果测试方案或测试过程发生变化,则要对运行计划进行及时的更新

  • [转载]企业实施自动化测试的筹备工作简介

    2008-12-03 10:41:07

      最近老徐开始着手整理和完善“组织级软件自动化测试体系”,逐渐将部分内容共享给大家,期望和广大软件测试从业者及爱好者共同探讨。

    测试筹备活动用于在整体自动化测试活动执行开始前,判断项目可能达到的自动化率、分析项目的手工测试现状、协调资源初步建立自动化测试小组,应该包括以下内容。

    (一)    确定实施自动化测试的应用系统对象

    测试管理部门接受来自业务部门和开发部门的自动化测试的申请

    测试管理部门主动提出对某个已上线运营系统自动化测试的要求

    (二)    确定可能达到的自动化率目标

    计划控制经理使用自动化率分析模型判断自动化测试的可能达到的自动化率目标,编制《自动化测试的自动化率目标分析报告》

    (三)    分析手工测试的现状

    计划控制经理使用手工测试现状分析模型分析项目的当前手工测试状态,判断手工测试现状是否存在影响自动化测试可行性的情况,编制《自动化测试的手工测试现状分析报告》

    (四)    初步建立自动化测试小组

    计划控制经理根据自动化测试小组组长的可用资源指定自动化测试小组组长,将《自动化测试的自动化率目标分析报告》和《自动化测试的手工测试现状分析报告》传递给自动化测试小组组长

    计划控制经理与自动化测试小组组长共同确认:启动“项目级自动化测试流程”

  • [转载]自动化测试需求分析

    2008-12-03 09:47:18

    作者:老徐 新闻来源:STTE  更新时间:2007-4-3 18:12:45

    1. 自动化优先级标定:自动化测试分析师获得所有的测试需求及测试案例,依据“测试需求可自动化判断标准”,使用《自动化测试_测试需求优先级计算模版》进行每个测试需求的自动化优先级的标定。
    2. 确定自动化测试范围:依据测试需求的自动化优先级标定结果,配合自动化率的目标确定将要对哪些测试需求进行自动化,从而达到确定自动化测试范围的目的。
    3. 文档编制:自动化测试分析师编制《自动化测试需求分析说明书》
    4. 内部评审:组长组织自动化测试小组的内部评审
    5. 外部评审:组长向自动化测试管理组的计划控制经理提出申请,由计划控制经理组织测试管理组的外部评审,评审《自动化测试需求分析说明书》,需要项目组、自动化测试小组和质量控制经理共同参与评审。
    6. 组长将评审通过的《自动化测试需求分析说明书》纳入配置管理库。
    7. 自动化测试分析师将《自动化测试需求分析说明书》中规定的所有自动化测试需求和测试案例纳入自动化测试技术平台的测试需求管理子系统。
  • [转载]自动化测试计划

    2008-12-03 09:45:35

    作者:老徐 新闻来源:STTE  更新时间:2007-4-3 18:13:15

    1. 设定测试运行模式:根据《自动化测试需求分析说明书》中的描述,针对所有业务测试过程之间的关系,设计所有业务测试过程的执行顺序、前后关联关系等
    2. 设定测试运行计划:根据《自动化测试需求分析说明书》中对于自动化测试执行应用的描述,例如在每次Build,或者在每次新版本发布时执行自动化测试,设计自动化测试将来的执行计划
    3. 确定自动化测试缺陷生命周期模式:在自动化测试的运行过程中,业务组件在验证过程中将会遇到验证失败的情况,应在计划中定义自动化测试缺陷定义标准、自动化测试缺陷处理方案,则在自动化测试实现活动中要开发相应的缺陷提交组件供每个业务组件调用,以在测试发现可能的缺陷时判断是否是真正的缺陷并自动向缺陷管理子系统中提交缺陷报告。
    4. 设定开发计划:根据所有业务测试过程之间的关系以及将来的执行计划,同时考虑每个业务测试过程的优先级,确定所有业务测试过程的开发时间计划、开发责任人等
    5. 确定所需开发资源:依据开发计划确定在开发业务测试过程中所需的自动化测试工程师资源、自动化测试工具资源、开发环境资源等
    6. 确定所需运行资源:依据测试运行计划确定在自动化测试运行过程中所需的自动化测试环境资源、自动化测试工具资源等
    7. 编制测试计划:自动化测试分析师编制《自动化测试计划》,组长组织测试管理部的内部评审
    8. 组长向自动化测试管理组的计划控制经理提出申请,由计划控制经理组织自动化测试管理组的外部评审,评审《自动化测试计划》,需要项目组、自动化测试小组和质量控制经理共同参与评审。
    9. 外部评审结束后,若通过则由计划控制经理依据《自动化测试计划》中提出的资源需求提供各种资源。
    10. 组长将评审通过的《自动化测试计划》纳入配置管理库。
  • [转载]自动化软件测试成熟度等级——译自《自动化软件测试——入门、管理和实现》一书

    2008-12-03 09:43:03

     个人觉得这本书的书名翻译的不太准确,我认为书名译作《自动化软件测试——引入、管理和实施》更为准确。这不是一本讲具体的自动化测试实现的书,所以“入门”、“实现”一词有些误导。主要的原因可能是这本书目前出的是影印版,并不是中译本,因此图书编辑可能没有仔细的阅读过书的内容就粗略的翻译了一下书名。

        作者把自动化测试成熟度划分为五个等级,实际上与CMM5中的等级一一关联。

        自动化软件测试Level 1: 

        这个等级的自动化软件测试被称作“随机的自动化”(accidental automation)。在这个阶段,自动化测试没有实施或者只是基于临时性的(ad hoc)。可能会试验性地使用自动化测试工具。通过捕获/回放工具,自动化测试脚本被记录和回放,只有工具产生的脚本被使用。脚本不会为了可复用性或可维护性的目的而进行修改。没有遵循一个自动化脚本设计或开发的标准。产生的脚本不可复用并且难于维护,并且在每一个软件build都需要重新创建。这种自动化实际上在每一个测试周期可能会比手工测试增加125%或者更多的测试花费。

        自动化软件测试Level 2:

        这个级别的自动化软件测试被称作“伴随性的自动化”(incidental automation)。在第二个等级,自动化测试脚本被修改,但是没有文档化的标准或可重复性。在这个阶段使用的工具包括项目计划工具、捕获/回放工具、模拟器和仿真器、语法和语义分析器、调试工具等。

        新项目中自动化测试工具的引入没有经过计划、没有遵循一个流程。没有测试设计和开发的标准。没有考虑测试进度和测试需求的问题,或者在构思自动化测试工具的使用时没有参考测试进度和测试需求。和等级1一样,这种类型的自动化没有提供多少投资回报,或者说实际上增加了测试的工作量。

        自动化软件测试Level 3:

        这个级别的自动化软件测试被称作“有意识的自动化”(intentional automation)。在第三个等级,自动化测试是明确定义的,并且得到了很好的管理。测试需求和测试脚本来自于软件需求规约和设计文档。

        自动化脚本的创建基于测试设计和开发规范,但是测试团队不评审自动化测试过程。自动化测试成为可重用以及可维护的。在这个级别的自动化测试中,投资开始有回报,收支平衡的点可以在第二次回归测试周期中获得。这个阶段的工具类型包括需求管理工具、项目计划工具、捕获/回放工具、模拟仿真工具、语法语义分析器、调试工具等。

        自动化软件测试Level 4:

        这个级别的自动化软件测试被称作“高级自动化”(advanced automation)。这个等级代表了对于等级3的一个实践了的和完善了的版本,同时加上一条主要的改进——发布后的缺陷跟踪。在修改、测试创建和回归测试的整个流程中,缺陷被捕获和提交。软件测试团队成为产品开发的一个完整的部分,测试工程师和应用程序开发者协同工作来创建一个满足测试需求的产品。任何的缺陷都很早的被发现,从而降低修复的成本。除了上面等级提到的工具,缺陷和变更跟踪工具、测试过程产生工具和代码评审工具在这个阶段得到应用。

        自动化软件测试Level 5:

        这个阶段应用的工具,除了上面等级用到的工具之外,还包括测试数据产生工具、度量采集工具(例如复杂度度量等)、覆盖率和频度分析工具、缺陷分析和缺陷预防的数据工具。

  • [转]自动化测试策略

    2008-12-03 09:34:35

    作者:老徐 新闻来源:STTE  更新时间:2007-4-3 18:10:56

    工作周期及阶段确定:组长初步确定工作周期,并定义自动化测试的阶段,例如需求分析/设计阶段,开发实现阶段,运行阶段,而运行阶段中要根据所属系统所处软件生命周期的不同阶段来定义自动化测试的运行周期,例如当前处于所属系统的运营维护阶段(上线之后),其每3个月进行一次新版本的发布,则自动化测试亦为每三个月执行一次。或其每周进行一次Build的发布,则自动化测试亦为每周执行一次。

    分析自动化测试风险:根据所属系统的开发平台、界面特性、测试环境搭建维护的难易程度、测试工具的适用性等方面的分析结果进行自动化测试风险的分析。主要从战略层面进行风险的分析,不要分析某个具体的自定义控件的可测试性。

    手工测试现状复审:依据手工测试现状分析报告中提供的已有业务测试过程进行业务需求覆盖度的分析,判断已有业务测试过程是否完整,若不完整则需要向测试管理部提出反馈:被测系统的手工测试现状尚不符合自动化测试的需求,请求是否延期并委托手工测试方完善业务测试过程。

    测试方法及工具确定:根据所属系统的特点和当前自动化测试组织的实施能力,确定自动化测试的方法,例如业务驱动方法、关键字驱动方法、数据驱动方法;另外要结合现有的软件自动化测试专用工具,判断采用何种自动化测试管理工具搭建自动化测试的管理平台、运行平台,或者是新开发一种框架来实现自动化测试。

    编写文档:自动化测试分析师编制《自动化测试工作策略》

    内部评审:组长组织自动化测试工作小组的内部评审

    外部评审:组长向自动化测试管理组的计划控制经理提出评审申请,计划控制经理组织自动化测试管理组的外部评审,评审《自动化测试策略》,需要项目组、自动化测试小组和质量控制经理共同参与评审。

    组长将评审通过的《自动化测试策略》纳入配置管理库。

Open Toolbar