QTP无人值守测试方案

vickywang_no1

想整理一个这样的方案，实现以下功能：
1.多人脚本在同一台电脑上运行；（脚本都是QTP9.0以上的，只有TD7.6服务器）
2.脚本运行时不需人员值守，能自行处理错误，并记录错误日志。
3.保证所有脚本运行都不遗漏。

小孩

如果说多个脚本在一台机上运行不要TD 也摆!
啥叫自动化就是在无人看守的情况下自动执行,和去保证过程中有一个用例的失败而不影响下一个用例的执行,所以这个也就是无人看守的核心.

xiaoyaoke

LS说的很对，自动化就是要无人值守吧，呵呵，弄好几个人看着还干吗自动化啊

lantianwei

1.要求你们的脚本规范做好，版本控制也要做好
2.自动处理错误需要你的场景恢复做好
3.这个没什么难度

vickywang_no1

对于WEB系统，场景恢复主要要考虑那些情况呢？可以列举一下吗，谢谢。

cnxidian

vickywang_no1

dreamever

2.脚本运行时不需人员值守，能自行处理错误，并记录错误日志。
这个需求如果要实现的话，重点在于测试脚本的设计和整体的规划，并且和你的执行策略也是有密切关系的。比如在我所做的自动化测试中，所有的脚本首先分成彼此独立的功能脚本，然后由功能脚本组合成更高级的工作流，在执行测试时，规定必须先执行所有的功能脚本，这样就能把由于脚本异常造成测试中断的概率降到最低。

假装不在

个人觉得，如果要做到无人值守，第一点，也是只有一点，就是要强壮。
另外，我对有人说，要被测试的程序比较后期或者已经比较健壮的情况才能让我们来做到无人值守。我很不同意这个观点，这样已经失去的测试的意义了。
脚本我们自己可以慢慢完善，之所以用描述的优势也有是在它覆盖了更多的可能性，随之自己脚本编写经验的积累，可以很自然的让脚本去处理特殊的情况。即使是给了你一个皱型的产品，我们也能测试它，做到无人值守。
就例如，你对一个按钮的点击后，你自己可以写函数处理，它会出现什么情况呢？
1，IE死掉。
2，页面报错
3，页面跳转
4，新IE出现
5，无反应
6，页面元素缺少
等等
只要你想到的，都可以写出来，这样，你的脚本即使在一个没怎么测试过的程序，也可以很顺利的跑。

vickywang_no1

4、8、9楼的回复对我很有帮助，谢谢。希望更多的回复，集思广益。

meng0819

我觉得还是需要结合成本考虑，如果需要录制回放结合TD好像也可以做到无人职守。
9楼所说的成本过高了，一般公司是承担不起的。
当然，开发脚本的成本高了，这样做下去的后果是以后的维护成本会高的。
得不偿失.

liangjz

我们目前方案针对QTP脚本做错误处理以及清晰记录当前执行脚本的ID。

比如错误处理利用on error resume next。。。。  if err.number <> 0 then.....

还有，某一个脚本退出后，外层的主Action 执行下一个脚本或者action的id

zte_boy

基本上错误处理方法都差不多，我也是详细记录了每个操作步骤的信息，如果err.number<>0的话，就调用日志记录程序和其他控制程序

peterz

建议楼主把TD7.6升级成QC9.0。QC9和QTP9.0+的集成化很好。你可以采用QC来进行功能测试用例的调用，把同一模块的测试放在一个测试集里运行，测试完成后还可以根据QC来查看运行结果。只要你的测试脚本够健壮，完全可以达到无人值守。

假装不在

个人觉得，这样的脚本你写多了，可以支持通用，扩展性和可移植性高，通用性强。
编写这些，早期效果看不到，但是如果在那些刚完型不久的程序测试，你就可以看出录制脚本与自己编写这些脚本的区别。

onlonely

可能楼上的就是属于，脚本写多了的人物。
莫非我们对脚本也来个模块化。。。说笑下。。。

jimmyzhou

MS自动化都是无人值受守的吧
1.QTP设置，脚本即使报错也继续执行下一个脚本
2.搭建一个自动化测试框架很重要，很多新人都喜欢研究QTP本身和编写脚本，其实有一个合理的自动化测试框架是最重要的

ym_wei

学习中

centurystone

收听收看，回贴

py31

真遗憾。这些我早就实现了，而且实现的比你们讨论的加在一起还好