Karate 1.5 Chrome UI测试频繁报错：连接拒绝与退出码137

问题背景 #

运行Karate 1.5版本的Chrome UI测试时，非UI（API）测试运行正常，但UI测试频繁失败，报错信息如下：

[WARN] [com.intuit.karate.shell.Command.run] - exit code was non-zero: 137 - [/usr/bin/google-chrome, --remote-debugging-port=xxxxx, ...]

ERROR com.intuit.karate - http request failed:
org.apache.http.conn.HttpHostConnectException: Connect to localhost: failed: Connection refused (Connection refused)

困惑点 #

• 退出码137总是对应之前尝试绑定失败的端口，而非当前出现连接拒绝的端口
• 已知137代表SIGKILL，Karate会调用destroyForcibly()清理Chrome进程
• 怀疑Chrome未正常启动或未就绪，导致Karate过早尝试连接调试端口从而出现连接拒绝
• 本地及容器环境中启用多个测试运行器时均会出现此问题

当前驱动配置 #

function fn() {
  var config = {
  };

  karate.configure('driver', {
    type: 'chrome', 
    showDriverLog: true,                   
    showProcessLog: true,                                       
    headless: true,
    pollInterval: 500,
    pollAttempts: 60,                   
    addOptions: [
      '--start-maximized',
      '--no-sandbox',
      '--no-zygote',
      '--disable-gpu',
      '--ignore-certificate-errors',
      '--disable-dev-shm-usage'
    ]
  });

  return config;
}

核心问题 #

1. 我的怀疑是否正确——Chrome未完全启动/就绪导致连接拒绝？
2. Karate+Chrome UI测试在CI或容器环境中不稳定的典型根因及最佳实践是什么？

问题解答 #

1. 关于Chrome未就绪导致连接拒绝的怀疑 #

你的怀疑是正确的。退出码137（SIGKILL）通常是Chrome进程因资源不足被系统杀死，或启动过程中异常崩溃。连接拒绝问题大概率是Karate在Chrome未完成启动、调试端口未就绪时就发起了连接请求。而端口不匹配的情况，可能是Karate内部端口管理的时序冲突：前一次失败的进程清理不彻底，新进程绑定新端口，但Karate仍尝试连接旧端口，或端口复用逻辑出现异常。

2. CI/容器环境中不稳定的典型根因及最佳实践 #

典型根因

• 资源不足：容器或CI节点的CPU、内存配额过低，Chrome启动或运行时因资源耗尽被系统发送SIGKILL（退出码137）
• 进程清理不彻底：测试结束后Chrome进程未被完全销毁，残留进程占用端口或资源，导致新测试无法正常启动Chrome
• 启动时序问题：Chrome在容器环境中启动速度较慢，默认的轮询配置（pollInterval、pollAttempts）不足以等待Chrome完全就绪
• 容器环境限制：缺少必要系统权限，或/dev/shm空间不足（即使添加--disable-dev-shm-usage仍可能存在问题）

最佳实践

• 调整资源配额：给CI/容器分配至少2核CPU、2GB内存，避免Chrome因资源不足被杀死
• 优化进程清理：
  • 测试套件结束时显式调用karate.driver.quit()确保Chrome进程销毁
  • 在CI脚本中添加前置/后置步骤，清理所有残留Chrome进程（如执行pkill -f chrome）
• 延长启动等待时间：增大pollAttempts（例如设为120）或pollInterval（例如设为1000），给Chrome足够的启动就绪时间
• 优化Chrome启动参数：
  • 移除无头模式下无意义的参数（如--start-maximized）
  • 添加--disable-extensions、--disable-plugins减少启动负载
  • 可尝试添加--single-process减少资源占用（注意：该参数可能降低稳定性，需测试验证）
• 隔离测试环境：并行测试时，确保每个测试运行器使用独立的Chrome实例和端口，避免端口冲突
• 日志排查：利用showDriverLog和showProcessLog的输出，重点查看Chrome启动时的错误日志，确认是否存在依赖缺失等具体启动失败原因

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