Visual Studio Online持续测试中云负载测试遇401未授权错误

我来帮你梳理下这个401未授权错误的常见排查点，毕竟我之前在Azure负载测试这块踩过不少坑😉

1. 测试控制器/代理的身份权限配置 #

• 服务连接权限：Self Provisioning模式下，你用的Azure服务连接对应的服务主体，有没有被授予访问Dev Test Labs VM、目标IaaS应用所在资源组的权限？至少需要Contributor或者更细粒度的权限，确保任务能正常调度VM并访问应用。
• Dev Test Labs VM身份：如果你的IaaS应用需要身份验证，Dev Test Labs里的测试控制器/代理VM有没有配置正确的身份？比如启用系统托管身份，并把这个身份添加到应用的访问控制列表（ACL）里；如果是AD域环境，VM有没有加入域，且运行测试代理的账号有应用访问权限。

2. 目标应用的身份验证适配 #

• 测试请求的凭证携带：你的IaaS应用是不是启用了Windows身份验证、OAuth2或者其他认证机制？如果是，负载测试脚本里有没有正确配置授权信息？比如在Web测试中添加Authorization请求头，或者在测试设置里指定正确的认证凭证。
• Azure AD保护的应用：如果应用用Azure AD保护，要确保测试代理能获取有效的访问令牌。可以尝试在测试任务中配置AD认证参数，或者给测试VM的托管身份分配应用的User Access Administrator或对应的数据访问权限。

3. 网络与访问规则验证 #

• VNet与NSG配置：检查Dev Test Labs的VM和目标IaaS应用是否在同一个VNet，或者有没有通过对等连接、VPN连通。同时确认NSG规则允许VM访问应用的端口（比如80/443），有时候网络不通会伪装成401错误，但先排除这个可能性。
• 私有网络访问限制：如果应用部署在私有网络，测试代理VM有没有加入同一个私有网络？如果是公网访问，应用的防火墙有没有允许测试VM的公网IP？

4. 测试任务的配置细节检查 #

• VM选择正确性：确认测试控制器和代理指定的是Dev Test Labs里正确的VM，有没有选错订阅、资源组或者VM名称？手滑选错资源会导致任务连接到错误的VM，自然无法授权访问目标应用。
• 非托管代理的运行账号：如果用非托管代理，代理服务运行的账号（比如本地系统账号）有没有访问目标应用的权限？可以尝试把代理服务改成用有应用访问权限的域账号或服务账号运行。

先从服务连接和VM身份权限这两个方向入手排查，这是这类401错误最常见的根源。

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