---
id: ka-guidance-验证方法
kind: guidance
title: 验证方法
sync_policy: engine_only
status: active
triggers:
  - 验证
  - verify
  - 测试
  - 端到端
  - 集成测试
  - 验收
  - 执行验证
  - 怎么验证
target_artifact:
  - review_report
extra:
  name: verification-method
  scope:
    - '*'
  products:
    - '*'
  category: procedure
  version: 1.0.0
  last_reviewed: '2026-06-17'
  verification_layer: L2
  stage: verify
  domain: verify
  owner_mechanism: mc-verifier
---

# 验证方法：怎么真实验证（禁止假验证）

> [[证据驱动与反幻觉]] 第 5/10 条：验证计划不是验证结果，失败必须修复复验。
> 计划不是结果。选择能直接证明本次风险和验收标准的最小测试组合，并保留真实执行证据。

## 分层验证

1. **单元测试**：单个函数/模块逻辑，mock 外部依赖
2. **集成测试**：模块组合，真实依赖（DB/缓存）
3. **端到端测试**：完整业务流程，浏览器/API 真实跑通

不是每个项目或变更都需要三层全套。按风险和依赖选择适用层，并对未采用的层说明为什么其他证据足以证明目标；不能只因单元测试方便就跳过真实集成风险。

## 证据收集

- 测试输出（pass/fail/total）
- 截图、trace 或录屏（仅在能证明界面/交互事实时）
- API 响应日志
- 数据库状态验证（改完数据真的变了）

## Evidence 级别（承接测试计划）

- **E0 不可接受**：无运行时证据（静态分析/AI 摘要/"我觉得对"）
- **E1 最低**：运行时证据（测试输出/响应日志）
- **E2 增强**：跨真实边界的主链路证据，例如浏览器、API、消息、存储或目标设备中的适用组合

高风险核心流程优先使用跨边界证据，但证据形态由真实系统决定。

## 禁止假验证

- 只跑 happy path（违规，必须覆盖异常/边界）
- mock 掉被测逻辑（违规，测试自己证明自己）
- 用"验证计划"冒充"验证结果"（违规）
- 未执行就说"全部通过"（违规）
- 失败不修复就说"建议验证"后标记完成（违规）

## 失败处理

验证失败 → 进入 [[反馈修复闭环]]：读 findings → 定位根因 → 修复 → 重验；达到 full 结果声明的重试上限后停止机械重试并请求用户决策。