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 = 网络时间 + 应用程序处理时间
图中拐点说明：
1.响应时间突然增加
2.意味着系统的一种或多种资源利用达到极限
3.通常可以利用拐点进行性能测试分析与定位
吞吐量：单位时间内系统处理的客户端请求的数量
计算单位：一般使用请求数/秒作为吞吐量的单位，也可以使用页面数/秒表示
计算方法：Throughput=(number of requests)/(total time)
图中拐点说明：
1.吞吐量逐渐达到饱和
2.意味着系统的一种或多种资源利用达到极限
3.通常可以利用拐点进行性能分析和定位
1.并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可以是同一场景或功能，也可以是不同的
2.在线用户数：某段时间内系统访问系统的用户数，并不一定同时向系统提交请求
3.系统用户数：系统注册的总用户数
其中三者的关系：系统用户数>在线用户数>并发用户数
资源利用率：指对不同系统资源的使用程度，通常用以占用最大值的百分比来衡量
通常指关注服务器的以下资源：
1.CPU:主要负责相关事情的判断以及实际处理的机制
2.内存：电脑中的记忆块区，以供CPU进行判断，但是临时的，访问速度快，遇到关机或断电数据会丢失
3.磁盘IO：数据读写到硬件
4.网络：
图中拐点说明：
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使用问题
内存使用问题
