Karate UI测试在GitHub Actions运行失败，求配置方案与问题解决

问题核心分析 #

报错显示Cannot read properties of null (reading 'focus')，本质是页面元素未完成渲染就执行了操作。本地环境资源充足，页面加载快所以无问题；而GitHub Actions的Ubuntu Runner资源有限，headless模式下Chrome渲染速度较慢，导致元素定位时机过早。

具体解决方案 #

1. 优化测试代码的等待逻辑

在操作元素前，必须确保元素已可见/可交互，避免直接执行操作：

Scenario:
    Given driver baseUrl + 'registration/'
    And waitForPage() // 等待页面完全加载完成
    # 先等待元素可见再操作
    And waitForVisible("//*[@id='firstName']")
    And input("//*[@id='firstName']", '')
    When click("//*[@id='content']/div/form/div[2]/button")
    Then waitForVisible("//*[@id='content']/div/form/div[1]/div[2]/div[1]/small")

• waitForPage()：等待页面load事件触发，确保静态资源加载完成
• waitForVisible()：比waitFor()更精准，确保元素不仅存在，还处于可见状态

2. 调整Chrome驱动配置适配GitHub Actions环境

修改Karate驱动配置，增加针对CI环境的启动参数：

* configure driver = { 
    type: 'chrome', 
    headless: true, 
    showDriverLog: true, 
    addOptions: [ 
        '--headless=new',
        '--no-sandbox', // 禁用沙箱，GitHub Actions的Ubuntu环境必须配置
        '--disable-dev-shm-usage', // 解决/dev/shm空间不足导致的Chrome崩溃
        '--disable-gpu', // 禁用GPU加速，headless模式下无需GPU
        '--window-size=1920,1080' // 设置标准窗口大小，避免元素布局偏移
    ],
    waitForTimeout: 15000 // 全局延长等待超时到15秒，适配CI环境的慢加载
}

3. 简化GitHub Actions的浏览器启动流程

避免手动启动chromedriver和Xvfb的潜在冲突，改用更稳定的配置：

runs-on: ubuntu-latest
timeout-minutes: 10
steps:
  - uses: browser-actions/setup-chrome@v1
    with:
      chrome-version: 114
  - uses: actions/checkout@v4 # 升级到最新版本，提升稳定性
  - run: |
      export DISPLAY=:99
      sudo Xvfb -ac :99 -screen 0 1920x1080x24 > /dev/null 2>&1 &
      # 移除手动启动chromedriver的步骤，Karate会自动匹配Chrome版本下载对应驱动

• 移除nanasess/setup-chromedriver：Karate的驱动管理模块会自动根据Chrome版本下载适配的chromedriver，无需手动指定版本，避免版本不匹配问题

4. 全局调整测试超时配置

在karate-config.js中增加全局超时，确保所有等待操作都有足够时间：

function fn() {
    var config = {
        baseUrl: 'your-app-url',
        karate: {
            waitForTimeout: 15000,
            connectTimeout: 10000,
            readTimeout: 10000
        }
    };
    return config;
}

验证效果 #

修改后重新触发GitHub Actions，观察测试是否不再出现随机失败的情况。如果仍有个别元素问题，可以针对特定操作增加pause(500)（短暂等待500ms）作为临时方案，但优先使用显式等待而非固定延迟。

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