性能测试常见的术语主要有并发、并发用户数量、请求响应时间、吞吐量、吞吐率、TPS、点击率、资源利用率等。

狭义的并发一般分两种情况。一种是严格意义上的并发，即所有用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务。
另一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操作，但是这些请求或操作可以是相同的，也可以是不同的。对整体系统而言，任然有很多用户同时对系统进行操作，因此，仍然属于并发的范畴。
可以看出，广义的并发是包含狭义的并发的，而且广义的并发更接近用户的实际使用情况，因为对 大多数系统而言，只有数量很少的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发一般都需要进行测试，通常的做法是先进行严格意义上的并发测 试。严格意义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生性能问题，后果很可能是致命的。严格意义上的并发测试往往 和功能测试关联起来，因为只要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。

关于并发用户数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全 部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发 生并发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。
并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据的，也可以是双向传送数据的。
并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特点。例如OA 系统统计并发用户的经验公式为：使用系统的用户数量*（5%~20%）。对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时 的并发用户数量就会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果一个OA系统的期望用户为1000个，只要测试出系统能支持 200个并发用户就可以了。

请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端发出一个请 求开始计时，到客户端接收到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间通常会被称为"TTLB"，即"Time to last byte"，意思是从发送一个请求开始，到客户端接收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或“毫秒”。
响应时间是指对请求作出响应所需的时间。它是作为用户视角的软件性能的主要体现。
响应时间分为2部分：呈现时间、系统响应时间。呈现时间取决于数据在被客户端收到响应数据后呈现页面所消耗的时间；系统响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。一般主要关心【系统响应时间】。
注明：N1为客户端到web服务器请求的时间
N2为web服务器到数据库服务器的请求时间
N3为数据库服务器给web服务器的反馈时间
N4为web服务器给客户端反馈的时间
A1、A3为应用服务器延迟时间
A2为数据库延迟时间
页面响应时间可以被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3）,而“应用延迟时间”又可以分解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。
响应时间的长短没有绝对，国际上没有固定指标，因此响应时间的长度是个区间，比如，一个电子商务web，可能被用户接受的响应时间2/5/10；2秒最为被用户接受，数据响应最佳；
5秒用户可以接受，10秒可能是用户接受的底限，除非必须访问该网站，否则当页面还没有完全展示，用户可能就关闭了。当然，这个也不是必须的，比如对于晚上纳税系统来说，可能一次上传数据非常大，因此，每次响应时间可能会达到40分钟～2小时，这个用户可能也会接受，因为毕竟不是每天都会这样，可能每月只有一次。
因此，合理的响应时间取决于实际的用户需要，不要生搬硬套。
并发用户数
并发用户数：从业务角度看，同一个时间内，多少用户访问被测试系统（集合功能）；抛开业务角度看，同样是一定数量的并发用户数，如果用户数的操作方式不同（场景不同），服务器承受压力是完全不同的。
估算并发用户数的公式：
C=nL/T （1）
C1=C+3√C （2）
公式1中,C是平均的并发用户数；n 是login session 的数量；L是login session的平均长度；T是考察的时间长度。如果一个典型OA应用，考试时间段长度应该为8小时工作时间。
公式2中，给出并发用户数峰值的计算方式，其中C1 指并发用户数的峰值。
实例：oa系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时使用该系统。更加公式1，2 可以得到：
C=400×4/8=200； C1=200+3×
√200
=242
另一种方法估算：C=n/10 C1=r×C r为2,3,4… 平均并发用户数为每天访问量的10%，峰值为平均值的r倍。
吞吐量
单位时间内系统处理客户请求的数量。一般用【请求数（点击数）/秒】或者【页面数/秒】来衡量。从业务角度来讲，吞吐量也可以用【访问人数/天】或者【处理的业务数/小时】等单位来衡量；从网络角度来说，吞吐量可以用【字节数/天】来衡量。
例如：对于一个web应用系统来说，从系统处理能力考虑，可以以【页面数/秒】作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的【业务数/小时】作为吞吐量的标准。
对于交互式应用，“并发用户数”、“响应时间”可以确定系统的性能规划；对于非交互式应用，用“吞吐量”来描述系统性能的期望可能更加合理。
吞吐量和并发用户数之间存在一定的联系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：u
F=
F——吞吐量
Nvu——VU（virtuae Use，虚拟用户）的个数
R——每个VU发出的请求（单击）数量
T——性能测试所用的时间。
性能计数器
Counter是描述服务器或操作系统性能的一些数据指标。性能计数器在性能测试中发挥着“监控和分析”的关键作用，尤其在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。
资源利用率：系统中各种资源的使用状况。“资源的实际使用情况/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。
同样条件下，某个资源A的使用率达到了接近100%的数值，而其他资源利用率都处于比较低的水平，则，资源A就可能是系统的一个性能瓶颈。
思考时间
也叫“休眠时间”，用户在操作期间，每个请求之间的间隔时间。为了较为真实模拟用户在实际操作中，发生的思考时间，请看公式：R=
从F= 和该公式进行简化可得：吞吐量与Nvu成正比，而与Ts成反比。
计算思考时间的一般步骤：
首先计算出系统的并发用户数；
统计出系统平均的吞吐量；
统计出平均每个用户发出的请求数量；
根据公式：R= 计算出思考时间。
事物响应时间
事物可能由一系列请求组成，事物的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出来的。例如：跨行取款事物的响应时间就是由一系列的请求组成的。事物响应时间和业务吞吐率都是直接衡量系统性能的参数。

吞吐量是指在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。
吞吐率（Throughput）
通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。是衡量网络性能的重要指标。
但是从用户或业务角度来看，吞吐率也可以用“请求数/秒”或“页面数/秒”、“业务数/小时或天”、“访问人数/天”、“页面访问量/天”来衡量。例如在银行卡审批系统中，可以用“千件/每小时”来衡量系统的业务处理能力。
TPS（Transaction Per Second）
每秒钟系统能够处理的交易或事物的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。
点击率（Hit Per Second）
每秒钟用户向Web服务器提交的HTTP请求书。这个指标是Web应用特有的一个指 标：Web应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是Web应用能够处理交易的最小单位。如果把每次点击定义为一 次交易，点击率和TPS就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。
需要注意的是，这里的点击不是指鼠标的一次“单击”操作，而是在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。

资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源 利用率是分析系统性能指标而改善性能的主要依据，因此，它是Web性能测试工作的重点。资源利用率主要针对Web服务器、操作系统、数据库服务器、网络 等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需求采集具体的资源利用率参数来进行分析。