QTP自动化测试过程随想

1316016 · 发表于 2008-10-29 16:40:25

QTP自动化测试过程随想

我之前做过短暂的开发，后来主要是测试，丰富的测试经验（但仅限于黑盒），并且有带领团队半年时间，期间和老板学习了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）       检讨审查
也就是在项目结束之后，对项目进行总结，调节。并通过事后诸葛亮式的检讨分析，找出改进的方案，对下一个项目的进展是很有帮助的。

以上，就是我对这三个月来工作的整理与总结，并有一些自己的建议，希望大家给出宝贵意见，共同探讨……
之前发在LR 论坛上，不太合适，转到这里来