测试需求、验证确认与可追溯性¶
测试不是从设备和工具开始，而是从“需要作出什么判断”开始。没有需求、风险或未知项作为上游，测试数量再多也不能说明覆盖完整。
验证与确认¶
美国国家航空航天局（NASA，National Aeronautics and Space Administration）系统工程手册给出的核心区别是：
- 验证：以客观证据证明产品满足已批准的规定要求；
- 确认：以客观证据证明产品在预期用途和预期环境中满足利益相关方需要。
两者都可以采用分析、检查、演示或试验。验证不等于“必须上台架”，确认也不等于“必须真实飞行”。
示例：
| 目标 | 类型 | 可能证据 |
|---|---|---|
| 飞控重量不超过规定值 | 验证 | 经确认量程和不确定度的称量 |
| 遥控失联后在规定时间进入目标状态 | 验证 | SITL/HITL、日志和状态机检查 |
| 操作者在目标场景中能够识别并处理告警 | 确认 | 代表性任务演示和人员反馈 |
| 整机在预期风况和载荷下完成任务 | 确认 | 前级通过后的受控飞行 |
同一试验可以同时产生验证和确认证据，但必须分别写明对应的规定要求与预期用途。
需求确认与产品确认不是一回事¶
需求确认发生在实现前或迭代过程中，检查需求是否：
- 清晰；
- 完整；
- 一致；
- 可实现；
- 可验证；
- 有来源；
- 与上层任务和风险一致。
产品确认发生在产品已有可评价状态后，检查其是否适合预期用途。错误需求即使被完美实现，也可能得到“验证通过、确认失败”的结果。
测试方法不只有试验¶
| 方法 | 适合问题 | 主要限制 |
|---|---|---|
| 分析 | 质量预算、带宽、最坏情况、容差 | 依赖模型和输入可信度 |
| 检查 | 标识、装配、配置、文件完整性 | 不能证明动态行为 |
| 演示 | 操作流程和功能可见性 | 定量精度通常有限 |
| 试验 | 施加输入并测量响应 | 受样件、环境和测量能力限制 |
方法应由要求和风险选择。不能为了“更像工程”而把可通过静态分析关闭的问题留给高风险飞行。
写成可测试要求¶
一条可测试要求至少包含：
- 唯一ID；
- 对象；
- 应实现的行为或性能；
- 条件和环境；
- 数值、单位和容差；
- 触发与结束状态；
- 适用构型；
- 来源；
- 验证方法；
- 通过与失败准则。
不充分：
可测试形式：
REQ-END-012：
在构型CFG-07、载荷200克、指定电池与环境范围内，
飞行器执行任务剖面MP-03后，
着陆时剩余能量不得低于项目批准值。
判定采用电池前后能量、飞行日志和测试卡，
测量不确定度及停止条件见M-04。
示例中的数值必须来自项目要求，不能从其他机型复制。
需求验证矩阵¶
| 要求ID | 版本 | 上层来源 | 方法 | 层级/环境 | 程序 | 判据 | 证据 | 结果 | 异常 |
|---|---|---|---|---|---|---|---|---|---|
| REQ-001 | A | NEED-03 | 分析+试验 | 动力台架 | TP-012 | 阻断 | 阻断 | 阻断 | 无 |
产品确认还要回到预期用途，而不只回到技术要求。建立独立确认矩阵：
| 期望/场景ID | 利益相关方 | 运行概念 | 效能度量 | 支撑性能度量 | 确认环境 | 判据 | 证据 | 结果 |
|---|---|---|---|---|---|---|---|---|
| EXP-001 | 阻断 | CONOPS-03 | MOE-02 | MOP-05 | 代表性任务 | 阻断 | 阻断 | 阻断 |
- 运行概念（ConOps，Concept of Operations）描述谁在什么环境中如何使用系统；
- 效能度量（MOE，Measure of Effectiveness）描述任务或使用目标是否达成；
- 性能度量（MOP，Measure of Performance）描述产品自身的技术性能。
验证矩阵与确认矩阵可以共享测试证据，但必须分别记录技术符合性和预期用途结论。
矩阵要支持双向追踪：
同时查找：
- 有要求但没有证据；
- 有测试但没有对应要求或风险；
- 有结果但无法定位原始数据；
- 有报告但受测配置不明。
覆盖率不能只数用例¶
“执行100个测试”不能说明覆盖完整。至少按以下维度检查：
- 功能与性能要求；
- 接口；
- 状态和模式；
- 正常、边界和异常输入；
- 启动、重启和恢复；
- 运行环境；
- 人员操作；
- 安全约束；
- 版本迁移；
- 已知风险；
- 不可测试项。
不可测试或暂不测试的要求也要保留在矩阵中，状态标记为阻断、未测试或有批准依据的不适用。
测试对象的谱系¶
测试报告必须说明受测件是：
- 原理样机；
- 开发样机；
- 工程样机；
- 资格鉴定样件；
- 生产代表件；
- 交付单元；
- 仿真模型；
- 数字孪生或其他模型。
开发样机的结果不能自动代表量产单元。测试后拆解、损伤或经历超限的样件也不能在没有复核时继续作为飞行件。
配置基线¶
结论只对实际测试配置有效，至少固定：
- 机架、动力、飞控、传感器和载荷；
- 序列号与硬件修订；
- 固件提交、构建目标和编译选项；
- 参数、校准和安全策略；
- 电池、螺旋桨和连接器；
- 测试程序与脚本版本；
- 仪器、固件和校准状态；
- 环境和场地；
- 处理软件与配置。
报告应区分计划配置、开始配置、实际测试配置和交付配置。测试中发生变化时，必须标记变化时刻和受影响数据。
入口与退出准则¶
入口准则回答“是否可以开始”，包括：
- 目的、范围、要求和判据明确；
- 测试计划和安全措施已批准；
- 样件、工装、仪器和数据链就绪；
- 已知异常已关闭或有批准处置；
- 风险、角色、停止和恢复明确。
退出准则回答“是否可以结束并关闭要求”，包括：
- 计划用例已执行；
- 未执行项有正式处置；
- 数据质量和测量能力已核查；
- 结果回填验证矩阵；
- 异常已关闭、复测或正式接受；
- 配置可重建；
- 报告已审查和归档。
测试就绪评审（TRR，Test Readiness Review）通过只表示可以开始，不表示测试完成或产品合格。
偏离批准与豁免¶
按NASA术语：
- 偏离批准（Deviation）通常在要求进入实施层级配置控制前批准不满足；
- 豁免（Waiver）通常在要求进入配置控制后批准不满足；
- 异常或不符合项只是观察到偏差，不是批准；
- 要求变更会修改基线，豁免不会自动修改原要求。
项目内部可借鉴这种区分，但不能把内部批准冒充监管豁免。
每项处置至少记录：
- 要求ID；
- 适用样件和配置；
- 原因；
- 技术与安全影响；
- 补偿措施；
- 剩余风险；
- 有效期；
- 批准权限；
- 关闭条件。
结论的合格写法¶
避免：
建议：
受测件TA-03在配置CFG-07、环境ENV-02、程序TP-012和判据REV-B下，
满足REQ-001与REQ-004。
未覆盖低温、雨淋、强风和其他载荷构型。
本结果不构成型号认证、适航批准或第三方合格证明。
检查理解¶
- 验证与确认的依据分别是什么？
- 为什么“测试很多”不等于覆盖完整？
- 测试对象谱系为什么影响结论外推？
- TRR通过能否说明产品已经合格？
- 豁免与要求变更有什么区别？