这是一个QTP或者自动化的瓶颈吗？

假装不在

学习QTP时间也不长，我见解的也不多，慢慢的遇见见问题也就自己在帮助文档，论坛，GOOGLE找答案，慢慢自己也对QTP有了更多的了解，但越靠近井口，你会发现天越大。
      话不多说，说说我题目中的瓶颈是什么。
      在论坛有人问，能让我的脚本通宵的跑，没人看的跑吗？管理员版主水民给的答案大同小异，只要你脚本够健壮就可以。所以，这就是这个话题中瓶颈所在。
      一个脚本在无人看守的情况下走，除非是你测试的程序够健壮或者是脚本，不然会因为一个小小的错误而停下来，谁知道你左脚刚出公司门，他就不走了。明天来的，看到只是一个让人沮丧的结果。
      因此，我们都学着去让脚本更健壮，哪么就要让它更智能的去捕获更多我们想不到的错误，所以我们用场景恢复（这也是我2天都在研究的）。
      建一个比较好的场景，就是达到能捕获大部分错误的场景，就是一个测试工程师的技术点所在，也是卖点吧，所以我们可以看到论坛很少有人拿这些出来卖，因此，如果建一个非常了不起的，很强的场景也是大家所渴望的，缺乏的是技术的交流，导致了脚本的可运行行很低。你可以说，你的脚本可以通宵的跑，没问题呀，但或者是你们公司的程序很强壮，但那样能说明你的脚本很强壮么，或者强壮到你不敢相信时候，你的脚本跑起来以及没什么意义了，自然这是不可能的，微软还2 3天就发几个补丁呢。

      题外话，我测试的程序是VB，是CS结构，自然大家知道VB程序的错误更是千奇百怪了。因此，我写了一些场景所需要的函数，例如捕获窗口类型，是程序自身的对话框能还是程序抛错，或者是windows抛错。感觉难点就是在于捕获它是什么？！你需要在什么时候就激活你的场景，每一步？发生错误时候？场景发生后你要干什么？这些都是我们需要考虑到的。我水平不高，也写不出多智能的，等写完了和大家分享下吧，但更需要和大家一起探讨和学习。在这里也要谢谢51testing给我的帮助。

yabest

呵呵，这个是大家都会碰到的问题！
只是感觉你选了一条很艰难的路，不讨好。
因为错误百出，你很难预测、处理所有的错误。

所以我选择了退后一步，管你遇到啥错误，哪个Case遇到错误，我就把你这个Case给Fail了，然后杀掉被测软件，重新启动被测软件，重新登陆系统，然后继续执行下一个Case！

呵呵，退一步海阔天空啊。。。

假装不在

那例如程序初始化它的时候就出错呢，case的大门都也要是你程序走起来为前提 。
例如你登陆程序后，界面出来了，然后它却同事抛了一个错误的msgbox....
你的方法很好，我学习下，谢谢哦。

假装不在

或者某些程序，他需要走的是流程，没有太多的支点给你走。

但其实我们一个晚上能发现的BUG多少，感觉第2天挺有成就感的。

你的意思是不是说在例如识别对象方面的呢？我说的是在业务流程中突然出现的错误，不过这样能发现一个错误也不错。

我个人觉得，如果能在错误出现时候成功捕获并选择处理步骤 有点天荒夜谈。

愚见愚见，希望大家提点建议。

之前我有建若干个场景，其中有一个的去捕获跳出窗口的，但QTP居然连一个edit都不放过，让我哭笑不得，我的正则表达式是这样的：
1、[^\x00-\xff]{1,}|[^\w+$]{1,}     标题是任意汉字，字符，字母，字长任意以及组合。

2、接下来我就是去捕获它的类型是不是一个Dialog或者是一个VBwindow,或者是一个window....但Dialog也是很诡异，他可以是一个自带的对话框，也就是合理存在的那种，也可能是程序出错，VBWINDOW也同样。
3、接着就是写几个处理函数让case去如何处理他们，如点确定或者取消，重启程序尝试，截图LOG...
4、设置场景发生是每一步或者错误时候。

后来又建了另一个场景2   这个是去处理函数的，感觉这个比较好用点。
1、就是某个函数走不下时候怎么搞？！
2、第一步当然是确定你的对象是不是死了或者是没被选中？
3、让它活起来或者是处理掉挡到你的窗口，让他选中。此时我们可以看到第一个场景的函数我们就可以再拿来用了。
4、第几步恢复它，截图LOG....因为这个场景的好处就是把你的代码当字符串传给你的函数，哪么，嘿嘿....

但2个场景建起来了，感觉很完美，走起来却大跌眼镜....
第1个场景就和我提到的一样，它很贪婪，居然edit都当弹出窗口。
第2个场景呢？走到那一步出错，QTP走得太快了，结果.....不知道怎么说，例如这样吧...
你选了个menu，正好在这个时候出错，但未必是下拉引起的，或是之前的步骤搞起来的，它给了你个msgbox，哪么你的函数就去处理它....
接着处理完了，你就让它在当前步走，它居然和我闹别扭不走了，走下一不，选择下拉的对象....我的妈呀，你还没拉裤子就说要开大了..



愚见，大家给给建议。讨论下，哈哈。

[ 本帖最后由 假装不在 于 2008-3-21 22:54 编辑 ]

yabest

这个启动和登录步骤的脚本是所有测试脚本的基础和前提，所以就要写得强壮、勇猛一点了，多加一些错误判断，多加一些重试操作。

然后如果这样勇猛的步骤都无法执行通过的话，那你这系统也不用测试了，等着第二天人工诊断错误原因吧，八成是系统环境异常，无法正常登录系统了。

假装不在

我上面写了自己的2个场景。哈哈，希望和大家一起讨论和进步。

感觉弹出窗口那个场景，QTP公司没给每多个窗口类型，很不合理。不知道其他版本是否有改进

[ 本帖最后由 假装不在 于 2008-3-21 22:57 编辑 ]

walker1020

对于可以预知的错误（如以前版本遗留的错误），可以使用 判断条件或 Case 语句来处理；对于可预知的异常情况，可以使用 Recovery Scenario；对于不可预知的异常情况， 只能参考IP yabest 在 2# 的留言去处理了。当然，也不一定非要杀掉被测软件，重新启动被测软件，重新登陆系统，然后继续执行下一个Case。 如果某个操作或步骤无法操作导致后面的操作无法继续进行，那么只能这样了。如果不影响后面的测试，那么跳过这一行或此 Action，继续运行下个 Case 好了。

[ 本帖最后由 walker1020 于 2008-3-21 23:00 编辑 ]

假装不在

谢谢楼上们的建议，我去学习下。
问下，RecoveryScenario这个是什么工具呢？我不大清楚。

看来大家都喜欢case呀，或者我的场景应用方向错了吧，耗了我2天时间。

walker1020

非常同意 yabest在 5# 的留言。一定要保证脚本的稳健性（Robost），不要因为脚本错误而导致测试无法继续进行。如脚本的预防错误、QTP报告无法识别对象（应用程序上确实有此对象）或对象不唯一等。

walker1020

Recovery Scenario是 QTP自带的、用来处理异常情况的一种机制。这个在 QTP User's Guide里面有详细说明。

假装不在

原帖由 walker1020 于 2008-3-21 23:06 发表
Recovery Scenario是 QTP自带的、用来处理异常情况的一种机制。这个在 QTP User's Guide里面有详细说明。

谢谢，我以及看到帮助的内容了，刚才用搜索的功能没看到，哈哈。找到了。

yabest

原帖由 walker1020 于 2008-3-21 22:58 发表
。。。
当然，也不一定非要杀掉被测软件，重新启动被测软件，重新登陆系统，然后继续执行下一个Case。如果某个操作或步骤无法操作导致后面的操作无法继续进行，那么只能这样了。如果不影响后面的测试，那么跳过这一行或此 Action，继续运行下个 Case 好了。
。。。

呵呵，在这个问题上，千万不能手软，一定要心狠手辣，斩草除根，杀无赦！

以前就是因为手软，想跟异常错误这位老兄来文的，跟他讲道理，用一些文绉绉的方法来判断分析情况，来做斯文处理，
结果最后吃了大亏。异常错误这位老兄毫不讲理，无赖一个，比如跳出个莫名其妙的子窗口挡在前面，让你无法操作动弹不得，结果一个case fail了，后面几十个case也跟着一骨碌fail掉了！

吃过几次亏后，我就一律痛下杀手，管它什么错误，我都杀无赦（这时候close主窗口也是关不掉的，你也不能判断是什么子窗口等原因造成的，只能杀杀杀）。屠刀过后，异常错误这位老兄就被我收拾的乖乖的，再也没有撒过泼了！

[ 本帖最后由 yabest 于 2008-3-22 00:15 编辑 ]

假装不在

原帖由 yabest 于 2008-3-22 00:13 发表


呵呵，在这个问题上，千万不能手软，一定要心狠手辣，斩草除根，杀无赦！

以前就是因为手软，想跟异常错误这位老兄来文的，跟他讲道理，用一些文绉绉的方法来判断分析情况，来做斯文处理，
结果最后吃了大亏 ...

你好暴力呀...那要是如果你登记完毕后，他给了个提示登记完毕呢，是把它写到一个case中还是？那如何做到去捕获这些窗口呢

higkoo

楼主多虑了

看你的实际情况来用吧，不要追求完美。

怎么简单怎么用，在投入和回报之间找个平衡点！

higkoo

不要为了自动化而自动化。

使用工具的目的无非就是让我们“好”一点。

灵活应用，想方设法  ：）

假装不在

是呀，是不是想太多了呢....
觉得怎么简单怎么用确实有道理，哈哈
我这样想写出那么的几个场景也就是为了一劳永逸，不过很难实现，我只是希望这样写出来，以后就不用老是去改自己录制的代码，老添加case多类呀，虽然也是个好方法。

假装不在

莫非这就叫好高骛远...
我们使用自动化也就是为了发现问题，但现在看到出现问题，却不知道怎么办....想把问题忽悠过去

[ 本帖最后由 假装不在 于 2008-3-22 12:22 编辑 ]

yabest

其实遇到问题，是很正常的，这也是大问题，不解决是不行的。
只是你选的路太艰难了，不讨好。
遇到这种不得不解决的难题，无法正面解决，那就多考虑别的方案别的方向，想办法绕过去就可以了。

假装不在

原帖由 yabest 于 2008-3-22 13:51 发表
其实遇到问题，是很正常的，这也是大问题，不解决是不行的。
只是你选的路太艰难了，不讨好。
遇到这种不得不解决的难题，无法正面解决，那就多考虑别的方案别的方向，想办法绕过去就可以了。

因为这次的测试中，流程很长，要录制的脚本很多，所以如果按照楼上说的用case，感觉很难做到。

yabest

原帖由 假装不在 于 2008-3-22 14:24 发表


因为这次的测试中，流程很长，要录制的脚本很多，所以如果按照楼上说的用case，感觉很难做到。

不明白你说的用case很难是什么意思。