手把手教你TestComplete_对象的等待问题

 

 

 因为各种各样的原因，回放脚本的时候不会那么顺利，测试环境可能慢一些，被脚本一催赶，立刻变得结结巴巴的，或者本来很伶俐的程序，突然一下就脑子短路，半天没动静了。反正一句话，常在河边走，偶尔总会踩狗屎的。所以对象的等待问题很难绕过去。

首先说等待，等待谁？仔细琢磨下，应该是等待下一个动作的相应对象，比如你完成上一个步骤后，要在下一个窗体的某个按钮上点击一下，这个窗体老半天不出来，表面是窗体不出来，窗体真出来了，你就敢说那个按钮一定能点得上？所以别傻傻的去等窗体，得找正主，具体的那个按钮。找到了正主，你就可以随便选择方法了。

可以玩狠的，直接死循环，你不出来我就死给你看：
  while (not obj1.obj1.obj1.obj1.exists)
    BuiltIn.delay 3000,"等待obj1。。。"
  Wend

探讨一下，这里exists有没有问题，如果这个对象已经在内存了，但是界面上没有显示出来，这句话就会有问题，会不会改成visible更好，那如果在内存了，又没显示出来，就白等了。那你写日志说对象在内存了，但是没显示出来就好啦。

还有种情况，会不会对象出来了，exists和visible都是true了，但是屏幕是刷白的状态，你做点击动作可能还是不行，会不会那么邪呼的，真的，会有这种更变态的情况的。那咋办，抓图片比对吧，这个法子肯定没问题了，都能看到了，还不能操作呀。

  while (not Regions.Compare("obj1bmp", obj1.obj1.obj1.obj1. obj1bmp, False, False, True, 0))
    BuiltIn.delay 3000,"等待obj1bmp。。。"
  Wend

这个怎么做的？录制的时候选择了图片的checkpoint，然后就贴出代码来。

这个做法比较山寨，一旦窗体出不来，整个代码就不用跑了。

什么？山寨？还有更山寨的！啥代码都不用写，直接设置一下：
菜单：Tools—Default project – properties
左面树状目录：playback
右面第一排右边的那项：Auto-wait timeout,ms: 10000
哦，原来是缺省等待10秒。
懂了塞，直接搞个倆小时，我就不信你不出来了，如果不出来就是死了，你都死了，那我也不用动了。

你们这些做法都太山寨太江湖气了。看看标准的做法，TestComplete提供了一系列的Wait函数。

举个例子：
TestObj.WaitVBObject(Name, Timeout)

TestObj A variable, parameter or expression that specifies a reference to one of the objects listed in the Applies To section
  
Name [in] Required String  
Timeout [in] Required Integer  
Result Object

解释：
是谁要等谁，通常来说都是父对象等待子对象，TestObj就是父对象，name就是子对象名字，timeout自然是要等多久，过时就代码决定该何去何从了。Result就返回子对象的引用。

看出来了吧，名门正派就是讲究的更清晰准确，谁等谁，等多久，用什么Wait函数来等，没等到可以代码细节处理。

 

总结：

不同的情况采取不同方式，如果你只需要完成一个简单的系统自动化，并不需要做很多控制，要求维护成本最低，那就直接配置个倆小时得了，如果你的系统需要精细化控制，就用wait函数来精确控制。至于死循环的那倆法子，你不想改变配置，又不想搞清楚是什么wait函数来等，就直接山寨了吧。

够用就好。大家自己选择吧。