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