信创适配验收要回答的问题很具体：本次声明的信创软硬件组合下，系统能否稳定运行核心业务，出现问题时能否回退和追溯。把验收拆成环境准备、功能与兼容、性能与稳定性、数据与迁移、安全与合规、运维与交付六个阶段，每项写明通过标准、证据形式和负责人，再用阻断项规则判定是否通过，结论就能复核。下文清单可直接用于到货与环境就绪后、上线前和版本升级后的适配验收。
要点总览（TL;DR）
- 信创适配验收只对本次声明的环境组合与功能范围生效，启动前先确认验收对象、时点、角色和范围边界，避免把结论扩大到未经确认的适配认证。
- 正式验收前必须齐备环境基线清单、部署包与安装文档、依赖清单、适配声明、测试账号与样例数据、回退方案，并完成环境可用性确认与变更冻结。
- 检查表按环境准备、功能与兼容、性能与稳定性、数据与迁移、安全与合规、运维与交付六个阶段组织，每项写明通过标准、证据形式、负责人和是否阻断项。
- 阻断项清零、检查项结论齐全、证据归档完成，三条同时满足才能判定通过；非阻断项需记录责任人、整改期限，影响上线使用的由业务方书面确认风险。
- 验收结论分为通过、有条件通过、不通过，遗留问题与复验任务需持续跟踪，版本升级或环境组件变更后按影响面触发复验。
验收对象、时点与参与角色
验收开始前先写清“验什么、什么时候验、谁来验”，这份清单只对本次声明的环境组合和功能范围生效。范围写宽了，验收会被拖入未确认的适配认证讨论；范围写窄了，上线后的问题又找不到责任边界。
验收对象是研发平台或业务系统在信创软硬件环境下的适配交付物，包括部署包、配置、依赖组件和配套文档。验收范围以适配声明中列出的环境组合为准，例如某类CPU架构搭配某版本操作系统、数据库、中间件和浏览器；声明之外的环境组合不纳入本次结论，需要时另行组织验收。
使用时点有三个：信创环境到货并完成基础就绪检查后，用于确认部署条件；系统上线前，用于确认业务可用；版本升级或环境变更后，用于复验受影响范围。三个时点共用同一套检查表，检查深度按变更影响面调整。
参与角色及职责如下：
| 角色 | 主要职责 | 在验收中的动作 |
|---|---|---|
| 业务方 | 确认核心业务流程与验收范围 | 提供业务场景清单，确认功能走通结果 |
| 运维 | 保障环境可用与变更受控 | 确认环境基线，执行部署，提供监控与备份记录 |
| 安全 | 独立复核安全与合规项 | 核查权限、日志、审计与安全基线，出具复核意见 |
| 供应商 | 提供适配交付物与书面材料 | 提交部署包、适配声明、测试记录与问题整改 |
| 测试负责人 | 组织测试执行与证据归集 | 按检查表逐项执行，记录结论与证据编号 |
交付物是一张验收范围与角色确认表，至少包含：验收对象名称与版本、本次覆盖的环境组合、验收时点、各角色负责人及确认签字。这张表在验收启动会上确认，后续检查项均引用其中的范围，避免验收过程中临时扩大或缩小。
验收前的环境与资料准备检查
正式验收最常见的失败原因是环境不全或资料缺失就开始测试，测出的问题无法判断是产品缺陷还是环境问题。准备阶段的目标是把这些前置条件逐项确认，全部满足后再进入功能测试。
| 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 信创环境基线清单 | CPU架构、操作系统及版本、数据库、中间件、浏览器逐项列明，与适配声明一致 | 环境基线表，含版本号与配置参数 | 运维 |
| 部署包与安装文档 | 部署包完整可校验，安装文档覆盖本次环境组合的步骤 | 部署包校验记录、安装手册 | 供应商 |
| 依赖清单 | 运行所需的系统库、组件、驱动版本明确，且与基线兼容 | 依赖清单及版本核对记录 | 供应商、运维 |
| 适配声明与兼容版本说明 | 书面材料写明支持的环境组合与已知限制 | 盖章或签字的适配说明文件 | 供应商 |
| 测试账号与样例数据 | 账号权限覆盖各角色，样例数据覆盖核心业务字段 | 账号清单、样例数据集说明 | 业务方、测试负责人 |
| 回退方案 | 明确回退触发条件、回退步骤与数据恢复方式，并演练过关键步骤 | 回退方案文档、演练记录 | 运维、供应商 |
| 环境可用性确认 | 网络、存储、中间件服务正常，基础健康检查通过 | 环境检查记录、服务状态截图 | 运维 |
| 变更冻结 | 验收期间环境配置与版本不再变更，例外需书面审批 | 变更冻结通知或审批记录 | 运维 |
准备阶段任何一项未通过，都不应进入正式验收。环境基线清单与适配声明不一致时，先澄清以哪份为准，再决定是否调整验收范围；回退方案未演练的，至少完成一次关键步骤演练并留存记录。
分阶段检查项与通过标准
以下检查表按六个阶段组织，每项都能判断“完成”或“未完成”，并标注是否为阻断项。阻断项标记为“是”的检查项未通过时，验收不能判定通过。
环境准备阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 安装部署 | 按安装文档在目标环境完成部署，无跳过步骤 | 部署记录、安装日志 | 运维、供应商 | 是 |
| 依赖齐全 | 依赖清单中组件全部就位，版本与基线一致 | 依赖核对记录 | 运维 | 是 |
| 启动检查 | 服务正常启动，日志中无阻断性错误 | 启动日志、服务状态截图 | 测试负责人 | 是 |
功能与兼容阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 核心业务流程 | 业务方确认的核心流程在信创环境完整走通，结果与预期一致 | 测试用例执行记录、结果截图 | 测试负责人、业务方 | 是 |
| 界面与交互 | 页面在指定浏览器下布局正常，关键操作可完成 | 界面截图、交互测试记录 | 测试负责人 | 否 |
| 外围集成 | 与本次范围内的接口、单点登录等集成正常 | 接口调用日志 | 测试负责人、供应商 | 视范围而定 |
性能与稳定性阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 约定负载下的响应 | 在验收方案约定的并发与数据量下，关键操作响应时间在可接受范围 | 性能测试报告 | 测试负责人 | 是 |
| 资源占用 | CPU、内存、磁盘占用在约定阈值内，无持续攀升 | 监控曲线截图 | 运维 | 否 |
| 长时运行 | 按约定时长连续运行，无异常退出、无内存泄漏迹象 | 运行日志、监控记录 | 测试负责人、运维 | 是 |
数据与迁移阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 数据导入完整性 | 导入记录数与源数据一致，抽样核对无缺失 | 导入日志、核对报告 | 测试负责人 | 是 |
| 字段对应正确 | 关键字段映射正确，编码与格式无错乱 | 字段映射表、抽样截图 | 供应商、业务方 | 是 |
| 可回退 | 按回退方案可恢复到验收前状态，数据一致 | 回退演练记录 | 运维 | 是 |
安全与合规阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 权限控制 | 各角色权限与授权矩阵一致，越权访问被拒绝 | 权限测试记录 | 安全 | 是 |
| 日志与审计 | 关键操作留痕，日志可查询、可导出 | 日志样例、审计查询截图 | 安全 | 是 |
| 安全基线 | 符合本次适用的安全基线要求，高危项已整改 | 基线核查表、整改记录 | 安全 | 是 |
运维与交付阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断项 |
|---|---|---|---|---|
| 监控 | 关键服务与资源纳入监控，告警可送达 | 监控配置截图、告警测试记录 | 运维 | 否 |
| 备份 | 备份策略已配置并完成一次恢复验证 | 备份记录、恢复验证记录 | 运维 | 是 |
| 升级与问题响应 | 升级步骤、回退路径、问题响应渠道与时限书面明确 | 运维手册、服务响应说明 | 供应商、运维 | 否 |
表中“视范围而定”的集成项，由验收范围确认表决定是否列为阻断项；列为阻断项的，未通过即影响验收结论。性能阈值和长时运行时长应在验收方案中事先约定，验收时按约定值判断，避免事后争议。
证据形式与负责人分工
验收结论以证据为准，口头说明和单次演示只能作为线索，不能作为通过依据。每项检查在表中对应一个证据编号，证据缺失的检查项按未完成处理。
常用证据类型及适用场景：
- 测试记录：功能、性能、权限类检查项，记录用例、执行时间、执行人和结果。
- 截图：界面、配置、监控状态类检查项，需包含时间或环境标识。
- 日志：部署、启动、运行、接口调用类检查项，保留原始日志文件。
- 部署记录：安装部署与依赖核对，记录步骤、版本和操作人。
- 书面确认：适配声明、回退方案、服务响应说明等由供应商出具的材料。
分工上，供应商负责提供部署包、适配说明、测试记录和整改材料；业务方确认核心流程与数据字段的业务正确性；运维确认环境基线、部署、监控、备份与回退；安全对权限、日志、审计和基线做独立复核，不复用供应商自测结论；测试负责人统一归集证据并维护证据编号与检查项的对应关系。
证据留存位置在验收启动时确定，按“验收批次—阶段—检查项编号”归档，保留期限按组织文档管理要求执行。归档后的证据不再修改，补充材料以新增版本方式记录。
阻断项与验收完成条件
阻断项是决定验收能否通过的问题，出现即暂停判定，整改并复测通过后才能继续。典型阻断项包括：环境无法完成部署或启动存在阻断错误；核心业务流程在信创环境不可用；数据导入不完整或无法回退；安全基线高危项未整改；备份未完成恢复验证。
非阻断项按问题清单记录，写明现象、影响范围、责任人和整改期限。整改期限应与上线计划匹配，影响上线后使用的非阻断项，需在上线前完成整改或由业务方书面确认接受风险。
复测与回归确认方式：阻断项整改后，由原检查项的负责人按同一通过标准复测，并补充新证据；涉及代码或配置变更的，回归受影响的核心流程和相关检查项，回归范围在问题清单中注明。
验收完成条件同时满足三条：阻断项全部清零并有复测记录；所有检查项均有明确结论（通过、不通过或经批准的风险接受）；证据按归档要求完成归集。三条缺一，验收结论不能记为通过。
验收结论记录与后续跟踪
验收结束后形成一份结论记录，状态分为三种：通过，表示阻断项清零、检查项结论齐全、证据归档完成；有条件通过，表示阻断项已清零，但存在经业务方书面确认接受风险的非阻断项，需附整改期限；不通过，表示存在未清零的阻断项或关键证据缺失。
结论记录至少包含：验收对象与版本、覆盖的环境组合、验收时点、各阶段检查项统计、阻断项及整改情况、遗留问题清单、结论状态和签字确认。遗留问题清单逐条写明问题描述、责任人、整改期限和复验方式。
复验触发条件包括：版本升级、操作系统或数据库等环境组件变更、部署架构调整、以及遗留问题整改完成后的确认。复验范围按变更影响面确定，至少覆盖受影响阶段的核心检查项。
验收记录、遗留问题和复验任务需要在团队日常使用的协作平台中流转，避免结论停留在个人文档里。ONES 可以把验收检查项建成工作项，关联证据附件和负责人，遗留问题按整改期限跟踪状态，版本升级后按复验触发条件重新发起检查，使验收结论、整改过程和复验记录保持在同一处可查。是否采用平台承载，取决于团队已有的协作方式；关键是验收记录能被后续复验直接引用，而不是每次重新收集。
常见问题
验收过程中环境配置被临时调整了，之前的测试结果还算数吗？
验收启动时应完成变更冻结，验收期间环境配置与版本不再变更。如果确实需要调整，先走书面审批，并评估调整影响哪些检查项：涉及环境基线、依赖版本或部署架构的，受影响阶段的检查项需要重新执行并补充新证据；仅涉及与检查项无关的配置，可在记录中说明后沿用原结论。判断标准是变更是否改变了检查项的前提条件，改变了就要复测。
供应商提供了适配声明，但声明里的环境组合和实际部署环境不完全一致，怎么处理？
先澄清以哪份材料为准，再决定验收范围。实际部署环境超出适配声明覆盖范围的，本次验收只对声明内的组合出具结论，超出部分另行组织验收或由供应商补充书面说明。声明中的已知限制要逐条对照检查项，确认是否影响核心业务流程；影响核心流程的限制，应按阻断项处理，不能以“声明里已写明”为由直接放行。
性能与稳定性没有事先约定阈值，验收时怎么判断通过？
性能阈值和长时运行时长应在验收方案中事先约定，验收时按约定值判断。如果启动验收时仍未约定，先由业务方、运维和供应商共同确认可接受的并发量、数据量、响应时间和资源占用上限，形成书面记录后再执行测试，避免测试完成后因标准不一致产生争议。约定值应结合真实业务负载设定，并写清测试条件，便于复验时对照。
非阻断项在验收时没有整改完，可以判定通过吗？
可以判定为有条件通过，前提是阻断项已全部清零，且非阻断项经业务方书面确认接受风险并附整改期限。影响上线后使用的非阻断项，需在上线前完成整改，或由业务方明确接受风险。整改完成后按原检查项复测并补充证据，遗留问题清单同步更新状态。阻断项未清零的，只能判定不通过。
版本升级后需要重新做全量验收吗？
复验范围按变更影响面确定，至少覆盖受影响阶段的核心检查项。版本升级通常涉及功能与兼容、数据与迁移阶段，环境组件变更还会影响环境准备和性能稳定性阶段；部署架构调整则需关注运维与交付阶段。全量复验适用于环境组合整体更换或影响面无法判断的情况。复验触发条件和范围建议在验收结论记录中事先写明，升级后直接引用。
