2、需求阶段介入：如何从测试视角评审需求规格，识别模糊与不可测需求

很多团队把测试当成开发完成后的「质检员」。说实话，这是最亏的做法。我见过太多项目，需求文档写得漂漂亮亮，一到测试环节就发现根本没法测——要么条件模糊，要么指标缺失，要么逻辑矛盾。这时候再回头改需求，成本至少翻三倍。

我个人习惯是：需求评审会，测试必须坐第一排。不是去旁听，是去「找茬」的。你想想看，如果一段需求连测试都无法设计用例，那开发怎么可能写对代码？

2.1 模糊需求的三大典型特征

我在项目中总结了一套快速识别模糊需求的方法。说白了，就是看需求描述里有没有这三个「坑」：

特征	典型表述	问题本质
定性无定量	「响应速度要快」「功耗要低」	缺少可测量的数值边界
条件不完整	「异常时自动复位」	未定义「异常」的具体触发条件
逻辑有歧义	「优先处理高优先级中断」	未说明同优先级时的仲裁策略

2.2 不可测需求的识别方法

什么叫不可测？不是测不了，是测了也没法判断对错。举个例子，需求写「系统运行稳定」。什么叫稳定？跑一小时不崩算稳定，还是跑一年不崩算稳定？这种需求，你写测试用例的时候根本没法写 pass/fail 标准。

我曾经在一个车载项目中遇到过这样的需求：「CAN 总线通信应具有高可靠性」。产品经理觉得写得很清楚，但测试团队直接懵了——「高可靠性」是多少？99.9% 还是 99.999%？误码率要求是多少？后来我们硬是拉着架构师重新定义，改成了「连续 72 小时通信，误码率低于 10⁻⁷」。这才算可测。

识别不可测需求，我建议用这个清单逐条过：

1. 有没有明确的通过/失败判据？ 没有 → 不可测
2. 测试条件是否可复现？ 依赖「偶然事件」→ 不可测
3. 测量手段是否具备？ 需要实验室没有的仪器 → 不可测
4. 指标是否覆盖全场景？ 只写了常温，没写高低温 → 不完整
5. 时序要求是否明确？ 「尽快」「立即」→ 不可测

2.3 测试视角的需求评审 checklist

我每次参加需求评审，手里都会拿一份 checklist。不是死板地逐条打勾，而是用它来提醒自己别漏掉关键点。下面这份清单，是我这些年迭代下来的版本：

评审维度	检查项	常见问题
功能完整性	所有输入组合是否都有定义？	遗漏边界值、非法输入处理
性能可测性	性能指标是否有数值上限？	「尽可能快」「尽量低」
时序明确性	时序约束是否量化？	「立即响应」「稍后处理」
异常处理	异常场景是否枚举完整？	只写了正常流程，缺异常分支
接口一致性	模块间接口定义是否对齐？	信号命名、时序、电平不匹配
环境依赖性	是否依赖特定硬件或软件版本？	未注明依赖版本号

2.4 需求评审中的测试前置策略流程

光有清单还不够，得有流程。我建议测试团队在需求阶段按下面这个流程走一遍：

2.5 实战案例：一个模糊需求的「解剖」

拿我最近参与的一个项目举例。需求原文是这么写的：

「当系统检测到电源电压异常时，应自动进入保护模式，并记录故障信息。」

乍一看没问题对吧？但用测试视角一拆，全是坑：

• 「电源电压异常」—— 多少伏算异常？是低于 3.0V 还是高于 3.6V？有没有迟滞？
• 「自动进入保护模式」—— 保护模式具体做什么？切断输出？降频？还是只报警？
• 「记录故障信息」—— 记录在哪里？EEPROM 还是 RAM？掉电后还在不在？

我们测试团队在评审会上直接列了一张「需求澄清表」，一条一条跟产品经理和开发对齐。最终改成了这样：

「当 VCC 低于 2.8V 或高于 3.6V 持续超过 2ms 时，系统应在 100μs 内将 GPIO_OUT 拉低，
同时将故障码 0xE1 写入 EEPROM 地址 0x0010。EEPROM 数据在掉电后需保持至少 10 年。」

你看，同样是描述一件事，后者每条都能写测试用例。这就是测试前置的价值。