JMeter脚本执行后数据库插入Flowsheet数量不足且无报错，如何排查根因？

这类“JMeter统计错误率为0，但业务结果不符合预期”的场景，根因基本都集中在HTTP层面通信成功但核心业务逻辑未执行的层面，具体常见诱因包括：

• 动态参数关联失效触发后端静默拦截
  Blazemeter录制脚本时，通常会自动抓取流程中的所有请求，但不会自动关联流程间的动态依赖参数。如果患者选择请求、Flowsheet页面加载请求返回的关键参数（如患者唯一ID、CSRF跨域token、页面临时操作凭证）没有配置动态提取器，所有线程会直接使用录制时写死的静态固定值发送保存请求。多数医疗类业务系统的后端接口，对参数不合法的请求不会返回4xx/5xx错误码，而是返回HTTP 200的带业务提示的页面（如“所选患者状态不可编辑”“参数校验失败”），但实际不执行数据库插入操作。由于JMeter默认仅靠HTTP响应状态码判定Sample成功与否，这类被业务拦截的请求会被统计为无错误。
• 会话隔离失效导致请求被抢占中断
  配置中开启了Same User on each Iteration，但如果HTTP Cookie Manager没有开启逐线程独立存储cookie的选项，10个线程会共用同一个全局登录态。当某个线程触发流程末尾的退出登录操作时，后端会主动清除该账号的全局会话，其余未执行完保存操作的线程发送请求时，会被后端识别为“会话失效”，同样返回HTTP 200的登录跳转页，不会执行保存的插入逻辑，也不会产生任何HTTP层面的报错。
• 后端幂等规则触发非阻塞拦截
  如果所有线程因为参数关联失效，都选中了录制时固定的同一个患者，后端针对同一患者同一时间窗口的Flowsheet保存操作，会触发幂等校验拦截：仅会为第一个到达的请求执行数据库插入，后续相同参数的重复请求会直接返回200的“操作重复”提示，不做重复落库，最终表现为落库数少于线程总数。
  加上线程组配置的Sample出错处理动作设置为Continue，流程不会因为单个请求的失败中断，会按顺序走完从登录到退出的全链路，从外部看整个脚本的执行流程没有任何断点。

针对这类“零错误率但业务结果不对”的问题，按照从易到难的顺序排查即可快速定位根因：

• 重构成功判定逻辑，打破“HTTP 200即成功”的误判
  给Flowsheet保存请求添加针对性的Response Assertion，匹配接口返回中真正代表保存成功的标识：比如匹配响应页面的“保存成功”文案、JSON响应中的业务成功状态码、或者保存完成后跳转的特定Flowsheet详情页URL。用1个线程、1次循环的配置重新跑脚本，确认业务断言可以正常识别真成功、排除假成功的Sample，再逐步提升线程数，统计所有被判定为业务成功的Sample数量，和实际落库数做初步对账。
• 逐线程校验动态参数与会话的独立性
  临时把线程数调整为2个，在参数提取器的后端添加调试取样器，打印每个线程获取到的患者ID、会话Cookie、临时token值，检查是否存在多线程共用同一个静态参数、Cookie相互覆盖的问题。重点核查Blazemeter录制脚本的自动提取规则是否匹配实际的响应内容，有没有因为正则表达式匹配不到值，导致参数直接回退为录制时的静态值的情况。
• 核查会话管理器的配置项
  打开HTTP Cookie Manager的配置面板，确认开启了“每个线程独立存储Cookie”的选项，关闭全局Cookie共享逻辑，避免多个线程的登录态、退出操作相互干扰。
• 联动后端确认静默拦截规则
  和后端开发确认保存接口的异常分支处理逻辑：比如会话失效时是否返回200、同一患者短时间重复提交时是否触发幂等拦截，把这些异常分支对应的响应特征加到断言规则里，精准定位被拦截的请求对应的拦截原因。
• 全量对账校验
  每次调整脚本后，执行小规模的多线程测试，逐次统计数据库新增的Flowsheet记录数，和JMeter通过业务断言判定的成功Sample数做比对，直到两者数量完全一致，再开展后续的全量压测。

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