证据一：评测集
保存评测集的版本、抽样规则、标注人与标注时间，确保任何人可以复现同一批测试。为什么：没有版本的评测集等于没有证据，后续无法判断系统是退化了，还是样本本身发生了变化所致，也无法向审计说明测试覆盖面。
证据二：用例台账
每条用例写明输入、预期结果、实际结果、判定人与时间。怎么做：台账按需求编号索引，能看出哪条需求被验证过、哪条没有对应测试，评审时按编号抽查而不是听汇报，也能看出覆盖缺口，覆盖缺口在评审时就能被发现。
证据三：结果导出
从系统中导出带时间戳的运行结果，而不是用截图拼贴。为什么：截图无法证明完整性与未篡改，导出文件才能做抽样复核与版本间差异比对，也减少口头解释的空间，导出前应确认字段与运行版本对应。
证据四：缺陷闭环
每个未通过项要有缺陷单、修复提交、回归结果三段记录，形成闭环。边界：确因范围外原因不修的，需业务方书面确认接受风险并列入遗留清单，不能只在会上口头说一句先放过，遗留项要有人名和日期。
证据五：签署与范围
验收单要写清测了什么、没测什么、依据哪个版本。为什么：验收范围之外的功能不应被默认合格，范围声明既是后续争议的边界线，也便于下一期规划时知道从哪里接续、哪些结论已经失效，避免下一期重复测同样的内容。
适用与不适用
适合谁
- 需要向客户或上级提交验收材料的项目组
- 发生过验收结论争议、需补齐证据链的团队
- 多期交付、要区分各期验收范围的项目
不适合谁
- 尚无测试执行记录、仅有意向书阶段的项目
- 不接受留存测试数据与结果的组织
典型场景
某设计院的图纸审查助手二期验收时，甲方质疑一期问题是否真的修好。项目组调出评测集版本、用例台账与两次结果导出做差异比对，确认修复项与遗留项分别对应，双方按范围声明签署二期验收单，并约定一期遗留项的复查时间。
可执行步骤
- 为评测集记录版本号、抽样规则、标注人与标注时间，并归档保存备查。
- 建立用例台账，按需求编号索引每条测试、判定结果与执行记录并存档。
- 从系统导出带时间戳与版本号的结果文件，避免只用截图作为证据。
- 为每个未通过项建立缺陷单，记录修复提交、回归结果与验证责任人。
- 验收单写明已测范围、未测范围以及所依据的系统版本与构建号，并附证据清单。
常见坑
- 评测集没有版本管理，后续无法判断是系统退化还是样本变化导致的差异，复盘只能凭印象。
- 用聊天截图充当测试证据，无法复核完整性与执行顺序，争议时站不住脚，也只能重新组织一轮测试。
- 缺陷只记录现象不记录修复与回归，同一问题在不同版本反复出现，每次都当新问题处理。
自检与验收清单
- 评测集是否有版本号、抽样规则与标注人记录
- 用例台账是否按需求编号逐条可追溯并有执行记录
- 运行结果是否为可复核、带时间戳的导出文件
- 未通过项是否形成缺陷单、修复与回归的闭环
- 验收单是否写明未测范围与所依据的系统版本号
常见问题
客户只要结论不要材料怎么办？
仍建议留存并在验收单里附证据清单，哪怕客户不细看。材料的作用不只是说服对方，也是在半年后出现争议时保护双方；缺证据时，任何一方都难以还原当时到底测了什么。
证据要交给客户保管吗？
视合同约定。通常交付版验收材料归客户，测试数据与内部记录按数据安全要求处理，含个人信息的部分应脱敏后再提供。边界应在合同中写清，避免交付后出现数据归属争议。
上一期没留证据怎么办？
无法追溯的部分应在新一期明确列为未验证基线，不做默认合格假设。可以从当前版本重新建立评测集与基线，但不要在文档里把未测内容写成已通过，否则下一期仍会重复同样的争议。