情景分析基础：业务情景的识别、用户行为建模、关键业务路径分析
压力测试不是盲目施压，而是基于真实业务逻辑的模拟。情景分析是连接业务与技术的桥梁，其核心任务是将复杂的业务运营转化为可量化的测试模型。本章聚焦于三个递进阶段：识别（发现哪些情景值得测试）、建模（抽象用户行为模式）、分析（定位关键路径与瓶颈）。
2.1 业务情景的识别
业务情景是用户与系统交互的完整叙事单元。识别过程遵循“自上而下”的分解策略：从业务域到业务模块，再到具体操作流。
| 识别维度 | 输入来源 | 输出产物 |
|---|---|---|
| 业务域 | 产品文档、运营日报、KPI指标 | 核心业务清单（如：下单、支付、退款） |
| 用户角色 | 用户画像、权限模型、CRM数据 | 角色-情景矩阵（如：普通买家、VIP买家、商家） |
| 时间窗口 | 历史流量曲线、活动日历、定时任务 | 高峰时段、秒杀窗口、批量结算周期 |
| 异常事件 | 故障复盘、监控告警、变更记录 | 降级情景、限流触发、数据补偿流程 |
识别避坑指南： 避免将“登录”或“查询商品列表”作为独立情景。这些通常是原子操作，应嵌入到完整的业务叙事中（如“未登录用户浏览商品后登录并下单”）。
2.2 用户行为建模
用户行为建模是将识别出的情景转化为可执行的测试脚本逻辑。模型需包含三个要素：操作序列、状态转移、数据分布。
- 操作序列：定义用户从进入系统到离开的步骤链，包含分支概率（如：搜索→查看详情→加入购物车→支付，概率分别为 100%、60%、30%、15%）。
- 状态转移：描述用户会话中系统状态的变迁，如“未支付→已支付→已发货→已完成”。
- 数据分布：模拟真实数据特征，包括商品ID的冷热分布、用户等级占比、请求参数的有效范围。
建模原则： 80% 的流量集中在 20% 的核心路径上。建模时应优先保证核心路径的精确度，再逐步覆盖长尾路径。
以下是一个典型的用户行为状态机模型，展示了从“浏览”到“支付成功”的完整路径及异常回退机制：
2.3 关键业务路径分析
关键业务路径（Critical Business Path, CBP）是指对业务连续性、收入或用户体验影响最大的操作链路。分析CBP的目的是确定压力测试的优先级和目标。
分析过程通常包含以下步骤：
- 路径枚举：基于状态机模型，列出所有从入口到出口的完整路径。
- 权重计算：结合历史流量数据，计算每条路径的访问频率和资源消耗。
- 风险评级：评估路径故障后的业务损失（如：支付路径故障导致直接收入损失，浏览路径故障导致用户体验下降）。
- 优先级排序：综合权重与风险，确定 Top-N 关键路径。
| 路径名称 | 访问频率（日均） | 平均响应时间 | 故障影响等级 | 测试优先级 |
|---|---|---|---|---|
| 浏览→搜索→详情→加购→支付 | 1,200,000 | 320ms | P0（收入中断） | 最高 |
| 首页→秒杀→下单→支付 | 800,000 | 150ms | P0（活动失败） | 最高 |
| 个人中心→查看订单→申请退款 | 50,000 | 500ms | P1（客诉上升） | 高 |
| 登录→修改密码→退出 | 10,000 | 200ms | P2（体验受损） | 中 |
常见误区： 不要将所有路径都纳入压力测试。非关键路径（如“修改个人头像”）在资源有限时应直接排除，或仅做功能性验证。过度覆盖会导致测试数据膨胀、执行周期拉长，反而稀释了核心路径的测试深度。
2.4 情景分析输出物
完成上述分析后，应输出以下标准化文档，作为后续特征构建和脚本开发的输入：
- 业务情景清单：包含情景ID、名称、触发条件、预期结果。
- 用户行为模型图：包含状态节点、转移边、概率标注。
- 关键业务路径表：包含路径描述、权重、风险等级、测试策略。
- 数据特征说明：包含参数取值范围、冷热数据比例、依赖的外部数据源。
情景分析的质量直接决定了压力测试的有效性。一个精准的业务模型，能让后续的施压过程事半功倍；反之，脱离业务逻辑的测试数据，只会产生无意义的数字噪音。