LoadRunner单迭代测试Microsoft CRM 365出现巨量响应时间，人工操作无此问题

我之前帮团队排查过好几次LoadRunner录制Dynamics 365脚本的类似问题，这种单迭代响应时间飙高但人工操作完全没感觉的情况，大多是脚本录制或回放配置没贴合实际业务场景导致的，下面是几个亲测有效的排查方向和解决办法：

1. 捕获了冗余的后台异步请求 #

Dynamics 365会在后台偷偷加载一堆遥测、用户行为分析类的异步请求，人工操作时这些请求在后台跑，根本不会影响前端体验，但LoadRunner会把所有请求的时间都算进去，直接把总响应时间拉虚高。

• 解决办法：
  • 录制前先去LoadRunner的「HTTP/HTML录制选项」里，过滤掉无关域名：比如把第三方统计、广告类的域名直接排除，或者路径里带/telemetry/、/analytics/的请求也过滤掉。
  • 录制完脚本后，手动扫一遍，把那些和你的业务流程完全无关的web_url、web_submit_data请求注释掉，只保留核心业务步骤的请求就行。

2. 动态参数没做关联 #

CRM 365几乎全是动态生成的参数——会话ID、请求令牌、表单验证值这些，要是录制完脚本里还留着硬编码的静态值，回放时服务器会触发异常校验，要么等待超时要么反复重试，响应时间自然就长了。

• 解决办法：
  • 先用LoadRunner自带的关联扫描功能：在脚本编辑器右键选「Scan Script for Correlations」，让工具自动识别需要替换的动态参数，生成web_reg_save_param关联函数。
  • 手动检查关键请求（比如登录后首页加载、表单提交）的请求头和请求体，确保像RequestVerificationToken、SessionId这类参数都是从之前的响应里提取的，不是写死的静态值。

3. 浏览器模拟配置不匹配 #

LoadRunner默认的浏览器模拟参数和真实浏览器差异很大，比如缓存策略、并发连接数设置不对，会导致服务器返回资源的方式和人工操作时不一样，耗时自然就上去了。

• 解决办法：
  • 打开脚本的「Runtime Settings」，调整「Browser Emulation」：
    • 勾选「Simulate browser cache」，模拟真实浏览器的缓存行为，避免重复加载CSS、JS、图片这些静态资源。
    • 把「Maximum number of concurrent connections per server」设为真实浏览器的并发数（比如Chrome默认是6个），别用默认的极端值。
  • 单迭代测试的话，关掉「Simulate a new user on each iteration」，保持会话连续性，更贴近人工操作的场景。

4. 缺少浏览器的预加载机制 #

人工操作时浏览器会提前预加载常用资源，但LoadRunner回放是按脚本顺序挨个执行请求，没有预加载，导致某些资源请求需要服务器重新生成，耗时增加。

• 解决办法：
  • 单迭代测试的话，可以注释掉脚本开头的web_cache_cleanup()函数，模拟浏览器的缓存状态，避免每次都重新加载所有资源。
  • 把静态资源请求（比如公共JS库、图标）用web_concurrent_start()和web_concurrent_end()包裹，模拟浏览器的并行加载行为，减少整体耗时。

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