如何使用JMeter实现含iframe支付流程的网站负载测试

可行性结论 #

这个场景完全可以通过JMeter实现，你之前用Blazemeter没捕获到iframe支付请求，是录制配置的问题，不是JMeter能力不支持。

Blazemeter漏抓请求的核心原因 #

Blazemeter录制插件默认开启第三方请求过滤规则，跨域的第三方支付域名请求会被直接筛掉；再加上iframe本身是独立的浏览上下文，如果录制时没等iframe完全加载就操作，或者插件的注入脚本被iframe的sandbox安全策略拦截，自然抓不到这部分链路的请求。

具体实现步骤 #

• 先手动抓全链路请求
  别上来就靠录制工具生成脚本，先打开浏览器DevTools的Network面板，勾选Preserve log，筛选展示所有类型的请求，手动走完一遍完整支付流程，把三个阶段的所有请求、参数、响应结构理清楚：
  1. 找主页面DOM里iframe标签的src属性，对应第一个支付信息输入页的加载请求，记好这个请求的域名、路径、必填请求头
  2. 定位输入卡号、有效期、CVV后点提交触发的请求，记清楚请求方法、参数格式，标记出所有动态生成的参数（比如csrf token、支付流水号、前端加密公钥）
  3. 找到卡信息提交后，第二个支付汇总页iframe的加载请求，记好页面里携带的支付确认token、预订单号这类动态值
  4. 定位最终点击支付按钮触发的提交请求，以及返回订单ID的响应格式
     这里要明确：iframe本质就是独立的HTTP请求，和你开新标签页直接访问iframe地址的请求逻辑没有任何区别，不存在什么特殊的"iframe模拟"配置。
• 配置JMeter核心元件
  1. 先加HTTP Cookie Manager，选标准cookie策略就行，它会自动维护不同域名下的会话cookie，不用手动处理跨域cookie传递的问题
  2. 按照抓包拿到的请求顺序，逐个添加HTTP请求：先加主页面请求，再加第一个iframe加载请求，然后是卡信息提交请求，接着是第二个iframe加载请求，最后加最终支付提交请求。别指望用"自动拉取嵌入式资源"的功能抓iframe请求，这个功能是抓图片、JS这类静态资源的，处理不了表单提交类的动态iframe请求
  3. 做动态参数关联：所有从前序响应里生成的动态参数（比如支付token、nonce、csrf、预订单号），用正则表达式提取器或者JSON提取器从对应响应里提取成JMeter变量，传给后续请求就行。比如第一个iframe页面里的隐藏支付token，直接用正则<input type="hidden" name="payment_token" value="(.+?)"就能提取到
  4. 严格匹配浏览器的请求头：重点补全Referer、Origin、Content-Type这几个字段，第三方支付网关基本都会校验Referer是否来自上一步的支付页面，缺了很大概率直接返回403被拦截。比如提交卡信息时Referer填第一个iframe的地址，提交最终支付时Referer填第二个汇总页的地址
• 处理前端加密逻辑
  如果卡信息提交前有前端JS加密（比如用RSA公钥加密卡号、CVV），也不用换工具：
  • 普通标准加密（AES/RSA/SHA256这类），直接加个JSR223元件写Groovy脚本实现相同加密逻辑，把测试卡的明文信息加密后作为参数提交即可
  • 如果支付流程带强浏览器指纹校验（比如检测webdriver标识、采集鼠标轨迹、输入间隔这类风控规则），加个WebDriver Sampler驱动真实浏览器走完支付环节就行，不用把整个测试都换成UI自动化工具，只需要把支付这一小段换成WebDriver采样器，其余业务接口还是走普通HTTP请求，性能损耗很低。

录制优化建议 #

如果后续想靠录制快速生成初始脚本，别用默认配置的Blazemeter插件：

• 关掉插件里的"过滤第三方请求"开关，把支付服务商的域名加到录制包含规则里
• 或者直接用JMeter自带的HTTP(S)测试脚本录制器，安装好对应根证书，把支付域名加入URL包含匹配规则，就能完整抓到所有iframe里的跨域请求。

注意UAT环境测试时，用支付服务商提供的官方测试卡信息，不要用真实银行卡，避免触发风控导致请求被拦截。

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