Selenium Grid异常启动大量Chrome实例技术求助

这种Chrome实例残留的问题真的很头疼，尤其是在分布式测试环境里，既占资源又影响后续测试执行。结合你的场景（NUnit3 Console Runner + 多VM Selenium节点），我来梳理几个可能的原因和对应的解决办法：

1. 测试用例中Driver未被正确释放 #

这是最常见的诱因——很多时候测试失败、异常中断时，driver.Quit()或driver.Dispose()根本没被执行到。

• 解决办法：
  • 用NUnit的[TearDown]特性兜底，确保无论测试成功/失败，都能触发Driver清理：

    [TearDown]
    public void CleanupDriver()
    {
        if (driver != null)
        {
            try
            {
                driver.Quit(); // 关闭所有关联窗口并终止Chrome进程
                driver.Dispose();
            }
            catch (Exception ex)
            {
                // 记录日志即可，别让清理失败导致测试额外报错
                TestContext.WriteLine($"清理Driver时出现异常: {ex.Message}");
            }
        }
    }
    

  • 并行测试场景下，绝对不要用静态变量存储Driver，每个测试实例要持有独立的Driver实例，避免多测试共享导致清理混乱。

2. NUnit3并行配置与Selenium节点不匹配 #

你提到每个节点最多跑4个测试，要确认NUnit的并行调度是否和节点配置对齐，超额调度容易导致资源耗尽，进程无法正常退出。

• 检查nunit3-console.exe的运行参数，比如--workers或--agents的设置，确保总并行数不超过6节点×4并发=24的上限。
• 也可以在NUnit.config里统一配置并行策略：

  <NUnit>
    <TestRunner>
      <Parallelization Enabled="True" MaxThreads="24" />
    </TestRunner>
  </NUnit>
  

3. ChromeDriver与Chrome版本不兼容 #

版本不匹配会导致Driver进程无视Quit()指令，顽固残留。

• 确保每个VM节点的Chrome版本和ChromeDriver严格对应，也可以用WebDriverManager自动管理版本（C#版可通过NuGet安装）：

  var driverManager = new ChromeDriverManager();
  driverManager.SetUpDriver(new ChromeOptions());
  

4. VM节点系统资源耗尽 #

当VM的CPU、内存被占满时，Chrome进程可能无法响应退出指令，变成“僵尸进程”。

• 测试时监控VM的资源占用，如果经常达到阈值，要么给VM加资源，要么暂时降低每个节点的并发数（比如从4调到3）。
• 可以在测试套件里加简单的资源监控逻辑，当资源不足时自动终止测试，避免进程残留。

5. 异常中断时的进程清理机制缺失 #

如果测试中途因网络问题、节点离线等意外中断，NUnit可能无法执行TearDown，导致Driver进程残留。

• 给VM节点加个定时清理任务，定期扫掉残留的Chrome和ChromeDriver进程：
  • Windows用批处理：

    taskkill /F /IM chrome.exe /IM chromedriver.exe
    

  • Linux用shell脚本：

    pkill -f chrome
    pkill -f chromedriver
    

  可以设置成每小时执行一次，或者在测试套件执行前后手动触发。

6. Selenium Grid节点配置问题 #

检查节点启动参数，是否设置了合理的会话超时，避免超时后进程未被自动清理。

• 启动节点时添加--session-timeout参数，比如：

  java -jar selenium-server-standalone.jar node --session-timeout=300 --max-sessions=4
  

  这样如果某个会话5分钟无响应，Grid会自动终止对应的Chrome进程。

你可以先从Driver的清理逻辑入手，检查TearDown是否覆盖了所有场景，再逐步排查版本、配置和资源问题。如果还是有残留，试试VM上的定时清理任务，应该能缓解这个问题。

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