总体流程
- 收集需求
- 开发测试脚本
- 创建并校验测试场景
- 执行测试
- 收集数据
- 分析及报告
第一步：获取非功能性需求
- 什么时候结束性能测试？性能测试的周期有多长
- 执行性能测试需要的内部及外部资源
- 设计测试环境，测试环境需要尽可能与真实环境一致，注意这可能会耗费很多时间
- 冻结代码，保证每一轮性能测试的过程中代码不要被修改
- 保证测试环境只用作性能测试，换句话说保证性能测试的过程中没有其他人使用测试环境
- 确定性能测试目标。一般需要项目负责人拍板
- 确认核心用例。核心用例一定是来自核心业务，确认之后尽量文档化，用例化，并进行评审，如果不抓住核心用例的话，很有可能性能测试会变成无用功
- 部分测试用例需要分别监控(比如登录或搜索)，因为这是独立业务(微服务？)
- 确认用例的输入，目标及测试数据(比如多用户登录的话至少要提前创建一些测试用户)，测试数据尽量真实准确，并考虑数据的安全性及机密性
- 确定负载模型
- 设计测试场景，比如虚拟用户数，用户的思考时间，运行的速率等
- 确定被测系统,服务器及网络的关键性能指标
- 确定性能测试的输出，一般是以测试报告的形式，最佳实践是形成一套测试报告模版
- 确定性能缺陷处理流程
输出
- high level的测试计划，包括需要使用的资源，时间表及里程碑等
- 详细的测试计划，包括所有的依赖，详细的测试场景测试用例，负责模型以及环境信息
- 风险管理，不要立flag，不要把话说死，要想好赶不上计划时候怎么办
组建性能测试小分队
- 平时功能测试，发布前性能测试
- 注意性能测试工具的培训和学习
- 小组成员必须熟悉性能测试流程和工具
第二步：搭建测试环境
首先需要明确测试环境中使用的硬件，软件及网络条件。请记住，力求使你的测试环境与生产环境尽可能一致
具体步骤:
- 尽可能争取多一点的时间来进行环境搭建
- 考虑部署模型。比如尽量让环境可以配置以得到不同的环境
- 考虑stub外部链接
- 考虑自己的负载生成能力，因为有时候我们需要生成足够大的负载
- 确保系统部署正确
- 为系统及支持软件提供足够的license
- 部署及配置性能测试工具(分布式)
- 部署好监控工具
第三步：开发性能测试用例
下面一些事项是需要注意的
- 确定session data：很多时候session data是贯穿整个事务的，比较难把握，需要提前确定是使用session data还是target data
- 确定输入数据
- 确定回放性能脚本时所需要带来的额外变更：比如wordpress项目中创建post需要修改后台代码
- 确保性能脚本能正确回放：单用户，多用户
第四步：设计性能测试场景
测试类型
-
pipe clean
-
容量
-
隔离
-
压力测试
-
稳定性
思考时间和执行速度
与业务专家一起确定
确定每个用例的负载
与业务专家一起确定
确定每个用例的负载模型
- big bang
- ramp up
- 混合模式
让性能测试正确退出
- 达到执行时间
- 达到执行的迭代
- 数据被消费完，确保一定要准备足够多的数据
是否需要模拟不同的带宽
确定后台监控策略
是否需要忽略浏览器缓存