• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

开放性敏捷自动化测试架构介绍

发布: 2008-7-07 12:11 | 作者: 网络转载 | 来源: 测试时代采编 | 查看: 103次 | 进入软件测试论坛讨论

领测软件测试网

  最近阅读微软关于自动化存在明显差异的两派讨论,对微软内部的争论不便置评。我所从事的领域与微软的有一些差异,主要是侧重电信领域的软交换及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的一个架构产品,我事先是不知道的,文章后面,我把我们的ROBOT和IBM的RATIONAL ROBOT的特性进行了比较。

    通过将近六个月左右时间的开发,这个架构基本开发成功,并应用到了10多个应用的接口测试中,发现了超过200个问题,实现了以下功能:

    1.对新应用的接口支持只需要不到2周的时间

    2.以通用模板为基础,所有CASE自动产生

    3.结果检查点自动产生,可以快速产生包括100万的结果检查点

    4.可支持多协议

   

    通过ROBOT框架测试过的产品在多个现场实施之后,竟然在半年的时间内没有报过任何一个问题,以前1个月都跑不了100个CASE通过ROBOT框架可以在2天的时间内完成3000个CASE,50万结果检查点的检查,这点也印证了这篇文章的标题:开放性敏捷自动化测试架构

      下面的表格是传统自动化体系与ROBOT架构的特性比较:

 

传统自动化体系
ROBOT通用架构
CASE生成
全部CASE需要脚本支持
无需脚本支持
数据驱动
比较困难,不同的应用需要写大量的代码
采用强大的模板解析引擎,数据驱动轻而易举
继承性
自动化脚本容易被测应用的变化而失效
应用逻辑变化只需要调整数据
可读性
不同的脚本编写人员有不同的编码风格
全部基于数据表达,清晰易懂
自然语言
不支持
支持,设计CASE的自然语言可以通过解析器识别,所见即所得
历史CASE转化
比较死板,需要逐一CASE编写脚本
采取全新的自动化思路,CASE转化交给机
扩展性
增加新的应用需要写大量的脚本
只需对应用进行模板定义
CASE维护
难以维护,需要大量的管理成本
基于数据,维护成本很低
CASE执行
需要很多时间提前准备环境,CASE执行方式单一
可以快速执行
检查点设置
比较单一,通常与CASE写在一起,维护成本非常高
CASE产生与检查点相分离,极低的耦合度,检查点强大无比,维护成本极低
不可靠,因为检查点比较单一
可靠,通过数据库跟踪技术,可以确保检查精确到字段级别

 

 

      下面的表格是IBM RATIONAL ROBOT与ROBOT的特性比较

 

IBM RATIONAL ROBOT
ROBOT
CASE生成
全部CASE需要脚本支持
无需脚本支持
后台应用
不支持
主要支持
GUI应用
主要支持
下阶段支持
开放性
较好
较好
数据驱动
支持,不太方便
采用强大的模板解析引擎,数据驱动轻而易举
可读性
不同的脚本编写人员有不同的编码风格
全部基于数据表达,清晰易懂
自然语言
不支持
支持,设计CASE的自然语言可以通过解析器识别,所见即所得
扩展性
比较困难,因为是商用产品
比较好,可根据不同的需求进行扩展
检查点设置
优于传统,但不太灵活
CASE产生与检查点相分离,极低的耦合度,检查点强大无比,维护成本极低

 

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 架构 自动化 开放性


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网