性能测试模版

版本历史

• 版本号 修订内容 修改人

内容摘要：

结合渠道测试特色，通过需求澄清，开发设计评审，压测策略分析，压测用例设计与评审，压测准备，执行，报告归档，脚本管理等环节，把空压测流程质量。

需求澄清

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.脚本准备：

• 编写受压接口脚本，并调试通过
• 编写测试数据生成脚本，并调试通过

压测执行：

• 将调试的脚本部署，选择施压压力机器，进行压测

压测报告编写：

• 将最终的执行完的结果，截图，汇总成为报告，邮件相关人员，开发及其他的干洗人员

压测报告的留档：

压测脚本和基线管理：

• 将压测脚本保留
• 根据压测结果设置性能基线
• 将用例纳入到极限用例，定时运行并监控