本文共 5045 字，大约阅读时间需要 16 分钟。

1.性能测试基础

1.1为什么要进行性能测试

1，应用程序是否能够很快的响应用户的要求？

2，应用程序是否能处理预期的用户负载并有盈余能力？ 3，应用程序是否能处理业务所需要的事务数量？ 4，在预期和非预期的用户负载下，应用程序是否稳定？ 5，是否能确保用户在真正使用软件时获得舒服的体验？ ……

问题的根源是什么？

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

误区：提高一下硬件配置就可以提高性能了，因此性能测试不重要？

答：依旧很重要。（eg 软件本身的问题如：内存泄漏等）

1.2性能测试关注点

1，并发用户数/吞吐量

2，平均响应时间 3，服务器资源占用情况（资源利用率） 4，可靠性、可扩展性 5，发现引起系统问题的原因，关注采用何种技术提高系统性能 6，软、硬件配置是否合适（容量规划/硬件选型） ……

1.3关注性能的人员

1，开发人员

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

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

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

3，用户

• 响应时间
• 系统稳定性

对于一般的web网站来说，在欧美国家普遍的标准为原则3/5/8(2/5/10)：

  3: 3秒钟用户会觉得是一个很好的体验。

  5: 5秒钟用户可能会觉得差了一点，还行，比较好。

  8: 8秒钟是用户所能承受的最大极限

4，业务人员

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

6，测试人员

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

性能测试时机

开发过程中(白盒测试)

开发结束(黑盒测试)

注意：

1，性能测试不独立于功能测试。（要在保证功能前提下进行性能测试） 2，性能测试不仅仅是并发用户测试。

2.概念和术语

并发数

    系统用户数：注册系统的用户数。

    在线用户数：登录这个系统的用户。     并发用户数（广义）：是对服务器产生压力的用户，即同一时刻针对同一个功能向系统的服务器发送请求的用户数量。     并发用户数（狭义）：同一时间用户对系统进行同一个操作的用户数，即同一时刻向服务器发送http请求（不是同一个功能）的用户数量。     （现实中一般都是狭义的）

eg：一个系统有3000人在线，其中30%浏览页面；20%填写订单；5%提交订单；15%查询订单；30%做其他事情。

则用户并发数（广义）为：5%提交订单 + 15%查询订单 = 600人

响应时间（Reponse Time）

    响应时间又叫请求响应时间：TTLB（time to last byte），对请求作出响应所需要的时间。

    响应时间 = （用户反应时间一般可以忽略） + 网络传输时间 + 服务器响应时间 + 数据库处理时间

    解释：网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。

    

事务响应时间（Transaction Reponse Time）

    事务是指一组密切相关的操作组合。

    例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。

每秒事务通过数（Transaction Per Second）

    TPS 是指每秒系统能够处理的事务数。

    它是衡量系统处理能力的重要指标。

地铁检票机：只有十台进站检票的机器，一台机器一秒能进一个人

并发用户数为5，则TPS为5

并发用户数为10，则TPS为10

并发用户数为100，则TPS仍为10

点击率（Hit Per Second）

    单位时间用户每秒向Web 服务器提交的HTTP请求数。

    点击率越大，服务器压力越大。     这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

吞吐量（Throughput）

    一段时间服务器处理的信息量。（单位多样，HTTP数、字节、事务数等）

吞吐率

    单位时间内服务器处理的信息量，即单位时间内吞吐量。

资源利用率

    不同系统资源的使用情况，反映。CPU，Memory，磁盘，网络……。

3.性能测试模型

3.1曲线拐点模型

分析：

• 资源利用率在第一区域稳定增长，在第二区域小幅增长，在第三区域呈直线，表示饱和。
• 响应时间随着并发用户数的增加，在前两个区域基本平稳，小幅递增，在第三个区域急速递增，产生拐点。
• 同时，吞吐量随着并发用户数的增加，请求增加，在第一区域基本稳定上升，在第二区域处理达到顶点，随后开始下降。
• 轻压力区和重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用的充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

总结：

• 当系统的负载等于最佳并发用户数时，整体效率最高，也没有资源被浪费，用户也不需要等待；
• 当系统负载处于最佳并发用户数和最大用户并发数之间时，系统可以继续工作但用户的等待时间延长；
• 当系统负载大于最大并发用户数时，用户满意度基本为零，甚至放弃访问。

3.2理发师模型

理发师模型是经典的解释存吐率与响应时间的模型。

比如有一家理发馆，里面有3名理发师，每个理发师水平相当，每给一位顾客理发需要10分钟的时间，如表所示：

设置并发数	总响应时间	平均响应时间	实际并发数
1（用户）	10分钟X1=10分钟	10 分钟/1=10分钟	1
2	10分钟X2=20分钟	20 分钟/2=10分钟	2
3	10分钟X3=30分钟	30 分钟/3=10分钟	3
4	20分钟X1+10分钟X3=50分钟	50 分钟/4=12.5分钟	3
5	20分钟X2+10分钟X3=70分钟	70 分钟/5=14分钟	3
6	20分钟X3+10分钟X3=90分钟	90 分钟/6=15分钟	3
7	30分钟X1+20分钟X3+10分钟X3=120分钟	120分钟/7≈17.14分钟	3
8	30分钟X2+20分钟X3+10分钟X3=150分钟	150分钟/8=18.75分钟	3
9	30分钟X3+20分钟X3+10分钟X3=180分钟	180分钟/9=20分钟	3

假设：用户最多等待2h

分析：

3.3地铁模型

假设：

    某地铁站进站只有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、增大连接数）。

场景八：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

4.性能测试分类介绍

• 基准测试
• 性能测试（Performance Testing）
• 负载测试（Load Testing）
• 压力测试（StressTesting）
• 并发测试（Concurrency Testing）
• 配置测试（ConfigurationTesting）
• 可靠性测试（Reliability Testing）
• 失效恢复测试（Failover Testing）
• 大数据量测试

负载测试（重要）

负载测试包含两种：并发测试和容量测试。

1.并发测试：在一定的环境（软/硬件、网络资源等）下，运行一种或多种业务，在不同的虚拟用户下，测试系统的性能。

目的：确定用户负载。

系统性能瓶颈：①响应时间3s （增加数据量，直到响应时间超过3s）

②（错误虚拟用户数+失败用户数） / 总的虚拟用户数 = 5% (不能超过5%)

eg：某一个系统的模糊查询，数据库有10000条数据，5000个用户同时进行模糊查询。让系统程序运行10min，每次增加500用户，当用户数9500时，用户响应时间3.001s。则最大用户负载9500。

2.容量测试：在一定环境下，运行一种或多种业务和一定的虚拟用户数，向数据库中构造不同级别的数据量，确定数据库的性能指标。

目的：确定数据库的性能指标。

eg：模糊查询，4000用户，数据库数量10000条，每次增加1000，持续运行10min。数据库数量达到30000时，用户响应时间为3.002s。则最大数据库容量是30000。

压力测试/强度测试（重要）

压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。

压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景，例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。

配置测试（重要）

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

例如在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响。

可靠性测试/疲劳测试（重要）

可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

特点：持续时间长；负载（数据库/用户）达到70%-80%。

失效恢复测试（了解）

失效恢复测试类似容错性测试。一般使用不多，除非是非常重要的系统。

1，失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。

2，一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用。

3，不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统。

大数据量测试（了解）

大数据量测试的两种类型：独立的数据量测试 和 综合数据量测试。

1，独立的数据量测试：针对某些系统存储、传输、统计、查询等业务进行大数据量测试。

2，综合数据量测试：和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案。

类比

转载地址：http://thjwi.baihongyu.com/