第三章 麻醉机软件需求分析与测试需求提取
好，咱们进入第三章。这一章，说白了就是解决一个核心问题：需求到底能不能测？
我见过太多项目，开发吭哧吭哧写完了代码，测试一看需求文档——「这玩意儿怎么测？」。麻醉机可不是闹着玩的，一个需求没测透，病人可能就面临风险。所以，需求分析阶段，测试人员必须介入。
3.1 需求文档评审：不只是走个过场
很多人觉得需求评审就是读一遍文档，签个字。我告诉你，这远远不够。
麻醉机的需求文档，我习惯从三个维度去审：
- 完整性：有没有遗漏的场景？比如「潮气量设置范围是20-1500ml」，那如果用户输入了1501ml呢？边界值有没有定义？
- 一致性：前后描述有没有矛盾？我记得有一次评审，文档前面说「报警延迟不超过5秒」，后面又说「高优先级报警立即触发」。那「立即」到底是多快？这俩说法其实有冲突。
- 无歧义性：每个术语都得有明确定义。「正常通气」是什么意思？「压力过高」是多少？别让开发和测试去猜。
评审清单（我常用的）
- 每个功能是否有明确的输入、处理、输出描述？
- 异常情况（如传感器故障、通信中断）是否有定义？
- 性能指标（响应时间、精度、容量）是否量化？
- 安全相关需求是否单独标识？
嗯，这里要注意。评审不是找茬，是帮团队提前发现问题。我一般会带着测试用例的草稿去参加评审，边听边想「这个需求我能不能写出测试步骤」。写不出来，那就是需求有问题。
3.2 需求可测试性分析：能不能测，得有个标准
需求可测试性，说白了就是：你能否设计一个明确的通过/不通过判定标准？
举个例子：
- 不可测的需求：「系统应具有良好的用户体验。」——什么叫「良好」？谁来定义？
- 可测的需求：「从按下电源键到进入待机界面，时间不超过5秒。」——拿秒表一掐就知道。
我在项目中遇到过最典型的不可测需求，是「报警声音应足够响亮」。后来我们改成了「在距离设备1米处，报警声压级不低于65dB(A)」。你看，这就可测了。
我的小技巧：给每个需求打一个「可测试性评分」。
- 5分：有明确的输入、预期输出、判定标准
- 3分：有描述，但缺少量化指标
- 1分：模糊不清，无法设计测试用例
低于3分的需求，必须打回去重写。
你想想看，麻醉机的软件测试，很多场景是没法在真实病人身上做的。比如「氧浓度过低报警」，你不能真的把氧气关掉去测。所以需求必须描述清楚：模拟什么信号、触发什么条件、期望什么响应。
3.3 测试需求矩阵（RTM）的建立：把需求和测试串起来
RTM，全称是 Requirements Traceability Matrix。说白了就是一张表，告诉你：每个需求，对应哪些测试用例？每个测试用例，验证了哪些需求？
为什么要做这个？
- 防止漏测：需求有100条，测试用例只有80个，那20个谁去补？
- 变更影响分析：需求改了，哪些测试用例要跟着改？RTM一眼就能看出来。
- 合规要求：医疗器械审核，审核员一定会查RTM。没有RTM，你的测试就是不完整的。
我习惯用Excel或者专门的工具来维护RTM。结构大概是这样的：
| 需求ID | 需求描述 | 优先级 | 测试用例ID | 测试结果 | 备注 |
|---|---|---|---|---|---|
| REQ-001 | 潮气量设置范围：20-1500ml，步进1ml | 高 | TC-001, TC-002, TC-003 | 通过 | 边界值测试 |
| REQ-002 | 呼吸频率设置范围：4-60次/分钟，步进1次/分钟 | 高 | TC-004, TC-005 | 通过 | 等价类划分 |
| REQ-003 | 气道压力过高报警：当压力>40cmH2O时触发 | 最高 | TC-006, TC-007, TC-008 | 待执行 | 安全相关 |
我曾经踩过的坑：
有一次，RTM里只写了「需求ID」和「测试用例ID」的对应关系，但没写测试结果。审核员问：「这个需求测过了吗？结果怎么样？」我翻遍了文档都找不到。从那以后，我要求RTM必须包含测试结果列，而且每轮测试后都要更新。
建立RTM的步骤，我一般这么走：
- 列出所有需求：从需求文档里逐条摘出来，给每个需求一个唯一ID。
- 设计测试用例：针对每个需求，设计至少一个正向测试用例和一个负向测试用例。
- 建立映射：在RTM里，把需求ID和测试用例ID对应起来。
- 评审覆盖度：检查有没有需求没有对应的测试用例，或者测试用例没有对应的需求。
- 动态维护：需求变更时，同步更新RTM。
这里有个细节：一个需求可能对应多个测试用例。比如「潮气量设置」这个需求，你需要测边界值（20ml、1500ml）、测无效输入（19ml、1501ml）、测步进精度（21ml、22ml...）。所以RTM里，一个需求ID后面可能跟着一串测试用例ID。
反过来，一个测试用例也可能验证多个需求。比如一个「系统启动自检」的测试用例，可能同时验证了「传感器初始化」、「报警功能自检」、「通信链路检查」等多个需求。这种情况，RTM里要体现多对多的关系。
总结一下我的经验：
- 需求评审，测试人员必须参加，而且要带着测试思维去审。
- 可测试性分析，是测试工作的前置条件。需求不可测，后面全是白干。
- RTM不是一次性工作，要持续维护。每次需求变更，第一件事就是更新RTM。
好了，这一章就到这里。下一章咱们聊聊测试用例设计，特别是麻醉机这种安全关键系统，怎么设计出既能覆盖功能、又能覆盖风险的测试用例。