JMeter非GUI模式在Jenkins中运行时Include Controller异常排查

这个问题我之前处理过好多次，核心原因基本都是JMeter非GUI模式下的路径解析逻辑和GUI不一样，加上Jenkins的工作目录特性导致的。咱们一步步拆解：

问题根源分析 #

• 工作目录不匹配：
  本地GUI运行时，JMeter的当前工作目录就是你打开A_script.jmx的目录，所以相对路径B_script.jmx能直接找到文件。但Jenkins执行构建时，默认的工作目录是Job的workspace根目录（或者你构建步骤里指定的其他目录），如果你的脚本是放在workspace的子文件夹里，或者启动JMeter时没有切换到脚本所在目录，相对路径就会失效。

• 路径解析逻辑差异：
  JMeter非GUI模式下，Include Controller里的路径是相对于启动JMeter命令时的当前工作目录，而不是A_script.jmx所在的目录。这和GUI模式下的路径解析逻辑完全不同，也是最容易踩坑的点。

• 报错里的ModuleController提示：
  你看到的ModuleController:Notification has no selected Controller其实是Include失败后的连锁反应——因为B脚本没被正确加载，里面的ModuleController找不到目标元素，才触发了这个错误，根源还是Include路径的问题。

具体解决步骤 #

1. 先确认Jenkins里的脚本位置 #

在Jenkins构建步骤里先添加一条命令，打印当前目录和文件结构，搞清楚脚本的实际位置：

• Linux/macOS：

  pwd
  ls -R ${WORKSPACE}
  

• Windows：

  cd
  dir /s %WORKSPACE%
  

  这一步能帮你确认A_script.jmx和B_script.jmx是否真的在同一目录，避免想当然的路径错误。

2. 切换到脚本目录再启动JMeter #

最简单的解决方法是，在执行JMeter命令前，先cd到脚本所在的目录。比如：

• Linux/macOS：

  cd ${WORKSPACE}/your-script-folder  # 替换成实际的脚本目录
  jmeter -n -t A_script.jmx -l test-results.jtl
  

• Windows：

  cd %WORKSPACE%\your-script-folder
  jmeter -n -t A_script.jmx -l test-results.jtl
  

  这样JMeter启动时的工作目录就是脚本所在目录，相对路径B_script.jmx就能正常识别了。

3. 使用绝对路径（更可靠） #

如果切换目录不方便，可以直接用绝对路径引用B脚本。Jenkins里可以用环境变量${WORKSPACE}（Windows是%WORKSPACE%）来拼接绝对路径：
在Include Controller的路径里填写：

${WORKSPACE}/B_script.jmx

或者用JMeter的属性变量来传递路径，比如启动JMeter时加上：

jmeter -n -t A_script.jmx -l test-results.jtl -JscriptDir=${WORKSPACE}

然后Include Controller的路径写：

${__P(scriptDir)}/B_script.jmx

这种方式更灵活，适合脚本目录结构变化的场景。

4. 检查脚本内的ModuleController引用（兜底） #

如果前面的方法都没用，再检查B_script.jmx里的ModuleController：确保它引用的元素名称没有拼写错误，而且是在A_script.jmx里存在的元素。不过你本地GUI运行正常，这个概率比较低，但可以作为最后排查步骤。

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