3、需求分析与测试设计：需求可测试性分析、测试用例设计方法（等价类、边界值、因果图）、需求追踪矩阵

各位同学，咱们今天聊点实在的。做医疗显微镜的嵌入式测试，最怕什么？怕需求写出来像天书，测试根本没法下手。我见过太多项目，需求文档写得漂漂亮亮，一到测试环节就抓瞎——「这功能到底怎么测？标准是什么？」

所以，这一章的核心就三个字：可测试性。说白了，就是需求写出来，测试工程师一看就知道「哦，我该这么测」。咱们从三个维度展开：需求可测试性分析、测试用例设计方法、以及需求追踪矩阵。嗯，都是硬骨头，但啃下来，后面就顺了。

3.1 需求可测试性分析：别让需求变成「玄学」

我个人习惯，拿到需求文档第一件事，不是写用例，而是先做可测试性评审。什么叫可测试性？就是每个需求都能被明确地验证通过或不通过。

举个例子，需求写「系统响应要快」——这能测吗？快是多快？1秒？100毫秒？还是「感觉快」？我曾在项目里遇到一个需求：「图像处理算法要高效」。当时测试组和开发组吵了三天，最后我拍板：必须量化。改成「从按下采集按钮到图像显示，不超过200毫秒」。这才叫可测试。

可测试性检查清单（我自己的经验总结）：
  • 明确性：需求是否使用「快速」「稳定」「良好」等模糊词汇？如果有，必须量化。
  • 可观测性：测试结果能否通过仪器、日志或界面直接观察到？比如「系统自动校准」，你得能看到校准完成的标志或日志输出。
  • 可控制性：测试环境能否精确控制输入条件？比如「温度超过40度时报警」，你得能模拟40度环境。
  • 可判定性：每个需求是否有明确的通过/失败判据？比如「误差不超过±5%」，而不是「误差在可接受范围内」。
避坑指南： 我曾经遇到一个需求：「系统在异常情况下应自动恢复」。听起来没问题对吧？但「异常情况」是什么？网络断开？电源波动？内存溢出？「自动恢复」又恢复到什么状态？最后我们花了整整两天，把「异常情况」拆成了12种具体场景，每种都定义了恢复后的状态。记住：不可测试的需求，就是无效的需求。

3.2 测试用例设计方法：等价类、边界值、因果图

好，需求可测试了，接下来就是设计用例。我常用的方法就三种，但每种都有讲究。你想想看，医疗设备测试，漏一个边界条件可能就是人命关天的事。

3.2.1 等价类划分：把无穷变成有限

等价类说白了就是「分堆」。比如显微镜的放大倍数范围是10x到100x，你不可能每个倍数都测一遍。那就分成有效等价类和无效等价类。

举个例子：

  • 有效等价类：10x ≤ 放大倍数 ≤ 100x（比如20x、50x、80x）
  • 无效等价类：放大倍数 < 10x（比如5x），放大倍数 > 100x（比如200x）

每个等价类选一个代表值测试就行。但注意，无效等价类一定要单独测。我见过有人把两个无效等价类放在一个用例里测，结果系统报错了，但不知道是哪个条件触发的——这就是给自己挖坑。

3.2.2 边界值分析：魔鬼在细节里

为什么单独讲边界值？因为经验告诉我，80%的缺陷都发生在边界上。你想想，代码里写的是 `if (x >= 10 && x <= 100)`，那10和100这两个点，还有9和101，最容易出问题。

我习惯用「两点法」或「三点法」：

  • 两点法：测边界值和边界值相邻的一个值（比如10和11，100和99）
  • 三点法：测边界值、边界值-1、边界值+1（比如10、9、11；100、99、101）

对于医疗显微镜，边界值测试尤其重要。比如对焦行程的极限位置、光源亮度的最大最小值、温度报警的阈值——这些地方出问题，轻则图像模糊，重则设备损坏。

注意： 边界值不是只测「输入参数」的边界。输出结果的边界也要测。比如「图像信噪比不低于30dB」，那30dB这个点就是边界。我曾经在项目里漏测了输出边界，结果设备在29.9dB时还能通过，但实际临床使用已经不合格了。

3.2.3 因果图：理清复杂逻辑

因果图，说白了就是「如果...那么...」的关系图。当需求里有多个条件组合时，因果图特别好用。

举个例子，显微镜的自动曝光功能：

  • 原因（输入条件）：A=光照不足，B=样本移动，C=手动模式开启
  • 结果（输出动作）：X=自动增加曝光时间，Y=暂停自动曝光

逻辑关系可能是：

  • 如果A且非C，则X
  • 如果B或C，则Y
  • 如果A且B，则先Y再X

画成因果图，一眼就能看出哪些组合没覆盖到。我习惯用表格把因果图转成「判定表」，然后每个组合生成一个测试用例。这样逻辑再复杂也不会漏。

我的小技巧： 因果图别画太复杂。如果原因超过5个，建议拆分成多个子功能。否则图本身就成了新的「需求文档」，谁也看不懂。我曾经见过一个因果图，画了12个原因、8个结果，最后连画图的人自己都解释不清了。

3.3 需求追踪矩阵：让每个需求都有「归宿」

需求追踪矩阵（RTM），听起来高大上，其实就是一张表。但别小看它，这是医疗器械认证的硬性要求。FDA和CE审核时，第一件事就是看你的RTM——每个需求有没有对应的测试用例？每个测试用例有没有对应的需求？

我习惯用这样的格式：

需求ID 需求描述 测试用例ID 测试结果 备注
REQ-001 放大倍数范围10x-100x TC-001, TC-002, TC-003 通过 边界值覆盖
REQ-002 自动对焦时间≤2秒 TC-004, TC-005 通过 等价类+边界值
REQ-003 温度超过40℃时报警 TC-006, TC-007, TC-008 未通过 因果图覆盖

注意几点：

  • 双向追溯：从需求能查到用例，从用例也能查到需求。缺一不可。
  • 覆盖率分析：每个需求至少有一个用例覆盖。如果某个需求没有用例，要么是需求不可测试，要么是测试遗漏。
  • 变更管理：需求变了，RTM必须同步更新。我见过最惨的项目，需求改了3版，RTM还是第一版，最后审核时被开了严重不符合项。
避坑指南： 我曾经在一个项目中，RTM里写了「所有需求已覆盖」，但审核老师随机抽了一个需求，发现对应的测试用例根本不存在——原来是我忘了更新RTM。从那以后，我要求团队每次提交测试报告前，必须用脚本自动检查RTM的完整性。记住：RTM不是写给别人看的，是给自己用的。

3.4 实战案例：显微镜自动白平衡功能

最后，咱们看一个完整的例子。假设需求是：

「系统应支持自动白平衡，在光源色温变化时自动调整，使图像色温误差不超过±200K。」

第一步，可测试性分析：

  • 「光源色温变化」——需要定义变化范围（比如3000K到7000K）
  • 「自动调整」——需要定义调整时间（比如≤3秒）
  • 「色温误差不超过±200K」——这个明确，可测

第二步，设计测试用例：

  • 等价类：色温3000K、5000K、7000K（有效）；2500K、7500K（无效，看系统是否拒绝或提示）
  • 边界值：3000K±1、7000K±1；误差值199K、200K、201K
  • 因果图：色温变化+光照强度变化+样本颜色变化，组合测试

第三步，更新RTM：

需求ID 需求描述 测试用例ID 测试结果
REQ-WB-001 自动白平衡，色温误差≤±200K TC-WB-001 ~ TC-WB-012 待执行

嗯，这样一套流程走下来，测试的底气就足了。你想想看，如果每个需求都这么处理，医疗显微镜的嵌入式系统测试，还会是「玄学」吗？

好，这一章就到这里。下一章咱们聊测试执行和缺陷管理——那又是另一番风景了。

← 上一章 📖 返回目录 下一章 →