📚 课程目录第3章需求分析与评审

3. 需求分析与评审：从需求文档中提取测试点，需求可测性分析

说实话，很多测试新人拿到需求文档，第一反应就是「直接写用例」。我早年也犯过这个错——需求文档翻两页就开始列步骤，结果测到一半发现需求根本没说清楚边界条件，返工改用例改到崩溃。

后来我养成了一个习惯：先做需求可测性分析，再提取测试点，最后才动笔写用例。这个顺序，能帮你省掉至少 30% 的返工时间。

一份规范的嵌入式需求文档，通常包含这几块：

你想想看，如果需求里写「按键响应要快」，这能测吗？什么叫快？100ms 算快还是 10ms 算快？不可量化的需求，就是测试的坑。

⚠️ 我曾经踩过的坑： 需求文档写「系统在异常情况下应自动恢复」，没有写恢复时间、没有定义异常类型、没有说明恢复后的状态。我按「能恢复」测了，结果客户验收时拿「恢复时间超过 5 秒」说事，直接打回。从那以后，我见到「应」「宜」「可」这类模糊词，一定会在评审会上追问到底。

我个人习惯用四个维度来评估一条需求能不能测：

举个例子，需求是「设备在掉电后重新上电，应能恢复到掉电前的状态」。

如果四个维度都 OK，这条需求可以直接提取测试点。如果有一项不满足，必须在评审阶段提出来，不要自己闷头猜。

  💡 我的经验： 可测性分析做得好，评审会上你就有底气。我一般会在需求文档旁边用红笔标出「不可测」的需求，评审时一条一条过。产品经理看到你拿数据说话，通常都会配合修改。

我总结了一个三步法，团队里新人都用这个套路，上手很快。

第一步：拆解需求，提取原子条件

把一条需求拆成「条件 + 动作 + 结果」的最小单元。比如：

需求：当温度超过 85℃ 时，系统应关闭加热器并发出报警。
拆解：
  - 条件：温度 > 85℃
  - 动作：关闭加热器
  - 结果：发出报警（蜂鸣器响 / LED 闪烁）

第二步：对每个原子条件做等价类划分

温度这个条件，可以划分成：

第三步：组合测试点，考虑异常场景

不要只测正常流程。我习惯问自己三个问题：

📌 一个小技巧： 提取测试点时，用「如果…那么…」的句式写出来。比如「如果温度 > 85℃ 且加热器正在工作，那么加热器应在 100ms 内关闭」。这样写出来的测试点，可执行性非常高。

我参加需求评审时，手里会拿一份清单，逐条核对。这份清单是我多年踩坑总结出来的：

评审会上，我一般会挑 2-3 个「看起来没问题」的需求，现场做可测性分析演示。比如：

「这条需求写的是‘系统在 5 秒内无操作自动进入休眠’，那我问一下：5 秒是从最后一次操作结束开始算，还是从操作开始算？休眠前要不要保存当前状态？休眠后按哪个键唤醒？唤醒后是回到休眠前的界面还是回到主界面？」

这么一问，产品经理和开发通常会愣住，然后开始翻文档确认。这就是测试的价值——把模糊的需求逼到墙角，让它现出原形。

下面这张图是我自己画的，团队培训时一直在用。它把从需求文档到测试点的整个流程串起来了。

拿一个真实的温控系统需求来走一遍流程。需求原文：

系统应能根据当前温度自动调节加热器功率，使温度稳定在目标值附近。

这条需求，可测吗？

评审时我提了修改建议：

修改后：系统应通过 PID 算法调节加热器 PWM 占空比，使温度稳定在目标值 ±1℃ 范围内，
        稳态误差不超过 0.5℃，调节时间不超过 30 秒（从启动到首次进入稳态范围）。

改完之后，测试点就非常清晰了：

  💡 核心原则： 需求文档里每一个「模糊词」，都是测试用例里的一个「漏洞」。你在评审阶段堵住的漏洞越多，测试阶段踩的坑就越少。我见过太多项目因为需求不明确，测试用例写了 500 条，最后发现 200 条都是基于猜测写的，根本没法执行。

好了，这一章的内容就这些。记住：需求分析不是产品经理一个人的事，测试工程师必须从第一天就参与进来。你越早介入，越能掌控质量。