硬件中的 Verification 与 Validation：有什么区别？

有时，一项硬件设计在测试台上看起来完全正确：MCU 以稳定的 160 MHz 运行，传感器通过 I²C 通信，电源在满载下也能保持 12 V。但即使产品满足了所有要求，在真正交付给用户后，仍然可能达不到预期。

验证与确认（V&V）正是用来弥合“满足要求”与“满足真实需求”之间差距的方法。一些硬件团队会混淆这两个术语。把 V&V 当作单一步骤来处理，或者因为原型机看起来能工作就跳过其中之一，往往会在后期才发现问题：比如在审计期间，或产品投入现场之后。

本文将说明在硬件开发中，verification 和 validation 分别是什么意思，以及它们之间有何不同。我们还会介绍 V&V 如何通过 V 模型与需求关联、如何制定 V&V 计划，以及如何避免常见错误。

关键要点

• Verification 用于检查硬件是否满足已定义的技术要求。 
• Validation 用于检查完整产品是否满足其设计目标所对应的实际需求。
• V&V 应尽早开始，并在整个硬件开发过程中，将需求与计划中的活动、验收标准、结果以及支持性证据关联起来。

什么是 Verification？

Verification 是检查硬件是否符合已定义需求和工程规格的过程。它回答的问题是： 我们是否把产品做对了？

Verification 的目的是用证据取代假设。团队不再只是“假定”电路能工作，而是将设计或实物原型与已定义需求进行比对，并收集证据来证明其是否满足这些需求。

Verification 可包括以下活动：

• 需求评审： 检查需求是否清晰、一致、可实现、可追溯且可验证。
• 设计评审： 将原理图、PCB 布局、机械图纸和接口与已定义需求及设计规则进行比对。
• 分析与仿真： 使用计算或模型检查热裕量、信号完整性、时序或功耗等参数。
• 检查： 根据设计文档检查实体硬件、尺寸、装配、元件或连接。
• 测试与测量： 对硬件进行测量，并将结果与要求限制值或预期设计行为进行比较。

什么是 Validation？

Validation 是检查硬件是否真正适用于其预期用途、目标用户和运行环境的过程。它回答的问题是： 我们是否在做正确的产品？

Validation 的主要目的是提供证据，证明产品确实解决了它原本要解决的问题。一个设计可能满足所有技术要求，但如果在真实运行条件下达不到预期表现，仍然算不上成功。Validation 让你有信心确认：完整系统确实适合完成利益相关方真正需要它完成的工作。

Validation 可包括以下活动：

• 需求确认：  检查需求是否真正反映了利益相关方的需要，以及产品在使用中将面对的条件。
• 系统级测试： 评估完整产品，确认各部分能够按预期协同工作。
• 用例测试： 检查产品是否能够完成其设计目标中的任务和场景。
• 环境测试： 在真实的温度、湿度、振动、负载或其他运行条件下评估产品。
• 现场测试： 在预期环境中运行硬件，以发现实验室里可能不会暴露的问题。
• 用户评估： 让具有代表性的用户实际使用产品，检查它是否支持其真实工作流程和需求。

硬件开发过程中的验证与确认。

Verification 与 Validation 的区别

V&V 往往会使用相同的工程工具，例如测试、测量、检查和分析。区别在于，你希望通过结果证明什么。

例如，热箱测试可以用于 Verification，证明产品能够在规定的 −20 °C 到 60 °C 范围内工作。而 Validation 关注的是：这个温度范围是否真正符合需求？如果产品被安装在一个日晒暴露的外壳中，温度会达到 75 °C，那么它即使通过了 Verification，在实际使用中仍可能失效。当使用完整产品在现场预期会遇到的温度曲线来运行同一个热箱测试时，它也可以支持 Validation。

Verification 通常会针对已定义需求给出更直接的通过/失败结果，并且可以应用于单项需求、设计或硬件要素。Validation 则更广泛地关注集成后的系统，以及其整体行为对预期用途而言是否可接受。

在以需求驱动的开发流程中，Verification 用于建立证据，证明单项技术需求已被满足。Validation 则进一步检查完整产品在真实运行条件下是否满足利益相关方的需求，并且它也可能揭示某项需求本身并不完整或定义错误。

V&V 如何融入 V 模型

V 模型展示了如何在硬件开发项目中组织 V&V。

V 模型将系统生命周期表示为一个“V”字。左侧从利益相关方的需求与期望开始，将其转化为系统和子系统需求，再细化为架构和详细设计。V 的底部是实现阶段。右侧则随着集成过程逐步向上，在元件、子系统和完整产品层面开展测试。

系统工程过程的 V 模型。

左侧的每一个层级都与右侧相应的测试层级配对，而这些配对关系建立了可追溯性。每项需求都要关联到用于检查它的 V&V 活动及相应证据，团队在设计仍在进行时就应规划这些活动。 

例如，“12 V 输入在满载条件下必须保持在 ±5% 以内”这一需求，可以在多个层级进行检查：根据原理图检查元件额定值，对电路板进行电源仿真，以及对装配完成的产品进行测量。

在这一结构中，V&V 承担着不同角色：

• Verification 在每个层级上确认已构建的内容是否符合左侧对应的需求和设计。评审、分析和仿真从左侧开始，而测试和测量则沿右侧展开。
• Validation 则对照左上角的利益相关方需求进行检查。它从根据这些需求确认需求定义开始，并在右上角作为系统级检查再次出现：完整产品是否满足利益相关方需求和预期用途？

如何制定 V&V 计划

当硬件进入测试阶段时，团队本应已经清楚要检查什么、它关联到哪些需求、如何判定结果，以及必须收集哪些证据。V&V 计划就是将这些决策整合到一份文档中。

一份 V&V 计划通常包括六项决策：

• 定义范围： 确定计划涵盖哪些产品、子系统或硬件功能，哪些内容不在范围内，以及基于风险优先投入 V&V 工作的部分。
• 将 V&V 活动与需求关联： 将技术需求连接到 Verification 活动，将利益相关方需求连接到 Validation 活动。这样每一项都有清晰的证据路径。
• 选择方法： 决定每项需求将如何进行 Verification，例如通过检查、分析、演示、测试或其他合适的方法；并决定每项利益相关方需求将如何进行 Validation，例如通过用例测试、环境测试、用户评估或现场测试。
• 定义条件和验收标准： 明确硬件配置、运行条件、设备以及可测量结果，并以此判定该活动是通过还是失败。
• 规划由谁在何时完成什么： 分配职责、所需资源和时间安排，并使每项活动与硬件开发的适当阶段对应起来，例如原型、EVT、DVT 或 PVT 构建阶段。
• 确定如何记录结果和证据： 定义每项结果如何被记录并关联到支持性证据，以及设计变更后哪些活动需要重复执行。

常见陷阱及其避免方法

虽然软件缺陷通常可以通过更新修复，但硬件设计中的问题，最好在电路板制造之前就解决。许多这类问题都源于需求的编写方式以及 V&V 的规划方式。

下表列出了常见的 V&V 误区，以及帮助避免这些问题的良好实践。

V&V 的优势

在开发后期进行硬件更改，成本通常高于软件更改。电路板重制、工装变更或认证测试失败都会消耗真实的时间和预算，而且已出货设备中的硬件也很难再“打补丁”。这就是为什么在硬件开发中，验证与确认尤为重要。结合使用时，它们能为团队带来四项主要收益：

• 更早发现问题： 评审、仿真和早期原型能够暴露需求缺口、设计错误和疏漏。在这个阶段，修复通常只需要修改规格说明或原理图。
• 为每项需求提供证据： 验证会将每项需求与结果关联起来，因此团队可以说明检查了什么、如何检查以及结果如何。这些证据也有助于满足合规要求，而像医疗设备这样的受监管硬件，通常会将其作为设计控制的一部分加以要求。
• 贴合真实使用场景： 确认会针对完整产品在其环境、用户和任务中的表现进行测试。这可以覆盖逐条需求检查可能遗漏的问题，例如传感器漂移或阳光下显示屏眩光。
• 为下一轮迭代提供输入： 测得的裕量和失效发现可用于指导设计更改、后续修订以及下一代产品开发。它们还能够指出哪些需求需要收紧或放宽。

用于管理验证与确认的软件工具

硬件开发涉及大量需求和测试结果，在整个项目中手动跟踪它们可能非常困难。团队最终可能会陷入文件分散、工具彼此割裂的局面，例如：

• 电子表格和文档： 对于需求和测试用例数量有限的小型项目来说，这种方式较为实用。但随着 V&V 范围扩大，维护可追溯性和审计就绪状态往往需要大量人工维护，而且记录也可能逐渐失去同步。
• 问题跟踪工具（例如 Jira、GitHub）： 这些工具可以通过链接、字段或标签进行调整，用于组织 V&V 工作并连接相关项目。但要维持需求可追溯性和完整的 V&V 覆盖，通常还需要额外配置和自定义插件。
• 专用需求管理工具： 这类工具专为需求结构化和可追溯性而设计。但具体到不同工具，测试规划和证据采集可能仍需要单独模块，或与外部测试工具集成。 

对于希望在共享工作空间中规划和跟踪 V&V 活动并与需求一起管理的团队， Requirements Portal 可将需求与验证计划、测试执行、证据和变更历史关联起来。这样一来，团队就能清楚看到哪些内容已完成验证，哪些仍需关注。

结论与后续步骤

简而言之，验证证明你的硬件符合规格，而确认证明它在实际使用中确实对用户有效。要做到这一点，V&V 不能只是最后的检查清单，而必须从项目一开始就嵌入产品开发流程。

如果你想进一步加深对 V&V 框架的理解，以下资料值得继续阅读：

• NASA Systems Engineering Handbook 提供了关于规划和执行航天级硬件产品 V&V 的实用指导。
• Guide to the Systems Engineering Body of Knowledge（SEBoK）从更广泛的系统工程视角介绍了 V&V。
• INCOSE V&V Across Product Lifecycle 涵盖了产品生命周期不同阶段的 V&V、V 模型、V&V 方法、测试用例以及成功判定标准。

如果你已经准备好从理论走向实践，不妨试试 Requirements Portal，将测试用例与需求和电子设计关联起来，跟踪覆盖情况，并记录工程证据。

常见问题

Verification 和 Validation 是同一回事吗？

不是。Verification 是根据已定义的需求检查硬件；Validation 则是检查这些需求以及最终产品是否在真实使用中反映了利益相关者的需要。

Verification 和 Validation，哪个先进行？

两者都应尽早规划，而且都不是单一阶段。随着设计推进，Verification 会从评审、分析和仿真开始展开；Validation 则从检查需求是否符合利益相关者需求开始，并随着集成产品逐步成形而变得更加重要。

常见的 V&V 方法有哪些？

常见的 V&V 方法包括评审、检查、分析、仿真、演示和测试。根据其目的是检查既定需求，还是在预期使用场景中评估产品，同一种方法既可用于 Verification，也可用于 Validation。