性能测试模版
版本历史
- 版本号 修订内容 修改人
内容摘要：
结合渠道测试特色，通过需求澄清，开发设计评审，压测策略分析，压测用例设计与评审，压测准备，执行，报告归档，脚本管理等环节，把空压测流程质量。
需求澄清
1.了解需求背景
- 与业务，产品，开发，了解项目需求背景，改造点，用户数量，用户场景等信息。
明确业务指标：
- 根绝线上生产流量或往期活动流量等参考值，与业务，产品，开发明确业务指标。
明确压测试范围：
- 与产品，开发，共同评估，哪些场景需要压力测试，具体涉及哪些接口等信息，明确目前应用承载信息如：应用生产机器数据，配置，数据库配置等信息
- 应用目前生产接口总调用量信息等等。
明确压测的目的：
- 与产品，开发共同评估，明确压测的目的，如：明确接口瓶颈点，为接口限流提供依据，
- 明确接口性能，检查在预估流量下，接口响应时间，TPS等满足业务需求的等等。
开发设计经评审
1.明确接口关联方
- 参加开发设计评审，明确被压接口冠梁方，整理被压接口链路信息等等。
了解卡接口设计细节：
- 了解接口设计细节，明确接口是否用到缓存Redis，MQ等中间件。
压测策略分析：
1.接口层策略分析：
- 1.接口层策略包含且不限于如下场景：
- 1.1单接口压测
- 全链路压测试
- a)最长调用链路压测
- b)最常用调用链路压测
2.复杂场景策略分析
用户场景策略包含且不限于如下场景：
- 1.单场景压测（正常场景）
- 2.多场景压测（正常场景，异常场景等等）
- 3.混合场景测试，按场景比例压测等等
3.压测数据量级分析
- 接口数据量分析，与声场数据量保持一致
- 应用现存接口调用量分析，是否要将现在接口调用量累加到目标量
4.依赖关联方分析：
- 分析是否依赖其他关联方，如登录依赖等等
压测用例设计与评审
1.接口层用例设计
针对接口层用例设计
- 覆盖所有要测是的接口
- 明确入参
- 明确response断言
- 明确要检查的点 如TPS,响应时间等等
复杂场景用例设计
- 明确不同场景的入参情况
- 明确混合场景的接口比例
- 明确混合场景每个接口检查点，如tps，响应时间，等等。
测试用例评审
- 由于测试人员发起主持，产品，开发参与，三方对压测用例进行评审，根据会议内容更新用力哦并形成会议纪要。
压测准备：
1.环境准备
- 确保受压服务LPT环境正常可用。
- 确保关联系统LPT环境正常可用
- 确保压测涉及到的组件Redis，MQ等正常的使用
2.数据准备：
- 编写受压接口脚本，并调试通过
- 编写测试数据生成脚本，并调试通过
3.脚本准备：
- 编写受压接口脚本，并调试通过
- 编写测试数据生成脚本，并调试通过
压测执行：
- 将调试的脚本部署，选择施压压力机器，进行压测
压测报告编写：
- 将最终的执行完的结果，截图，汇总成为报告，邮件相关人员，开发及其他的干洗人员
压测报告的留档：
压测脚本和基线管理：
- 将压测脚本保留
- 根据压测结果设置性能基线
- 将用例纳入到极限用例，定时运行并监控