1、需求分析
-
采集性能测试需求:
哪里需要性能测试:业务交易、业务量、业务量趋势等
备注:
- 可以从新业务(根据产品需求文档)、老业务更新(根据已有程序逻辑)角度采集需求
- 确定高频次的业务
- 确定影响大的业务
-
分析性能测试需求:
性能的标准是多少:
- 业务指标:如TPS、RT等
- 硬件性能指标:CPU、内存、I/0使用率等
-
制作业务性能需求表格:
-
查看各个页面的PV,选取最高的一个时段的数据(如:每天10点访问量最高)
-
根据PV量,计算TPS(根据二八原则,20%的时间里实现了80%的访问量)
TPS = (PV*80%)/(60*60*20%)
-
根据TPS计算用户的并发(虚拟用户数)
虚拟用户数 = TPS * (RunTime+ThinkTime)
备注:
RunTime和ThinkTime是指脚本运行一次脚本所有请求的时间,所以实际公式应该为(请求1RunTime+请求1ThinkTime+请求2RunTime+请求2ThinkTime...)
ThinkTime标准:0.3s
RunTime时间标准:3s
-
2、测试模型
- 业务模型:即业务流程
- 测试模型:从业务模型分析出来的需要测试的业务,通常为:高频次业务、高资源占用业务等
- 性能测试场景:根据用户习惯设计负载场景,即为具体的测试用例或脚本;
3、测试计划
- 系统概述:跟非专业人士说明被测系统是干什么的
- 测试环境:UAT、SIT、PRE
- 需求分析:根据业务模型分析整理出性能测试模型
- 测试策略:采用什么方式来测试
- 测试场景:如何组合场景来测试,理解为具体的测试执行步骤(重点)
- 基准测试:设置虚拟用户数为1,跑一遍所有脚本,确保接口不报错。证明程序正常;
- 配置测试:设置虚拟用户数为正常访问的最高值,跑一遍所有脚本,确保接口不报错。证明程序能抗住最大访问量;
- 负载场景测试:动态设置虚拟用户数(正常访问量的1-3倍递增),跑一遍所有脚本,查看软硬件的性能。找到软件、硬件的最大性能;
- 稳定性测试:设置虚拟用户数为正常访问的最高值,持续跑所有脚本,确保程序不宕机。证明服务器的文档;
- 测试准备:数据准备、服务器环境准备;
- 时间计划:测试进度和时间规划
- 测试组织架构:测试主要责任人和负责模块;
- 交付物清单:性能测试计划、性能测试报告、性能测试脚本
- 系统风险:对测试过程中,可能发生风险的地方作出预案(人员变动、流程阻塞等)