Squish做GUI自动化测试时，真正影响脚本稳定性的往往不是点击和输入动作，而是控件能否在下一次运行时被准确找到。录制过程中，Squish会根据控件属性建立对象名称并保存到Object Map，脚本执行时再通过这些信息重新定位控件。处理“Squish怎么创建GUI自动化测试，Squish测试脚本无法识别控件如何处理”时，需要把测试步骤、对象映射和界面加载状态放在一起看，尤其要避免让窗口标题、动态文本等容易变化的属性成为主要识别条件。
一、Squish怎么创建GUI自动化测试
一个基础的Squish用例通常包括被测程序、测试套件、测试用例、对象映射和验证点。刚开始建立自动化测试时，可以先通过录制得到一条能够稳定重复执行的用例，再逐步整理对象名称和脚本逻辑，这样更容易发现问题发生在哪一层。
1、创建测试套件并配置被测程序
①启动Squish IDE，新建【Test Suite】。
②根据被测程序选择Qt、Java、Web、Windows等对应的GUI技术类型。
③配置【AUT】，让Squish Server能够找到并启动实际测试程序。
④选择Python、JavaScript等项目准备使用的脚本语言。
⑤新建【Test Case】，先运行一次AUT，确认程序能够由Squish正常启动。
Squish执行测试时由Runner通知Server启动AUT，因此AUT名称与实际程序路径必须正确对应。被测程序本身启动失败时，后面的对象识别自然也无法正常进行。
2、录制第一条GUI测试脚本
①选中测试用例，单击【Record】开始录制。
②在AUT中完成按钮点击、菜单选择、文本输入等实际业务操作。
③操作完成后停止录制，返回脚本编辑界面。
④检查自动生成的clickButton、mouseClick、type等语句是否对应实际操作。
⑤执行一次【Run Test】，确认相同流程能够自动完成。
录制过程中，Squish会为访问过的控件自动建立对象名称。常用方式是通过Symbolic Name在脚本中引用控件，再由Object Map保存它对应的实际属性，因此后续控件属性改变时，可以集中调整对象映射。
3、给关键结果增加验证点
①重新运行录制功能，在需要检查的位置插入【Verification Point】。
②选择页面标题、文本内容、选中状态或启用状态等需要验证的属性。
③运行测试并观察验证结果。
④对于时间、随机编号等会不断变化的数据，不要直接使用固定值验证。
⑤基础流程稳定后，再把重复操作整理成公共函数，减少后续维护量。
二、Squish测试脚本无法识别控件如何处理
出现Object Not Found时，不能直接认定“控件名称失效”。如果脚本每次都找不到，通常更像对象属性或层级发生变化；如果偶尔成功、偶尔失败，则要优先检查界面加载时序。先把这两类问题分开，排查效率会高很多。
1、先用Spy确认Squish当前能看到什么
①启动AUT，打开Squish的【Spy】视图。
②使用【Object Picker】重新选中无法识别的控件。
③查看控件的type、name、text、window、container等实际属性。
④将当前属性与【Object Map】中原来的Real Name进行比较。
⑤如果控件本身能被Spy选中，说明Squish能够访问该对象，问题通常集中在原对象映射上。
Squish官方也建议通过Spy获取对象名称或把控件加入Object Map。对于新增加、还没有录制过的控件，也可以通过这种方式直接取得Symbolic Name。
2、把容易变化的属性从对象映射中清理掉
窗口标题、业务数据和列表内容经常会随着运行状态变化。如果对象映射依赖这些内容，第一次录制能够成功，换一份数据后就可能找不到控件。
①打开【Object Map】，找到报错控件对应的Symbolic Name。
②查看Real Name中是否包含动态的windowTitle、text或caption。
③不需要参与定位的属性直接删除，保留更稳定的type、objectName或父容器关系。
④文字只有部分内容固定时，把精确匹配调整为【Wildcard】。
⑤匹配规则确实复杂时，再使用【Regular Expression】。
例如窗口标题会从“Address Book-Untitled”变成“Address Book-MyAddresses.adr”，就没有必要把完整标题固定在对象名称中。Squish官方支持Exact、Wildcard和Regular Expression等字符串匹配方式，并建议能够使用通配符解决时优先不用复杂正则。
3、检查父窗口和对象层级是否已经变化
有时按钮本身的text和type都没变，但它被移动到了新的对话框、选项卡或容器里，旧对象名称依赖的window或container已经失效。
①在【Spy】中查看当前控件的父对象关系。
②与原Object Map中的window、container属性比较。
③父窗口名称变化时，先修正父对象映射。
④再检查子控件能否通过原Symbolic Name重新识别。
⑤同一类控件出现多个实例时，增加能够区分它们的稳定属性，不使用容易变化的显示文本硬凑唯一性。
Symbolic Name的价值就在这里：界面层级发生变化时，可以通过修改Object Map恢复原脚本，而不需要在几十条测试用例里逐行更换对象名称。
4、偶发找不到时检查加载时序
①找到直接操作控件的脚本位置。
②在操作前使用【waitForObject】等待目标控件真正可访问。
③控件暂时不可见，但只需要判断是否已经创建时，可使用【waitForObjectExists】。
④需要分支判断时，可以使用【object.exists】检查对象当前是否存在。
⑤减少使用固定【snooze】硬等几秒的写法，避免不同机器性能下出现新的不稳定。
【waitForObjectExists】会持续等待对象出现，超出指定时间后才报告LookupError；而【waitForObject】更适合需要继续操作可见控件的场景。相比固定延时，这种等待方式更能适应页面加载速度变化。
三、怎样让Squish控件识别长期稳定
测试脚本数量增加以后，对象识别最好作为一项独立的维护内容，而不是等某条用例失败后再临时修。稳定的对象映射应该尽量依赖控件自身长期不变的属性，同时把脚本逻辑和界面细节分开。
1、优先维护Object Map而不是批量改脚本
①脚本中尽量使用【Symbolic Name】，不要到处复制完整Real Name。
②同一个控件只保留一条清晰的对象映射，及时清理录制过程中产生的重复条目。
③界面改版后先调整【Object Map】，再执行一组典型用例验证。
④发现某个动态属性经常造成失败时，在对象层统一修改，不在每条脚本里单独处理。
2、用几类典型场景验证识别结果
①分别测试首次启动、重新登录、不同业务数据和不同窗口状态。
②确认同一个Symbolic Name在这些场景下仍然指向正确控件。
③刻意准备两个外观相似的按钮或列表项，检查对象规则不会误识别。
④对异步加载页面连续运行多次，确认不存在偶发Object Not Found。
⑤只有属性方式确实无法稳定识别的自定义绘图区或特殊控件，再考虑其他识别方案。
Squish默认使用多属性对象名称，就是为了在界面发生一定变化后仍能保持较好的识别能力。对象规则越依赖稳定属性，后续版本维护时需要修改的脚本就越少。
总结
“Squish怎么创建GUI自动化测试，Squish测试脚本无法识别控件如何处理”的关键，在于建立稳定的对象识别关系，而不只是把人工操作录制成脚本。GUI界面持续迭代很正常，真正决定自动化测试维护成本的，是对象名称能否适应文本、窗口层级和加载时机的变化。把对象映射整理好，再用稳定场景反复验证，后续新增和维护测试用例都会更顺畅。希望本文对大家使用Squish开展GUI自动化测试有所帮助，如果在对象映射、控件识别或脚本稳定性方面还有疑问，欢迎联系咨询。
