性能测试方案

1、和产品沟通，提供的核心功能是什么
2、和开发沟通，通常性能存在哪些地方
3、文件操作，数据库操作注意
原则：模拟所有可能发生的最极端情况

性能测试实施步骤
1、规划测试
2、创建vuser脚本
3、创建方案
4、运行方案
5、监视方案
6、分析测试结果

性能测试范围的定义
1、和整个开发团队一起确认性能测试的范围
2、系统中被频繁使用的功能，调用的接口
3、系统中涉及到大量数据库读写功能
4、大量读写系统缓存部分的功能

性能测试目的
1、验证改进的性能效果，需要和以前的测试结果进行比对
2、新的业务上线，验证新系统能够满足系统的上线指标
3、验证系统的稳定性
4、验证系统的架构是否存在瓶颈

性能测试环境搭建
性能测试环境：
    --硬件环境：参考实际生产环境搭建，考虑自身硬件成本
    --软件环境：尽量和生产环境使用的版本和配置保持一致，并尽可能采用最优配置
    --网络环境：尽可能参考生产环境的网络结构和搭建，尽可能不要跨多个网段
最优的性能测试环境：
    --就是即将正式上线使用的生产环境
    
数据库中的基础数据的准备
-基础数据的内容和数据量：
    -需要参考具体系统的业务内容和使用规模
    -类似系统的数据量规模
    -尽可能多增加一定比例的冗余数据，数据库直接添加，脚本写
基础数据准备方法：
    -数据库存储过程
    -LoadRunner，selenium等自动化测试工具
    

性能测试完成的目标
1、新上线的测试系统没有明确的数字标准比对情况下，北侧是系统已经被测试到了系统极限（系统的某些资源已经耗尽，cpu,句柄，内存，数据库出现大量的slow query，系统有些处理已经变慢），比关切系统证明是可以水平扩展的，则可以上线
2、有以往测试结果进行比对，只要证明类似的测试条件下，此次的结果比以往的测试结果更好即可（每秒处理个数更多，单次请求的处理速度更快）
3、美哟可以比较的测试结果，但是产品已经上线一段时间（至少3个月），有一些运营数据，则需要分析运营的数据来作为比对的基准，只要被测系统达到3个月内系统并发峰值的4倍就可以认为是可接受的（如果是接口为测试对象，则需要混合主要的接口来进行性能测试）
4、开发人员提供经验值作为比对的基准，则北侧对象只要证明满足开发人员提出的经验值即可
如果选择以上的某一种策略，则必须明确系统的每秒处理个数和每次请求的平均时间的具体数值，并出具最终的性能测试报告。

Loadrunner的脚本工作
录制基本的Vuser脚本
增强并编辑脚本：脚本问题，如何修改，看日志，检查点，关键字检查（对页面某些变量检查，因为每次请求返回200表示收到请求成功，但是不一定该执行的就执行了）
配置运行时设置
以独立模式运行Vuser脚本
脚本集成到LoadRunner方案中

性能测试的脚本调试
1、录制或者编写性能测试脚本
2、修改测试脚本，使用随机化策略
3、调试和运行脚本，查看log和数据库内容等方式验证脚本正确性

性能测试脚本的执行
1、设计好特定的性能测试场景
2、初始的压力线程数
3、逐步加压的策略
4、测试执行结束条件
5、结束时的停止多线程的方式
注：加压的压力测试机器和被测试对象最好在一个局域网段

性能测试的数据收集
1、测试用例编号
2、测试时间
3、并发数
4、成功请求数
5、失败请求数
6、平均每秒处理个数
7、平均每个请求处理时间
8、方差
9、备注：关闭防火墙考虑

10、响应时间小于1s的请求个数
11、响应时间超过1s小于2s的请求个数
12、响应时间超过2s小于3s的请求个数
13、响应时间超过3s小于4s的请求个数
14、响应时间超过4s小于5s的请求个数
15响应时间超过5s的请求个数

性能测试数据分析
1、分析系统性能瓶颈
2、验证是否数据满足性能测试完成条件
3、整理测试报告，汇总性能测试数据，整理性能测试结果，给出测试结论
4、和整个开发团队确认测试结果
（当前cpu处理的并发请求个数，排队，系统是否产生延时：load averagecpu核数*0.7，可能出现负载，延时）

经验和教训的总结
1、总结本次出现的性能问题的原因和问题解决方法，作为团队的只是积累
2、总结测试过程中出现的流程，沟通，技术等问题，并进行相关流程的优化

 

 

----------个人学习笔记