一、响应时间
响应时间是“对请求做出响应所需要的时间”。之前说过，它既有客观的成分，也有主观的成分，一般将用户所感受到的软件性能（响应时间）分为呈现时间和服务器端响应时间两个部分。对于一个Web应用，呈现时间就是浏览器接受到响应数据后呈现和执行页面上脚本所消耗的时间；而服务器端响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。响应时间可以被进一步分解，下图描述了一个Web应用的页面响应时间==网络传输时间(N1+N2+N3+N4)+应用延迟时间(A1+A2+A3)，其中A2为数据库延迟时间，A1/A3为服务器延迟时间。如此划分的目的是更容易定位性能瓶颈。关于响应时间的参考值，我们一般遵循着2/5/10原则，但这仅仅是个参考值。例如一个使用频次很低的功能，如果响应时间>100s，也是能接受的。响应时间是否合理，最终取决于实际的用户需求。
二、并发用户数
并发用户数，简单来说，就是同一时间段之内有多位用户访问系统。
如果性能测试的目的是验证当前系统能否支持现有用户的访问，那么使用工具模拟用户数，模拟用户的行为，得到的测试结果就能真实反映实际用户访问时的系统性能表现。这里的同一时间段访问系统的用户数量可以称为“并发用户数”，是从业务的角度模拟真实的用户访问，体现的业务用户数。而还有一种针对服务器端的并发用户数，就是我们平时说的“并发用户数”，从服务器端承受的压力出发，描述的是同时向客户端发出请求的用户。
说到并发用户数，那么相关的概念还有“系统用户数”和“同时在线用户人数”。其中，系统用户数就是使用该系统的人，不管他是登录一次还是经常使用，亦或者仅仅只是注册了，都算。同时在线人数就是后台统计的系统最高峰时有多少人在线，这个多少人就是一般所说的同时在线人数。假设有200人同时在线，40%的人在写写写，写完点击提交才会发起请求；20%的人眼冒绿光的沉迷于首页的炫酷效果中；30%的人在使用某一业务；还有10%的人在挂机。那么此时只有30%的用户真正对服务器构成了压力。所有针对服务器端的实际承受压力，不止取决于并发用户数，还要考虑用户的业务场景。
通过对服务器的日志进行分析，可以了解用户的使用状态，并由此算出服务器承受的最大并发用户数。当然还有一些三者之间的计算公式，此处不说了，仅仅是个参考值，别当做标准值。
三、吞吐量
吞吐量直接体现系统的性能承载能力，是指单位时间内系统处理的客户请求的数量，一般用单击数(请求数)/秒来衡量（TPS/QPS）。对于交互式应用，吞吐量指标反映的是服务器承受的压力，在容量规划测试中是一个重点关注的指标，因为它能够说明系统级别的负载能力。在性能测试过程中，吞吐量可以在以下两个方面发挥作用：
1、协助设计测试场景，衡量性能测试场景是否达到了预期的设计目标；
2、协助分析性能瓶颈。
在没有遇到性能瓶颈时，吞吐量和并发数的联系可以用公式F=N(vu)*R/T来计算，其中F=吞吐量，N(vu)=VU的个数，R=每个VU发出的请求，T=性能测试所用的时间，如果存在性能瓶颈，此式不成立（此时就需要画图了）。
注释：所谓的单击数一般指客户端发出的请求，而不是指页面上的一次单击事件。
四、性能计数器
性能计数器是描述服务器或操作系统性能的一些数据指标，例如windows的使用内存数和进程时间等。
计数器在测试中的作用是监控和分析，在分析系统的可扩展性和性能瓶颈时，计数器的取值较为关键。单一的性能计数器只能体现系统的某一个方面，对测试的结果分析必须基于多个不同的计数器。
五、思考时间
用户在进行操作时，每个请求之间的间隔时间，具现在脚本中，就是Think函数。吞吐量的公式F=N(vu)*R/T，其中R可以用T/T(s)来计算，即请求数=时间/请求间隔时间。
最后给出一个参考的计算思考时间方法：
1、首先计算出系统的并发用户数；
2、统计出系统平均的吞吐量；
3、统计出平均每个用户发出的请求数量；
4、根据R=T/T(s)计算出思考时间T(s)。
原文地址：https://www.cnblogs.com/zichuan/p/10105608.html