1.性能测试的基础

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

WHY：（为什么测试）

• 应用程序是否能够很快的响应用户的要求？
• 应用程序是否能处理预期的用户负载并由盈余能力？
• 应用程序是否能处理业务所需要的事务数量？
• 在预期和非预期的用户负载下，应用程序是否稳定？
• 是否能确保用户在真正使用软件时获得舒服的体验？

问题的根源是什么？

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

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

WHAT：（关注什么）

开发人员

• 系统架构：架构设计是否合理？
• 数据库设计：数据库设计是否存在问题？
• 代码：代码是否存在性能问题？系统中是否存在不合理的内存使用方式？
• 设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？
• 系统管理人员（操作系统、网络、服务器等等）
• 资源利用率：应用服务器和数据库资源使用状况合理吗？
• 系统容量：系统最多能支持多少用户的访问？系统最大的业务处理量是好多少？
• 系统稳定性：系统是否能支持7×24小时的业务访问？
• 系统可扩展性：系统是否能实现扩展？系统性能可能的瓶颈在那里？系统更换那些设备能提高性能?

用户

• 响应时间：过长时间的等待会让使用者烦躁不安；
• 对于一般的web网站来说，在欧美国家普遍的标准为原则3/5/8(2/5/10)；

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

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

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

• 系统稳定性：出现HTTP500的错误或数据库崩溃会让用户对系统失去信心；

业务人员

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

测试人员

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

WHERE：（关注领域）

• 能力验证：性能测试中最简单也是最常用的一个应用领域，主要关心的是“在给定的条件下，体统能否具有预期的表现”；
• 规范能力：规划能力领域与能力验证领域有所不同，其主要关心的是“应该如何才能视系统具有我们要求的性能能力”或是“在某种可能发生的条件下，系统具有如何的性能能力”；
• 性能调优：主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域；
• 发现缺陷：主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷；
• 误区：性能测试独立于功能测试；性能测试就是并发用户测试；在开发环境测试一下性能就可以了；

WHEN：（何时测试）

• 功能测试中后期
• 误区：性能测试在其他测试完成后，测试一下就可以了

2.概念和术语介绍

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进行测试；

性能测试对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等；

一般地，他主要针对系统的性能指标制定性能测试的测试方案，执行测试用例得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，系统响应时间，批量业务处理能力等等；

性能测试主要用来保证产品上线或发布后系统的性能满足用户需求，性能测试在软件质量保证中起重要作用；

并发数

系统用户数：简单地说就是该系统的注册用户数。例如，一个论坛里有10000个注册用户，他们可以是活跃的，也可以是僵尸的；

在线用户数：即登录系统的用户。例如，论坛其中有4000个用户的状态为在线，但在线用户并不一定都对服务器产生压力，因为有的用户登录后什么也不干；

并发用户数：是对服务器产生压力的用户。例如，可能在线的4000个用户中，只有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 = 400*4/8 = 200

并发用户数峰值为：C' = 200 + 3*根号200 = 243

响应时间（Reponse Time）

• 又叫请求响应时间：TTLB（time to last byte）
• 对请求做出响应所需要的时间
• 网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间；

事务响应时间（Transaction Reponse Time）

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

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

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

地铁检票机：

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

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

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

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

点击率（Hit Per Second）

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

吞吐量（Throughput）

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节数/天来衡量；

思考时间（Think Time）

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

资源利用率

不同系统资源的使用情况。CPU,Menory，磁盘，网络；

3.性能测试模型

曲线拐点模型

 

1）X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

2）随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。

3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

4.性能测试分类介绍

4.1 基准测试

有基础的标准，这样能通过堆积发现系统的不同点与变化；

应用于以下场景：

（1）可以制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化后，在进行一次相同标准下的测试，即可看出变化对性能的影响；

（2）系统进行基准测试可以在较早的阶段发现性能问题；

（3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考；

4.2 狭义性能测试（Performance Testing）

是通过模拟生产运行的业务压力量和使用组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求；

4.3 负载测试（Load Testing）

负载测试是在被测试系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种指标已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据；负载测试包括并发测试和容量测试

4.4 压力测试（Stress Testing）

压力测试是测试系统在一定饱和状态下，例如cpu，内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景，例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄露等；

负载测试和压力测试两者可以结合进行；

负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况；

压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试；

4.5 并发测试（Concurrency Testing）

目的：确定系统最大用户负载，以及在不同的用户负载之下，系统的各项性能指标的表现情况

如何测试：在环境一定的条件下，系统的数据库容量一定等，不断的增加用户数，持续运行系统（10min左右），查看系统的响应时间（错误率），观察，直到响应时间达到行业内用户响应时间的一个饱和标准，确定这一时刻的并发用户数。

系统——模糊查询，每次测试境条件一致，数据库容量10000条数据。

3000个用户，同时进行模糊查询，持续10min，每次增加500个用户，进行模糊查询，持续 10min，直到响应时间超过3s停止。（3/5/8原则），比如9500个用户，响应时间为3.00003秒。

4.6 配置测试（Configuration Testing）

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

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

4.7 可靠性测试（Reliability Testing）

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

4.8 失效恢复测试

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

4.9 大数据量测试

大数据量测试的两种类型：

1.独立的数据量测试

针对某些系统存储、传输、统计、查询等业务进行大数据测试

2.综合数据量测试

和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案；

这些测试类型其实是密切相关，甚至无法区别，例如几乎所有的测试都有并发测试。在实际中不用纠结具体的概念。而是要明确测试的目的。

 

	能力验证	规划能力	性能调优	发现缺陷
性能测试	*
负载测试		*	*
压力测试 * * * *	*	*	*	*
配置测试   * *		*	*
并发测试       *				*
可靠性测试 *	*
失效恢复测试	*		*	*