关闭RDP会话后Squish执行mouseMove报运行时错误的解决方案咨询

RDP会话正常断开时，Windows会直接销毁该会话对应的交互式桌面渲染栈，Squish默认的mouseMove、mouseClick等输入方法走的是系统级输入注入逻辑，依赖活动的交互式桌面上下文，会话销毁后输入接口调用失败就会抛出RuntimeError: Failed sending fake pointer move错误，所有系统级模拟的鼠标、键盘操作都会触发同类问题。

这类方案不需要修改现有测试用例，稳定性最高。

• 用tscon命令绑定会话到本地控制台：RDP连接到VM后，不要直接点窗口右上角的叉断开，在VM内以管理员权限打开命令提示符，执行命令tscon %sessionname% /dest:console，执行后RDP会自动断开，当前会话会被绑定到VM的本地控制台会话，图形渲染栈不会被销毁，Squish的系统级输入模拟可以正常运行。如果执行报错，可以先跑query session查询当前会话的ID，把命令里的%sessionname%替换为对应的会话ID即可。
• 替换远控方式：改用VNC这类挂载在VM本地控制台会话上的远控工具，这类工具断开连接时不会销毁本地桌面上下文，不会触发输入失效问题。如果必须用RDP，断开时统一走上面的tscon命令，不要直接关闭RDP窗口。
• 配置任务计划/运行环境：如果是通过Windows任务计划、CI工具触发Squish命令行执行，任务属性必须勾选「只在用户登录时运行」，不要选「无论用户是否登录都运行」——后者会启动无桌面的隐藏会话，根本无法运行GUI测试。同时提前关闭VM对应用户的自动锁屏、屏保自动恢复到锁屏界面的配置，避免会话空闲后被系统锁定。
• 额外注意：不要通过最小化RDP窗口的方式挂着会话，RDP最小化时默认会切走图形渲染资源，同样可能导致输入失败，这种场景需要修改本地机器的注册表保留RDP最小化时的渲染能力，稳定性远不如tscon方案。

你提到的sendEvent系列函数确实可以绕过该问题：这类函数是直接向Qt控件的事件循环投递原生Qt事件，完全不依赖Windows系统级输入接口，不受RDP会话销毁的影响。

• 适用边界：仅能处理Qt原生控件的操作，如果测试流程中包含系统弹窗、第三方非Qt组件的交互，这部分操作仍然会因为系统输入接口不可用失败。
• 对应事件类型：
  • 鼠标移动：QEvent.MouseMove
  • 鼠标按下：QEvent.MouseButtonPress
  • 鼠标释放：QEvent.MouseButtonRelease
  • 鼠标双击：QEvent.MouseButtonDblClick
    构造事件时需要传入正确的控件相对坐标、控件映射到桌面的全局坐标、当前按下的鼠标按键、键盘修饰键状态，否则会出现事件不响应、点击位置错误的问题。
• 示例代码（Python版Squish脚本，替代原生mouseMove）：

target_widget = waitForObject(":Your_Target_Widget")
rel_pos = QPoint(100, 200)  # 控件内相对坐标
global_pos = target_widget.mapToGlobal(rel_pos)
# 构造鼠标移动事件：事件类型、相对坐标、全局坐标、当前按键状态、修饰键状态
move_evt = QMouseEvent(
    QEvent.MouseMove,
    rel_pos,
    global_pos,
    Qt.NoButton,
    Qt.NoButton,
    Qt.NoModifier
)
sendEvent(target_widget, move_evt)

• 注意事项：该方案维护成本较高，原生Squish输入方法内部自动处理了窗口前置、焦点切换、坐标偏移修正等边界逻辑，自己通过sendEvent构造事件需要手动处理所有这类逻辑，很容易出现用例不稳定的问题，仅作为无代码方案无法落地时的备选。

内容的提问来源于stack exchange，提问作者FatTail