看来你在JMeter录制ASP.NET Web应用的登录负载测试脚本时踩了个典型的坑——明明手动登录一切正常，回放脚本就报用户名或密码错误。这种情况在ASP.NET生态里太普遍了，大多是没处理好它自带的表单验证和状态维持机制。我来帮你一步步排查解决：

1. 确认__VIEWSTATE和__EVENTVALIDATION的关联是否正确（Web Forms场景） #

ASP.NET Web Forms会动态生成__VIEWSTATE和__EVENTVALIDATION这两个隐藏字段，每次请求的取值都不一样，必须从登录页面的GET响应里提取，再精准传递到后续的POST登录请求中。你提到做了关联，不妨再核对下：

• 用正则表达式提取器（或CSS/JQuery提取器）从GET登录页面的响应中抓取这两个字段：
  • __VIEWSTATE的正则示例：id="__VIEWSTATE" value="(.+?)"
  • __EVENTVALIDATION的正则示例：id="__EVENTVALIDATION" value="(.+?)"
• 确保POST登录请求里的这两个参数，已经用提取出的变量（比如${VIEWSTATE}、${EVENTVALIDATION}）替换掉录制时的固定值，而不是沿用旧的失效值。

2. 检查SessionId的自动传递是否正常 #

ASP.NET依赖ASP.NET_SessionId维持会话状态，录制时的SessionId在回放时早已失效。解决这个很简单：

• 确保你的测试计划里已经添加了HTTP Cookie管理器，它会自动帮你处理Cookie（包括SessionId）的生成、传递和更新，不用手动关联。
• 留意Cookie管理器的设置：如果是多线程循环测试，“Clear cookies each iteration?”选项要根据场景调整——第一次登录前建议清空，后续迭代保持Session延续。

3. 排查AntiForgeryToken（MVC/Core场景） #

如果你的应用是ASP.NET MVC或Core，登录表单里大概率会有__RequestVerificationToken这个隐藏字段，它也是动态生成的，必须关联：

• 从登录页面的响应中提取该token，正则示例：name="__RequestVerificationToken" type="hidden" value="(.+?)"
• 在POST登录请求的参数列表中添加这个字段，值用提取出的变量替换。

4. 验证参数化凭证的传递准确性 #

你已经做了凭证参数化，不妨再确认两点：

• 参数化的变量名要和登录表单的name属性完全匹配，比如页面里用户名输入框的name是txtUserName，那JMeter里的参数名就得一模一样，不能写错。
• 打开查看结果树，查看POST请求的实际提交内容，确认参数值确实是你设置的有效凭证，而不是空值或错误的占位符。

5. 补全必要的请求头 #

ASP.NET服务器有时会验证请求头的合法性，比如：

• 添加HTTP Header管理器，设置正确的User-Agent（和录制时一致即可），避免被服务器识别为非浏览器请求。
• 确保Referer字段设置为登录页面的完整URL，部分服务器会验证请求来源是否合法。

6. 查看服务器日志（如果有权限） #

如果以上步骤都试过还是不行，建议查看服务器的IIS日志或应用日志——里面会记录登录失败的具体原因（比如token无效、Session过期、参数不匹配等），能帮你快速定位核心问题。

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