性能测试基础篇

性能测试基础

WHY： 为什么要进行性能测试
WHAT: 关注的性能测试内容
WHO: 哪些人员关注性能
WHERE: 性能测试的关注领域
WHEN: 何时进行性能测试

WHY： 为什么要进行性能测试

• 看软件是否能够很快的响应用户的要求？
• 软件系统是否能处理预期的用户负载并有盈余能力（处理可能的高峰期情况）？
• 软件是否能处理预期的事务数量？
• 在预期和非预期的用户负载下，应用程序是否稳定？
• 在能够处理用户的请求下，用户有良好的体验

问题的根源是什么？

• 在多种平台上的数百个服务器
• 异构系统、多种应用
• 数千个工作站
• 局域网、广域网和其他分类型的分布式网络体系结构
• 交错的故障点

误区：提高一下硬件配置就可以提高性能了，因此性能测试不重要？
软件本身的问题如：内存泄漏

WHAT: 关注的性能测试内容

1. 并发用户数/吞吐量
2. 响应时间
3. 系统运行时占用的资源
4. 点击率
5. 可靠性，可扩展性
6. 发现引起系统问题的原因,关注采用何种技术提高系统性能
7. 软、硬件配置是否合适（容量规划/硬件选型）

WHO: 哪些人员关注性能

• 开发人员

系统架构：架构设计是否合理？
数据库设计：数据库设计是否存在问题？
代码：代码是否存在性能问题？系统中是否存在不合理的内存使用方式？
设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？

• 系统管理人员（操作系统、网络、服务器等等）

资源利用率：应用服务器和数据库资源使用状况合理吗？
系统容量：系统最多能支持多少用户的访问？系统最大的业务处理量是多少？
系统稳定性：系统是否能支持7X24小时的业务访问？
系统可扩展性：系统是否能够实现扩展？系统性能可能的瓶颈在哪里？更换哪些设备能够提高系统性能？

• 用户

响应时间：过长时间的等待会让使用者烦躁不安；
对于一般的web网站来说，在欧美国家普遍的标准为原则3/5/8(2/5/10)：
3: 3秒钟用户会觉得是一个很好的体验。
5: 5秒钟用户可能会觉得差了一点，还行，比较好。
8: 8秒钟是用户所能承受的最大极限
系统稳定性：出现HTTP500错误或数据库崩溃会让用户对系统失去信心

• 业务人员

参数：如何向用户提供参数，例如支持多少用户使用？响应时间是多少？

• 测试人员

以上所有层面都需要关注
是否能够发现系统中存在的瓶颈？
是否真实有效的评估系统性能能力

WHERE: 性能测试的关注领域

• 能力验证

性能测试中最简单也是最常用的一个应用领域，主要关心的是“在给定的条件下，系统能否具有预期的表现”。

• 规划能力

规划能力领域与能力验证领域有些不同，其主要关心的是“应该如何才能使系统具有我们要求的性能能力”或 是“在某种可能发生的条件下，系统具有如何的性能能力

• 性能调优

主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域。

• 发现缺陷

主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷

WHEN: 何时进行性能测试

功能测试中后期

概念

并发数

狭义的并发用户数：同一时刻，使用系统的同一个功能（发送请求）的用户数量
广义的并发用户数：同一时刻，向服务器产生压力（发送请求）的用户数量（可以是不同的功能
系统用户数：注册系统的用户数量。
**在线用户数：登录系统的用户数。**例如，其中有666个用户的状态为在线，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干
并发用户数：是对服务器产生压力的用户。例如，可能在线的666个用户中，只有20%的用户对服务器产生了压力，这20%的用户数就是并发用户数
严格意义的并发用户数：同一时间进行同一个操作的用户数

并发数如何估算?
没有准确的估算方式，下面是一个估算方法
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C’ = C + 3根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系
统。那么：
平均并发用户数为：C = 4004/8 = 200
并发用户数峰值为：C’ = 200 + 3*根号200 = 243
举例2.1000个系统用户，500个在线，100用户打开网页在浏览，200在进行查询操作，100进行提交操作，100用户打开网页去吃饭了。产生压力的用户数量：
300 广义的并发用户数
狭义的并发用户数量：200个用户同时访问查询操作，100个用户同时访问提交操作

响应时间:RT/ART

又叫请求响应时间：TTLB（time to last byte）
用户发送请求到期待的结果出现经历的时间
响应时间=反应时间+网络传送时间（来回）+服务器处理时间+数据库响应时间
网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。

事务响应时间：TRT

服务器处理一个事务所用的时间
事务：一系列密切相关的操作的集合
支付：财务系统，银行系统，会员发送一列请求，构成了支付事务

事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。
该数值对用户的意义更直观

每秒事务通过数

**TPS 是指每秒系统能够处理的事务数。**它是衡量系统处理能力的重要指标。
当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。

地铁检票机：
只有十台进站检票的机器，一台机器一秒能进一个人
并发用户数为5，则TPS为5
并发用户数为10，则TPS为10
并发用户数为100，则TPS仍为10

点击率

**用户每秒向Web 服务器提交的HTTP请求数。**点击率越大，服务器压力越大。
这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

吞吐量（吞吐率）

服务器在单位时间处理的信息量（bytes，TPS），直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节数/天来衡量。

思考时间

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。

资源利用率

不同系统资源的使用情况。CPU,GPU，内存，磁盘，网络带宽，电源。

性能测试模型

曲线拐点模型

1）X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
2）随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型

假设：
某地铁站进站只有3个刷卡机。
人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。
乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。
场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。
场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。那么，A、B、C乘客进站时间为1s，而D，E、F乘客必须等待1s，所以他们3位在进站的时间是2s。
场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。
场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。
场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。
场景八：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

性能测试分类：

1.基准测试

对一个新系统进行性能测试，记录各项性能指标，作为后续性能测试的一个标准
有基础的标准，这样能通过对比发现系统的不同点与变化。
应用于以下场景：
1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。
2）系统进行基准测试可以在较早的阶段发现性能问题。
3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考

2.并发测试

在一定的软硬件环境下，不断地给系统增加负载，获得系统在不同的用户数量级别之下，系统的性能表现，查看系统在负载达到什么程度的时候，系统性能达到饱和。
并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁或者其他性能问题

模糊查询功能，数据库有5000条数据，给系统设置1000个用户同时访问模糊查询功能，平均响应时间2.8s
增加500个用户，1500个用户同时访问模糊查询功能，平均响应时间3s
增加500个用户，2000个用户同时访问模糊查询功能，平均乡音时间3.2s

3.压力测试

为了找出系统的性能瓶颈，以及产生系统瓶颈的原因
一般是让系统的用户负载达到饱和长时间运作，检查系统资源是否合理，同步问题，内存泄漏，检查原因
压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。

负载测试和压力测试两者可以结合进行。
负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

4.容量测试

测试系统在包和容量下系统各性能指标的表现
在一定软硬件条件下，用户量一定，不断增加数据库中数据的数量，查看不同级别下系统个性能指标的表现

模糊查询功能，数据库有2000条数据，测试获得此时的系统性能指标，响应时间2.5s
增加数据库数据至6000条数据，响应时间2.9s
增加数据库数据至7000条数据，响应时间3.1s

5.可靠性测试

在一定的软硬件环境下，系统负载达到最高负载的60%~70%，长时间（30min)运行系统，查看系统的性能指标（响应时间，TPS，点击率，吞吐量，资源利用率）是否稳定

6.配置测试

通过不同的应用服务器，网络环境，数据库不同的参数，不同的硬件设备查看系统的性能表现，找出最有最合理的资源配置

7.狭义性能测试

同一时刻，向一个系统的同一个功能发送请求，使用户不断增加
是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求。

8.负载测试

给系统定容定量，不断增加负载（用户数），看系统最大承受的用户负载是多少，看系统是否达到了需求所需要的性能指标 RT，TPR，吞吐率，资源利用率
负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，这种测试方法可以找到系统的处理极限，为系统调优提供数据。

9失效恢复测试

1.失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
2.一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用
3.不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统

10大数据量测试

大数据量测试的两种类型：
1.独立的数据量测试
针对某些系统存储、传输、统计、查询等业务进行大数据量测试
2.综合数据量测试
和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案