使用Cucumber、Selenium、Java18和JUnit无法运行自动化测试求助

一、WebSocket连接失败（Selenium驱动与浏览器通信问题） #

• 核对浏览器与驱动版本：ChromeDriver/GeckoDriver必须和本地浏览器大版本完全匹配，比如Chrome 119就得用ChromeDriver 119.x。直接去驱动官网下对应版本替换，或者在build.gradle里加webdrivermanager依赖自动管理驱动：

  testImplementation 'io.github.bonigarcia:webdrivermanager:5.6.0'
  

• 排查防火墙/代理：Windows 11防火墙可能拦了Selenium和浏览器的WebSocket通信，临时关防火墙测一下，或者给浏览器、Java进程加防火墙允许规则。
• 换浏览器测试：比如从Chrome切到Firefox，排除单一浏览器的兼容问题。

二、GoogleSteps类无法实例化 #

• 检查构造方法：确保GoogleSteps的构造方法是public，不能是私有，要是依赖了BasePage这类类，得保证这些依赖能正常初始化（比如要么手动new，要么靠Cucumber的依赖注入）。
• 确认Cucumber扫描路径：在build.gradle的Cucumber配置里，glue必须指向steps所在的包，比如：

  cucumber {
    glue = ['com.yourproject.steps']
    features = ['src/test/resources/features']
  }
  

• 排查依赖冲突：跑gradle dependencies看依赖树，把重复或者版本不兼容的依赖排除掉。比如别同时混着JUnit 4和JUnit 5，所有测试依赖统一用JUnit 4.13.2。

三、BasePage初始化失败 #

• 检查WebDriver初始化逻辑：BasePage里如果用到WebDriver，得确保Driver实例是全局有效的——比如是不是在Cucumber的Hook类（@Before注解的方法）里先初始化了Driver，再传给Page类。
• 检查驱动路径：要是BasePage里有静态代码块加载驱动，Windows下路径得用\\或者/，而且驱动文件得确实存在指定路径里。
• 排查依赖注入：如果用了DI框架管Page对象，得确认BasePage的Bean配置没毛病，依赖的对象都能正常拿到。

四、通用排查动作 #

• 清缓存重构建：执行gradle clean build --refresh-dependencies，把旧的编译文件和缓存依赖清掉，重新下载依赖编译。
• 回滚代码：之前能跑，就对比Git提交记录，回滚最近改的build.gradle、Page类或者Steps类，看是不是改代码搞崩的。
• 换JDK版本：Cucumber 7.11.1对JDK 18的支持可能有坑，试试降级到JDK 17（LTS版本），大部分框架对LTS版本兼容性更稳。

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