Squish远程执行不稳定，常见表现是同一套脚本在本机稳定，放到远程节点就开始偶发超时、偶发找不到对象、偶发启动失败。根因往往不在脚本本身，而在远程链路把界面可见性、网络抖动、节点一致性这些隐性变量放大了。把问题拆成连接层、会话层、AUT层、结果层逐项固化，远程波动通常会明显收敛。

　　一、squish远程执行为什么不稳定

　　远程执行的“不稳定”多半来自环境差异与时序差异，先把失败类型分清楚，会更快落到可修复点。

　　1、远程会话不可交互导致对象状态不刷新

　　Windows节点用RDP登录后被锁屏、切换用户或进入节能休眠，界面还在但无法真实响应输入，脚本就会出现点击无效与等待超时，截图也可能抓到黑屏或旧画面，现场看起来像对象识别不稳定，其实是会话不可用。

　　2、squishserver默认不允许外部主机访问

　　squishserver即使在节点上启动成功，也可能只接受本机回环地址的连接，控制端或CI机去连就会被拒或偶发断开，需要在squishserverrc里显式配置允许主机列表才会稳定对外服务。

　　3、网络抖动把同步问题放大成偶发失败

　　远程对象查询依赖持续网络交互，网络短抖会让对象查询与事件注入变慢，原本勉强够用的等待时间就会变成偶发超时，表现为某次能跑、某次跑不过，且失败点不固定。

　　4、节点启动了错误的AUT或错误版本

　　同名可执行文件在节点上存在多份路径时，未做Mapped AUT映射容易启动到另一份AUT，窗口结构与对象树不一致会把对象库问题放大成“随机失败”，尤其在节点长期维护、多版本共存的环境里更常见。

　　5、控制端连接到了错误的server实例

　　同网段有多台节点或同节点多实例时，若不显式指定host与port，runner可能连接到默认的本机或错误端口，导致执行落到非预期节点，表面像不稳定，实际是执行目标漂移。

　　6、结果目录与权限问题导致定位信息缺失

　　远程跑挂后如果结果目录不可写，失败截图与日志附件落不下来，团队只能反复重跑碰运气，稳定性问题被进一步放大成“越跑越乱”，但核心仍是落盘路径与权限未固化。

　　二、squish远程节点应怎样管理

　　远程节点管理要解决两件事，一是节点看起来永远像刚装好一样干净可控，二是节点对外提供的squishserver服务可预测可追溯。

　　1、把节点基线做成固定模板

　　统一操作系统版本与补丁节奏，统一显示缩放与分辨率，统一输入法与语言包，统一AUT版本与依赖组件，统一Squish版本与工具包支持，节点越多越要用模板化基线减少差异源头。

　　2、在节点上配置squishserver的允许主机与端口口径

　　在节点机找到squishserverrc文件位置，类Unix系统常见为/etc/squishserverrc，Windows常见为C:squishserverrc，按Squish文档配置允许连接的主机或网段，避免只允许localhost导致远程连接不稳定。

　　3、在控制端把远程server连接做成固定配置

　　打开Squish IDE后进入【Edit】→【Preferences】→【Squish】→【Remote Testing】，关闭自动启动本地server的选项，填写远程节点Host与端口4322，再保存为一条可复用的远程配置，后续切换节点用切配置替代手填参数，减少连错与漏配。

　　4、用Mapped AUT把节点上的AUT路径锁死

　　在Squish IDE进入【Edit】→【Server Settings】→【Manage AUTs】，在Mapped AUTs下点击【Add】把目标AUT可执行文件映射进去，确保server启动AUT时不再从AUT Paths里搜索猜测，避免同名程序被误启动。

　　5、把远程会话保持为持续可交互状态

　　关闭锁屏与休眠，关闭屏保与省电策略，保证RDP或VNC会话在执行窗口期间不会被系统回收，若节点必须无人值守，至少确保执行账号始终处于登录且桌面可见的状态。

　　6、把节点资源占用做成可控上限

　　同一节点同一时间只跑一条GUI用例链，避免多个AUT争焦点与抢GPU资源，定期清理残留进程与浏览器驱动进程，减少上一次残留影响下一次的随机失败。

　　三、squish远程节点应怎样巡检与固化

　　节点管理要长期稳定，离不开巡检与固化动作，目标是让每次失败都能快速判断是节点故障还是脚本问题，并能把节点问题提前拦截。

　　1、建立节点健康检查用例并每日跑一次

　　准备一条最短用例，只做三件事，连接server，启动AUT，打开一个稳定页面并退出，若这条用例都不稳定，优先处理节点与链路，不要让业务回归去背锅。

　　2、把runner连接参数显式化

　　命令行执行时显式指定squishrunner连接的host与port，避免默认连接localhost导致执行目标漂移，同时把结果目录统一落到固定路径，便于归档与回溯。

　　3、把结果与截图归档为节点维度目录结构

　　按日期与节点名分目录保存执行产物，确保每次失败都有对应的日志与截图可追溯，节点侧权限与磁盘空间纳入巡检项，避免磁盘满或权限变更造成“突然不出图”。

　　4、把节点变更纳入变更记录与回滚口径

　　任何影响GUI自动化的变更，如显卡驱动、系统缩放、系统补丁、AUT版本、Squish版本，都记录变更时间与范围，出现波动时先用变更记录缩小排查面，必要时按既定口径回滚到上一基线。

　　5、对不稳定节点做隔离与标签管理

　　给节点打标签，例如win11-qt6，ubuntu-wayland，embedded-x11，把不稳定节点先从回归池里隔离，待健康检查恢复稳定后再放回，避免把节点噪声扩散到全链路。

　　总结

　　Squish远程执行的不稳定，通常来自会话不可交互、server外连权限未配置、网络抖动放大同步问题、AUT路径未映射导致版本漂移，以及结果落盘不可追溯。按squishserverrc放开允许主机，按【Manage AUTs】配置Mapped AUT锁定AUT路径，按runner显式指定host与port并统一结果目录，再配合节点基线模板与健康检查巡检机制，远程执行的波动一般会明显收敛。