GitLab CI运行TestCafe时IE11无法启动且测试冻结问题求助

我之前在Windows环境下用GitLab Runner的SSH/Shell执行TestCafe测试时，也碰到过和你一模一样的IE11冻结问题——直接在虚拟机或SSH连接里跑没问题，一放到CI里就卡壳。折腾了好几天，总结出几个关键的排查方向和解决办法，你可以挨个试试：

1. 检查GitLab Runner的服务运行权限 #

GitLab Runner默认用Local System账户作为服务运行账户，这个账户没有桌面交互权限，而IE11必须依赖桌面环境才能正常启动和运行测试。

解决步骤：

• 打开Windows服务管理器（services.msc），找到gitlab-runner服务
• 右键选择「属性」，切换到「登录」标签页
• 选择「此账户」，输入一个拥有本地管理员权限的账户（比如你平时登录虚拟机的账户），输入密码
• 勾选下方的「允许服务与桌面交互」选项
• 重启GitLab Runner服务，再重新触发CI任务

2. 确保Runner在有桌面的会话中执行 #

GitLab Runner的Shell executor默认会在Windows的Session 0（后台会话）中运行命令，这个会话没有可视化桌面，IE11无法正常初始化。

解决办法：

• 如果用的是Shell executor，在Runner的配置文件（config.toml）里给对应的runner加上shell = "powershell -ExecutionPolicy Bypass -NoProfile -Interactive"，强制启用交互式会话
• 如果用的是SSH executor，确保SSH连接是交互式的——在CI脚本开头加上Start-Process explorer.exe（或者其他能唤起桌面会话的命令），再运行TestCafe

3. 调整TestCafe的IE11启动参数 #

给TestCafe命令加上针对性的参数，强制IE11以兼容CI环境的方式启动：

testcafe ie your-test-file.js --disable-gpu --force-browser-launch --verbose

• --disable-gpu：禁用GPU加速，避免CI环境下的显卡兼容问题
• --force-browser-launch：强制启动浏览器，忽略可能的启动检测错误
• --verbose：输出详细日志，方便排查冻结时的具体环节

4. 配置IE11的安全与兼容性设置 #

CI环境下的IE11可能有默认的高安全设置，阻止TestCafe注入测试脚本：

• 在虚拟机中手动打开IE11，把你的测试站点添加到「信任站点」
• 关闭「增强保护模式」（设置 -> 安全 -> 互联网 -> 自定义级别 -> 找到「增强保护模式」禁用）
• 关闭弹出窗口阻止程序
• 可以用reg export命令导出IE的配置，在CI脚本里用reg import导入，确保每次CI运行都用相同的设置

5. 排查工作目录权限问题 #

有时候CI的工作目录权限不足，导致TestCafe无法生成临时测试文件，进而卡住：

• 在CI脚本开头切换到一个有读写权限的目录，比如：

cd C:\Temp
New-Item -Path .\testcafe-temp -ItemType Directory -Force
Set-Location .\testcafe-temp

• 再执行TestCafe命令

如果还是不行，建议打开TestCafe的调试日志（加上--debug参数），看看冻结时日志停在哪个步骤——比如如果停在「Waiting for browser to connect」，那大概率是浏览器没正常启动，回到前两个权限/会话的问题排查；如果停在某个测试步骤，那可能是测试用例本身在CI环境下的兼容性问题。

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