4. 测试需求到测试点的转化
在Simulink测试用例自动化设计中，测试需求文档往往以自然语言描述系统“应该做什么”，而测试用例必须落到模型上“具体激励什么、观测什么、判定什么”。这两者之间缺少一座桥：测试点。测试点是把一条需求拆解为可被模型输入、输出或内部信号直接验证的最小断言单元。本节要解决的核心问题是：如何从功能需求、接口需求、安全需求三类文本中识别可测项，并建立需求与测试点之间的追踪矩阵，使后续自动化用例生成有据可依。
一、什么是可测项：从“需求语句”到“可观测断言”
一条需求是否可测，取决于它能否映射到模型上可施加的激励和可观测的信号。例如需求“当车速超过30 km/h时，车门应自动上锁”，其中“车速”是输入信号，“30 km/h”是阈值，“车门锁状态”是输出信号，“超过阈值后应变为锁定”是判定条件。这四个要素齐备，该需求就是可测的。反之，“系统应具有良好的响应性能”没有量化阈值、没有观测点，属于不可测需求，必须先与需求方澄清，转化为“在阶跃输入下，响应超调量不超过5%，调节时间不超过0.5 s”这类可测形式。
识别可测项时，建议对每条需求提取五元组：激励对象、激励条件、观测对象、期望行为、判定容差。缺少任何一项，都标记为待澄清项，而不是直接进入用例设计。
二、三类需求的识别侧重点
功能需求关注“输入到输出的行为映射”。识别重点是状态迁移、条件分支、计算逻辑。例如“当使能信号为真且计数达到10时，输出置1”，其测试点应覆盖：使能为假、使能为真但计数未到、计数到达边界、计数溢出等分支。功能需求的可测项通常对应Simulink中的逻辑判断、状态机迁移和查表模块。
接口需求关注“边界上的数据契约”。识别重点是信号的数据类型、量纲、取值范围、采样周期、更新时序。例如“CAN输入信号EngineSpeed为uint16，范围0～8000 rpm，周期10 ms”，其测试点应验证：超范围输入是否被限幅或报错、类型不匹配是否触发断言、周期抖动是否影响下游计算。接口需求的可测项往往落在Inport、Bus、Signal Specification和Rate Transition模块上。
安全需求关注“异常与故障下的受控行为”。识别重点是故障检测条件、响应时间、降级策略、安全状态。例如“当传感器信号超出有效范围持续100 ms时，系统应在50 ms内进入安全状态”，其测试点需要构造故障注入、计时观测和状态确认。安全需求的可测项通常需要配合Test Sequence或Signal Builder注入异常，并用Assertion或Test Assessment判定。
三、需求-测试点追踪矩阵的建立
追踪矩阵的作用是保证双向可追溯：每条需求至少有一个测试点覆盖，每个测试点都能回溯到需求来源。矩阵的列建议包含：需求编号、需求类型、需求描述摘要、测试点编号、测试点描述、激励对象、观测对象、判定条件、覆盖状态、关联用例编号。建立过程分三步：
- 编号与拆解：给每条需求分配唯一编号（如FUN-001、IF-003、SAF-002），再按五元组拆出测试点，测试点编号采用“需求编号-序号”形式，如FUN-001-TP01。
- 映射与查漏：逐条填写矩阵，检查是否存在无测试点的需求（覆盖缺口）或无需求来源的测试点（冗余测试）。
- 评审与冻结：与需求方、模型开发方共同评审测试点的判定条件是否与需求一致，冻结后作为自动化用例生成的输入。
下面这张图展示了从三类需求到测试点，再到追踪矩阵和自动化用例的转化关系。图中以一条功能需求、一条接口需求和一条安全需求为例，标出了各自的测试点拆分结果与矩阵中的关键字段。
四、实操示例：一条安全需求的测试点拆分
以SAF-002为例，需求原文为“当传感器信号超出有效范围持续100 ms时，系统应在50 ms内进入安全状态”。拆分过程如下：
- 激励对象：传感器信号SensorValue，正常范围0～5 V。
- 激励条件：注入6 V（超上限）或-1 V（超下限），持续时间设为100 ms、99 ms、101 ms三个边界值。
- 观测对象：安全状态标志SafeState，以及从故障发生到SafeState置1的时间差。
- 期望行为：持续≥100 ms时，SafeState在50 ms内变为1；持续<100 ms时，SafeState保持0。
- 判定容差：时间判定允许±5 ms，电压判定允许±0.05 V。
由此得到三个测试点：SAF-002-TP01验证99 ms不触发，SAF-002-TP02验证101 ms触发且响应时间≤50 ms，SAF-002-TP03验证6 V与-1 V两种超限方向均能触发。在Simulink中，可用Test Sequence模块产生阶跃信号，用Test Assessment模块编写“verify(SafeState==1, ...)”断言，并通过Simulation Data Inspector记录时间差。
五、常见问题与处理
实际项目中，最常见的三类问题是：需求不可测、测试点粒度过粗、矩阵与模型信号脱节。需求不可测时，应回到需求方补充量化指标；测试点粒度过粗时，可按边界值、等价类、状态迁移进一步拆分；矩阵与模型信号脱节时，应在模型上增加Test Point或Outport，使每个测试点都有明确的观测路径。只有矩阵中的每个测试点都能在Simulink中找到对应的激励入口和观测出口，后续的自动化用例生成才具备可执行的基础。