HTTP Status 401意味着未经授权，所以我宁愿假设你的第二个凭证有问题。
因此，首先请仔细检查用户凭据是否正确，并检查用户是否可以访问“测验”（无论它是什么），当您使用真实的浏览器手动执行此操作时。这也可能是权限问题。
关于“如何参数化”-我们不能提供一个全面的答案，如果不知道你的“测验”的细节，通常它应该通过相关或参数化（正确的凭证，唯一的值等）处理。
当涉及到“验证”时，通常人们使用响应Assert来确保响应包含预期的数据，并且不包含错误。
此外，您肯定无法从一台机器上模拟10万个虚拟用户，因此请记住，您需要使用Distributed Testing

在100，000个并发用户的情况下，存在足够的风险来支持市场上的任何工具，特别是在100，000到100万用户竞技场中具有强大的经过验证的跟踪记录并进行全面监控和分析的工具。
第二，当你正在努力学习工具基础知识时，你不应该运行一个100，000用户的测试，风险已经足够了，应该由一个有经验的团队来进行这样的测试。
第三，您正在努力解决的概念是识别和处理动态数据的工具基础级别
1.记录两次，相同的凭据。检查记录之间的差异。这些差异相当于会话、状态、时间等。使用工具功能解决这些问题
1.第三次记录。更改凭据。这次更改（除了上面（1）中确定的更改）与帐户选择直接相关。使用工具功能解决这些问题。
您需要对负载生成器上的用户权重进行基准测试，以了解您需要多少负载生成器。监视负载生成器上的精细资源利用率，依次为1、10、100个用户。然后计算100，000个用户的资源池大小。您可以放心地假设您在5时至少有20个生成器，对于非常大的生成器和非常小的资源占用的虚拟用户，每个虚拟用户可以有40或50个负载生成器，这取决于每个用户的资源需求。
您不想“最大化”您的负载生成器。您希望它们订阅不足。当您在内存和CPU上超过80%的资源池利用率时，您的开销将降低用户的速度。您不会在网络等冲突域中获得100%的利用率。您的磁盘很容易成为一个拖动锚，这取决于您的日志级别，从而降低每个用户的速度
在您要求达到的负载级别上，一切都是不平凡的。您的管理层需要几位强大的导师来帮助您构建可靠的测试、测试床、监控框架、分析框架，并快速成熟您的技能。
请始终记住，我们所做的事情的价值不是测试。测试只是产生数据。价值在于分析数据，以提出改进被测系统性能的建议。为此，您需要比简单的负载抛出更多的功能。您需要监控应用程序的有限资源池，访问应用程序日志，便于分析结果（汇集时间和资源利用水平）和报告的界面/应用程序。