3. 业务场景梳理：如何从用户旅程与核心业务流程中提取待测场景
压力测试不是盲目压测所有接口，而是必须从真实的业务场景出发。本章将讲解如何通过用户旅程地图与核心业务流程分析，系统性地提取出需要纳入压力测试特征清单的待测场景。
3.1 用户旅程 vs. 业务流程：两个视角的差异
| 维度 | 用户旅程 (User Journey) | 业务流程 (Business Process) |
|---|---|---|
| 视角 | 用户视角，关注体验与触点 | 系统视角，关注状态流转与数据 |
| 粒度 | 宏观阶段（如浏览→下单→支付） | 微观步骤（如校验库存→扣减余额→生成订单） |
| 产出 | 识别高并发用户行为路径 | 识别关键事务与依赖关系 |
| 压测价值 | 确定混合场景比例 | 确定单场景与链路的性能基线 |
实践建议：先绘制用户旅程，再拆解为业务流程。用户旅程告诉你“用户会做什么”，业务流程告诉你“系统要扛什么”。
3.2 第一步：绘制用户旅程地图
用户旅程地图以时间轴为主线，记录用户从进入系统到完成目标的全过程。以电商系统为例，典型旅程包括：
- 发现阶段：搜索商品、浏览推荐、查看详情
- 决策阶段：加入购物车、对比商品、查看评价
- 转化阶段：提交订单、选择支付方式、完成支付
- 售后阶段：查看订单状态、申请退款、联系客服
每个阶段对应一组用户操作，这些操作在压力测试中就是待测的业务场景。
关键原则：只保留在峰值流量下可能成为瓶颈的旅程阶段。例如“查看评价”在秒杀场景下流量远低于“提交订单”，可降级处理。
3.3 第二步：拆解核心业务流程
在用户旅程的基础上，将每个触点对应的后端业务流程进行拆解。以“提交订单”为例，其业务流程包含：
- 库存校验：查询商品库存是否充足
- 价格计算：应用优惠券、积分、满减规则
- 订单生成：写入订单表、订单明细表
- 库存扣减：原子性扣减库存，防止超卖
- 支付调用：调用第三方支付网关
每个子流程都可能成为性能瓶颈，需要独立评估是否纳入压测范围。
3.4 第三步：场景优先级评估矩阵
并非所有业务流程都需要压测。使用以下矩阵对候选场景进行优先级排序：
| 场景 | 用户频次 | 业务重要性 | 资源消耗 | 优先级 |
|---|---|---|---|---|
| 商品搜索 | 极高 | 高 | 中 | P0 |
| 提交订单 | 高 | 极高 | 高 | P0 |
| 支付回调 | 中 | 极高 | 低 | P1 |
| 查看历史订单 | 低 | 中 | 中 | P2 |
| 用户注册 | 低 | 高 | 低 | P2 |
避坑提醒：不要只压测 P0 场景而忽略 P1 场景的连锁反应。例如支付回调虽然频次低，但失败会导致订单状态不一致，引发数据雪崩。
3.5 第四步：构建场景依赖关系图
业务场景之间存在依赖关系，压测时必须考虑数据流与状态传递。以下是一个典型的电商下单场景依赖关系：
3.6 最终输出：待测场景特征清单
经过以上四步，最终输出结构化的待测场景特征清单，包含以下字段：
- 场景编号：唯一标识，如 SC-001
- 场景名称：如“用户下单全链路”
- 关联旅程阶段：如“转化阶段”
- 核心接口：如 POST /api/order/create
- 依赖场景：如“登录场景”、“库存查询场景”
- 优先级：P0/P1/P2
- 预估并发量：基于业务预估的峰值 TPS
实战案例：某电商大促压测中，通过用户旅程发现“秒杀抢购”路径包含 7 个核心接口，但实际压测时只选取了其中 4 个 P0 接口进行全链路压测，其余 3 个通过降级策略处理，最终将压测成本降低 40%，同时保障了核心链路稳定。
完成场景提取后，下一阶段将进入压测数据准备环节，确保每个场景都有真实且合规的测试数据支撑。