关于性能测试需要知道的-关于测试

随着各企业的业务发展、用户量以及数据量的不断增加，系统承载的压力也会随之增加，服务系统的性能好坏又严重影响企业的利益。因此，性能测试重要性与需求越来越强烈。

常见的性能测试目的

性能测试是确定系统在特定工作负载下的稳定性和响应能力。在进行性能测试之前，首先是要明确性能测试的目的，目的不同，对应的解决方案会有很大差异，最常见的性能测试目的（或契机）有三种：

性能测试的三种目的

(1) 评测当前系统性能

通过性能测试了解系统当前的性能是否达到预期。例如：新系统上线前、技术升级后，都会进行性能测试，确保系统在线上稳定可靠地运行。

(2) 寻找瓶颈，优化性能

系统已知有性能问题，进行测试寻找瓶颈，以便优化其性能。例如：用户提出业务操作响应时间长，需要定位问题，调整性能；系统运行一段时间后，速度变慢，寻找瓶颈，进而优化

(3) 预测系统未来的性能、可扩展性

通过性能测试预测系统在未来达到一定负载量的情况下，系统的性能表现。为的是提前预防并降低风险。扩展能力非常好的系统，性能是随资源扩展呈线性或接近线性提升。

性能测试的不同类型

(1) 基准测试

基准测试：系统较低压力时，查看系统的运行状况并记录相关数作为基础参考。

(2) 负载测试

负载测试是通过逐渐增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统能承受的最大负载量的测试。目标：确定系统的性能容量（如系统在保证一定响应时间情况下能够允许多少并发用户的访问），系统各项指标，如吞吐量、响应时间、CPU负载、内存使用等如何决定系统的性能。

(3) 压力测试

压力测试通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。目标：压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

(4) 并发性能测试

负载测试和压力测试通常被合称为并发性能测试。即大并发场景下的系统性能，多用户同时访问时，检测系统是否能够稳定运行。

平均并发用户数C=nL/T
n：平均每天访问用户数（login session的数量）；
L：一天内用户从登录到退出的平均时间（login session的平均长度）；
T：考察的时间段长度（一天内多长时间有用户使用系统）；
并发用户数峰值：C'≈C+3*根号C

(5) 大数据量测试

大数据量测试包括独立的数据量测试和综合数据量测试。独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。综合数据量测试指系统在具备一定数据量时，在负载压力测试下，考察业务是否能够正常运行的测试。目标：测试数据量较大时系统的性能状况。

(6) 容量测试

容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数），系统在其极限状态下没有出现任何软件故障且能正常运行。

(7) 配置测试

通过对被测系统软硬环境的调整，了解各种不同环境对系统性能的影响程度，从而找到系统各项资源的最优分配原则。

(8) 稳定性测试

稳定性是通过给系统加载一定的压力，让系统持续运行一段时间（通常为7x24小时），检测系统是否能够稳定运行。稳定性测试也称为疲劳强度测试，属于可靠性测试的范畴。目标：测试系统长时间无故障稳定运行的能力

(9) 失效恢复测试

失效恢复测试是针对有冗余备份或负载均衡的系统来说，检验如果系统局部发生故障，系统灾备措施是否可以正常启动，用户是否可以继续使用。（如：集群、热备等）目标：通过实施失效恢复测试，评估系统的健壮性和可恢复性。

在实际项目当中，可根据不同的性能测试目的，选相对应的性能测试方式。

性能测试的监控指标

在进行各类性能测试时，需要同步检测系统各项性能指标，从而分析系统的实际的响应能力与稳定性等。常用的性能监测指标有四类：业务性能指标、资源性能指标、中间件监测指标、数据库监测指标。

业务性能指标

每秒交易数（TPS）：每秒钟系统能够处理的交易或事务的数量
响应时间：从请求端发起请求开始，到请求端接收到服务器端的返回结束，这个过程所耗费的时间。
并发用户数：指系统可以同时承载的正常使用系统功能的用户的数量，即在给定的时间段内正在使用系统的用户数。
在线用户数：没有提交请求，会话状态在线的用户数。
吞吐量：指系统在单位时间内处理请求的数量。即在给定时间段内系统完成的交易数量。

(1) 响应时间行业标准

互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
金融企业：1秒以下为佳，部分复杂业务3秒以下。
保险企业：3秒以下为佳。
制造业：5秒以下为佳。
时间窗口：不同数据量结果是不一样的，大数据量的情况下，2小时内完成。

(2) TPS行业标准

互联网企业：500毫秒以下，如某宝业务10毫秒左右。
金融行业：1000TPS~50000TPS，不包括互联网化的活动
保险行业：100TPS~100000TPS，不包括互联网化的活动
制造行业：10TPS~5000TPS
互联网电子商务：10000TPS~1000000TPS
互联网中型网站：1000TPS~50000TPS
互联网小型网站: 500TPS~10000TPS

资源性能

CPU指标：主要指的CPU使用率、利用率，包括用户态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。一般情况下，CPU使用率、利用率要低于警戒值范围75%。
内存/SWAP：内存利用率100%并不代表内存有瓶颈，衡量系统内有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下。
磁盘吞吐量：磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于70%。
网络吞吐量：网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。一般情况下不能超过设备或链路最大传输能力的70%。

资源性能（CPU、内存、磁盘）行业标准：

CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%;
CPU sys%小于或者等于30%;
CPU wait%小于或者等于5%
SWAP交换空间利用率低于70%
磁盘繁忙率低于70%
网络吞吐不能超过最大传输能力70%

中间件指标

中间件监测指标主要包括JVM、线程池、JDBC连接池，常用的中间件如：Tomcat、Weblogic等。

中间件监控内容及行业标准：

线程数最小设置50和最大设置200比较合适。
JDBC最小设置50和最大设置200比较合适。
JVM最小堆大小和最大堆大小分别设置1024M比较合适。

数据库性能指标

SQL：执行SQL耗时
吞吐量：每秒事务次数（TPS），每秒查询次数（QPS）
锁：锁等待次数和锁等待时间
命中率：索引缓冲区命中率、线程缓存命中率、表缓存命中率、查询缓存命中率等。

数据库监控内容及行业标准：

SQL耗时越小越好，一般情况下微秒级别。
命中率越高越好，一般情况下不能低于95%。
锁等待次数越低越好，等待时间越短越好。
操作系统内核参数主要包括信号量、进程、文件句柄。

性能测试流程

首先要制定测试计划，明确目的、策略等。以测试计划为依据，逐步开展性能测试工作。

明确性能测试目标

确定本次性能测试的目标，包括性能测试对象、需求范围，以及性能指标达标要求，即测试退出条件。

制定性能测试计划

确定了测试对象和测试需求之后，需要制定一份性能测试计划，指导性能测试工作的进行。包括：简介、测试环境、测试场景、测试数据、测试策略、测试时间与人员安排。

(1) 测试环境

描述性能测试环境的物理架构。

(2) 测试场景

针对各业务功能模块，设计不同测试类型（稳定性测试、负载测试、压力测试）等的单场景、组合场景测试。

(3) 测试数据

描述各性能测试场景下的数据量要求，加压多大数据量需要提前与业务侧对齐目标，系统现存数据体量以及每年增长幅度也可以通过与业务人员（产品经理)确定，当然也可以一些经验方法或公式来估算。比如：有并发用户数与峰值公式，以及二八原理估算方法。

【并发用户数公式】：C = nL/T。C：平均的并发用户数；n：平均每天访问用户数（login session的数量）；L：一天内用户从登录到退出的平均时间（login session的平均长度）；T：考察的时间段长度（一天内多长时间有用户使用系统）；
【并发用户数峰值公式】：C'≈C+3*根号C。其中：C：公式1中的平均并发用户数；
【二八原理估算测试强度】：每个工作日中80%的业务在20%的时间内完成。例如：每年业务集中在8个月，每个月20个工作日，每个工作日8小时，即每天80%的业务的在1.6小时完成。去年全年处理业务约100万笔，其中15%的业务处理中每笔业务需对应用服务器提交7次请求；其中70%的业务处理中每笔业务需对服务器提交5次请求；其余15%的业务处理中每笔业务需对应用服务器提交3次请求。（根据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。）