本文共 5110 字，大约阅读时间需要 17 分钟。
典型的术语有：并发用户、并发用户数量、请求响应时间、事务响应时间、吞吐量、吞吐率、TPS、点击率、资源利用率等。
| 术语 | 说明 |
|---|---|
| 并发用户 | 是同时执行一个操作的用户，或者是同时执行脚本的用户，这个并发在设置不同场景的时候并发的情况是不一样的，在实际的测试中需要根据具体的需求进行设计。 |
| 并发用户数量 | 并发主要是针对服务器而言，是否并发的关键是看用户操作是否对服务器产生了影响。因此，并发用户数量的正确理解为：在同一时段与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。 并发用户数量的统计的方法还没有准确的公式，因为不同系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式为：使用系统用户数量*(5%~20%)。对于这个公式是没有必要拘泥于计算的结果，因为为了保证系统的扩展空间，测试时的并发用户数量要稍微大一些，除非是要测试系统能承载的最大并发用户数量。举例说明：如果一个OA系统的期望用户为1000个，只要测试出系统能支持200个并发用户就可以了。 |
| 请求响应时间 | 请求响应时间指的是客户端发出请求到得到响应的整个过程的时间。 这个过程是从客户端发起一个请求开始计时，到客户端接收到从服务器端返回的响应结果为止计时结束。 在某些工具中，请求响应时间会被称为TTLB，即 time to last byte，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所消耗的时间。 请求响应时间单位一般为“秒”或者“毫秒”。 |
| 吞吐量 | 指在一次性能测试过程中网络上传输的数据流量的总和。 吞吐量/传输时间，就是吞吐率。 |
| 事务响应时间 | 事务可能由一系列请求组成，事务的响应时间主要是针对用户而言，属于宏观上的概念，主要为了向用户说明业务响应时间而提出的。 例如：跨行取款事务的响应时间就是由一系列的请求组成。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。 |
| 吞吐率 | 通常用来指单位时间内网络上传输的数据流量，特定条件下也可以用来指单位时间内处理的客户端请求数量，它是衡量网络传输性能的重要指标。通常情况下，吞吐率可以用“字节数/秒”，“请求数/秒”，或者“页面数/秒”来衡量，在Loadrunner中则用每秒传输的字节数来衡量。 |
| TPS | 指每秒钟系统能够处理的交易或者事务的数量，用来衡量系统业务处理能力的重要指标。 |
| 点击率 | 每秒钟用户向服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标。WEB应用是一种“请求——响应”模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。 点击率只是一个性能参考指标，重要的是分析点击产生时的影响。 |
| 资源利用率 | 资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率，磁盘利用率等。 资源利用率是分析系统性能指标进而改善性能的主要依据，因此是WEB性能测试工作的重点内容。 资源利用率主要针对WEB应用服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主要参考。在性能测试中，要根据分析需要采集相应的参数进行分析。 |
并发测试
主要用来测试多用户同时访问同一系统/同一模块/同一业务功能/同一数据记录时是否存在性能问题，几乎所有的性能测试都会涉及并发测试。
负载测试（Load Testing）
负载测试是一种性能测试，其中应用程序的性能是在预期负载下评估的。在负载测试中，我们评估不同的性能参数，如响应时间、服务器负载（即吞吐量）和负载测试执行期间观察到的错误率。
通过在被测试系统（SUT）上不断增加压力，直到性能指标达到极限，例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。
压力测试（Stress Testing）
压力测试是一种性能测试，其中应用程序的性能是在远高于预期或预期负载的负载下评估的。这有助于测量应用程序的盈亏平衡点，即应用程序无法正确响应的负载。
对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大服务水平（SLA）级别的测试。
例如，测试一个WEB Application在大量的负载下，何时系统的事务响应时间会变得不可接受或者事务不能正常执行。
压力测试是为了发现在什么条件下应用程序的性能会变得不可接受，主要通过改变应用程序的输入以对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。
压力测试一般在标准工作环境中进行；而强度测试一般在非标准工作环境中进行。
稳定性测试（又叫：耐久性测试（Endurance Testing））
耐久性测试也称为“浸泡测试”。在耐久性测试中，被测试的应用程序承受长时间的连续载荷，如2-3天。这有助于发现应用程序中的内存泄漏问题。
在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。（区别于压测在于，不比把系统资源调用到最高，在这满足基本性能指标即可。）
强度测试
为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。（非标准工作环境下，人为降低工作环境资源，如网络带宽、系统内存、数据锁等，以测试系统在资源不足的情况下的工作状态，通过强度测试，可以确定本系统正常工作的最差环境。）或者可以理解为测试系统在异常情况下的处理能力，例如测试系统在较低的资源配置下的性能。
下面是一些强度测试的场景：
强度测试是特别重要的测试，对评估系统的稳定性、健壮性、扩展性均具有重要的意义。这种在特殊条件下的测试，更容易发现系统深层次的性能问题。
尖峰试验（Spike Testing）
有助于检查在并发用户数突然激增之后，应用程序是否可以从任何问题中恢复。
在性能测试中属于压力测试的一个子集，指的是在某一瞬间或者多个频次下用户数和压力陡然增加的场景。
为了验证我们的网站在访问用户急剧增加的情况下，或者短时间内反复急剧增加工作负载时能否正常工作；以及程序能否从高负荷中恢复并正常工作时常常用到这种测试手法。
Spike 在英文中是钉子的意思，或者我们可以将其称之为冲击测试，反复冲击服务器。
容积测试（Volume Testing）
在容积测试中，我们向应用程序提供大量数据。这可以通过在数据库中插入大量数据来完成，也可以根据应用程序或功能上传一个大文件进行处理。
Volume testing is a type of performance testing that helps in checking the performance of an application when subjected to a large volume of data.
性能测试类型常见的英文描述：
Load Testing – Load Testing checks the application’s ability to perform under anticipated user loads. The main objective of this testing is to identify performance bottlenecks before the software application goes live.
Stress Testing – This testing involves testing an application under extreme workloads to see how it handles high traffic or data processing. Here, it identifies the breaking point of an application. Endurance Testing – This testing is done to make sure the software can handle the expected load over a long period of time. Spike Testing – It is used to test the software’s reaction to sudden large spikes in the load generated by users. Volume Testing – Here, a large amount of data is populated in a database and the overall software system’s behavior is monitored. The main objective of this testing is to check the software application’s performance under varying database volumes. Scalability Testing – The main objective of scalability testing is to determine the software application’s effectiveness in “scaling up” to support an increase in user load.
服务端并发和客户端并发不是同一个概念。客户端并发仅仅是为了模拟多用户访问，服务端并发是同时处理的请求数。从收到客户端的请求到处理完成发出响应，都是属于并发执行的请求。
客户端并发数不等于服务端并发数。虽然服务端同一时刻执行的线程数等于cpu个数，但是高性能的服务一般是都会使用了异步io；遇到io操作就扔给了操作系统执行，cpu接着干其他的事。所以应用程序同时可以处理多于cpu数目很多的请求。但也不是无限多的。影响并发的系统资源有socket数，带宽紧张程度，内存紧张程度，cpu繁忙程度，磁盘繁忙程度。这些资源共同影响并发数。
这些资源中有些非常充足比如socket数（普通的服务都是设置了600000, 通过ulimit -n查看），有些就比较匮乏，比如磁盘（具体效率可以去google）。当磁盘遇到瓶颈的时候，socket资源充当了缓冲区。虽然同时能够接受很多请求，但是真正能做出响应的比较少，造成响应时间增加，这种并发没有意义。
所以，能保证最低响应时间的并发才是有效并发。
我们在压力测试过程中，不断的增加并发数，如果平均响应时间增加，说明并发能力已经到头了，再加大并发总体性能将要降低。
转载地址：http://ntvdi.baihongyu.com/