Azure Pipelines中JMeter负载测试Web Driver采样器重复执行问题排查

• 线程组与Taurus配置叠加冲突：检查Taurus的执行配置（如config.yaml里的execution块），是否设置了iterations、hold-for等循环/持续执行参数，和JMeter第一个线程组的“循环次数”配置叠加，导致线程组被多次触发。本地测试可能未启用这类Taurus全局配置，而Pipeline环境的配置文件存在重复执行逻辑。
• 采样器重试机制误触发：确认LoginToEnvironment采样器的“重试次数”是否被设置为大于0，或者Taurus全局配置中开启了retry策略。本地执行时环境稳定未触发重试，但Pipeline环境中首次登录后的会话可能因网络延迟、资源不足等问题被判定为失败，进而触发重试逻辑。
• 环境依赖不一致导致会话失效：Pipeline运行环境的浏览器版本、WebDriver版本与本地存在差异，首次登录后生成的会话Cookie未被正确保留或识别，JMeter判定登录未完成，进而重复执行登录采样器。比如容器化环境中浏览器的无头模式配置与本地不同，导致登录后的会话上下文丢失。
• Taurus的执行上下文隔离问题：在Pipeline的容器环境中，Taurus可能未正确销毁JMeter的执行上下文，导致第一个线程组的实例被重复初始化执行。本地执行时进程结束后上下文直接销毁，不会出现这类问题。
• 会话传递失败触发的连锁重试：第一个线程组登录后的会话Cookie未成功传递到第二个线程组，导致第二个线程组的API请求因未授权失败，若脚本中存在自定义的“失败后重新登录”逻辑（如通过监听器、BeanShell脚本实现），会触发登录采样器重复执行。

排查建议 #

• 对比本地与Pipeline的Taurus配置文件，移除不必要的全局循环/重试参数，确保与JMeter线程组配置不冲突。
• 查看Pipeline运行时的JMeter详细日志，定位LoginToEnvironment采样器的每次触发来源，确认是线程组循环还是重试机制导致。
• 统一本地与Pipeline环境的浏览器、WebDriver版本，检查采样器的“重试次数”设置为0。
• 验证会话Cookie传递：在第一个线程组添加Cookie管理器，确保登录凭证被正确保存，第二个线程组可直接复用；或在Taurus配置中启用会话共享相关设置。

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