51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: benwu
打印 上一主题 下一主题

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

[复制链接]

该用户从未签到

21#
发表于 2008-8-26 10:47:52 | 只看该作者
如果项目的系统是涉及到很多界面层的自动化测试,不知道这个UT ROBOT是否能有效支持?
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2008-8-31 01:22:01 | 只看该作者
好像很神奇的样子哦,努力学习ing……楼主太强了,佩服佩服!
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2008-9-1 10:43:52 | 只看该作者
原帖由 陈能技 于 2008-8-26 10:47 发表
如果项目的系统是涉及到很多界面层的自动化测试,不知道这个UT ROBOT是否能有效支持?


同问 对于GUI测试 这个架构能否一样适用?
回复 支持 反对

使用道具 举报

该用户从未签到

24#
 楼主| 发表于 2008-9-17 23:50:07 | 只看该作者
有一段时间没有上来了,前段时间去杭州参加了公司组织的持续创新比赛,UT ROBOT项目作为唯一一个软件测试项目,从初赛的300多个项目中脱颖而出进入16强,最终获得了铜牌成绩,我们的软件测试架构获得公司上下的肯定,也为团队赢得了外出旅游的奖金。
   
    在这里回答帖子中同行所提出的问题:

    1.你提到此框架已经应用于若干项目中,想问一下这些项目是完全不同的项目么?还是框架的实现本身已经包含了对这些项目中共同点的一些假设?
    UT ROBOT强调的是框架,并不是仅为某个应用设计,应用的项目有相似的,也有不尽相同的。当然,对于软件产品,不管怎样都是有相通之处的,对于框架的设计,就是要对不同的软件产品进行高度的抽象,以尽量满足大部分软件产品测试的需要。同时我们也要承认,没有任何一个工具或者框架是放之四海而皆准的,所以,这也是我所提倡的架构要为产品服务,只有根据不同公司的产品特点来进行开发才能提高测试框架的适用性,否则就很容易出现水土不服的情况。测试框架必须来源于对测试深刻理解,象我们即使从事多年软件的测试,每天都会不断的涌现出新的想法,每天看着做出来的框架还是有很多可以改进的地方,试想如果只是简单使用了商用的架构,要把新的想法融合进去是非常困难的。
   
    2.关于CASE的自动生成,是不是主要是测试数据的不同组合,也就是场景相同,测试数据不同的情况?
    Test Case的主要有几个元素:预设场景,数据集合,数据处理,收集结果,环境清理,结果检查点;这些都是UT ROBOT考虑的重要因素,当然还有一点非常非常重要的也是容易被忽视的就是Case的版本控制,这点我将在后面专门阐述。通过实现以上的要点,可以灵活的跟据具体的情况,针对不同的数据组合结合部同的测试场景来自动生成CASE。

    3. 对于GUI测试这个架构能否一样适用?
    简单的说,可以;大家都知道GUI的测试是要有专门的GUI模拟技术来支持,UT ROBOT的核心在于数据,所以通过UT ROBOT+RUBY+WATIR的结合,利用WATIR+RUBY进行封装,通过UT ROBOT进行关键字驱动,从而实现对GUI测试的支持,这个工作正在进行当中。
   
    这里我想重点说说Test Case的版本控制问题,这也是UT ROBOT最新支持的重要特性。在我们的软件产品中,Test Case的版本涉及到以下几方面的版本变更:
    1.被测试软件本身的版本变更;
    2.不同语言版本的变更;
    3.不同国家版本的变更;
    4.不同业务的版本变更;
    5.不同应用模式的版本变更;
    6.不可预期的版本变更...
    对于以往的一些测试工具或者架构,以上任何一方面的版本变更都会带来极大的Case维护代价,大家常见的是被测试软件本身的版本变更,这里就不多说;就举不同国家版本的变更来说,我们的产品应用到不同的国家地区,如台湾、巴西、菲律宾、智利等等10几个国家,每个国家的应用模式都不一样,同样的测试参数在不同国家的应用方式都不一样。如果为每个国家都去维护一套CASE的话,不难想象,这种维护量是致命的,更加致命的是还有很多是不可预期的版本变更,这样会带来极大的维护工作,对于传统的通过业务脚本去实现测试业务逻辑的方法而言,版本变更就愈加显得力不从心了,试想,一个业务逻辑的变更要导致10几个国家版本的CASE的变更和其它因素的变更,这种变更CASE的代价就很有可能抵消自动所带来的好处。UT ROBOT考虑到以上的变更因素,尤其是不可预期的版本变更,通过扩展框架数据结构,实现了非常灵活的版本变更管理,只需要维护一套CASE就可以轻松应付以上的种种变更因素,其实现的原理是通过引入变量和条件表达式的方式来处理各种变更情况,从而达到只需要维护一套CASE就可以适用于不同的语言、不同的国家、不同的业务、不同的应用模式的情况。   
   总结一下,一套健壮的框架需要对测试知识进行高度的抽象,考虑的因素越多,框架就越容易扩展,当然,实现的难度和代价也就越大。和不同的人交流,有助于我们在设计及实现框架的时候少走一些弯路,正所谓:三人行,必有我师焉!
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2008-10-7 11:11:52 | 只看该作者
楼主能否讲解一下该架构的实现原理呢?
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2008-11-5 20:28:10 | 只看该作者
顶 期待楼主更新!
回复 支持 反对

使用道具 举报

该用户从未签到

27#
 楼主| 发表于 2009-2-23 16:49:56 | 只看该作者
有一段时间没有更新了,在这里给大家继续汇报一下UT ROBOT的进度,希望与有兴趣的朋友继续交流


灵活支持不同类型的应用程序:
1.接口类型测试
2.面向过程应用测试
3.Web Service测试
4.Web GUI测试
5.回归测试


特点:
1.无需编写脚本
2.轻易支持新应用
3.关系型数据驱动
4.自动产生CASE脚本
5.CASE版本管理
6.灵活的结果检查点管理
7.支持多用户
8.动态日志跟踪
9.运用于多个项目测试

“五年磨一剑,鼠标一点,轻轻松松完成新功能测试及自动化测试”

截图1:增加新应用

截图2:灵活版本管理,支持主线开发及分支开发



截图3:灵活的测试任务管理




截图4:轻松的CASE执行方式


截图5CASE脚本的动态编译及实时查看



截图6:灵活的CASE选择



截图7:动态日志跟踪


截图8:轻松的结果检查点配置












[ 本帖最后由 benwu 于 2009-2-23 18:04 编辑 ]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2009-2-23 17:38:15 | 只看该作者
截图怎么没有。。。
回复 支持 反对

使用道具 举报

该用户从未签到

29#
 楼主| 发表于 2009-2-23 18:09:42 | 只看该作者
图片看不到可能是图片文件太大的原因,已经缩小图片的尺寸
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-16 09:59 , Processed in 0.069428 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表