51Testing软件测试论坛

标题: 如何用QTP判断程序运行时候挂起？怎么处理 [打印本页]

作者: gily19821116 时间: 2009-6-9 15:16
标题: 如何用QTP判断程序运行时候挂起？怎么处理
在运行参数化的自动化脚本的时候，发现有些时候程序出错挂起，不能关闭。如何教qtp判断程序挂起或者死机？如何处理这样的程序，来继续后续的操作？

作者: shanxi 时间: 2009-6-9 15:19
hang 跟 crash最大的区别是：
hang后还能见到界面，而crash后界面不可见。

[attach]52730[/attach]

作者: gily19821116 时间: 2009-6-9 16:13
标题: 回复 2# 的帖子
能具体一点吗？我还是个新手，呵呵，这方面不是太懂。挂起是还有界面，但是死机，会有弹出报告啊。而且挂起的界面不一定是一样的，通过界面判断是不是有点麻烦啊？

作者: intothestorm 时间: 2009-6-9 16:15
标题: Recovery Scenario
你可以创建一个恢复场景，并关联到你的脚本。
按照你的情况建议选Test run error->Any rrror，后续操作是建立一个杀掉程序进程，重新登录的初始化function。

作者: itisok 时间: 2009-6-9 16:42
如果被测程序挂起了，我觉得可能出现两种情况：
1.qtp没被阻塞，qtp操作超时失败。这种情况在recovery中重启被测应用就可以了。
2.导致了qtp被阻塞。这种情况比较麻烦，需要单独一个监视qtp是否被挂起的程序。

作者: kuangquanshui 时间: 2009-6-9 16:51
没怎么明白学习了

作者: gily19821116 时间: 2009-6-9 17:00
标题: 回复 4# 的帖子
呵呵，我还不知道什么是场景恢复啊~~~能具体一点吗？我的qtp是没有问题，是程序本身挂起了~~~才导致qtp无法继续啊

作者: gily19821116 时间: 2009-6-9 17:08
标题: 回复 1# 的帖子
我是qtp在执行脚本的时候，exe程序本身有问题，出现挂起，导致qtp没有办法继续运行。如果回复程序，那挂起的程序是否会自动关闭？我不了解场景恢复啊

作者: dreamever 时间: 2009-6-9 17:18
如果是出现了"程序非法关闭"的提示框，那么就是QTP没有挂起，但是被测程序挂起了。这个时候你需要首先关闭那个对话框；
可以通过杀进程的方式实现。windows下出现“程序非法关闭”提示框的时候，在进程列表中一定会出现一个进程 ddwin.exe的进程，只要关掉该进程，就可以关闭那个提示框。cmd命令行下执行tskill ddwin即可。你可以写一段vbs脚本，每10秒钟执行一次，避免因为那个提示框导致你所有的测试脚本都失败。

作者: gily19821116 时间: 2009-6-9 17:28
标题: 回复 9# 的帖子
如果是去投票没有挂起，程序挂起，而且没有windows弹出框，怎么让qtp判断？然后怎么关闭程序，继续下面的执行呢/

作者: dreamever 时间: 2009-6-9 17:34

原帖由 gily19821116 于 2009-6-9 17:28 发表
如果是去投票没有挂起，程序挂起，而且没有windows弹出框，怎么让qtp判断？然后怎么关闭程序，继续下面的执行呢/

::yiwusuoyou::: 现在我真晕了，那你说的挂起倒底是什么意思啊……难道桌面上什么状况都没有？那你怎么知道是挂起了？

作者: itisok 时间: 2009-6-9 18:00
标题: 回复 10# 的帖子
主动和被动判断都是可以的
主动的话就是给这个程序发消息，没响应就是挂起了
被动的话就是等待qtp执行下面语句时报错，然后通过recovery再进行相应处理

作者: gily19821116 时间: 2009-6-9 18:02
标题: 回复 11# 的帖子
不是qtp的问题，而是exe不继续执行下面的程序，但是也不弹出出错提示框。一直停在一个地方不动。显示程序没有响应。

作者: dreamever 时间: 2009-6-9 18:03
……别是那个程序本身就存在失去响应的问题吧……那样的话确实没什么办法，手工测试的话也没法继续了。

作者: gily19821116 时间: 2009-6-9 18:11
标题: 回复 14# 的帖子
是的，是程序本身没有响应了，qtp就执行不下去了。想把这个状态的程序关闭，重启，继续后面的测试。这个思路不知道合适吗？怎么判断程序不响应？

作者: dreamever 时间: 2009-6-10 09:23

原帖由 gily19821116 于 2009-6-9 18:11 发表
是的，是程序本身没有响应了，qtp就执行不下去了。想把这个状态的程序关闭，重启，继续后面的测试。这个思路不知道合适吗？怎么判断程序不响应？

在RFT里,可以通过IWindow接口提供的getText方法获取应用程序的标题,如果程序失去响应了,那么它的标题就是xxxx(无响应),这样的话就可以对标题进行判断,如果标题中出现了无响应,则关闭相应的程序进程，而且只能关闭进程，因为这个时候程序其实已经不接受你的任何指令了。
QTP里应该有类似的实现方法，可以对程序的标题进行判断，这个楼主尝试一下吧，毕竟已经不用QTP好多月。你可以获取当前桌面中所有窗口的标题，只要窗口的标题中出现了（无响应），你就关闭它，只是这种做法编码的难度有点高。恐怕还得调用window api的函数了，好象是叫findWindowEx的，具体的看一下msdn即可直接

作者: intothestorm 时间: 2009-6-10 10:01
晕，dreamever你把问题搞得太复杂了

本身容易crash/hang的被测程序就不适合做自动化，自动化适合在程序稳定的后期大量的回归测试阶段做。
楼主如果你偏要虎山行

，建议你研究一下场景恢复。

作者: kuangquanshui 时间: 2009-6-10 10:59
全乱了一点都没看明白

作者: lantianwei 时间: 2009-6-10 11:42
问题不很简单吗？
确定被测程序HANG住的时候是何种表现形式，然后写个程序进行监控。。。不就OK了吗

作者: shanxi 时间: 2009-6-10 12:04

原帖由 dreamever 于 2009-6-10 09:23 发表

在RFT里,可以通过IWindow接口提供的getText方法获取应用程序的标题,如果程序失去响应了,那么它的标题就是xxxx(无响应),这样的话就可以对标题进行判断,如果标题中出现了无响应,则关闭相应的程序进程，而且只能关闭进 ...

很怀疑在程序已经无响应的情况下，应用程序还能接收取窗口标题的消息。

实际上这种情况下，timeout后没正确匹配，截图，选择继续下一个case或者中断整个case的执行就行了。

[ 本帖最后由 shanxi 于 2009-6-10 12:08 编辑 ]

作者: gily19821116 时间: 2009-6-10 12:11
标题: 回复 19# 的帖子

我是初学者~~~qtp现在还停留在描述性编程摸索阶段~~~上面的想法挺高深，暂时还是能力不及哦。慢慢来吧，只想用一个最简单实用的。

作者: dreamever 时间: 2009-6-10 13:12

原帖由 shanxi 于 2009-6-10 12:04 发表

很怀疑在程序已经无响应的情况下，应用程序还能接收取窗口标题的消息。

实际上这种情况下，timeout后没正确匹配，截图，选择继续下一个case或者中断整个case的执行就行了。

至少Rft是可以的,因为RFT获取窗口标题时,与这个窗口的状态是无关的.哪派该窗口已经无响应了也没关系

作者: shanxi 时间: 2009-6-10 13:33

原帖由 dreamever 于 2009-6-10 13:12 发表

至少Rft是可以的,因为RFT获取窗口标题时,与这个窗口的状态是无关的.哪派该窗口已经无响应了也没关系

我用ProcessExplorer制造了一起跟hang相近的suspend事件，用我的spy工具还能得到窗口标题，我先前的猜测有些不正确，不过有时hang时窗口标题可能会变化。

网上还有一种方式，用undocumented api，风险也比较大

BOOL IsHungAppWindow(
HWND hwnd)
*参数hwnd为欲判断窗体句柄
*返回<推测> True表示挂起 Flase表示未挂起
{
return (NtUserQueryWindow(hwnd, WindowIsHung) != NULL);
}

作者: dreamever 时间: 2009-6-10 15:52

原帖由 shanxi 于 2009-6-10 13:33 发表

我用ProcessExplorer制造了一起跟hang相近的suspend事件，用我的spy工具还能得到窗口标题，我先前的猜测有些不正确，不过有时hang时窗口标题可能会变化。

网上还有一种方式，用undocumented api，风险也比较大 ...

你强~！！

作者: itisok 时间: 2009-6-11 14:26
标题: 回复 23# 的帖子
可以用sendmessagetimeout，随便发个支持的消息，判断如果是超时返回，就挂起了。

作者: dreamever 时间: 2009-6-11 14:44

原帖由 intothestorm 于 2009-6-10 10:01 发表
晕，dreamever你把问题搞得太复杂了
本身容易crash/hang的被测程序就不适合做自动化，自动化适合在程序稳定的后期大量的回归测试阶段做。
楼主如果你偏要虎山行，建议你研究一下场景恢复。

严重同意。
对于这样容易失去响应的程序，还是先让开发修改吧。我们做自动化测试的目标是减少重复测试的工作量，而不是给自己增加工作量。

作者: shanxi 时间: 2009-6-11 15:19

原帖由 itisok 于 2009-6-11 14:26 发表
可以用sendmessagetimeout，随便发个支持的消息，判断如果是超时返回，就挂起了。

App挂起后App自己是无法处理消息的，但我并不需要用这种方式判断，所做的仅仅是针对该问题的分析。
20楼我给出了普适的方法。

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