1、集合点
如果在LR的controller里面不设置集合点，然后让1000个用户并发执行脚本没有系统瓶颈，那么可不可以认为这个系统支持1000个用户同时并发？
不设置集合点，没有并发
不设置集合点，只是说1000用户再用。。真正产生压力就是多少个用户同时在跑一个应用
2、用户要求支持100个用户，但是这个100用户是什么概念呢？同时在线人数？同时执行某个操作的人数？平均负载？峰值负载？
举个例子，假如说用户要求系统每秒最大可以处理100个登陆请求，那么你需要验证系统的响应能力是否可以达到这个要求。怎么验证呢？你可以使用上面这篇文章中的方法，使用不同的负载来观察系统的响应情况，例如分别使用 10/25/50/75/100 个并发用户来执行登陆操作，然后观察系统在不同负载下的响应时间和每秒事务数。
在实际执行时，你会发现随着并发用户数量的逐渐增加，先是每秒事务数增加，而响应时间变化不大；
但当到达某个点时，例如 50 并发用户时，每秒事务数不再随负载的增加而增加，而响应时间的值开始变大，硬件资源和软件资源使用已经饱和；
当负载继续增大，例如到达 75 或 100 并发用户时，响应时间开始明显延长，并且每秒事务数开始下降，硬件资源和软件资源使用完全饱和。
如果根据上面的描述，你可能会发现登陆模块最大能支持的并发用户数只有75。当然，如果考虑到响应时间的要求，可能会只有 50。
你可以按照上面的思路来执行测试，并应用文中提到的方法来对系统的响应能力进行分析，最终得到你的结论。
3、那么如何测试“用户要求系统每秒最大可以处理100个登陆请求”呢，
是在设置场景的时候在一个场景中设定100个用户，然后每隔多长时间增加几个用户还是在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户……？
"每隔多长时间增加几个用户"——如果是要验证系统的响应能力，不赞成这种方法；
"在不同的场景中如10个用户为一个场景，另一个场景25个用户，另一个场景75个用户"——你可以直接设计一个 100 用户的场景，但是不能只有这一个场景。至于其他场景如何设计，要结合测试的结果来考虑。例如，如果你发现 100 个并发用户的时候平均事务响应时间只有0.2秒，那么系统还可以承受更大的负载，你可以考虑再增加 200/300/400/500 等场景的测试；而如果发现系统在 100 并发用户的情况下响应时间已经是 5 秒，那么应该增加 15/25/50/75 等场景的测试。
没有足够多的数据和样本，单凭一个场景的测试是很难进行分析和得出结论的。
说白了性能测试跟做试验很相似。
4、性能测试案例中的并发用户数怎么计算得到？
例如：某公司的OA系统，注册用户5000，在线用户2000。
那么，我做性能测试时，设定并发用户为多少呢？
有些固定的经验公式，还是要根据什么得到？
一直困扰。
1.性能需求需要进一步明确：在线用户数量不等于并发用户数量；“在线用户2000”是指的整个系统的负载，那么单个业务模块的负载是多少？要明确系统的平均负载和峰值负载；
2.如果你要验证系统的性能，就不单单是测试系统是否可以承受某个并发量，而是测试系统在各种不同级别的负载下的性能表现，包括吞吐量、响应时间以及资源占用情况，并根据测试的结果找到系统的最佳并发用户数和最大并发用户数——需要参考性能需求；而如果没有或者无法确定性能需求，那么需要根据测试结果来评价系统的性能表现是否可以接受。
就像本文中提到的，分别测试了 10/25/50/75/100 不同级别的负载，假如根据测试结果来看，确定平均事务响应时间必需小于 3 秒，那么根据测试结果可以发现只有并发量为 10 的时候才能满足要求。如果这个并发量明显小于实际负载，那么需要进行性能优化；反过来也是一样，假如明确了系统的平均负载为 50，根据测试结果可以发现，当并发量为 50 时，平均事务响应时间已经超过了 11 秒，如果这个响应时间已经远远大于用户可以忍受的时间，那么同样也需要对系统的性能进行优化。
5、.如果测试环境与生产环境存在差距，首先应该尽可能的缩小差距。如果实在是无法缩小差距——例如客户那里是小型机，而你连 Server 都没有，那就要在报告中详细的注明你的测试环境和各项配置，说明测试结果在当前环境下有效。一个比较理想的方案是计算每个请求的处理成本，然后统计在并发量变化的情况下处理成本的变化，估算请求数量与软硬件资源利用率的关系——银行不就是计算了个什么查询和跨行交易的成本来向咱们收费的嘛 ^_^
6、“性能测试”是“了解系统在一个既定的环境和场景中的性能表现是否与期望的目标一致，并根据测试数据识别性能瓶颈，改善系统性能的过程”。
而“性能”本质上是“并发量与吞吐量（每秒事务数）、响应时间以及资源利用率之间的一种平衡”。
换句话说，性能测试是要去认识一个事物的特性——去了解被测系统在某个环境和场景中的性能如何，然后再比较这个性能是否与预期的目标一致；而不是简单的“验证能否支持某个并发量”。也就是说你的 PM 给出的是一个目标——当然，这个目标还不够明确，而你要做得是测试，并得出数据和结论。
另外，用户或 PM 提出的性能需求的真正目的是要了解“当8000用户/服务器的情况下系统的性能表现是怎样的”，就是说除了并发量还要考虑吞吐量、响应时间和资源利用率
阅读(921) | 评论(0) | 转发(0) |
