【性能测试】性能测试小总结

性能测试核心问题

找到系统瓶颈，然后调优

测试方案

1. 单交易基准测试
   
   • 单独一个请求的性能测试
   • 初试设置1个线程，即1个并发量，查看TPS
   • 然后，1,5,10,20,30,50…依次并发，去找最大TPS对应的最小并发量
   • jmx文件中添加TPS监控组件（transaction per second）来查检测TPS
   • 寻找到TPS最优时的最优并发量
   • 然后设计3-4组并发量，执行性能测试，检测并统计记录应用及服务器性能数据
2. 混合场景测试
   
   • 假如某个系统包含A、B两个业务，A、B业务请求量为2:1，那么在评估整个系统性能时要考虑业务占比
   • 在已知业务占比情况下，可以手动调整并发量，观察两个业务的TPS值来寻找合适的并发量作性能测试
   • 也可以在压测脚本中通过生成随机数的方法来比较严格控制业务的请求量
   • 创建jmx文件时添加两个线程组，分别设置线程数，根据TPS监控来看多个接口占比（根据业务场景确认比例），查看并发数，并发数之和就是系统最大并发数。
3. 稳定性测试
   
   • 稳定性测试时的并发量，一般取最优TPS时对应的并发值*80%
   • 一般需要至少跑12个小时
   • 测试过程中需要观测系统的各个性能指标
4. 异常场景测试
   
   • 比如缓存挂掉、数据库挂掉等场景

测试数据

1. 测试数据库中添加测试数据，要注意数据的多样性
2. csv文件中配置多个请求参数

脚本编写

1. 和开发确认入参取值个数及范围
2. 和开发确认请求成功、失败的断言条件
3. 考虑脚本本身的性能问题，如数据库创建连接、释放时是否会有性能问题

其他问题

1. 单交易并发测试需要执行多久？
   
   • 一般5-10min，一般不少于5min最好
2. 性能测试需求调研时预期TPS怎样确认？
   
   • 根据线上业务量预估
   • 其次，根据业务诉求预估
   • 如果是新项目，可以根据28原则来大概预估
3. 稳定性测试时需要在单台机器跑还是多台？
   
   • 这个没有太大差别
4. 根据检测系统的一段时间内请求量，和压测的次数总和来对比，看数据是否对的上，来保证压测的有效性
5. 压测的目的是要找出TPS、响应时间最优情况下的用户数量吗？
   
   • 因为压测时的用户数量（并发线程） 是没有实际意义的。系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。拿查询来说：考虑的是查询接口支持1秒多少次查询，而不是支持多少人同时查询。

性能测试能力定位

1. 初级：会写脚本+会设计场景+会执行
   
   • 脚本+参数化 来模拟调用接口的真实情况，然后设计场景找最优并发数，统计各场景的资源等能提供的信息
2. 中级：会点瓶颈定位
3. 高级：深入瓶颈定位+调优建议