JMeter结合Selenium测试时等待下拉框选项填充的实现方法

你只完成了WebDriverWait对象的实例化，全程没有给这个对象绑定任何需要校验的等待规则，也没有触发等待的执行逻辑——这个对象创建完成后就被闲置了，自然不会对脚本流程产生任何延迟阻塞的效果。相当于你拿了个秒表握在手里，但是根本没按启动键，也没定要测的目标事件，当然等不到你要的效果。

方案1：临时固定延迟（适合快速调试） #

如果只是临时跑通流程，不想配置复杂的等待逻辑，可以直接用WebDriver Sampler自带的休眠方法加固定延迟，代码非常简单：
WDS.sampleResult.sleep(3000)
执行这行代码时，脚本会直接阻塞3秒后再往下走。注意这个方法不适合正式压测场景：固定延迟要么会因为等待太久拉长测试执行时间，要么会因为实际页面加载波动导致等的时间不够。

方案2：智能等待下拉框选项加载完成（正式场景推荐） #

用WebDriverWait实现等待时，必须搭配until()方法传入具体的等待判断条件，才能真正触发轮询等待逻辑。针对下拉框异步加载选项的场景，有两种非常适配的等待逻辑：

• 等下拉框选项数量超过初始占位值数量
  大部分异步加载的下拉框，初始状态只会有1个“请选择”类的占位选项，等接口拉取完数据后才会追加有效选项。这种场景下可以设置等待规则：只要下拉框内的option标签数量大于1，就立即结束等待往下执行，代码示例：

  // 初始化超时时间20秒的等待实例
  var waitPropHist = new org.openqa.selenium.support.ui.WebDriverWait(WDS.browser, 20)
  // 传入等待条件：定位目标下拉框的所有option元素，等元素数超过1个时放行
  waitPropHist.until(org.openqa.selenium.support.ui.ExpectedConditions.numberOfElementsToBeMoreThan(
      org.openqa.selenium.By.cssSelector("select#下拉框的实际元素id option"),
      1
  ))
  

  这段逻辑默认每500ms轮询一次页面状态，条件满足就立刻执行后续操作，最多等待20秒，超时直接抛错，比固定延迟灵活很多。
• 等下拉框选项数量达到已知的固定总数
  如果明确知道下拉框最终会加载的选项总个数，可以把等待条件替换成精准匹配总数的逻辑：

  waitPropHist.until(org.openqa.selenium.support.ui.ExpectedConditions.numberOfElementsToBe(
      org.openqa.selenium.By.cssSelector("select#下拉框的实际元素id option"),
      15 // 替换成你实际知道的最终选项总数
  ))
  

注意：如果你的页面下拉框不是原生<select>元素，是div标签模拟实现的下拉组件，只需要把定位器替换成对应模拟下拉的选项元素选择器即可，等待逻辑的核心思路完全一致。

内容的提问来源于stack exchange，提问作者V.Bhanderi