51Testing软件测试论坛

标题: 这是一个QTP或者自动化的瓶颈吗？ [打印本页]

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

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

作者: yabest 时间: 2008-3-21 22:26
呵呵，这个是大家都会碰到的问题！
只是感觉你选了一条很艰难的路，不讨好。
因为错误百出，你很难预测、处理所有的错误。

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

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

作者: 假装不在 时间: 2008-3-21 22:31

那例如程序初始化它的时候就出错呢，case的大门都也要是你程序走起来为前提

。
例如你登陆程序后，界面出来了，然后它却同事抛了一个错误的msgbox....
你的方法很好，我学习下，谢谢哦。

作者: 假装不在 时间: 2008-3-21 22:38
或者某些程序，他需要走的是流程，没有太多的支点给你走。

但其实我们一个晚上能发现的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 时间: 2008-3-21 22:38
这个启动和登录步骤的脚本是所有测试脚本的基础和前提，所以就要写得强壮、勇猛一点了，多加一些错误判断，多加一些重试操作。

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

作者: 假装不在 时间: 2008-3-21 22:55

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

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

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

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

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

作者: 假装不在 时间: 2008-3-21 23:03
谢谢楼上们的建议，我去学习下。
问下，RecoveryScenario这个是什么工具呢？我不大清楚。

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

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

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

作者: 假装不在 时间: 2008-3-21 23:09

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

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

作者: yabest 时间: 2008-3-22 00:13

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

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

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

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

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

作者: 假装不在 时间: 2008-3-22 00:48

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

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

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

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

作者: higkoo 时间: 2008-3-22 10:09
标题: 哈哈
楼主多虑了

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

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

作者: higkoo 时间: 2008-3-22 10:14
标题: 学习是痛苦并快乐着
不要为了自动化而自动化。

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

灵活应用，想方设法：）

作者: 假装不在 时间: 2008-3-22 12:01

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

作者: 假装不在 时间: 2008-3-22 12:01

莫非这就叫好高骛远...

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

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

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

作者: 假装不在 时间: 2008-3-22 14:24

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

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

作者: yabest 时间: 2008-3-22 16:06

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

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

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

作者: hsjzfling 时间: 2008-3-22 17:15
莫非lz只拿一个用例来跑？？流程长就要特别注意脚本的复用~~
设计自动化用例的时候也需要注意，尽量避免各个case使用太多相同的模块(公共流程部分)，防止出现某一个关键流程出错就导致其它部分完全没办法测试(虽然在某个正常业务流程下那一步报错，后面都没法进行)~~
对于比较重要的case，也需要重点测试，不能一报错就抛弃它不管了，很可能只是因为网络短暂异常等外因引起的。那么应对方法可以在控制层判断是否需要重测，或者笨一点把这类用例穿插执行多次。第二天早上爬起来看看返回的错误描述、截图就好了~~

作者: 蟑螂 时间: 2008-3-22 17:28
对啊，目前的自动化测试可以说是理想的状态，有好多异常情况要考虑的。

作者: 假装不在 时间: 2008-3-22 19:34

原帖由 yabest 于 2008-3-22 16:06 发表

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

上面说的，如果代码量比较少，预计到某个地方会出现错误，可以添加case，哪么如果你的代码量很大，感觉自己手工去修改，成本太高了。也很浪费精力。

作者: 假装不在 时间: 2008-3-22 19:36

原帖由 hsjzfling 于 2008-3-22 17:15 发表
莫非lz只拿一个用例来跑？？流程长就要特别注意脚本的复用~~
设计自动化用例的时候也需要注意，尽量避免各个case使用太多相同的模块(公共流程部分)，防止出现某一个关键流程出错就导致其它部分完全没办法测试(虽然在 ...

是呀，但如果用例也很多呢~~觉得case只能解决预知到的。或者我了解的不多，愚见，大家说说看。

，谢谢楼上们的建议。

作者: mklodoss 时间: 2008-3-24 23:12
标题: 路过
感觉这也是一个学习的过程，需要慢慢的积累，说不定到了一定的程度，就更上一层楼了。呵呵！

作者: 假装不在 时间: 2008-3-25 09:29

个人感觉如果能够在这个点上做到很好，那么自动化或QTP将会在自己手中得到非常好的发挥。

作者: mythxhg 时间: 2008-3-27 09:38
异常情况分2种吧:
1.程序写好的,可预知的异常,也就是程序本身可以捕捉到异常,这类异常一般程序会弹出自己的提示框来向用户警示,所以把这类型的提示框列举出来用场景恢复判断运行不下去是不是这写提示框搞的鬼,然后点确定或者取消等来进行处理,需要怎样处理就自己看情况而定了.
2.另一类是程序运行的不可预知的错误,也就是程序自身无法捕捉或者没有捕捉而带出的异常,这类型异常一般是由系统自身的异常提示窗口向用户警示,对于这类型错误警告窗口的处理仍然是可以使用场景恢复来做的,不过具体处理这写窗口的操作时需要自己写代码了,具体上对这些东西的操作论坛上有人写过,包括我也写过.也不是什么麻烦事.

总之还是需要利用好场景恢复,它可以告诉你异常出现了,并且停下来作为异常处理的入口开始执行异常的处理.
当然象一些系统异常你即使点了确定或者取消等等,系统也可能不再是正常的了,所以象楼上一些说的那样切底杀了重来也未尝不可,至于判断之类的事情还是尽量减少,更多的在脚本内写判断并不意味着可以更加健壮,因为异常往往就不是出现在你写了判断的地方,它的随机性很强.所以在建一个好的场景恢复并在里面写好判断才是正确的方法,因为场景恢复实际上就是一种实时监视的工作,它比你直接在代码里判断更加能处理随机性比较强的异常情况.

作者: xiao* 时间: 2008-4-1 09:40
标题: 一个好的强壮的脚本是必要的
我的做法是，在每一个动作之前或之后都要判断相应的对象或数据是否存在。否则，则退出该脚本。一个脚本写好了基本不怎么用该，做多是对象属性改变后，对对象库做一次更新。：）

作者: 假装不在 时间: 2008-4-1 09:56
27#,你说的那个，“具体上对这些东西的操作论坛上有人写过”能不能帮忙找出来下，我这几天在研究TD，没把我自己的脚本完善下去，自己也有写，主要是在窗口弹跳以及脚本运行中下的功夫，但效果不佳。

作者: 假装不在 时间: 2008-4-1 10:00
28#你的方法固然好，但你这样每一步都判断会不会影响脚本的整体性能呢？
如果不存在有很多种的原因，包括它可能被错误窗口遮挡住，也有可能是正个程序死掉，那么你要去激活它，而激活的，有可能是整个程序，或者是某个程序的子窗口等等。
你这样还不如在恢复场景中加一个判断脚本运行的。
到了某个步骤运行不下去，可能是错误窗口搞鬼，也有肯那个是对象死掉。

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