• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 测试工具QTP与WinRunner的比较(转)

  2008-8-28

   

  
  

  本文是我很早以前整理的，因为今天在论坛上有位朋友问到相关问题，因此贴出来供大家参考。由于写作时间有点早，之后也没再深入学习过这两个工具，因此如果文中有错误之处，还望各位批评指正！
  
  QTP，全称为Quick Test Professional，它与WinRunner同为MI公司开发的功能强大的功能测试工具。从时间上来看，WinRunner在1995年便已经推出，远早于QTP，而QTP直到2002年才正式推出。从MI公司提供的一些官方资料来看，虽然他们宣称暂时不准备淘汰WinRunner，但他们的宣传资料上又明确表示，QTP已经具备了WinRunner中几乎所有的特性，同时具备了一些独有的特性，并且总体来说，使用更简单、更易扩展和维护，推荐新用户使用QTP，并建议已使用WinRunner的老客户逐渐实现转换。由此看来，MI公司实际上已经有使用QTP逐步取代WinRunner的计划。更重要的是，QTP对J2EE，.NET架构的应用程序支持得比WinRunner要好（从我实际的试用过程中，也感到确实是如此），因此我认为，从我们公司的实际情况出发，针对产品综合部今后将逐步开展自动化测试的计划，QTP应该是一个比较好的选择。
  
  不论是WinnRunner还是QTP，它们都是功能十分强大的测试工具，加上目前国内关于测试工具的培训和文档资料，实在是少之又少，因此要完全了解和掌握它们，绝不是一朝一夕的事情。在这里我只能就目前对它们的理解程度粗略地介绍一下二者的两点主要不同之处。
  
  1、       使用的脚本语言不同。WinRunner使用的是TSL语言，这是MI公司独有的语言，有特殊性，因此在学习上会有一定难度，不过好在它与C 语言比较类似，如果测试人员有一定的C语言编程基础，会相对容易一些。而QTP使用的则是微软的VBscrīpt语言，比较通用，而且也相对简单易学。从语言上的比较上来看，我个人觉得在编程能力上，WinRunner更胜一筹，因为它拥有相当丰富的C语言函数库，而相对而言，QTP则更大众化，它面向的是没有太多技术背景和编程经验的测试人员。
  
  2、      QTP8.0具有的一大特性：关键字驱动测试（keyword-driven testing）。它的具体操作方法我将有另外的文档详细说明，这里只是简单介绍一下。通过“关键字驱动测试”，测试人员不需要“录制”测试脚本，而可以改成“设计”测试脚本。即：先将应用程序的GUI对象添加到QTP的对象仓库（Object Repository）中，然后针对每一个需要操作到的对象设计每个测试步骤。我个人感觉，这的确是一个很酷的特性，它使我们可以不必实际去操作应用程序，就可以编写出测试脚本，这样做既节省了时间，而且还有一个更大的好处就是可以在应用程序还没有设计完成，或者由于出错无法正常执行的时候仍然可以编写我们的测试脚本。应用程序只需要有使用界面（UI），而不必实际运行，测试人员就可以开始建立测试脚本，为我们实施自动化测试赢得更充足的时间。而在 WinRunner中，虽然也可以采用先学习对象，然后编写代码的方式来完成测试脚本，但这样做要求测试人员对TSL语言比较熟悉才做得到，远不如QTP 来得简单。在实际的操作中我还发现，有些时候采用录制的方法无法捕获对应用程序的操作，此时改用关键字驱动测试却可以收到不错的效果。
  
  3、相对WinRunner，QTP还具有很多优点，例如“数据表整合”，“Active Screen”，“point and click”，更容易参数化等等，但对于这几点我还没有深入的做过比较，如果今后我对此有了更多的体会和了解，我将再作整理。
  

  查看(37) 评论(0)

• 开放性敏捷自动化测试架构介绍(转)

  2008-8-28

  本人主要是侧重电信领域的软交换及BOSS业务的测试，从本人多年所处理的现场问题来看，在现场发生的约80%的问题来源于软件版本升级后引入的新功能带来的对老功能的影响，有过不少沉痛的经验教训。
        我们公司曾经设置过专门的自动化测试部门，轰轰烈烈的从事自动化平台的开发，基本上发动了测试部门的所有同事从事测试CASE的脚本开发，时间力行半年，结果由于众所周知的原因，整个自动化体系以失败告终，最后，该自动化测试部门也就无疾而终了。我总结了一下，主要是下面的原因造成，这基本上也是行业内不同公司实施自动化失败的主要原因：
  
        1.自动化平台的思路缺乏创造性，基本上都是以脚本编写CASE，录制回放为主。
  
        2.传统的自动化体系存在以下成本因素，导致自动化的投入产出比较高，从而制约了自动化的有效实施
  
        2.1 开发成本
  
        2.2 调试成本
  
        2.3 维护成本
  
        2.4 培训成本
  
        2.5 规范化成本
  
  
      众所周知，BOSS系统以业务众多为主，以业务受理单一个接口为例，我们的测试案例库就存在不下3000个CASE，如果通过传统的编写自动化脚本来进行CASE转化的话，从我们以前实施的代价是：由于每个CASE都要涉及到脚本编写，环境清理，环境设置，结果检查，调试等几个步骤，一个人一个月能完成的CASE不过50个，一旦应用的业务发生变化，相关的CASE也就作废了，在这种情况下，大家也就清楚了自动化为何操作不下去的原因了.
  
  
      通过分析传统自动化所固有的缺陷，我重新定义了自动化架构的核心新思路：自动化架构必须实现CASE的产生，执行，结果检查三大要素的分离。我把新自动化的架构命名为ROBOT，无巧不成书，IBM也存在名字为RATIONAL ROBOT的一个架构产品，文章后面，我把我们的UT ROBOT和IBM的RATIONAL ROBOT的特性进行了比较。
  
      通过将近六个月左右时间的开发，这个架构基本开发成功，并应用到了10多个应用的接口测试中，发现了超过200个问题，实现了以下功能：
  
      1.对新应用的接口支持只需要不到2周的时间
  
      2.以通用模板为基础，所有CASE自动产生
  
      3.结果检查点自动产生，可以快速产生包括100万的结果检查点
  
      4.可支持多协议
  
      通过ROBOT框架测试过的产品在多个现场实施之后，竟然在半年的时间内没有报过任何一个问题，以前1个月都跑不了100个CASE通过ROBOT框架可以在2天的时间内完成3000个CASE,50万结果检查点的检查，这点也印证了这篇文章的标题：开放性敏捷自动化测试架构
     
     下面是传统自动化体系与ROBOT架构的特性比较：
             传统自动化体系                       UT ROBOT通用架构  
  ============================================================
  CASE生成  全部CASE需要脚本支持                 无需脚本支持  
  数据驱动  比较困难，不同的应用需要写大量的代码  采用强大的模板解析引擎，数据驱动轻而易举  
  继承性    自动化脚本容易被测应用的变化而失效    应用逻辑变化只需要调整数据  
  可读性    不同的脚本编写人员有不同的编码风格    全部基于数据表达，清晰易懂  
  自然语言  不支持                                支持，设计CASE的自然语言可以通过解析器识别，所见即所得  
  CASE转化 比较死板，需要逐一CASE编写脚本        采取全新的自动化思路，CASE转化交给机器  
  扩展性    增加新的应用需要写大量的脚本          只需对应用进行模板定义  
  CASE维护  难以维护，需要大量的管理成本         基于数据，维护成本很低  
  CASE执行  需要很多时间提前准备环境             可以快速执行  
  检查点设置  比较单一，通常与CASE写在一起       CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本极低  
  可靠性     不可靠，因为检查点比较单一           可靠，通过数据库跟踪技术，可以确保检查精确到字段级别  
  
  下面的是IBM RATIONAL ROBOT与UT ROBOT的特性比较   
            IBM RATIONAL ROBOT                      UT ROBOT  
  CASE生成  全部CASE需要脚本支持                         无需脚本支持  
  后台应用   不支持                                       主要支持  
  开放性     较好                                         较好  
  数据驱动   支持，不太方便                               采用强大的模板解析引擎，数据驱动轻而易举  
  可读性     不同的脚本编写人员有不同的编码风格           全部基于数据表达，清晰易懂  
  自然语言   不支持                                       支持，设计CASE的自然语言可以通过解析器识别，所见即所得  
  扩展性     比较困难，因为是商用产品                     比较好，可根据不同的需求进行扩展  
  检查点设置  优于传统，但不太灵活                        CASE产生与检查点相分离，极低的耦合度，检查点强大无比，维护成本低  
  

   

   

   

   

  BOSS是指为电信运营商提供的营帐支撑系统，因为移动电信的业务的特点是业务非常复杂，有成千上万的价格计划套餐，计费也比较复杂，后台的支持网元有上百个，我们现在整套BOSS系统能支撑软交换，GSM，IPTV等等多业务，现在的BOSS相关网元已经超过300个，所以接口是非常多的，因为这种特点，所以接口协议和后台数据的测试就是主要方面
  
       UT ROBOT的主要成绩体现在我们通过ROBOT回归的部分网元，在现场实施之后几乎没有再报回归方面的遗漏问题。BUG下降了85%，因为有了这个数据说话，所以坚定了我们在这个架构上的信心
  
    
  
      UT Robot强调的是框架，也就是可以适用在多个应用，多业务的测试中，即使不是我们公司的产品也可以应用   
  
      自动化测试需要考虑以下方面：
      1.CASE执行前的环境准备：这是为了保证批量测试的时候不影响其它CASE的执行
      2.CASE执行后的环境清理：这也是为了保证批量测试的时候不影响其它CASE的执行
      3.结果检查点：非常重要，这是测试准确性的根本
      4.参数的组合关系：只有可以自由组合CASE，才能覆盖各种场景
      5.核心思想：CASE的生成，执行，结果记录，以及回归要分离
  
      6.协议无关：具体完成协议发送的功能与框架想分离
  
      7.业务无关
  
      现在Robot已经应用到我们BOSS的部分网元的测试中，并且做到了与协议和业务无关，我们现在的效率是，一周之内就可以支持新的简单网元的自动化测试。
  
      举例：对于WebService的SOAP接口测试，通过CASE的生成，执行，结果记录，以及回归要分离，可以实现数据库基本的所有字段的测试。可以在短时间内完成40个接口，超过5000个CASE的生成，生成的CASE中包括：枚举值、边界值、异常值、各种自定义组合的CASE，这个测试效果非常好，不仅发现了大量的功能问题，同时也发现了大量的版本变更过程中回归业务的问题。因为ROBOT在实现功能测试的同时也要支持自动化回归测试，当然，这是要求测试人员按照规范来写的。
  
     
  
      因为采用的是模板定制测试数据的方式，测试人员不需要编写任何代码，只需要关注业务层面，即使webservice发生了变化，也只需要进行数据的变更就可以了，同时数据的版本管理可以很好的适应不同版本的变化情况。
  
      为了更好的说明，我把测试环境中的数据拿出来说明一下，下面是SOAPSERVER几个CASE的返回结果，如第1个case，caseid=InsertAddress_2  从WEBSERVICE返回的值是1，可能有些人认为这个CASE就算PASS了，实际，这还远远不够，我们需要关注的是数据级别的变化，因此，我们需要另外的手段去记录所有数据库变化的情况，一个CASE，所涉及到的结果检查点就达到几十甚至上百个。
  
    
  
      说到这里，大家应该明白了，UT ROBOT的特点是将结果检查点与CASE的回归执行时相分离的，否则在一个CASE中同时包含了上百个结果检查点的检查，得写多少脚本才能完成，维护代价得多大？
  
    
  
      在这里，还得提到我们的数据库变化追踪技术(就是一次接口的请求带来的后台数据库的所有表所有字段的变化情况)，这个技术保障了所有结果检查点的完整性。
  
  
  CASESET     CASEID CASETYPE VERSIONID TYPE PARATYPE RESULT
  1 SAMSOAPSERVER InsertAddress_1.1_0_0 IMPORT 1 -1600  
  2 SAMSOAPSERVER InsertAddress_2.1_0_0 IMPORT 1 1  
  3 SAMSOAPSERVER InsertAddress_2.1_1_0 IMPORT 1 1  
  4 SAMSOAPSERVER InsertAddress_1 IMPORT 1 1  
  5 SAMSOAPSERVER InsertAddress_2 IMPORT 1 1  -1 -1555
  6 SAMSOAPSERVER UpdateAddress_1.1_0_0 IMPORT 1 1  
  
  
  下面是对CASEID=InsertAccount_1的具体表的具体数据的结果，只有到了字段级别的检查才是有效的结果检查
  CASESET CASEID CASETYPE VERSIONID TABLE_NAME FIELD_NAME VALUETYPE UNITE_KEY_VAL LAST_VALUE LAST_VALUE2
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=114  sdf
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CANCELDATE 3 ACCOUNTNUM=114  
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=114  
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREATEDATE 3 ACCOUNTNUM=114  2008-05-29 00:00:00
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=114  30
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=114  2008-05-29
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=114  2323
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=114  UTStar_SST_Rain
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=114  20
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=114  2008-06-20 06:53:55
  SAMSOAPSERVER InsertAccount_1  1 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=114  654
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITCARDNUMBER 2 ACCOUNTNUM=109  2323
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITLIMIT 1 ACCOUNTNUM=109  30
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREDITEXPIREDATE 2 ACCOUNTNUM=109  2008-05-29
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT ACCOUNTNAME 2 ACCOUNTNUM=109  UTStar_SST_Rain
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CREATEDATE 3 ACCOUNTNUM=109  2008-05-29 00:00:00
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT AVERAGEUSAGE 1 ACCOUNTNUM=109  20
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT BILLINGMONTH 2 ACCOUNTNUM=109  
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT BILLINGADDRESSID 1 ACCOUNTNUM=109  642
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT ACTIVATEDATE 3 ACCOUNTNUM=109  2008-06-20 04:58:19
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CONTACTPERSON 2 ACCOUNTNUM=109  sdf
  SAMSOAPSERVER InsertAccount_1  2 ACCOUNT CANCELDATE 3 ACCOUNTNUM=109

  查看(61) 评论(0)

• QTP自动化测试流程(转)

  2008-8-28

   

  1）准备TestCase
          - 在进行自动化之前，将测试内容进行文档化，不建议直接录制脚本
          - 在录制脚本之前设计好脚本，便于录制过程的流畅
          - 由于测试用例设计和脚本开发可能不是同一个人完成，便于团队合作
          - 便于后期的维护
          - 文档化的方式：TD或者文档
   
  2）配置QTP
          QTP支持不同的开发环境，在正式录制之前，需要根据被测程序的开发环境，选择合适的Add-In，并进行加载。
   
  3）录制脚本
          启动QTP的录制功能，按照Test Case的操作步骤描述执行，QTP自动记录每一步操作，并自动生成VBscrīpt脚本。
   
  4）修改增强脚本
          刚刚录制好的脚本可能包含错误，或者没有达到预期的目的，这就需要在录制脚本的基础上，进行修改增强
          - 删除录制过程中多余的以及错误的操作，以最少的脚本完成任务
          - 如果前面操作的输出是后面操作的输入，则需要使用变量或者输出值来进行替换
          - 不是所有的操作都可以通过录制产生的，有些需要通过手工编码实现这些功能
          - 录制产生的脚本是线性的，可以加入条件、循环控制语句，实现更复杂的流程
          - 对脚本进行结构化
          - 加入注释，便于阅读和维护
   
  5）调试脚本
          - 回放通过的脚本，不一定是正确的，也可能会包含错误
          - 在测试脚本正式使用之前，要保证其本身的正确性
          - 避免测试脚本故障和被测程序故障搅在一起，不容易定位
   
  6）回放脚本
          - 对于回放的错误，不要急于马上提交Bug，首先要判断是脚本本身的错误还是程序的错误，确认后再提交。
   
  7）脚本维护
          - 随着工作的不断推进，脚本量会越来越多
          - 被测试程序的不断更新，也需要更新相应的测试脚本
          - 采用版本管理工具保存脚本，如CVS、VSS，可以随时获取历史版本
          - 采用统一的脚本架构
          - 采用统一的命名规范
          - 添加充分的注释，避免时间久了，自己都不能马上读懂脚本

  查看(42) 评论(0)

我的主题

• winrunner需要参数化和关联吗?
• 反对下载扣分