51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6160|回复: 11
打印 上一主题 下一主题

Selenium RC 开发框架

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-3-3 23:12:49 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
当使用Junit+selenium RC 进行测试时,所有的id都在代码中写死了,那么版本更新后将面临着巨大的维护量。我想写一个框架能集中管理这些对象,并且封装一些操作对象的方法,test里头就只需要调用这些方法组装成有逻辑的testcase即可。不知道有人这么做过没有,可行性有多大?我知道有个UI element的东西可以做,但是貌似还不如自己写个config的properties文件方便。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

12#
发表于 2011-5-5 13:32:52 | 只看该作者
我和鹰眼团队3人小组一起开发的鹰眼系统 就已经解决了 集大成者,自动化平台+自动化框架  对象库只是其中一个模块,增加了Excel参数化,支持预警系统,自动运行和手动运行都可以,用例跑不过支持短信、邮件和旺旺通知,正在增加Yslow统计功能
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2010-9-6 17:44:18 | 只看该作者
tellurium就是为了分离页面组件操作和测试逻辑而设计的。不必闭门造车吧。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2010-8-26 15:54:26 | 只看该作者
原帖由 irabbit 于 2010-8-26 15:50 发表
想问一下,你的想法是写properties文件,然后将所有常量, xpath之类等等放在里面,在java里面只是读取文件里面的值,对吗?以后修改也是修改一个文件里面的值,是这样吗?

有没有实际执行过?

放在库里,还包括数据,执行过,完全可行。这个你要设计一下所有这些数据的结构。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2010-8-26 15:50:35 | 只看该作者

回复 1# 的帖子

想问一下,你的想法是写properties文件,然后将所有常量, xpath之类等等放在里面,在java里面只是读取文件里面的值,对吗?以后修改也是修改一个文件里面的值,是这样吗?

有没有实际执行过?
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2010-8-24 11:54:59 | 只看该作者
java中用dom4j读取xml配置文件,之前写项目的时候用到的,不知道能不能在selenium上使用
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2010-3-4 22:23:05 | 只看该作者

回复 1# 的帖子

现在我们做的就是把自动测试和QC的框架整合到了一起,测试人员很方便使用,直接拖用例执行就好,等报告就好了。-----------------
不知道这个是什么意思,能不能再说说?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2010-3-4 22:21:27 | 只看该作者

回复 1# 的帖子

嗯,说的有道理。建一个框架的确成本很高,可是不建立维护量又很大,真是很难抉择。。。
不知道biscuit的解决方案是什么,能不能说详细点?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2010-3-4 21:38:42 | 只看该作者
楼上可否把解决方案写一下,让大家参考下,谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2010-3-4 18:00:16 | 只看该作者
这个问题我早已经解决了.
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-3-4 11:49:46 | 只看该作者
赞同楼上
回复 支持 反对

使用道具 举报

该用户从未签到

2#
发表于 2010-3-4 09:17:25 | 只看该作者
我曾经想做过,也有个设计,是封装selenium,完全用模拟简单的脚本命令模式来替代了脚本的开发工作,selenium和java脚本完全做成了一个解释执行器,把想要运行的操作、数据、和UI对象完全独立存于库中,动态组织成脚本运行,这些数据都是动态可配置的。这个东西做了一半,解释执行器都做好了,server端的配置构建器也差不多了,结果给头取消了。不过个人觉得这方向是可行的。
取消理由很简单:使用配置对QA来说很麻烦,减少维护量和增加灵活性的同时,却增加了使用工作量及难度,增加培训成本等。
我想了想,确实有这样的问题,其实测试框架是为测试服务,不是为了框架而框架,我觉得你要设计框架最好就是要抓住一个根本出发点来做,如果为了框架的某些优势而把工作量或难度转嫁到下游是得不偿失的,也没有意义,实际中也许测试员因为不好用而拒绝使用自动化了。
现在我们做的就是把自动测试和QC的框架整合到了一起,测试人员很方便使用,直接拖用例执行就好,等报告就好了。这个才开始做没多久,很简陋,但方向我觉得是对的。目前脚本的工作量全是脚本人员的,不过就俺一个。这样屏蔽了很多下游不需要做的事,其实是便于自动化推行的。目前我的做法代码基本是死code,很多功能都没考虑,等推行开大家用的好,自然会提很多需求,这样环境下改进,才是最有效直接的,比你单纯的想做这样的东西要好一些,其实有些软件不是设计和做的不够好,而只是不适合环境的使用而已。其实应用层软件的开发目标是为了——实用!
希望以上这些对你有所帮助,个人觉得一个更从实际和使用的角度去考虑你的框架作用,如果想去做个框架的话。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-26 12:11 , Processed in 0.072881 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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