一、性能测试的分类
1.负载测试
通过逐步增加系统负载，观察系统性能的变化，在满足系统性能指标的前提下，服务器所能承受的最大负载量的测试。（找到系统能承受的最优负载量）
2.压力测试
通过逐步增加系统负载，观察系统性能的变化，测试性能在什么负载情况下处理失效的状态。（找到系统所有承受的极限负载量）
3.并发测试
通过模拟用户并发访问同一应用、模块或数据，观察系统是否存在问题
4.稳定性测试
通过给系统加载一定的业务压力（模拟用户真实的业务压力），运行一段时间（通常指：24小时，324小时，724小时），检查系统是否稳定。
二、性能指标
1.吞吐量
代表服务器每秒能处理的业务请求的数量，直接体现服务器的性能承载能力
常见的吞吐量衡量方式：
1、从业务角度来说，每天业务数，每小时业务数，每天用户数，每天业务访问数等
2、从网络角度来说，每天字节数
3、从技术角度来说，TPS、QPS
2.并发数
定义：并发测试时的用户数
并发用户数：某一时刻同时往服务器发送请求的用户数
并发补充：
1、相对并发：同一时刻同时访问同一个应用
2、绝对并发：同一时刻同时访问同一个操作
3.响应时间
指的是用户从客户端发出请求开始，到客户端收到服务器发送的响应为止的所有时间
响应时间=服务器处理时间+网络传输时间
4.点击数
衡量web服务器性能指标(web项目特有的指标)
1、点击数不是一般所说的在页面上的点击次数
2、指的是在页面上点击以后，浏览器往服务器发送的HTTP请求资源（图片、js、css)的请求数量
3、通常可以使用每秒点击数来衡量服务器处理能力
5.资源利用率
是指系统各种资源的使用情况，使用率=已使用的资源/全部的资源*100%
通常，没有特殊需求的话
1、CPU，不高于80%（±5）
2、内存，不高于80%
3、磁盘，不高于90%
6.错误率
指的是系统在负载情况下，业务失败的概率
1、不同系统对错误率要求不同，最低不要超过千分之五
2、稳定性好的系统，大部分是由于超时引起的错误
7.TPS（每秒事物数）
每秒事务数，每秒服务器能处理的业务数量
事务：
1、用户角度，指的是业务，可以包括完成业务功能的一个或者多个操作
2、代码角度，可以包括一段或者多段代码
tps = 并发数/平均响应时间
8.QPS（每秒查询数）
每秒查询数，每秒服务器能处理的请求数量
应用：
控制服务器每秒处理的请求数，通常在负载、压力测试时用来模拟用户的业务背景压力
三、性能测试流程
1、性能测试需求分析
2、性能测试计划
3、性能测试用例
4、测试脚本编写/录制
5、搭建场景
6、运行脚本
7、系统性能调优
8、性能测试报告总结
四、需求分析
1、熟悉被测系统
熟悉系统的业务功能
熟悉系统的技术架构
2、明确性能测试内容：
从业务角度明确，关键业务
从技术角度明确，对资源消耗比较大的业务
3、明确性能测试策略：
负载测试
压力测试
稳定性测试
并发测试
4、明确性能测试的指标:
有明确需求指标
无明确需求指标:
- 查找相关资源
- 竞品分析
- 预估未来的性能
五、性能测试计划
主要内容：
1、项目背景
2、测试目标
3、人员安排
4、时间进度安排
5、性能测试环境（系统架构、软硬件配置、测试数据）
6、性能测试工具（测试工具、监控工具）
7、测试策略：
确定性能测试类型（负载压力、稳定性、并发）
确定性能测试场景（单一场景、混合场景）
8、风险控制
六、性能测试用例
测试用例作用是用于覆盖测试需求
内容包括：
测试步骤、预期结果
并发数
测试策略（参数化、关联、检查点。。。。）
七、测试脚本的编写/录制
根据测试用例的要求来使用工具进行编写/录制即可
注意：关注代码冗余的问题
八、搭建场景
将测试脚本按照用户业务场景来配置性能的测试工具
注意点：
虚拟用户数量及启动虚拟用户的方式
场景的相关设置（如：集合点）
脚本之间是否存在依赖问题
九、运行脚本
本质上就是运行场景
注意点：
负载的测试机不能满足模拟的虚拟用户数量
没有考虑缓存
没有模拟用户真实的环境
性能用例运行次数过少
十、系统性能调优
性能测试人员经过对测试结果的对比，发现系统性能的瓶颈
提示：
(1)调优人员：以开发为主导，数据库管理员、系统管理员、网络管理员、性能测试分析人员配合进行性能问题的调优
(2)验证：性能测试验证通常需要很多轮；每轮回归时需要对所有的测试指标进行全方位的对比
系统调优由易到难的顺序：
硬件问题
网络问题
应用服务器、数据库服务器的配置问题
源代码、数据库脚本
系统架构问题
十一、性能测试报告
1、对整体性能测试阶段的回顾（覆盖需求、测试不同阶段的进度和产物、性能测试结果的分析）一一技术角度
2、对整体性能测试阶段风险的管理一一管理的角度
3、对项目性能测试结果的总结（通过与否、经验和教训）
1134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
