目录：导读
前言
性能测试场景，其实和功能测试没什么区别，只是侧重点不同。
我们在功能测试中经常用到的等价类边界值等分析和设计测试case的方法，目的是为了尽可能的覆盖业务场景，避免遗漏导致的功能逻辑缺失或者未达到预期。
而在性能测试中，基于性能需求分析和设计性能测试场景，侧重的是基于业务场景的请求/流量配比，以及测试数据准备。
设计性能测试场景
假设现在我们要开展一次性能测试，需求背景及描述如下：
需求背景：互联网电商平台；
需求描述：验证订单相关的业务及订单服务的性能；
预期目标：订单服务可以支撑日常线上业务稳定运行；
预期指标：服务级别TPS>200，P0接口99RT<100ms，线上应用CPU%<=40%；
这个时候，如何进行需求分析和测试场景设计呢？
需求分析
要验证订单服务的性能；
需要混合场景验证；
要考虑请求流量配比；
P0接口的99RT<100ms；
需要梳理订单服务P0接口；
检查相关监控工具是否接入；
场景设计
假设订单服务有4个P0接口；
分别是创建订单/确认订单/订单列表/订单详情；
各自请求流量占比分别是35%/30%/20%/15%（这里忽略其他占比较小的接口，实际工作中要考虑真实占比）；
那么压测场景设计如下：
| 编号 | 场景名称 | 场景类型 | 压测方式 | 压测目的 | 备注说明 |
|---|---|---|---|---|---|
| 1 | 创建订单 | 单机单接口 | 梯度递增 | 寻找性能拐点，发现性能瓶颈 | 可能需要多次压测验证 |
| 2 | 确认订单 | 单机单接口 | 梯度递增 | 寻找性能拐点，发现性能瓶颈 | 可能需要多次压测验证 |
| 3 | 订单列表 | 单机单接口 | 梯度递增 | 寻找性能拐点，发现性能瓶颈 | 可能需要多次压测验证 |
| 4 | 订单详情 | 单机单接口 | 梯度递增 | 寻找性能拐点，发现性能瓶颈 | 可能需要多次压测验证 |
| 5 | 混合场景 | 单机服务级(流量配比) | 梯度递增 | 寻找性能拐点，发现性能瓶颈 | 可能需要多次压测验证 |
| 6 | 混合场景 | 单机服务级(流量配比) | 稳定并发压测 | 验证预期范围内的性能是否达标 | 多次调整并发，直至性能达标 |
| 7 | 混合场景 | 单机服务级(流量配比) | 稳定性测试(>12h) | 验证服务长时间运行的稳定性 | 以最后一次稳定并发压测数值压测 |
如上所示，大概需要设计七个场景，分别验证接口级别和服务级别的性能。
问题：为什么不直接压测混合场景？
答案：因为一个服务有多个接口，每个接口都可能存在影响性能的因素，通过单接口压测，快速排查解决存在性能问题的因素，这样可以减少直接混合场景压测的性能问题定位分析和优化验证难度。
数据准备
性能测试中数据准备的情况取决于被测的业务场景，以上面的需求为例，准备测试数据时要注意两方面：
业务逻辑
订单商品库存是否充足；
下单用户是否有可用优惠券；
下单用户优惠券是否可叠加；
订单商品是否参与营销活动；
下单用户是否需要登录状态检查；
订单商品优惠券与营销活动是否可叠加；
数据量级
下单用户数量级；
用户登录态token有效期；
商品库存数量是否足够多次使用；
用户优惠券是否足够(需考虑优惠券核销和恢复)；
营销活动创建以及优惠券&商品和营销活动的关联配置；
完成上述的几个步骤，接下来才是考虑后续的动作。后续的压测准备事项大概包括如下几项：
环境检查；
DDL同步；
被测服务分支发布；
脚本开发及联调通过；
举的例子仅供参考，实际上还需要结合具体的业务需求来设计，需要学会灵活变通。
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结（尾部小惊喜）
生命不息，奋斗不止。勇敢追逐梦想，坚持努力付出，披荆斩棘，从不放弃。只要你有恒心和毅力，就一定能创造属于自己的精彩人生！
机会永远留给有准备的人，坚持努力不懈，总有一天你会收获美好的人生。在奋斗的路上，不要忘记心中初衷，为自己的理想奋斗到底！
人生没有终点，只有不断超越自己的起点。勇敢尝试新事物，不断学习进步，终将开启通向成功的大门。坚持追求梦想，披荆斩棘，才能实现人生价值！