51Testing软件测试论坛

标题: QTP自动化测试过程随想 [打印本页]

作者: 1316016 时间: 2008-10-23 16:08
标题: QTP自动化测试过程随想
======================================== 第二季  1/6/2009 ==============================================
之前在第一轮开发脚本的时候，已经将我的经验及总结和大家分享了。经过三个多月的开发，我又经过了两轮的开发，现在处于代码维护阶段，此为第二季分享

以前觉得“需求->开发->维护”三步骤中维护是最容易的，但是现在却让我们最挠头。

这几次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，我们自动化的效率就可想而知了。。。。。。
=====================================  End  =========================================================

==================================== 第一季 10/2008=====================================================
我之前做过短暂的开发，后来主要是测试，丰富的测试经验（但仅限于黑盒），并且有带领团队半年时间，期间和老板学习了6-Sigma（黑带），也做过几个专利，所以很有流程，改善，和客户需求方面的sense, 并且感觉很有创新的意识，现在专职作QTP自动化开发，一个项目刚刚结束了，于是把随想发出来，共同讨论。
PS：虽然注册很久了，但是苦于没有好的项目实际操组，没有比较多的感想上来发表，所以这是我第一在网上发帖，大家口下留情。。。。。

回顾整个项目过程中各阶段操作，作出以下总结：
1. 需求确认阶段
此时需要手动测试人员的大力支援，并且建立良好的沟通，提升我们熟悉业务效率，沟通包括：
a. 需求提出：与手动测试接洽人确认自动化实施的策略是什么.
将老板与客户的想法作为大的方向，结合手动测试实际需求，并考虑到自动化实现的现状，共同拟定出项目的Scope。
提出需求的绝不可以是自动化Team的“一厢情愿”。当然，现实中有时是由自动化方提出的更多一些，但是这个根本的原则是，要得到手动的认可与确认，否则当东西做出来后，他们说一句这不是我想要的东西时，我们自动化Team将全体晕倒……
b. 需求确认与熟悉：自动化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 Pass Pass Pass Pass 　 10/16/2008 Lynn
V360_TC0002 TC_CAPUniteSearch Pass Pass Pass Pass 　 10/16/2008 Lynn
…… …… …… …… …… …… …… …… ……

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

以上，就是我对这三个月来工作的整理与总结，并有一些自己的建议，希望大家给出宝贵意见，共同探讨……

[ 本帖最后由 1316016 于 2009-1-6 18:08 编辑 ]

作者: 1316016 时间: 2008-10-23 16:11
怎么发到[LoadRunner]中了，晕，看来我还是新人阿~~~~ 新人阿

作者: Lemon_s 时间: 2008-10-23 16:24
照样顶，呵呵。

作者: lqin1982121 时间: 2008-10-23 18:05
写得挺好的，你可以详细说说，你们与手动测试人员沟通的情况吗？比如说他们对做出来的东西觉得不好用的时候，但你们又觉得现有能力只能做到这样，这个时候你们会怎么处理？

作者: 1316016 时间: 2008-10-24 10:02
赫赫谢谢这个项目是我到新公司才开始做的，我上面说的发现最后不是手动测试需要的时候，是我在前一个公司出现的状况，但也很普遍，也不知我们这次项目是否可以逃过这一厄运，
我们的做法是：找出最初达成一致的会议记录或者是确认文档，总归是找他们 “签字画押”过的东西比对，看是当初需求不明确还是我们做错了，不过这也只是个形式，我们也只是为了避免他们在最后否定我们的成果，如果他们坚持要修改或者添加的话，我们也只能照做，这就是自动化的第位，以前是开发对测试“颐指气使”，现在是测试对自动化“颐指气使”，呵呵惨啊啊。。
不过，随着自动化流程的规范与上级主管的重视，只要我们把握住我们的原则，我们将不再是“受气小媳妇”似的，我们将得到所有人的尊重，这需要我们自己很强大。。。。
话又说回来，手动测试之所以对我们作出的结果不满意，还有一个原因是一般自动化的人并不是直接参与手动测试的人员，我们甚至在一分钟前对这个系统毫无概念，这就要我们有手动测试的sence，并且具有快速了解系统的学习能力，赞一个我这方面自认为不错，另外，如果系统很大，需要长期执行的话，我们可以安插一个自动化的“卧底”到手动测试那里，这样的话就可以极大地避免我们作出来的东西不是手动测试需要的情况出现。

再来说我们具体是如何与手动测试做前期沟通的，，，，
我一直认为在这个阶段，自动化作了许多本该手动测试该做的事情，如：Test Case的筛选，理想状况下，是他们选出想要自动化的case,我们仅需要学习该部分case,并且转换成我们自动化的用例即可，但是更多情况下，是我们需要看完一整份手动测试的Case，然后和他们谈，按照我们的理解提出所想做哪些内容。这个时候，小的项目还好，一个大的项目我们很难一次全部做完，肯定要分阶段完成，于是造成了我们在第一阶段就要看完所有的Case，到了下一阶段的时候，又全都忘了，如果手动Case比较陈旧，与当前系统不符的时候，就更惨了，这些都将大大拉长谈需求的时间，并且这种“本末倒置”的效果不好，而且自动项目有时更多的是大老板为了Show给客户看，然我们专门针对哪个部分开发自动化测试，这时如果大老板的想法和手动的理解不一致的话，我们走的弯路更多，这就是我们的该项目时谈需求的遇到的问题，先抛出来，再谈我未来想改善后的沟通模式把，再一起探讨，
首先，确认大体的Scope，这需要将老板的意思与手动测试的需求，再结合自动化的预留时间周期，确定我们大致的方向，此时仍旧以手动测试的需求为主，谁也不想作出个系统像“花瓶”一样，仅给客户做demo,我们还是想做出个真正实用的东西，这就要以手动测试的需求为主。
其次，在scope确认之后，就需要手动测试为我们提供相应的TestCase，我们最理想的状况是给我们的都是符合scope的，但实际上，他们往往不会遂了我们的“心愿”，我已经做好了在最短时间内看全部的，并且是陈旧的Case准备，没办法，谁让现实这么残酷呢？谁让我的学习能力这么强呢？赫赫

在有了scope基础上，如果他们再针对业务流程为我们作个实际demo，我们又会少走很多弯路，20-80法则嘛，至于demo的多少，就看自动化和手动测试的交情了，以项目的名义聚个餐阿，可以事半功倍，腐败阿腐败阿。。。。。。
再次，有了最小范围的Test Case，和业务流程的demo，我们就可以根据test case编辑出我们的Auto-Test Case,记得一定要和手动确认（“签字画押”），并挑出无法实现的部分，并算出自动化比例阿，等等参数，至此，需求阶段就告一段落了。

楼上，不知道这样写清楚了吗？？还有你们那里是怎么做的？我感觉这个也不是最终极版本，应该还有改进，谢谢了，共同探讨。。。。

[ 本帖最后由 1316016 于 2008-10-24 10:22 编辑 ]

作者: 1316016 时间: 2008-10-29 14:31
没有人回复？？自己顶

作者: liqf 时间: 2008-10-30 13:55
标题: 顶!
请教下楼主，你们一般会挑选哪些类型的TEST CASE来实现自动化呢？
另外，对象库是怎么管理的，各脚本之间的复杂调用如何处理？
呵呵，问题比较多，如果方便，可否单独沟通。

作者: CharlesCui 时间: 2008-10-30 14:33
自动化，呵呵。
很想看一个成熟的，有一定复杂度的应用，能够有一套完整的自动化测试解决方案，可惜现在还没看到过。

我接触过用QTP的团队，没几个做的真的好的，我也接触过做自动化测试的团队，只有涉及到白盒的测试，那种可以通过代码搞定的，无需通过人肉方式就可以跑起来的测试才是真正的自动化。其他的黑盒的成功的自动化少之又少，而且没意义，因为人肉测试的成本很低，自动化测试的成本很高。

楼主如果有成功案例能否拿出来看一下？要一整套流程完整的Case。
单独针对几个功能点的Case没意思。

作者: xww24 时间: 2008-10-30 14:39
赞你，楼主

作者: gogogotest 时间: 2008-11-4 15:55
学习，呵呵，很不错

作者: george19760207 时间: 2008-11-4 16:37
写的很好啊，受益良多

作者: ym_wei 时间: 2008-11-6 10:21
写得很好，学习了

作者: 1316016 时间: 2008-11-6 18:17
标题: 回复 7# 的帖子
其实我感觉在整个自动化中，最重要的就是Case的筛选，
我们筛选的原则是：
1.大老板的意图
尤其是在自动化Team成立初期，项目多是老板指定的，而老板对具体的测试不熟悉，他们只给一个大概的范围，很难揣测的。
2.手动测试急需的。
在大老板的方向下，找具体对应的手动测试负责人沟通，向他们寻求测试具体的范围，当然是在大老板方向指引下的。这个很重要，如果选择的方向不对，根本等不到看你具体实现的代码如何好，你就已经GameOver了。
3.功能相对稳定的，运行频繁的，如回归测试中的Case
为了降低后期维护的成本，选择稳定的部分作自动化，开发变动很大的地方可以等稳定后再实现。
为了提升后期运行的效率，选择经常被测试的地方做自动化，这样会让手动测试感觉自动化很有用。

还有就是，自动测试不能完全替代手动测试，并且有些Case如果手动测试会简单些用自动化反而复杂，所以我们不会对整份的TestCase实现自动化，总是在许多份中抽离出我们要自动化的case，这就需要自动Case 与手动Case的对应关系列明，哪些是自动的了，哪些是仍需手动的，方便手动安排测试人力。

先聊到这，后面的问题我们以后讨论，下班打网球去了
一整天坐在电脑前，大家都要加强锻炼啊！！！！

作者: 1316016 时间: 2009-1-6 16:54
更新了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)