QTP自动化测试过程随想
 

2009-12-17 来源:51Testing

 

我之前做过短暂的开发,后来主要是测试,丰富的测试经验(但仅限于黑盒),并且有带领团队半年时间,期间和老板学习了6-Sigma(黑带),也做过几个专利,所以很有流程,改善,和客户需求方面的sense, 并且感觉很有创新的意识,现在专职作QTP自动化开发,一个项目刚刚结束了,于是把随想发出来,共同讨论。

回顾整个项目过程中各阶段操作,作出以下总结:

1、需求确认阶段

此时需要手动测试人员的大力支援,并且建立良好的沟通,提升我们熟悉业务效率,沟通包括:

1)需求提出:与手动测试接洽人确认自动化实施的策略是什么.

将老板与客户的想法作为大的方向,结合手动测试实际需求,并考虑到自动化实现的现状,共同拟定出项目的Scope。

提出需求的绝不可以是自动化Team的“一厢情愿”。当然,现实中有时是由自动化方提出的更多一些,但是这个根本的原则是,要得到手动的认可与确认,否则当东西做出来后,他们说一句这不是我想要的东西时,我们自动化Team将全体晕倒……

2)需求确认与熟悉:自动化Team对提出的需求进一步分析,制定出自动化的Auto-Test Case。

分析的前提是,熟悉业务,即看懂test case并可以实际测试。原则上讲,作自动化的人应该是对所做业务非常熟悉的人,至少要有手动测试经验的。但实际上,我们不可能熟悉所有的项目,于是如何快速掌握业务操作流程就颇为重要。此时最捷径的方式就是与手动测试人员沟通,沟通的效果越好,则此处所用的时间就越少。

PS:在我们的上一个项目中,我们在需求确认阶段,看完了所有手动Test Case,将其分类出我们需要的,然后与之确认,说实话,有点耽误时间。

2、开发阶段

如果说需求确认阶段我以前有过经验的话,开发阶段对于我来说可算是全新的。以前我们自动化项目,对于开发阶段,代码变化很少,其重点是如何将多个设备或者 PC的并行操作串联起来。可是这里的项目不一样,需要很强的编程能力,需要对QTP很熟悉,这也是我比较薄弱的地方。正应为如此,我在这个阶段学习到的东西也是最多的。

首先,很好的Frame框架,为我们的编码及维护带来很大的方便。

其次,编码方面,对于常用的函数,以前都需要看Help的规范后才可以编写,现在非常熟悉,可以直接快速编码。学习了许多新的编码技巧,如:

1)Dictionary Object使用,这个以前听都没听过,汗~~

2)描述性编程的实际应用,以前只是看过相关的概念

3)时间函数的应用,如Sync方法,WaitProperty属性,或者自编辑一个For循环,动态等待时间。

再次,协同编码保证代码同步。

通过SVN管理我们的代码,其缺点在于可以同时有许多人编辑同一个文件。这样的开发模式似乎在各件开发中很常见,但是我的纯开发经验并不多,加之管理工具的变更(之前用的是VSS),开始的时候我连Check in,check out都不会,学会这样的操作不难,难的是如何在思想上建立这样的协同操作模式,如何在资源共享的前提下,不会因为一个人的修改,导致别人的不便。我们 Team达成共识,提交代码前先看服务器上是否有更改,Update之后再提交,如果这样还不行的话,只能比对文件差异。但针对对象库的管理中,由于存储数据特殊,无法比对,则在修改前需要与文档的创始人说明,之后再作更新。

3、整体项目管理

我认为在这次我们的项目过程中,没有融入所谓的项目管理,由于人员还比较少也有一定经验,我们完全凭借自觉性与经验去跟进项目进度,这样是很危险的,下一步如果我们扩展团队,并且加入些经验不足的人参与编码,项目风险就会很大,所以我们要启用一个项目监管的机制。

1)资源调整

未来我们人力充沛的前提下,可以试着安排一个人到手动测试组学习,当然他要有自动化的概念,“卧底”到那里去学习测试,了解需求,这是小组间的调整。

在自动化测试组内,我们可以通过开展定期的经验分享,来共享我们的信息,并且有了问题积极主动去问别人,我们可以算一笔账,假如我遇到一个问题,如果自己解决或者上网查资料,假设要半个小时,但是如果我询问下周围的人,可能只需五分钟就完成了,两人各耽误五分钟,也就是用十分钟完成了半小时的事情,何乐而不为?你也可能说,对于我来讲,我是用五分钟完成了半小时的事情,但对于答疑的人来说呢??他是白白浪费了五分钟,没有人愿意这么做的……但是,这件事情还有可能反过来,也就是我用五分钟解决那个人需要半小时的问题,此时我们是双赢,这样的循环,我们的效率能不高吗??我们现在是团结协作的时代,不是考验个人独立学习的时代,所以,不要把这种资源共享,当作是一种没有独立解决问题能力的表现。在和手动测试谈论需求时,我们也要充分利用这样的 Support,而不是自己在家啃Test Case。

2) 事务优先级

针对自动化开发的在各公司尴尬的现状,分清主次更为重要。这体现在我们筛选Test Case中。我们遵循20-80法则,我们要勇于将耗费80%时间完成的20%Test Case剔出出去,除非手动测试有特殊的需求,这与自动测试的本质并不违背。自动测试的宗旨并不是将所有手动测试的Case都实现自动化,而是要将那些变化不大的,流程逻辑较为简单的,测试频率高的Case实现自动化即可,我们不可为了一味地追求自动化比例而将那些无谓的Case加入。

3)事务监督

下面将以问答的形式来讨论该问题:

a. 问:如何定制合理的项目进度表? 让组员们工作不是很轻松,也不用每天加班完成?

答:这需要我们了解所有资源的配置情况,掌握每一个操作环节最平均的时间,并且了解该环节80%可能用的时间范围(置信区间,作为辅助决策。

b. 问:如何掌握项目进度?即:项目负责人如何保证项目是On schedule的?项目经理或者更高的主管如何了解项目的进度?

答:定期Meeting,请组员们汇报工作进展,并讨论遇到的问题。

以每周一报为例,会议的内容为:组员介绍本周具体工作内容(有点像TimeSheet的填写),与上周预计内容比对是按时完成还是有延误,延误的原因是什么??项目负责人对下周工作安排。

经过几次的计划->实施->修正计划,对每周的工作进度就会比较了解,从而有利于对整理项目进度的预估。

c. 问:如何验收我们的项目成果?

答:每个人对“完成”这个概念的理解不同,有的人认为Complete即可,有的人认为Good,而有的人追求的是Perfect。为了保证我们的项目完成之后的一致性,可以建立一个完成的CheckList,将“完成”的概念量化,如验收test case script的完成,我们可以定制如下的CheckList验收。

NO Function Name Check Point Review History Code Review Time Optimization Data Create Doc Sync Remark Date Reviewer
V360_TC0001 TC_CAPBasicSearch               10/16/2008 Lynn
…… ……               …… ……

4)检讨审查

也就是在项目结束之后,对项目进行总结,调节。并通过事后诸葛亮式的检讨分析,找出改进的方案,对下一个项目的进展是很有帮助的。

经过了两轮的开发,到了代码维护阶段。以前觉得“需求->开发->维护”三步骤中维护是最容易的,但是现在却让我们最挠头。

这几次Run出结果之后,所有的人见面第一句话都是:“呃,在我电脑上是Pass的,怎么现在就Failed了?”

静下心来检查代码,总有一些让我们忽略的问题被查到,但还是有许多顽疾存在着,尤其是界面刷新不及时或者莫名其妙的问题真的让我们很恼火。开发是一件创造性的事情,测试是一件破坏性的事情,无论二者都有成就感可言,但是维护或者说是擦屁股的事情搞得我们每个人都心烦意乱。总结我们的需求,开发,及运行经验,还有最近维护时遇到的问题,总结一下:

1、需求分析阶段,编写AutoTest Case时,步骤详略得当,不可以太简单,也不必太过繁复,多用项目的专业用语(阅读此文件的人都是对项目有一定熟悉度的人),这样有利于维护人员,或者后期手动测试人员了解Case的测试内容。

2、开发代码时:

1)脚本内的注释写清楚

2)对象库及对象命名尽量有意义

3)中间步骤(如页面的跳转,某些重要的Button或Link)要写清楚,最好写到Report中

4)检查点的判断,要直观,并且写清楚输入,输出的值,及期望的输出,如,查询功能失败,要写明输入什么样的条件使得查询失败,否则QA可能输入另一组数据查询,结果为成功

5)写完整个Case之后,需要察看整体的Report,是否容易看懂,整个Report就需要象一个故事一样,上下文连贯。

6)在开发的尾声,需要安排时间互相Review代码,按照1)~5)去审查别人的代码,这样也会发现一些问题的。不仅如此,互相察看代码有益于我们发现别人的长处,和一些自己没有注意到的知识点。

7)代码完成之后,切忌不可束之高阁,而要多运行几次,并且在不同的电脑上运行,可以利用晚上的时间,相互运行代码。

我觉得,6)和7)在开发阶段是不可省略的步骤,我们之前总是说开发时间紧,就缩短或者省略这两个步骤,导致我们正式运行时错误百出。

3、维护阶段

总结我们经常出现的错误,有如下几类:

1)环境问题 (如界面刷新,异常中止)

这些问题我们只能自认倒霉,但是总觉得可以再次优化,就是还没有想到好办法。会继续摸索

2)QTP与IE冲突

由于QTP的某种操作,会导致IE的异常中止;或者由于IE的设置,导致QTP无法反映。此类问题出现的频率不高,但是一旦出现会导致一连串的错误出现。

3)对象异常

有如下情况:

第一种是由于站点本身的升级导致对象的变更或逻辑的改变,此时需要修改代码;

第二种情况,由于界面跳转异常导致对象无法识别,在捕获的图片中可以看到。

还有一种情况,针对我们的框架下,对对象库的加载,会有对象重复的现象,导致对象无法被识别。此时就需要对重复的对象进行处理,保证其唯一性。

最常见的是对象不唯一导致的无法识别,多出现在WebElement中,我们往往通过对某个WebElement的value值判断其成功与否,但是有时界面中会有许多隐藏的Webelement存在,如果恰巧WebElement的识别属性用描述性编程,或者是正则表达式的话,就容易识别不到。需要加入 Index属性去识别。

4)脏数据的存在

举个例子,某个Case为:添加->查询->删除操作,如果第一次运行没有执行到删除就错误中止了,第二次运行时,之前添加的代码就会存在,影响添加或查询,我们可以这样设计Case:删除->添加->查询->删除

再如,A操作的前提需要B操作设置,但是B的设置会影响到A相关的其他操作,我们设置Case:B config1 -> A Operate -> B config2,但是,如果该Case在B config2前异常中止了,则B的config1将被带入到下一个Case中。针对这样的Case,可以将Case放到最后一个执行,降低对其他代码的影响几率。

我们最后的测试报告都会由手动QA人员确认,并且察看Bug是否为系统的Bug,并且统计Bug发现的比率,

1)查看遗漏率 自动化发现的Bug / QA发现的Bug

这个需要察看QA发现的Bug是否在我们自动化测试的Case中,如果在,那是我们的问题,如果不在,我们就需要添加到Case中,这就可见在需求阶段与QA确认的重要性,否则,人家不认可你的检查点或者说你的Case 有遗漏,我们就很郁闷了

2)准确率 QA确认的Bug / 自动化发现的所有Bug

这个好有压力阿,如果自动化发现10个Bug,结果有九个是脚本或者环境的问题,只有一个是真正的Bug, 我们自动化的效率就可想而知了。

版权声明:本文为51Testing论坛会员1316016原创,http://bbs.51testing.com

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。

资源网站: UML软件工程组织