点击查询后，结果列表已经显示，脚本却在选择第一条记录时报错；手动重试一次，又能继续运行。这类问题在异步界面中比较常见：窗口、列表和列表里的数据，可能分几次才准备好。Squish提供了不同的等待方法，设置超时前，要先确定脚本究竟在等什么。下面采用Squish IDE的英文界面名称，说明等待时间的设置入口和控件加载异常的检查方法。

　　一、Squish如何设置对象等待超时

　　对象等待超时可以按测试套件统一设置，也可以单独指定。只有少数页面加载较慢时，适合在对应步骤增加等待时间，其他步骤沿用原来的设置。

　　1、修改测试套件的默认等待时间

　　①在【Test Suites】视图中找到目标套件，点击工具栏的【Test Suite Settings】。

　　②切换到【Test Settings】，找到【waitForObject()timeout】，按毫秒填写等待上限。例如30000表示30秒。

　　③保存设置，重新运行包含异步加载步骤的用例，观察报错位置是否变化。

　　这个设置影响套件内采用默认超时的对象等待调用。若脚本已经给某次调用填写了独立超时参数，该次调用仍以显式参数为准。

　　2、给特定对象单独设置超时

　　Squish的waitForObject默认等待上限通常为20000毫秒。它会在对象满足条件后继续执行，无需等满设定时间。

　　①打开对应测试脚本，定位发生超时的waitForObject调用。

　　②保留原有对象名称，在第二个参数中填写该步骤需要的毫秒数。例如为报表窗口指定30000。

　　③检查公共初始化脚本是否修改过testSettings.waitForObjectTimeout，避免套件设置与运行时设置不一致。

　　④重新运行，记录触发加载到控件可操作之间的耗时，再决定最终上限。

　　3、按等待目标选择方法

　　①需要点击按钮、输入内容时，使用waitForObject，等待对象存在、可见且启用。

　　②只需要确认后台对象已经创建时，使用waitForObjectExists；它不保证对象已经可以交互。

　　③对于受支持的列表、树或表格项，使用对应版本的waitForObjectItem，等待容器和目标项满足条件。

　　④等待数据状态变化时，使用waitFor检查明确条件，并处理超时返回结果。

　　object.exists只做即时检查，不能替代持续等待。列表框已经存在，也不代表查询记录已经填充完成。

　　二、Squish异步加载控件未及时出现是什么原因

　　同一条超时报错，可能对应加载慢、对象未就绪或定位条件失效。排查时先保留失败现场，确认界面当时停在哪里，再决定是否增加时间。

　　1、控件已显示，但仍处于禁用状态

　　按钮灰着、表格处于加载状态时，即使肉眼能看到控件，waitForObject也可能继续等待。

　　①通过【Launch AUT】启动被测程序，操作到问题页面。

　　②点击【Object Picker】拾取目标控件，在【Application Objects】中选中它。

　　③查看【Properties】里的可见、启用及业务状态属性。Qt控件可重点检查【visible】和【enabled】，其他技术栈以实际属性为准。

　　④观察请求结束后属性是否变化；若一直禁用，检查必要输入、权限和前置操作是否完成。

　　2、动态属性变化，原对象名称无法匹配

　　①发生【Object Not Found】提示时，点击【Pick New Object】，选择当前界面的目标控件。

　　②比较新旧对象的识别属性，留意包含记录数量的标题、动态文本，以及父窗口是否发生变化。

　　③需要继续查看对象映射时，点击【Debug】，检查【Object Map】中的原条目。

　　④优先保留稳定且能唯一定位对象的属性，修改后重新验证。

　　如果符号名称由脚本动态拼接，拾取按钮可能不可用。也不要为了匹配成功，把限制条件全部删除，否则可能找到同类型的其他控件。

　　3、前一步没有真正触发加载

　　①打开【Test Results】，从超时记录向前查看，确认登录、页面切换和查询动作是否按预期完成。

　　②在【Test Suite Settings】→【AUT】核对【Arguments】以及运行环境，检查是否连接了错误的测试环境。

　　③对照应用日志中的请求时间、响应状态和错误信息，确认数据请求是否发出并成功返回。

　　④若控件在超时后才出现，可在交互调试窗口点击【Retry】，用原定位条件再次查找。

　　原条件重试成功，可以作为加载较慢的线索；若页面已经出现错误提示、请求未发出或返回数据为空，延长对象等待时间通常解决不了问题。

　　三、Squish如何保留等待失败现场

　　偶发问题到了下一次运行可能就消失了。提前留下截图和对象信息，能帮助判断是界面状态不同，还是加载时间发生了变化。

　　1、启用错误截图

　　①进入【Test Suite Settings】→【Test Settings】，启用【Log a screenshot on an error】。

　　②若用例还包含断言失败，按需启用【Log a screenshot on a FAIL test result】。

　　③重新运行后，在【Test Results】中查看对应截图，核对当前页面、弹窗和加载提示。

　　截图能说明失败时界面的大致状态，具体属性仍需结合对象检查和应用日志判断。

　　2、验证对象映射是否仍然有效

　　①保持Spy正在检查被测程序，打开【Object Map】。

　　②选中超时报错使用的符号名称，右键选择【Check Object Existence】。

　　③若检查失败，返回【Application Objects】和【Properties】，对比实际对象及父级属性。

　　④修正映射后，从相同初始状态重新运行用例，确认脚本无需人工介入也能通过。

　　总结

　　异步界面里，“看到了”和“可以操作了”之间往往还有一段距离。Squish的等待机制能让脚本跟随界面状态前进，但合理的等待上限也应保留应用性能变化的线索。如果原本几秒完成的页面逐渐拖到几十秒，即使用例仍能通过，也值得记录下来。对测试维护人员来说，一次失败留下的现场信息，常常比反复重跑更有价值。希望这些操作能帮助大家查清控件等待超时的原因，减少偶发失败带来的排查负担。后续遇到其他Squish对象识别或回放问题，也欢迎继续交流。