我知道这可能是问题的重复，但我开始在我的 Web 项目中使用 WebPerformanceTest 和 LoadTest。我可以运行 WebPerformanceTest 和 Loadttest。
现在我需要与 Dev 团队或 Busniess 团队分享哪些参数/统计数据？我想到了这些。但是如果有人分享我可能需要考虑分享的其他参数，那就太好了。
1.应用可以支持的用户数
2.Reposne时间应用程序在可持续负载下可以给出什么
【问题讨论】：
标签： performance load-testing performance-testing performancecounter loadrunner
以下您可以考虑分享的内容，
【讨论】：
如果您不限制响应时间，最大用户数可能会令人困惑。对于 100 毫秒请求，10 个同时用户意味着 100 rps（每秒请求数），对于 10 秒请求，100 个同时用户意味着只有 10 rps。 如果您使用简单的基于命中的测试（例如测试单页或特定请求性能），最好使用 rps 指标。
对于响应时间 - 平均时间也可能令人困惑，尤其是在响应时间差异很大的情况下，最好提供一些百分位数的响应时间。
即50 毫秒内 50%、55 毫秒内 75%、60 毫秒内 90%、70 毫秒内 95%、90 毫秒内 99% 和 10 秒内 100%。平均时间为 150 毫秒。对于某些服务，150 毫秒是非常好的，但是大约 1% 的非常慢的响应是不可接受的，并且仅使用平均响应时间和中等响应时间几乎找不到该问题。
另外，根据我的经验，收集资源使用情况统计信息（cpu、内存、I/O 强度和网络使用情况）对于确定瓶颈非常有帮助（即由于内存不足导致 I/O 高导致服务变慢）用于缓存）。
【讨论】：
你问的问题对吗？
对我来说，负载和性能测试的很大一部分是决定我的客户想要了解关于被测系统的哪些信息。有一个元素是“我可以向客户展示什么数据？”但这是基于解释他们的要求。客户可能不知道该问什么，作为测试人员，您的工作就是了解客户想要什么，并为他们提供他们想要的答案。
您列出的两个主题向用户展示了系统的显示方式：系统何时中断以及响应速度。根据用户负载的变化率和测试的持续时间，这些因素有多种变化。
其他因素包括正在测试的服务器计算机的各个部分的性能。 Visual Studio 负载测试可以在测试运行时从其他计算机收集性能数据。因此，他们可以监控 Web 服务器、数据库服务器、应用程序服务器等。在每台服务器上，可以收集有关 CPU 和内存使用情况、SQL 和 IIS 性能等的数据。所有这些数据都可以（最容易通过图表）与用户负载、错误率和事务时间进行比较，以确定系统的哪些部分有足够的空间、哪些部分很忙以及哪里出现了瓶颈。监控所有这些数据还可能会发现来自各种服务器的阈值警告，应根据 Microsoft 文档以及可能的其他来源检查它们，以确定它们是否会对系统性能产生不利影响，以及是否应该对其进行更详细的调查。
这些和许多其他想法都是可能的，但这一切都可以追溯到制定您的客户想要学习的内容。
same question 是在另一个论坛上被问到的，上面的话和我在那里发布的答案几乎相同。
【讨论】：
您可以向您的客户提供以下详细信息：
【讨论】：
听起来您根本没有（或非常差）要求，并且您在性能测试和工程领域没有深入的了解。至于收集什么
测试前：
构成负载的业务功能的完整负载配置文件。
每个业务功能的文档。每个业务职能部门的时间项目。
每个定时业务功能的预期响应时间
特别注意思考时间和迭代节奏
来自当前系统的 Web 日志，因此您可以客观地衡量在任何给定时间有多少人在系统上，而不是有多少会话处于活动状态且尚未超时。
测试环境与生产环境具有一些定义的匹配级别，以适当地扩展您的负载。
在测试中
响应时间与业务功能在需求/用户故事上的时间相匹配
其他枚举数据点的需求（命中、返回量等）
测量被测系统中的任何有限资源，以识别慢速响应时间的瓶颈。您可以从顶层（CPU、磁盘、内存、网络）开始，然后在发现顶层资源受限时逐步了解这些统计信息。
测试后：
执行概述：您是否满足要求（是|否）
详细数据：响应时间、监控峰值
分析：阻碍您前进的可能瓶颈在哪里
如果您试图代表人类行为，那么在任何情况下都不应消除思考时间。思考时间或单个会话上请求之间的时间被纳入客户端-服务器模型的定义中，当您将其减少到零时，您的测试变得越来越不能预测生产中会发生什么
【讨论】：
通常，它基于您希望在给定硬件和环境下实现的基准。 以下是关键参数
响应时间（通常是页面）
CPU、内存和磁盘 IO 以及网络的吞吐量利用率
带宽（适用于与外设集成的情况 系统）
成功百分比
【讨论】：