2. 需求分析与场景定义
说实话，我刚入行那会儿，拿到需求文档就头大。
几十页的Word文档，密密麻麻的文字，看完一遍感觉什么都懂了，真要动手搭场景时又一脸懵。后来带我的老工程师跟我说了一句话，我记到现在——「需求文档不是用来读的，是用来拆的。」
好，今天我们就聊聊怎么拆。
2.1 场景要素提取：从文字到结构化
一份典型的需求文档，里面会包含功能描述、性能指标、接口定义、异常处理等等。但我们要的不是这些文字本身，而是藏在文字背后的场景要素。
我个人习惯把场景要素归纳为五类：
| 要素类别 | 说明 | 示例 |
|---|---|---|
| 输入 | 场景的触发条件或数据 | 用户点击登录按钮、传感器上报温度值 |
| 输出 | 系统期望的响应或结果 | 返回登录成功页面、触发告警通知 |
| 环境 | 场景运行时的上下文 | 网络延迟200ms、CPU负载80% |
| 状态 | 系统在执行前的状态 | 用户已登录、设备离线 |
| 约束 | 场景执行时的限制条件 | 响应时间不超过500ms、并发用户数1000 |
你想想看，如果能把一段需求文字拆成这五类，场景的骨架就出来了。
举个例子，需求文档里写着：
「当用户连续输错密码3次后，账号将被锁定30分钟，期间任何登录尝试均返回'账号已锁定'提示。」拆解后：
- 输入：连续3次密码错误
- 输出：账号锁定，返回「账号已锁定」
- 环境：正常网络环境（默认）
- 状态：用户账号正常，未锁定
- 约束：锁定时长30分钟，锁定期间不可登录
嗯，这里要注意——很多新手容易漏掉「环境」和「状态」。我在项目中遇到过，一个场景在正常环境下跑得好好的，换到弱网环境就崩了。所以提取要素时，环境要素千万别默认取「正常」，要主动问一句：这个场景在什么环境下可能出问题？
2.2 场景边界条件定义
边界条件，说白了就是「临界点」。很多bug都出在边界上，而不是正常路径上。
我习惯用等价类划分 + 边界值分析的方法来定义边界条件。这个方法不复杂，核心就两句话：
- 把输入数据分成几个等价类，每个类里的数据表现应该一样
- 重点测试每个等价类的边界值
举个例子，需求里说「系统支持1~1000个并发用户」：
| 等价类 | 边界值 | 测试关注点 |
|---|---|---|
| 有效类（1~1000） | 1、2、999、1000 | 系统正常响应 |
| 无效类（<1） | 0、-1 | 系统拒绝或提示 |
| 无效类（>1000） | 1001、2000 | 系统限流或报错 |
我曾经踩过一个坑。有个需求说「温度超过60度触发告警」，我测了59度、60度、61度，都过了。结果上线后，用户反馈说温度从59度直接跳到62度时，告警没触发。后来一查，代码里用的是if (temperature > 60)，但温度采集模块的采样间隔是5秒，中间跳过了60度这个值。你看，边界条件不只是数值边界，还有时序边界。
2.3 场景优先级划分
场景多了，不可能全测。优先级划分是必须的。
我常用的方法是风险 × 频率矩阵。说白了，就是两个维度：
- 风险：这个场景出问题，后果有多严重？
- 频率：这个场景在真实使用中出现的概率有多高？
画个矩阵：
| 低频 | 中频 | 高频 | |
|---|---|---|---|
| 高风险 | P2 | P1 | P0 |
| 中风险 | P3 | P2 | P1 |
| 低风险 | P3 | P3 | P2 |
P0是必须测的，P1是尽量测，P2是有时间就测，P3可以放一放。
你可能会问：风险怎么评估？我个人的经验是看三点：
- 对用户的影响：会不会导致用户数据丢失？会不会让用户无法使用核心功能？
- 对业务的影响：会不会导致交易失败？会不会引发合规问题？
- 对系统的影响：会不会导致系统崩溃？会不会影响其他模块？
频率怎么评估？看历史数据、看用户反馈、看产品经理的经验。如果没有数据，就按「最坏情况」来估。
2.4 本章知识体系
下面这张图，是我自己梳理的本章核心逻辑。你看一眼，就能把整个流程串起来。
你看，整个流程其实就四步：从需求文档出发，先提取要素，再定义边界，最后排优先级。每一步都有具体的方法和工具，不是凭感觉来的。
好，今天就聊到这儿。记住一句话：场景定义的质量，决定了仿真验证的上限。这一步做扎实了，后面搭建场景、执行验证都会顺畅很多。
可可精品资料库