如何分析并设计性能测试场景

前几天写了一篇文章《如何设计自动化测试 case》，里面聊到了为什么要设计 case：

1 便于业务活动开展

2 确保业务场景覆盖

3 质量度量和质量内建

其实这几点原因，在性能测试活动中同样适用。

这篇文章，我想聊聊基于性能测试需求分析的压测场景设计的话题。

如何理解性能测试场景？

性能测试场景，其实和功能测试没什么区别，只是侧重点不同。

我们在功能测试中经常用到的等价类边界值等分析和设计测试 case 的方法，目的是为了尽可能的覆盖业务场景，避免遗漏导致的功能逻辑缺失或者未达到预期。

而性能测试中，基于性能需求分析和设计性能测试场景，侧重的是基于业务场景的请求/流量配比，以及测试数据准备。这实际上就是我在前面的文章《全链路压测(8):构建三大模型》中提到的性能测试三大模型：

1 业务场景模型

2 请求流量模型

3 测试数据模型

如何设计性能测试场景？

假设现在我们要开展一次性能测试，需求背景及描述如下：

需求背景：互联网电商平台；

需求描述：验证订单相关的业务及订单服务的性能；

预期目标：订单服务可以支撑日常线上业务稳定运行；

预期指标：服务级别 TPS>200，P0 接口 99RT<100ms，线上应用 CPU%<=40%；

这个时候，如何进行需求分析和测试场景设计呢？

需求分析

1 要验证订单服务的性能；

a 需要混合场景验证；

b 要考虑请求流量配比；

2P0 接口的 99RT<100ms；

a 需要梳理订单服务 P0 接口；

b 检查相关监控工具是否接入；

场景设计

假设订单服务有 4 个 P0 接口；

分别是创建订单/确认订单/订单列表/订单详情；

各自流量占比分别是 35%/30%/20%/15%（这里忽略其他占比较小接口，工作中要考虑真实占比）；

那么压测场景设计如下：

如上所示，大概需要设计七个场景，分别验证接口级别和服务级别的性能。

问题：为什么不直接压测混合场景？

答案：因为一个服务有多个接口，每个接口都可能存在影响性能的因素，通过单接口压测，快速排查解决存在性能问题的因素，这样可以减少直接混合场景压测的性能问题定位分析和优化验证难度。

数据准备

性能测试中数据准备的情况取决于被测的业务场景，以上面的需求为例，准备测试数据时要注意两方面：

业务逻辑

1 订单商品库存是否充足；

2 下单用户是否有可用优惠券；

3 下单用户优惠券是否可叠加；

4 订单商品是否参与营销活动；

5 下单用户是否需要登录状态检查；

6 订单商品优惠券与营销活动是否可叠加；

数据量级

1 下单用户数量级；

2 用户登录态 token 有效期；

3 商品库存数量是否足够多次使用；

4 用户优惠券是否足够(需考虑优惠券核销和恢复)；

5 营销活动创建以及优惠券 &商品和营销活动的关联配置；

完成上述的几个步骤，接下来才是考虑后续的动作。后续的压测准备事项大概包括如下几项：

1 环境检查；

2DDL 同步；

3 被测服务分支发布；

4 脚本开发及联调通过；

以上就是关于性能需求分析以及场景设计的内容，文中举的例子仅供参考，在实际的工作中，需要学会灵活变通。当然，经验比较丰富的同学场景设计其实可做可不做，流程只是提供一种工程实践的指导思路，并不需要完全照搬。