性能测试方案
创建人：
日期：
一、概述
1.测试目的
2.读者对象
本文阅读对象客户、项目经理、产品经理、测试经理，以及所有想知道本项目的性能测试过程、性能测试设计策略和性能指标的人
3.参考资料
XXXX
4.术语解释
| 术语 | 解释 |
|---|---|
| XXX | XXXXX |
| XXX | XXXXX |
| XXX | XXXXX |
二、测试环境
1.网络环境
打压机器与被压机器环境
2.服务器环境
| 服务器用途 | cpu | 内存 | 安装软件 |
|---|---|---|---|
| XXX | XXX | XXX | XXX |
| XXX | XXX | XXX | XXX |
| XXX | XXX | XXX | XXX |
3.测试工具
jmeter OR loadrunner
三、测试需求
1.测试功能点
四、业务模型分析
1.现网压力预估
- 极端情况假设
结论一：
- 常规估算
结论二：
只要满足以上的性能要求，我们可以认为是符合运营安全要求的。
2.性能需求
根据分析得出的结果
3.现网带宽预估
- 极端情况的假设
结论一：
- 常规业务访问估算
结论二：
五、准备工作
1.功能测试
2.测试环境搭建
2.1客户端环境的搭建
2.2服务端环境的搭建
3.测试数据
4.录制脚本
对于每一个测试功能点，都要事先录制好相应的测试脚本，包括参数化、关联等。
准备好测试数据，并且调试好，保证在测试的时候能够顺利的运行。
5.规范制定
为脚本、分析结果等制定命名规范，方便后期分析统计。
六、测试完成准则
在执行脚本过程中监控CPU、内存，查看测试结果中的响应时间，CPU、内存、响应时间在规定范围值内，即可结束
在长时间运行后，系统不崩溃，各功能正常；服务器CPU，内存，响应时间等参
数保持稳定；脚本运行停止后，一段时间内占用的资源可以正常释放。
七、测试风险
- 选择的业务流不具有代表性。即选择的测试功能点经过负荷测试和长时间测试后不
能重现系统问题，如内存溢出，速度慢等问题；
选择测试功能点的原则：客户使用系统时经常操作的业务流，以及觉得反应比较慢的几个功能模块； - 不是在实际环境中的测试（即模拟的测试环境和客户实际使用环境配置差别较大），
由于测试环境的不同，测试结果和实际使用环境中的结果有一定的出入； - 测试环境中的数据量比实际环境中使用一段时间后的数据量要少的多，系统目前的
性能不能代表数据量增长后的性能。
为了规避以上风险，建议采取的措施
1）选择的业务流不具有代表性-----和客户确认，从客户处获取第一手资料
2）为避免环境差异导致的性能指标不具有参考意义----因此测试环境搭建在生产环境中
3）造测试数据 模拟生产环境上线2年后的数据 进行测试
八、测试设计策略
1.关键资源不处于阻塞状态
| 服务器 | CPU利用率 | 内存利用率 | 应用响应时间 |
|---|---|---|---|
| 应用服务器 | x | x | x |
| 数据库服务器 | x | x | x |
2.组合测试用例策略
- 先逐一执行单个接口的并发调用
- 最后组合执行多个数据查询接口的调用
3.测试执行策略
- 在正常的生产数据下，采用阶梯式的方式，对所有接口使用多线程进行打压，获得TPS最大值时的线程数。例如对查询接口分别使用线程数1,10,20,30,40…进行打压20分钟，获得TPS最大值时的线程数
- 使用TPS最大值时的线程数对接口进行打压2小时，获得性能数据
九、业务模型
具体业务场景
