发布新日志

  • 浅谈几种自动化数据准备的方法

    2012-07-31 15:42:16

    数据准备实现的几种方法

    数据准备是软件测试过程中非常重要的一个环节,特别是自动化测试。对于复杂的系统,数据准备会占用相当多的时间,因此好的数据准备工具对提高测试的效率非常重要。

    目前,数据准备工具实现方法主要有以下几个:

    1.         前端UI自动化脚本

    2.         通过DML操作数据库

    3.         调用应用提供的接口

    4.         通过发送请求方式

     

    一、UI自动化脚本实现数据准备:

    实现方法:

    通过UI的自动化脚本实现数据准备比较直观,并且能直接调用已经实现的UI自动化脚本代码。比如,测试搜索功能时,翻页是必需要测试的,而且测试翻页会涉及很多用例,比如单关键词,多关键词组合查询后,翻页是否保留初始查询条件等。当然,可以通过修改代码把每页显示条数减少测试翻页,但不严谨,易出问题,如若测试完成后代码没有改为原始值。

    对于这类问题,使用UI自动化脚本准备数据就很方便了。测试翻页前,首先多次调用添加数据的脚本,然后做后续必要操作,比如更新索引,更新缓存等。所有都通过后,进行查询操作,验证翻页是否正确。

    优点:

    1.         实现比较简单,UI自动化的框架和工具较多,并且有不错的录制回放工具,在录制的基础上再修改脚本就可以

    2.         数据完整性和一致性好

    3.         若已有相关功能的自动化脚本,可复用,节约时间

    缺点:

    1.         UI依赖大,执行效率低

    2.         变化频繁,维护成本高

    3.         复用性差,不利于其他测试,比如接口测试、性能测试调用

    4.         UI自动化测试结合紧密,很难成为独立的工具

     

     

     

    二、通过DML操纵数据库:

    实现方法:

    通过DML操纵数据库进行数据准备是很高效的,因为这种方法抛开了前端页面,抛开了程序逻辑,直接把数据写入DB,或者进行更新、删除等操作。以上搜索测试,使用这种方式准备数据,效率会很高,而且如果性能测试需要大量的干扰数据而非正常的业务数据,也可以采用这种方式。

    优点:

    1.         高效、直观。

    2.         复用性好,可被性能测试、接口测试等调用。

    3.         维护成本相对较低。

    缺点:

    1.         对于比较复杂的系统,表间关系依赖较多,字段间依赖复杂且多时,这样的方式往往会很复杂,一旦sql语句有问题,也会影响效率。

    2.         这样的数据被用于自动化测试时,可能与系统的实际功能不一致,导致验证失败。比如一般系统查询时先查缓存,返回结果。通过DML方式插入的数据,缓存不会自动更新,可能查询结果中没有新的数据。

     

    三、通过调用应用接口:

    实现方法:

    通过调用应用的hsf接口实现数据准备,这样方式可以很好的规避UIDML方式的缺点,实现比较高效而且与实际功能一致的数据。但实现相对难一些,需要对hsf接口有较深的了解。

    优点:

    1.         适用于复杂业务,更高效。

    2.         数据完整性、一致性好

    3.         复用性好,可被性能测试、接口测试等调用。

    4.         维护成本相对较低。

    缺点:

    1.         实现相对难一些,需要对接口了解较多;

     

    四、通过提交http请求:

    实现方法:

    提交http请求方式准备数据,相对于UI的方式效率较高,不需要等待页面、控件加载,而是通过程序语言直接提交请求,此时应用接收到的请求与用户通过页面操作提交的请求是一样的,因此程序逻辑均会被执行,如插入数据后会更新缓存等。这样的方式准备的数据完整性和一致性好。

    优点:

    1.         数据完整性和一致性好。

    2.         维护成本相对较低。

    缺点:

    1.         实现时相对麻烦,需要考虑cookie,tb_token等变量,比如创建订单需要用户信息,提交这个请求嵌,首先需要先发送登录请求,然后从response header中获取cookietoken,创建订单时需要带上cookietoken,这样应用才能认为是正常的请求,才会继续执行。

    2.         请求中包含的内容较多时,拼接请求也比较耗时,因此代码量相对较大

    3.         若服务器端验证浏览器安全控件时,如支付时,实现很困难。

     

    五:总结

                       每种准备数据的方法都有优缺点,实际工作中,可以灵活运用,把不同方法组合起来,比如创建订单时,可以使用调用hsf接口方式实现,但支付状态,可以通过sql语句,直接修改记录的方式实现(当然前提是不需要验证数据完整性和一致性)。

  • STAF+STAX安装和配置---运行STAFDemo

    2008-11-12 16:51:09

    安装完STAF后,可以通过运行Demo的方式检查STAF安装和部署是否正确。 STAF的Demo默认路径:C:\STAF\samples\demo

    • 在命令窗口运行:java STAFDemoController,启动Demo控制窗口
    • 本机的计算机名称自动显示在machine中,点击start启动Demo.
    • 启动完成后,弹出Arbitrary Process窗口
    • 运行过程中,修改主控窗口中的Variable中背景颜色,点击set后查看Arbitrary中背景颜色发生相应变化
    • 在远程机器中运行此Demo:修改主控窗口的机器名为远程的机器名,点击start
    • Arbitraty Process窗口出现在远程机器中。修改Variable的背景后点击set,查看远程机器的Arbitrary的背景。

    如果Demo运行没有问题,则STAF安装正常,如果远程无法运行,首先需要查看2台机器的staf.cfg, 机器之间需要设置了level 5 trust.

  • STAF+STAX学习笔记二 ---STAF配置

    2008-11-11 16:59:40

    STAF配置文件是staf.cfg,window下默认的路径为:c:\staf\bin\.

    安装完staf后,为了实现多台机器通过staf统一测试和管理,需要修改staf的配置文件,

    以2台机器为例,进行配置:host1:10.62.162.55 host2:10.62.162.65

    • 2台机器上均已经安装了Staf,且运行正常
    • 通过修改staf安装目录(默认c:\staf\bin)下的staf.cfg这个配置文件实现
    • 首先把每台机器的staf.cfg中增加另一台机器的信任级别: 如: trust machine tcp://10.62.162.65 level 5
    • 保存后,重新启动staf. 确认运行正常
    • 在command中运行:staf local trust list,查看信任的机器,新增加的机器名显示在列表中
  • STAF+STAX学习笔记一 ---STAF安装

    2008-11-11 16:30:06

    STAF:Software Testing Automation Framework,软件测试自动化框架,是一个开源的,支持多种平台,多种语言的框架;主要围绕着可重用组件和服务(如过程调用,资源管理,日志,监视) STAF 采用点对点的实现机制,被用来减轻自动化测试的工作负担,加快自动化测试的进程。在 STAF 的环境中,所有的机器都是对等的,没有客户端和服务器的区分。(详情参见:http://staf.sourceforge.net/ Staf站点)

    我是安装在window环境上,安装过程比较简单:

     1、下载相应的STAF:http://staf.sourceforge.net/getcurrent.php,推荐下载绑定JVM的版本

     2、运行下载的.exe文件,之后Next,Next... Done

     3、安装完成后,在安装目录默认是c:\staf下查看install.properties,检查安装的版本与OS是否一致

     4、运行STAFEnv.bat,设置环境变量

     5、运行startSTAFProc.bat启动STAF

    安装完成后,以后staf会随着机器启动自动启动,如果希望手动启动,可以通过msconfig修改。

    参考:崔俊涛的《利用 STAF 实现程序更新包的自动部署测试》
    http://www.ibm.com/developerworks/cn/opensource/os-cn-staf/index.html?ca=drs-cn

     

  • STi的一个bug?

    2008-10-15 14:14:05

    用ruby+watir写自动化测试脚本时发现一个问题:

    定义一个类的方法时,忘记了一个带有默认值的参数,后来试图添加这个参数,但每次添加时,都会引起STi crash:

    最初代码如下:

    require 'watir'

    class Addworkitem
      def additem(team,project,projectdesc,pjalltime,pjextratime,other='',otheralltime=0,otherextratime=0)
        begin
         $ie=Watir::IE.new()
         $ie.goto("http://.....")
         sleep 1
         $ie.maximize()
         $ie.table(:id,'zz11_NewMenu_t').link(:text,'新建').click()

         ........ 

        rescue
         raise
        end
      end
    end

    运行时发现other=''后缺少一个参数otherdesc, 在sti中添加otherdesc='desc'

    时,输入otherdesc=后,继续输入', sti就crash了,反复试了很多次,都会crash.

    在其他的机器上尝试,出现同样的问题。    

  • 拨开迷雾,把你看清楚--写测试脚本时注意分析源代码(原创)

    2008-10-10 23:52:46

    用ruby+watir写测试脚本时,如果对html代码不时很熟悉,就会被控件UI显示方式迷惑,写代码时就根据显示方式写脚本。

    容易造成迷惑的主要有以下几个方面:

    1、button和img,link

    比如,一个看起来是button的控件,实际可能是一张图片,如果采用ie.button()的方式,就无法捕获该控件;反之亦然。因此需要查看源文件,确认是button还是img,link等

    2、frame和iframe

    如果只看UI,页面由几个frames组成,或者嵌入iframe时,直接通过ie.XXX的方式,无法捕获iframe中和其他frame中的element, 此时,需要首先获取frame, ie.frame();然后再对其中的元素进行操作

    3、编辑器

    有些编辑器为了UI美观和控制按钮,内容输入框经常一个hidden的textarea,上边是iframe或者其他代码,如果仅仅通过ie.XX是无法获取到的。这时,可以采用直接给textarea赋值的方式。

    ie.text_field(:xpath, "//textarea[@id='XX']/").value='XXXXX?'

    这种方式在运行时,无法看到输入操作,但提交数据没有问题。 也许还有其他的方式,不过目前还没有找到,:)

     

  • watir使用中WindowHelper类处理弹出窗口的方法无法使用问题分析与解决

    2008-09-19 19:16:18

    写自动化脚本时,经常遇到各种类型的弹出窗口,查看watir的安装目录(C:\ruby\lib\ruby\gems\1.8\gems\watir-1.5.6\watir)发现有几个相关的类,

    主要包括:windowhelper,windowclicker等。 查看原文件发现,Windowhelper中包含了多种处理弹出窗口的方法,于是决定使用较简单的一种:

    代码如下:

    @ieq.div(:id,'ks-main').div(:id,'content').div(:id,'main').div(:id,'question').div(:class,'bd').div(:class,'actions').div(:class,'l').link(:text,'关闭问题').click

    Thread.new{

    @aa=WindowHelper.new

    @aa. push_confirm_button_ok

    }

     

    但运行时,点击关闭问题后,Thread都不会点击弹出窗口的回车按钮。

     

    不用WindowHelper,自己写调用Win32oleautoit的脚本,运行仍然不成功。 试了很多办法都不成功,被这个问题困扰了一天,终于在国外网站上找到原因,

    原因如下: 调用WindowApi时,会阻止所有的ruby线程,watirclick_no_wait()就是通过进程实现的。

     

    既然如此,有2种解决办法:

    1、   click 改成click_no_wait ,其他不变,这种方法比较简单

    2、   Thread.new 中启动进程:

    Thread.new {

       System(rubyw –e  ….. )

    }

Open Toolbar