确定信创适配验收要求，核心是把“适配”拆成可核验的对象：运行环境、关键业务路径、性能与稳定性、数据与接口、运维与安全，再为每类对象定义指标、取数口径、证据形式和通过标准，形成一张可复算的验收表。本文按这一思路给出指标分类、口径写法、执行步骤和填写示例，适用于为某套系统在指定信创环境下建立验收要求；具体竞品替换、迁移方案和未经核实的认证结论不在本文范围内。
要点总览（TL;DR）
- 信创适配验收要求由五类可测项构成：环境适配、功能适配、非功能表现、数据与接口、运维与安全，每类都要落到指标名、单位与采集方式。
- 每项指标写全统计对象、分子、分母、时间窗、单位、采样方式六个口径要素，并约定分母为零、数据缺失和不可比情形的处理规则。
- 验收按五步执行：冻结环境与业务基线、按口径采集并留存证据、计算对照通过标准、处理不通过与例外项、形成结论与遗留问题清单。
- 通过标准结合业务实际确定，功能类以关键路径全部通过为条件，非功能类由业务方与运维方共同确认阈值，定性项用证据齐全加判定规则替代。
- 验收结论只覆盖已验证的环境组合与业务范围，环境升级或版本变更后需重新验证，指标达标需结合日常监控与回归补充。
验收要回答什么问题：目标与边界
信创适配验收要回答的是一个有限问题：目标系统在指定的信创环境组合下，能否正常运行、走通关键业务、并被运维团队接住。验收结论应能支撑“这套环境组合可以进入下一阶段”的判断，而不是回答“这个产品是否值得选型”或“能否替代某个现有系统”。把目标收窄，后面的指标才不会无限膨胀。
验收目标建议写成三条可检验的陈述：其一，系统在约定环境组合下可安装、可启动、可登录；其二，约定的关键业务路径能完整执行并得到正确结果；其三，部署、升级、备份恢复、日志与权限等运维动作可执行。三条分别对应运行、业务、运维三个层面，缺一条都会让验收结论失真。
范围需要同时锁定四个维度：环境组合（CPU 架构、操作系统、数据库、中间件、浏览器或客户端版本）、业务功能范围（哪些模块和路径纳入、哪些暂不纳入）、非功能范围（响应时间、并发、稳定性、资源占用是否纳入及纳入程度）、时间窗（验收覆盖的日期区间与数据采集周期）。范围清单越具体，验收时越不容易被“顺便也测一下”拖成无边界测试。
边界也要提前写明。具体竞品替换与迁移方案属于其他主题，本文不展开；厂商宣传中的适配认证，在拿到证书清单和版本号并逐项核对之前，只能作为环境清单的输入，不能直接写成验收结论。验收文档中应区分“已核验事实”和“待核验声明”，避免把宣传口径当成通过依据。
本节交付物是一页验收目标与范围说明，至少包含环境清单（每项写明产品名与版本号）和业务范围清单（模块、路径、纳入与否）。这一页是后续所有指标和口径的锚点，签字确认后再进入指标设计。
指标与范围：把适配拆成可测项
适配验收的指标不宜按“功能点数量”笼统统计，而应按对象分类定义，每类指标回答一个独立问题。下表给出五类指标及其定义方式，可作为指标分类表的骨架。
| 指标类别 | 回答的问题 | 典型指标 | 单位与采集方式 |
|---|---|---|---|
| 环境适配类 | 系统能否在目标环境组合上安装并启动 | 安装成功率、启动成功率、环境组合覆盖数 | 次数、组合数；安装记录与启动日志 |
| 功能适配类 | 关键业务路径能否走通、结果是否正确 | 关键路径通过率、边界功能通过数、报错与降级表现 | 条、次；测试记录与截图 |
| 非功能类 | 在目标环境下性能与稳定性是否可接受 | 响应时间、并发用户数、连续运行时长、CPU 与内存占用 | 毫秒、个、小时、百分比；压测报告与监控数据 |
| 数据与接口类 | 数据读写是否正确、接口是否连通且字段一致 | 数据一致性校验通过率、接口连通率、字段一致率 | 条、百分比；比对脚本结果与接口返回 |
| 运维与安全类 | 能否部署、升级、恢复，权限与审计是否可用 | 部署成功次数、备份恢复成功率、日志完整性、权限与审计项通过数 | 次、项；操作记录与日志 |
环境适配类指标的关键是“组合”而非“单项”。CPU 架构、操作系统、数据库、中间件、浏览器各自通过，不等于组合通过；验收表应列出实际验证的环境组合，并标注每个组合的验证结论。功能适配类要区分主路径与边界功能：主路径决定业务能否开展，边界功能（如大批量导入、特殊字符、超长字段）决定异常时是否可控。非功能类指标必须写明测试条件，包括数据量、并发模型和运行时长，否则数字之间无法比较。
数据与接口类指标容易被忽略。验收时应至少覆盖一次完整的数据写入、读取、更新和删除，以及关键接口的连通与字段映射核对。运维与安全类指标则以“动作能否完成”为主，部署、升级、备份恢复各执行一次并留存记录，日志、权限、审计按项核对。每类指标在分类表中都要有指标名、对象、单位、采集方式四列，缺采集方式的指标不进入验收表。
数据口径与证据：每个指标怎么取数、拿什么证明
口径的作用是让不同环境、不同批次的数据可以放在一起比较。每项指标至少写明六个要素：统计对象、分子、分母、时间窗、单位、采样方式。以“关键路径通过率”为例，统计对象是纳入范围的关键路径条目，分子是通过的条目数，分母是纳入范围的条目总数，时间窗是本次验收执行周期，单位是百分比，采样方式是逐条执行并记录结果。六个要素写全，换一个人复算也能得到同一结果。
证据形式要与指标匹配。功能类指标以测试记录、截图和问题单为主；非功能类以压测报告和监控数据为主；数据与接口类以比对结果和接口返回报文为主；运维类以操作记录和日志为主。证据应能定位到具体时间、环境和执行人，仅有“已测试通过”的结论性描述不足以支撑验收。
缺失值和分母为零要提前约定规则。分母为零时，该指标记为“不适用”并注明原因，不按 0% 或 100% 计入汇总；数据缺失时，区分“未采集”和“采集失败”，前者补采，后者记录原因并评估是否影响结论。不可比情形要显式标注，例如环境版本不同、数据量级不同、并发模型不同，标注后再决定是分组比较还是单独说明，避免把不可比的数据强行平均。
| 指标 | 分子 | 分母 | 时间窗 | 证据 | 缺失处理 |
|---|---|---|---|---|---|
| 关键路径通过率 | 通过的路径条目数 | 纳入范围的路径条目总数 | 验收执行周期 | 测试记录、截图、问题单 | 未执行为未采集，补测；执行失败计入分母不计入分子 |
| 接口连通率 | 连通且字段一致的接口数 | 纳入核对的接口总数 | 单轮核对 | 接口返回报文、字段映射表 | 接口未部署记为不适用并注明 |
| 备份恢复成功率 | 恢复成功的次数 | 执行的恢复次数 | 验收执行周期 | 操作记录、恢复后校验日志 | 未执行则该项不进入结论 |
通过标准应结合业务实际确定，本文不给出通用达标线。功能类通常以“纳入范围的关键路径全部通过、边界功能问题有明确处置”为通过条件；非功能类以业务高峰期的可接受响应和稳定运行时长为条件，具体数值由业务方与运维方共同确认并写入验收表。定性项没有数值阈值时，用“证据齐全 + 判定规则”替代，例如日志完整性以“约定字段齐全、可追溯到操作人”为通过标准。
计算与评估步骤：从口径到通过判定
验收执行可以按五步推进，每一步都有明确产物，便于交接和复测。
- 确定环境基线与业务基线。环境基线记录每项软硬件的产品名与版本号，业务基线记录纳入范围的模块、路径和数据量级。基线确认后冻结，验收期间变更需记录并评估影响。
- 按口径采集数据并留存证据。逐项执行测试，同步保存测试记录、日志、截图和接口返回，证据按指标编号归档，保证后续可定位。
- 计算各指标并对照通过标准。按口径计算分子分母，分母为零的记为不适用，不可比的数据分组呈现，再逐项判定通过与不通过。
- 处理不通过项、例外项与复测。不通过项登记问题单，明确责任人和修复期限；例外项写明原因和影响范围；修复后在相同基线下复测，复测结果单独记录，不覆盖首轮数据。
- 形成验收结论与遗留问题清单。结论按环境组合和业务范围分别给出，遗留问题列明当前状态、影响和后续验证计划。
判定规则要在执行前写清楚：全部关键项通过为通过；关键项存在不通过但已有明确修复计划且不影响业务开展的，可判为有条件通过，并附条件清单；关键项不通过且无可行处置的，判为不通过。非关键项的失败记录在遗留问题中，不单独改变总体结论。这样判定可以复现，也便于不同批次之间对比。
验收项、证据和遗留问题需要在团队之间流转。以 ONES 为例，可以把每条验收指标建成工作项，关联测试记录和问题单，验收文档随版本更新保留历史，评审时按工作项状态核对通过情况。ONES 信创版适配鲲鹏、飞腾 CPU，银河麒麟、统信等操作系统以及达梦数据库等基础软硬件，并已与主流信创软硬件完成互信认证；具体认证对象与版本清单仍需向厂商索取后逐项核对，作为环境基线的输入。
例子：一条关键业务路径的验收表怎么填
以下为演示情景，数值仅用于说明填写方式，不代表任何产品的实际表现。假设验收对象是“工单创建并流转至关闭”这条关键路径，环境为某一组已确认的信创环境组合。
| 项目 | 填写内容 |
|---|---|
| 验收对象 | 工单创建并流转至关闭，在指定信创环境组合下执行 |
| 指标 | 路径成功率、单次操作响应时间、数据一致性 |
| 口径 | 成功率＝成功完成全流程的次数÷执行总次数，执行 20 次；响应时间取每次提交至页面返回的耗时，单位毫秒，记录中位数与最大值；数据一致性＝字段核对一致的记录数÷核对记录总数 |
| 证据 | 逐次测试记录、操作截图、应用日志、数据库核对结果 |
| 通过标准 | 20 次全部成功；响应时间在业务确认的可接受范围内；核对记录全部一致 |
| 不通过处置 | 登记问题单，定位环境差异或版本问题，修复后在相同基线下复测 20 次，复测结果单独记录 |
这张表的关键在于每个数字都能追溯：成功次数来自逐次记录，响应时间来自日志时间戳，一致性结论来自字段核对。若某次执行因环境未就绪而中断，应记为未采集并补测，不计入成功率分子，也不从分母中剔除，除非事先约定该情形属于不适用并写明原因。
解读与限制：结论怎么用、哪些不能保证
验收结论只覆盖已验证的环境组合与业务范围。换一个操作系统版本、升级数据库、调整中间件配置，都可能改变结果，需要重新验证或至少做回归。结论中应写明环境基线版本和业务范围，超出这个范围的推断不成立。
指标达标不等于长期稳定。验收是在特定时间窗和数据量下采集的，生产环境的并发模式、数据增长和运维操作会带来新问题。建议把验收指标接入日常监控，在版本变更后执行回归，用持续数据补充单次验收的结论。
通过标准应结合业务实际确定，不同系统、不同业务高峰的合理阈值不同，套用统一数值容易得出误导性结论。验收表还应保留例外项和遗留问题，说明哪些能力尚未验证、哪些问题待修复，让结论的使用者清楚边界。厂商提供的适配清单和互信认证可以作为环境基线的输入，具体版本与证书仍需逐项核对后再写入验收文档。
常见问题
验收时环境组合很多，是否每个组合都要跑完全部指标？
不必对每个组合执行全部指标，但需要事先分层。建议把环境组合分为主用组合和备用组合：主用组合执行完整指标集，包括关键路径、非功能、数据接口和运维动作；备用组合至少执行安装启动、关键路径和一次数据读写核对。分层规则写入验收范围说明，并注明每个组合实际执行的指标条目，避免出现“组合已覆盖”但关键路径未验证的情况。
关键路径执行中途因环境未就绪中断，这次执行算不算失败？
按事先约定的口径处理。若中断原因是环境未就绪、依赖服务未启动等非被测对象问题，记为“未采集”，补测后以补测结果计入；若中断由被测系统自身报错引起，计入分母但不计入分子，按不通过处理。两种情形都要在测试记录中写明中断时间、现象和判定依据，避免事后争议。规则应在验收执行前写入口径表，执行中不临时更改。
厂商提供的适配清单和互信认证，能直接作为验收通过依据吗？
可以作为环境基线的输入，不能直接作为验收结论。需要向厂商索取认证对象与版本清单，逐项核对是否覆盖本次验收的环境组合和版本号，核对结果写入环境基线。验收通过与否仍以本次在目标环境下的实际执行结果为准。以 ONES 信创版为例，其适配鲲鹏、飞腾 CPU，银河麒麟、统信等操作系统以及达梦数据库等基础软硬件，并已与主流信创软硬件完成互信认证；具体认证对象与版本仍需按上述方式核对。
有条件通过的结论在什么情况下可以使用？
有条件通过适用于关键项存在不通过、但已有明确修复计划且当前不影响业务开展的情形。使用时需附条件清单，逐条写明不通过项、影响范围、修复责任人和完成期限，并约定复测方式。若关键项不通过且没有可行处置方案，应判为不通过。条件清单中的事项完成后，在相同基线下复测并单独记录结果，不覆盖首轮数据，便于追溯结论变化。
验收通过后，环境小版本升级是否需要重新验收？
取决于变更影响面。操作系统、数据库、中间件的小版本升级可能改变驱动、依赖库或配置行为，建议至少执行关键路径回归和数据读写核对；涉及 CPU 架构、操作系统大版本或数据库主版本变更时，按新一轮验收处理，重新冻结基线并执行完整指标集。无论哪种情形，变更都应在验收文档中记录版本差异，并说明本次验证覆盖的范围，避免用旧结论覆盖新环境。
