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

hsjzfling

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

蟑螂

对啊，目前的自动化测试可以说是理想的状态，有好多异常情况要考虑的。

假装不在

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


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

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

假装不在

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

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

mklodoss

感觉这也是一个学习的过程，需要慢慢的积累，说不定到了一定的程度，就更上一层楼了。呵呵！

假装不在

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

mythxhg

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

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

xiao*

我的做法是，在每一个动作之前或之后都要判断相应的对象或数据是否存在。否则，则退出该脚本。一个脚本写好了基本不怎么用该，做多是对象属性改变后，对对象库做一次更新。：）

假装不在

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

假装不在

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