一、软件性能概述：
1.1 在软件质量模型中效率特性即为软件的性能，其包含两方面特性：
1.1.1 时间特性：指系统处理客户端请求的响应时间；
1.2.1 资源特性：指在性能测试过程中，系统资源的消耗情况，常见的主要包括CPU、内存和磁盘的使用情况；
1.2 从不同的视角看：
1.2.1 用户：关注软件系统对客户端提交请求所响应的时间。需要注意的是，这里说的响应时间，是系统将全部数据呈现在客户端的时间。
1.2.2 系统管理员与性能测试工程师：他们除了关注系统响应时间外，还关注系统资源的使用情况。因为即使系统响应时间达到了要求，但并不代表系统就能正确地处理客户端提交的请求。例如银行系统，处理存款业务时的响应时间达到了要求，但当前CPU和内存的使用率都达到了90%，超过了正常使用的阀值，这就不能保证服务器不出问题，因为服务器已经处于一个临界状态。另外，他们还关注系统硬件资源的可扩展性即规划性能部分，比如：系统现在支持100个用户并发没有问题，那么将来支持200个用户并发时是否会出现性能问题？
1.2.3 开发人员：他们关注以上所有角色关注的所有问题，另外，还关注内存泄露、数据库死锁、中间件及应用服务器等问题；
二、性能测试相关术语：
2.1 响应时间：
2.1.1 概念：指应用系统从发出请求开始到客户端接收到所有数据所消耗的时间。该定义强调的是所有数据都已经被呈现在客户端所花费的时间。
2.1.2 Web系统的页面响应时间分解：客户端->网络传输->Web服务器->网络传输->数据库服务器->网络传输->Web服务器->网络传输 ->客户端
2.2 并发用户数：
2.2.1 概念：指同一时刻与服务器进行数据交互的所有用户数量。
2.2.2 注意几个关键点：
a. 同一时刻；
b. 有数据交互；
c. 系统用户不叫并发用户；
d. 在线用户不叫并发用户；
2.2.3 如何计算呢？
a. 参考其他同类产品；
b. 分析服务器日志的数据（相对可靠）；
c. 试上线运行（不建议）；
2.3 吞吐量：
2.3.1 概念：指单位时间内服务器处理的字节数，单位为 B/s，吞吐量的大小直接提现服务器的承载能力；
2.3.2 当系统没有遇到性能瓶颈时，可以采用下面的公式计算：
F = (N * R) / T
*F = 吞吐量
*N = VUser数
*R = 在T时间内每个VU发出的请求字节数
*T = 性能测试所用时间
吞吐量在VU增长到一定数量时，系统出现性能瓶颈，此时吞吐量的值并不会随着VU的数量的增加而增大，而是趋于平衡。在实际测试过程中，测试前吞吐量是不知道的，必须通过不断添加VU来测试，才能得到吞吐量的拐点，亦即服务器吞吐量的最大值。
类似水池的吞吐量，它的出水量是1立方米/秒，1根进水管的进水量是0.1立方米/秒，放入10根注水管的时候，进出持平。当放入11根注水管时，出水量还是1立方米/秒，水池会开始积水。
2.4 吞吐率：
2.4.1 概念：Throughout，指单位时间内从服务器返回的字节数，也可以指单位时间内服务器处理客户提交的请求数。它是衡量网络性能的一个重要指标。吞吐率=吞吐量/测试时间，值越大，系统的负载能力越强。
2.5 TPS：
2.5.1 概念：Transaction Per Second，表示服务器每秒处理的事务数，如果一个事务对应为一笔业务，那么TPS即表示服务器每秒处理的业务笔数，值越大说明服务器处理能力越强。将它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。当压力加大时，TPS曲线如果变化缓慢或趋于平缓时，很可能是服务器开始出现瓶颈了。
2.6 点击率：
2.6.1 概念：Hit Per Second，指每秒钟用户向服务器提交的HTTP数量。如果把每次点击作为一次提交事务来对待，那么点击率和TPS的概念是等同的。
2.6.2 对于Web系统来说，“点击率”是服务器处理的最小单位，点击率的值越大，说明服务器端所需要承受的压力越大。
2.6.3 注意：点击一次不代表客户端只向服务器端发送一个HTTP请求，一般都是多个HTTP请求，并且点击率仅仅反映的是客户端提交的请求数，不能直接表现服务器端当前承受的压力，因为提交的请求服务器不一定全部会处理，有可能出现服务器拒绝请求的情况。
2.7 资源利用率：
2.7.1 概念：指服务器系统中不同硬件资源被使用的程度，资源使用率=资源实际使用量/总的可用资源量；
2.7.2 资源利用率是分析系统性能指标进而改善性能的主要依据，在配置调优测试的过程中，通过比较配置调优前后系统资源的利用率来判断调优效果。
2.8 性能计数器：
2.8.1 概念：Counter，是描述服务器或操作系统性能的一些数据指标。主要是通过添加计数器来观察系统资源的使用情况。包括：操作系统性能计数器、数据库计数器、应用服务器计数器等。
2.9 思考时间：
2.9.1 概念：Think Time，也称为“休眠时间”，指用户在进行操作时，每个请求之间的时间间隔。如果是负载测试，则可以直接忽略设置思考时间，如果是压力测试或可靠性测试，则可以依据实际场景设置一个思考时间，一般设置为3~5s；
三、性能测试划分：
3.1 负载测试（Load Testing）
3.1.1 概念：通过对被测系统不断地加压，直到超过预定的指标或者部分资源已经达到了一种饱和状态不能再加压为止。
3.1.2 特点：
3.1.2.1 找到系统最大的负载能力，为性能调优提供数据
3.1.2.2 该方法需要在特定的环境下进行测试
3.1.2.3 不断地对系统进行加压，直到系统中部分资源达到极限
3.2 压力测试（Stress Testing）
3.2.1 概念：指系统已经达到一定的饱和程度（如CPU、内存或磁盘等已经处于饱和状态），此时系统处理业务的能力，是否会出错。
3.2.2 特点：
3.2.2.1 测试在系统已经达到一定饱和程度时，系统处理业务的能力
3.2.2.2 使用模拟负载等方法，使系统资源达到一个较高的水平
3.2.2.3 一般用于系统稳定性测试
3.3 配置测试（Configuraion Testing）
3.3.1 概念：指通过调整系统软硬件环境，了解各种不同环境对系统性能的影响，从而找到系统的最优配置。
3.3.2 特点：
3.3.2.1 通过调整环境了解不同因素对系统性能的影响情况，从而找到调优的方法
3.3.2.2 通过调整系统软硬件环境，使系统在不同环境下进行性能测试
3.3.2.3 该方法一般用于系统调优和规划能力
3.4 并发测试（Concurrency Testing）
3.4.1 概念：通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在死锁、系统处理速度是否明显下降等其他一些性能问题
3.4.2 特点：
3.4.2.1 目的：当多用户并发访问时，系统是否存在一些可能的并发问题
3.4.2.2 模拟多用户同时并发操作
3.5 可靠性测试（Reliability Testing）
3.5.1 概念：当系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性，此处强调在一定业务压力下持续运行的能力，如系统能够持续无障碍运行多少天。
3.5.2 特点：
3.5.2.1 目的：测试系统在一定的业务压力下系统可持续运行的时间
3.5.2.2 环境：指明系统在一定的业务压力环境下持续运行
3.5.2.3 测试过程中要关注系统运行的情况
3.6 基准测试（Benchmark Testing）
3.6.1 概念：在一定的软件、硬件及网络环境下，模拟一定数量虚拟用户运行一种或多种业务，将测试数据作为基线数据，在系统调优或者系统评测过程中，通过运行相同的业务场景并比较测试结果确定调优是否达到效果或者为系统的选择提供决策数据。
3.6.2 目的：
3.6.2.1 度量改善性能测试的情况
3.6.2.2 测试并且调优，保证系统达到性能要求或服务协议要求，在这个过程中，基准测试和性能测试迭代配合，以确定调优的情况
3.7 失效恢复测试
3.7.1 重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行。
3.7.2 一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能否继续使用系统。
3.8 现网性能测试
3.8.1 在实际网络、实际环境中进行测试，完全和真实用户一样。
3.8.2 注意点：
3.8.2.1 时间段的选择：
3.8.2.2 垃圾数据处理：
3.8.2.3 网络限制：
四、性能测试应用领域：
4.1 能力验证：重点在于验证系统是否具备某种能力。一般这样描述：“某系统能否在条件A下具备B性能”
4.1.1 要求在一个已确定的环境下运行；
4.1.2 需要根据典型场景来设置测试方案与测试用例；
4.2 规划能力：体现系统如何才能达到要求的性能指标。一般这样描述：“系统如何才能支持未来用户增长的需求”
4.2.1 对系统能力的一种探索性的测试；
4.2.2 可以了解系统的性能及系统性能的可扩展性；
4.3 性能调优：通过测试来调整系统的环境，最终使系统性能达到最优的状态。是一个持续调优的过程，主要调优的对象有数据参数、应用服务器、系统的硬件资源等。
4.3.1 确定本次性能测试的基准环境、基准负载和基准的性能指标，目的是将这些基准数据作为后期测试数据的参考对象；
4.3.2 对系统进行调优，再调整系统运行环境和测试方案，重复进行性能测试，并记录测试结果；
4.3.3 将调整后的测试结果与基准数据进行比较，以确定调优的效果，重复执行步骤b直到性能指标满足要求；
4.4 缺陷发现：通过性能测试手段来发现系统存在的缺陷。
【补充内容】
1、系统用户数：即该系统的注册用户数，他们可以是活跃的，也可以是非活跃的；
2、在线用户数：即登录系统的用户数，但在线用户并不一定都会对服务器产生压力，因为有的用户登录之后什么都不做，或者说不会做跟服务器端有数据交互的操作；
3、并发数可以通过分析服务器日志得以确定。
3.1 并发数=PV/PV Time * 页面连接次数 * HTTP响应时间 * 因数/Web服务器数量；
3.2 PV （Page View）即页面浏览量。
4、并发有两种理解方式：一种为所有用户在同一时刻做同一种操作，主要是为了验证程序或数据库对并发的处理能力；另一种为多个用户对被测系统发起了多个请求，这些请求可以是同一种操作，也可以是不同的操作，类似于混合场景；
并发用户数≠每秒请求数， 这是两个容易混淆的概念。
对于一个VUser来说，每秒发出多少请求跟服务器返回响应的速度有关。如果VUser在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有相应数量的请求需要处理，而并不一定是保证每秒中发送相应数量的请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
5、资源：
5.1 CPU：能反映出系统地繁忙程度，一般分为系统CPU与用户CPU，其中系统CPU是处理系统本身所占用的资源，用户CPU是处理程序所占用的资源。
5.2 Load Average：指一段时间内CPU正在处理和等待处理的任务，也就是CPU使用队列的长度的统计信息。
5.3 Memory：要注意内存是否有泄露或溢出。
5.4 队列：队列长，说明处理能力可能达到了极限或者遇到了阻塞。
5.5 I/O：与磁盘的交互，重点关注交换频率和磁盘队列长度。
5.6 网络：重点关注网络流量，看是否存在网络带宽的瓶颈。
