技术解读 · 公开资料解读，配图为场景示意。
本文要点
一条可复查的验收记录，应包含测试条件、输入、预期结果、实际结果与证据。未通过项需要保留影响范围、处理人和复测结论。
背景与依据
NIST OT 安全指南同时关注系统性能、可靠性与安全运行。以下以验收记录为例，讨论项目如何保存这些方面的检查证据。 [1]
把“正常”改成别人可以重复的描述
例如检查采集恢复时，可以记录模拟的断连条件、恢复方式、应补传的数据范围与实际核对结果。这样的记录比“网络恢复正常”更容易复查。
示例只描述记录方法，实际故障测试需采用批准的方案。输入数据、脚本或截图应能够定位到对应版本。
每类测试都需要明确预期
数据检查关注缺失、重复和口径；性能检查关注约定负载下的响应；权限检查关注不同角色能做与不能做的操作。三类测试不应混写成一个“通过”。
涉及算法或节能量的结果，还需要另附样本、计算和对比条件。一个功能测试记录无法证明业务收益。
未通过项的处理比一次签字更重要
建议写明问题影响、临时措施、责任人和复测安排。部分功能延期时，应说明现阶段允许的使用范围，避免现场误以为已经全面完成。
交接资料中保留最终版本、未结事项与资料位置。后续修改时关联原记录，可以看清问题是否复发以及哪些条件已经变化。
把问题变成可以复测的记录
澄序工业建议每个问题都有触发条件、预期表现、实际表现和复测结论。证据完整后，后续维护人员才能沿用已有判断。
阅读要点对照
| 关注点 | 应该看什么 | 容易忽略什么 |
|---|---|---|
| 测试条件 | 版本、输入与环境 | 别人无法重做 |
| 结果证据 | 预期、实际与附件 | 只有“正常”二字 |
| 问题闭环 | 影响、责任与复测 | 签字后丢失问题 |
延伸一问
截图可以作为验收证据吗？
可以作为一部分，但还应提供测试条件、数据来源及必要日志。截图本身通常不能说明完整过程。
参考资料与阅读范围
- Guide to Operational Technology (OT) Security，SP 800-82 Rev. 3 ↗
美国国家标准与技术研究院（NIST） · 2023-09-28 · 查阅日期：2026-09-10
本文为公开资料解读与方案建议；文中场景和计算示例不代表企业历史业绩。技术要求需结合设备资料与现场条件核验。 来源用于支持上文标明的背景；正文的场景分析与建议不代表来源机构的项目结论或对本站的认可。