前言
性能测试场景，其实和功能测试没什么区别，只是侧重点不同。
我们在功能测试中经常用到的等价类边界值等分析和设计测试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同步；
被测服务分支发布；
脚本开发及联调通过；
举的例子仅供参考，实际上还需要结合具体的业务需求来设计，需要学会灵活变通
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
