空间管理您的位置: 51Testing软件测试网 » 阿里巴巴QA架构组成长空间 » 日志

记录阿里巴巴QA架构组成长点滴。2008年关键词为效率，技术，影响力！QA/测试架构师定义:开发和设计测试框架测试库；纵横全局的考虑产品的功能，设计复杂的测试系统；负责研发某一项特定的测试技术；为公司考虑如何提高测试效率。领导公司测试技术的发展和测试策略上的方向,关注整个公司的测试部门的问题,前瞻性的考虑未来的版本的测试策略和技术。测试架构师计划/设计测试平台，关注着产品的测试过程，提供咨询服务，影响到公司内的测试机构测试社区，以及开发机构等，对产品各个方面施加深远而正确的影响，最终提高整体软件质量。

自动化测试议题

上一篇 / 下一篇 2008-03-18 12:57:58 / 个人分类：自动化测试框架与实现

查看( 811 ) / 评论( 8 ) / 评分( 0 / 0 )

1）如何有效统计自动化测试成本效益

A 缺乏比较精细的历史数据支持

B 外部因素在变化，比如手工测试人员技能变化、流程变化...

C 自动化运行次数未知

....

2) 如何评价自动化测试框架优劣

通常，我们会用扩展性、稳定性、可测性等等指标衡量一个应用系统。但自动化框架是否也有自己的一些特有的评价指标呢？

3) 如何和各测试组协作，让自动化测试项目在有测试项目压力以及技能不整的情况下，高效运作

参与业务需求整理和脚本开发的同学都肩负多个任务，当自动化开发遇到项目测试时，自动化时间比较难得到保证？

另外，参与自动化测试项目的同学对自动化的认识以及技能也不一样的。

综合各种情况，我们有更好的措施确保项目良好运作?

4) 如何在基础的数据积累平台还没有搭建的情况下，获取更多有意义的数据

如何降低自动化测试各个环节数据的误差程度？

5）如何为QTP脚本提速？

整个网站的自动化脚本期望30分钟内完成，这个愿望是否有足够的判断依据？兄弟单位的情况如何呢？除了增加硬件以及性能外，对QTP或者VBscrīpt 脚本进行profile以及提速呢？

6) 自动化测试当中碰到的一些技术问题

如excel sheet名称如何突破32个byte长度的约束？

相关阅读:

自动化测试框架说明 (xmtang, 2007-11-20)
推荐Badboy进行WebUI自动化 (luxuabc, 2007-12-07)
QuickTest Professional 自动化对象模型 (neusoftiger, 2008-1-09)
QTP中的datatable (chenjie021, 2008-1-18)
用QTP获得HTML的TAG属性值并验证 (qaarchitech, 2008-2-27)
结合excel驱动与数据池，来做场景调度 (qaarchitech, 2008-2-27)
上传svn前，脚本的清理工作 (qaarchitech, 2008-2-27)
使用WshShell对象取获取Windows环境变量 (qaarchitech, 2008-3-14)
QTP中对识别为WebElement的对象进行输入操作的一种解决办法 (qaarchitech, 2008-3-17)

收藏举报

TAG: 自动化难题自动化测试框架与实现

引用删除 lantianwei / 2008-03-22 15:10:20: TO qaarchitech
我下个星期去面试,先去看下吧!呵呵.....

引用删除 qaarchitech / 2008-03-22 11:14:09: 另外，lantianwei 来杭州阿里巴巴日文站技术部面试了么？
呵呵，或者你乐意先做功能测试然后再争取做自动化测试我们也很欢迎

引用删除 qaarchitech / 2008-03-22 11:10:35: lantianwei 说的很有见地。
1
我们当下速度平均一个业务流1分钟，主要慢在一个业务流需要很多个对象识别上。
QTP设置本身已经是放到FAST了。
所以我们正在考虑 PROFILE 代码已经减少IO 操作上。
2 数据库本身的数据关联关系没有EXCEL这么直观。况且平台当下还没有搭建起来。还有一个重要的原因，还没有出成绩之前大动干戈不划算，哈哈

引用删除 lantianwei / 2008-03-21 09:39:07: to liangjz
1.不知道你们的脚本运行慢是什么原因导致的,是QTP本身呢还是由于脚本处理逻辑和数据交互浪费了时间?如果是前者,可以通过设置QTP实现;如果是后者,我的建议是在框架中加一个编译层,即在运行脚本之前保证得到逻辑尽量简单,数据为硬编码的脚本,这样就可以减少在这两方面浪费的时间了,这个编译过程可以自动实现.不过你们要对你们的框架进行一个改造,这就考验你们框架的可扩展性了!呵呵...
2.对于SHEET名称,解除这种限制好像不是很好做到,我同事说2007版在这方面做了改进,你们也可以试下.如果不行,还是建议你们把这些数据移植到数据库中,反正你们也在搭建测试平台了,移植到数据库也是迟早的事.
3.说的不对,还请指正!

引用删除 rcpp / 2008-03-20 09:33:24: lantianwei 发布于2008-03-19 08:43:15
6.不是非常理解为什么一个SHEET的名称的长度要32个byte那么长,能说名一下理由吗?
这个也不难理解，规范命名用了全写，没有缩写，容易出现很长的名字

引用删除 liangjz / 2008-03-20 09:04:42: 楼上的同学可能不知道我们的应用场景。
在预发布环境上回归验证，目前SCM争取到的时间大约为30分钟。
一个大型网站所有的脚本需要在半个小时执行完毕且重要的验证点确信无误。
看似苛刻，但也有苦衷：）我们自主能做的就是提高QTP脚本速度

引用删除 meng0819 / 2008-03-20 06:48:05: 5.个人认为自动化的运行没有必要追求快,因为其实自动化测试的目的也是模拟用户操作,太快反而有时会缺少真实性.如何加快脚本的运行:将QTP的一些运行附加选项全部清空,保证在运行时不做其他任何附加操作;禁止智能识别;用事件模式运行脚本等等
我觉得快的话可以运行更多的case，这属于性能的问题了。

引用删除 lantianwei / 2008-03-19 08:43:15: 问题都非常有深度啊!
我谈谈自己的一点陋见,如有错误还望大家指正!
2.我觉得评价一个自动化测试框架应该从可扩展性,稳定性,准确性,高效性,易操作性,可维护性方面考虑
3.关于这个,我觉得框架实现的最好是项目插入式,也就是保证框架的高度复用性和独立性,新建一个自动化测试项目可以直接在该框架下工作,而无须做任何改动.关于测试人员的技能不齐的问题,可以通过一些培训解决,这里要强调一点,自动化脚本的实现一定要简单,也就是上面说的易操作性.如果框架稳定性也非常好,那么因为个别测试人员的技术问题导致的脚本问题,也不会影响到整个自动化测试项目
5.个人认为自动化的运行没有必要追求快,因为其实自动化测试的目的也是模拟用户操作,太快反而有时会缺少真实性.如何加快脚本的运行:将QTP的一些运行附加选项全部清空,保证在运行时不做其他任何附加操作;禁止智能识别;用事件模式运行脚本等等
6.不是非常理解为什么一个SHEET的名称的长度要32个byte那么长,能说名一下理由吗?呵呵....

查看全部评论