当前位置：首页 > news >正文

软件工程中两个关键概念：验证（Verification）和确认（Validation）

news 2026/5/26 11:10:13

软件工程中两个关键概念：验证（Verification）和确认（Validation）。

✅验证（Verification）关注的是过程合规性：即“我们是否正确地构建了产品？”——它通过评审、走查、静态分析、单元测试、集成测试等手段，检查开发输出（如设计文档、代码、模块）是否严格符合前期定义的规格说明（Spec）。强调“做得对”（Right way）。
✅确认（Validation）关注的是结果适用性：即“我们是否构建了正确的产品？”——它通过用户验收测试（UAT）、原型演示、Beta测试、场景模拟等方式，验证最终产品是否真正满足用户的实际需求、业务目标和使用环境。强调“做对事”（Right product）。

二者常被简记为：
🔹Verification = Are we building the product right?
🔹Validation = Are we building the right product?

它们不是互斥而是互补的——一个系统可能完全符合规格（验证通过），但规格本身错误或遗漏（导致验证通过却确认失败），例如：开发了一个响应极快但完全无法导出数据的报表系统——它“正确实现了规格”，但规格未包含导出功能，因此不是用户需要的“正确产品”。

经典类比： Verification — 检查飞机图纸是否被精准照着制造出来（哪怕图纸设计的是纸飞机）； Validation — 检查造出来的飞机能否载人安全飞行（即是否解决了真实的航空运输问题）。

在敏捷开发中，兼顾验证（Verification）与确认（Validation）的核心在于将质量内建（Built-in Quality）融入每个迭代（Sprint）的全生命周期，而非依赖后期集中检查。其关键策略如下：

✅1. 需求端：以可验证、可确认的方式定义“完成”（Definition of Done, DoD）

DoD 必须同时包含验证项（如：代码通过静态扫描、单元测试覆盖率 ≥80%、API 符合 OpenAPI 规范）和确认项（如：通过用户可理解的验收测试场景、PO 现场签字确认、真实用户参与 UAT 演示）。
每个用户故事（User Story）需附带AC（Acceptance Criteria）—— 用行为驱动语言（如 Gherkin：Given-When-Then）编写，既是自动化测试脚本基础（支持验证），也是业务价值可观察的确认依据。

✅2. 开发中：左移验证 + 持续确认

验证左移：TDD/BDD 实践确保代码从编写起就面向规格；CI 流水线自动执行单元测试、接口测试、安全扫描，即时反馈“是否按规实现”。
确认前移：每 Sprint 中期组织Sprint Review 前的轻量级演示（In-Sprint Validation Check），邀请真实用户或领域专家快速反馈；采用可运行原型（如 Figma 交互原型 + Mock API）在编码前验证需求理解。

✅3. 协作机制：跨职能协作打破“开发-测试-业务”孤岛

“三剑客”协同：产品负责人（PO）、开发人员、测试工程师（或 QA 工程师）在 Sprint Planning 和 Refinement 阶段共同澄清 AC、设计测试用例、识别隐性需求（如性能、可访问性），使验证标准与确认目标对齐。
使用活文档（Living Documentation）（如 Cucumber Reports、Swagger UI + 示例响应）同步呈现“规格→实现→验证结果→用户确认证据”，保障信息透明。

✅4. 反馈闭环：用度量驱动持续改进

🌟 本质逻辑：敏捷不取消验证与确认，而是将其原子化、常态化、协作化、自动化——每个用户故事都是一个微小的 V&V 循环：“理解需求（确认起点）→ 定义AC（验证锚点）→ 编码+测试（验证执行）→ 演示+反馈（确认闭环）”。

反模式警示： × 把确认推迟到发布前才做UAT（导致“最后一刻失败”） × AC写成“系统应稳定”，无法验证也无法确认 × PO只签字不参与测试，验收变成形式主义 × 测试团队独立于Sprint，延迟反馈周期