浅谈我所理解的性能测试~待更新

1.什么是性能测试

1.1性能测试的定义：

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

1.2性能测试的类型：

1.基准测试：在各系统施加较低压力时，查看系统的运行状况并记录相关参数来作为基础

2.负载测试：指对系统不断增加压力或增加一定压力下的持续时间，直到系统的某项或多项指标达到安全临界值

3.压力测试：是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力

4.稳定性测试：在给系统加载一定业务压力情况下，使系统运行一段时间，以此检测系统是否稳定

5.并发测试：测试多个用户同时访问同一个应用，同一个模块或者数据记录时是否存在死锁或其他性能问题

1.3性能测试应用场景

作用	主要用途	典型场景	特点	常用性能测试方法
能力验证	关注在给定的软硬件条件下，系统是否具有预期的能力表现	在要求平均响应时间小于2秒的前提下，如何判断系统是否支持50万用户/天的访问量?	1.要求在给定的环境下运行2.需要根据典型场景设计测试方案和用例	1.负载测试 2.压力测试 3.稳定性测试
规划能力	关注如何使系统具有我们要求的性能能力	某某系统计划在一年内获客量在XXX万，系统到时候是否支持用户量？如果不能，如何调整系统？	1.它常是一种探索性的测试 2.常用于了解系统性能和获得扩展性能的方法	1.负载测试 2. 压力测试 3.配置测试
性能调优	主要是对系统进行调优	某某系统上线运行一段时间后响应速度越来越慢，此时如何办？	每次只改变一个配置，切忌无止境的调优	1.并发测试 2.压力测试 3.配置测试
缺陷发现	发现缺陷或问题重现，定位手段	某些缺陷只有在高负载的情况下才能暴露出来，如线程锁，资源竞争或内存泄露	做为系统测试的补充，用来发现并发问题，或者对系统已出现的问题进行重现和定位	1.并发测试 2.压力测试
性能基准	常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短	很难定义完整的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，判断迭代

2.什么时候需要性能测试

3.性能测试流程

3.1性能测试流程

1.需求分析
2.测试准备
3.测试执行
4.结果分析与调优
5.报告与总结 

4.测试前需要准备什么

4.1性能测试专业术语

响应时间：从用户发送一个请求到用户收到服务器返回的响应数据这段时间

数据路径：客户端发送请求，通过网络发送到web服务器进行处理，如果需要操作数据库，再由网络转发到数据库进行处理，然后返回值给Web服务器，Web服务器最后把结果数据通过网络返回客户端

计算方法：Response Time = 网络时间 + 应用程序处理时间

1572339163599.png

图中拐点说明：

1.响应时间突然增加

2.意味着系统的一种或多种资源利用达到极限

3.通常可以利用拐点进行性能测试分析与定位

吞吐量：单位时间内系统处理的客户端请求的数量

计算单位：一般使用请求数/秒作为吞吐量的单位，也可以使用页面数/秒表示

计算方法：Throughput=(number of requests)/(total time)

1572339500741.png

图中拐点说明：

1.吞吐量逐渐达到饱和

2.意味着系统的一种或多种资源利用达到极限

3.通常可以利用拐点进行性能分析和定位

1.并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可以是同一场景或功能，也可以是不同的
2.在线用户数：某段时间内系统访问系统的用户数，并不一定同时向系统提交请求
3.系统用户数：系统注册的总用户数

其中三者的关系：系统用户数>在线用户数>并发用户数

资源利用率：指对不同系统资源的使用程度，通常用以占用最大值的百分比来衡量

通常指关注服务器的以下资源：

1.CPU:主要负责相关事情的判断以及实际处理的机制

2.内存：电脑中的记忆块区，以供CPU进行判断，但是临时的，访问速度快，遇到关机或断电数据会丢失

3.磁盘IO：数据读写到硬件

4.网络：

1572339861087.png

图中拐点说明：

1.服务器某资源利用逐渐达到饱和

2.通常可以利用拐点来进行性能测试分析与定位

1.TPS: Transactions Per Second,每秒事务数
2.思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间
3.点击数：每秒钟用户向WEB服务器提交的HTTP请求数
4.PV:访问一个URL,产生一个PV(Page View,页面访问量),每日每个网站的总PV是衡量一个网站规模的重要手段
5.UV:作为一个独立的用户，访问站点的所以页面均算作一个UV(Unique Visitor，用户访问)

4.2需求分析数据量化

4.3测试模型与测试数据准备

曲线拐点模型：

地铁模型：

4.4性能负载工具与系统监控工具

性能负载工具：

系统监控你工具：

5.测试需要解决哪些问题

5.1 项目具体需求

• 通过解读项目需求，需要提取出来的指标有：

  响应时间：

  并发数：

  Tps数目：

  总Tps数：

  稳定性交易总量：

  事务成功率：

  交易波动范围：

  稳定运行时长：

  资源利用率：

  测试交易场景：

  需要测试的接口：

  需要测试的场景：

  项目对应的生产与测试环境：

  系统通讯使用的协议：

  需要安排的压力机数量：

  交易占比：分析线上日志得出Tps占比

  系统架构：

5.2 测试需要得出的数据

• 需要明确一个基准：例如一个用户迭代100次，关注响应时间，事务成功率100%

• 关注系统负载能力：例如十个用户跑十分钟，关注响应时间，事务成功率100%

• 关注系统容量能力：估算一个总TPS，根据公式计算出每个交易的PACING和VU，获取系统最大处理能力，再册数三个梯度作为对比，四组容量VU等差，TPS等差,对比每组容量实际占比和测试占比，关注响应时间，总TPS，TPS，事务成功率，APP CPU利用率，数据库CPU利用率，线程死锁，数据库死锁

注：响应时间应小于负载测试时间，总TPS应约等于预估总TPS，每个交易的TPS应接近预估总TPS占比，事务成功率100%，APP CPU小于60%，DB CPU小于80%，DUMP线程栈检测是否有线程死锁，查看数据库日志是否有数据库死锁

• 关注系统稳定能力：采用最有容量的80%作为压力持续运行一段时间，观察长时间运行的性能表现，关注响应时间，TPS，总TPS，事务成功率，交易总数，观察是否有内存溢出，CPU利用率是否达标，内存是否不持续增长，是否正常出发fullgc,gc时间，gc频率

6.系统性能有哪些关注点

6.1 用户角度出发

• 响应时间

对于用户来说，使用系统时最为关注的是点击按钮，提交请求到系统返回结果，整个过程所消耗的时间就是用户对于该系统性能最为直观的感受。

6.2 管理员角度

• 响应时间

• 服务器使用资源是否合理

• 应用服务器和数据库使用资源是否合理

• 系统能否实现扩展

• 系统最多支持多少用户访问，系统最大业务处理量

• 系统性能是否存在的瓶颈在哪

• 更换哪些设备可以提高系统性能

• 系统是否支持全天候的业务访问

6.3 开发人员角度

• 架构是否合理

• 数据库设计是否合理

• 代码是否存在性能方面的问题

• 系统是否有不合理的内存使用情况

• 系统是否存在不合理的线程同步方式

• 系统是否存在不合理的资源竞争

6.4 测试人员角度

• 连接超时

• 系统崩溃

• 系统交互

• CPU使用问题

• 内存使用问题

7.怎么评价性能测试的结果