在国产服务器环境上线研发平台，适配验收需要回答一个具体问题：这套平台在既定的国产软硬件组合上，能否稳定支撑研发团队的日常工作。本文给出一套可执行的验收项目制定方法，覆盖环境基线、验收分类、判定标准、证据形式与执行步骤，适用于正在做信创适配选型或上线前验证的团队。
要点总览（TL;DR）
- 适配验收的对象是研发平台在国产服务器软硬件栈上的可用性与稳定性，结论要能支撑上线决策与整改安排，业务功能需求本身的验收不在其范围内。
- 先把环境基线固定到具体版本号并留档，区分主用环境与兼容环境；验收期间冻结基线，版本变化后原结论失效需复测。
- 验收项目按功能可用、性能、数据、集成、运维、安全六类拆分，每类给出可核验的指标口径，避免只测登录和首页就宣布适配成功。
- 定量项写清公式、分子分母、时间窗、单位与阈值来源，定性项写清检查动作、证据形式与判定人；阈值由业务方与运维方共同确认，不套用通用达标线。
- 结论按阻断项、整改项、观察项三类表达，厂商适配声明与认证材料作为准入参考，最终判定以本环境实测证据为准。
适配验收要回答什么问题
适配验收的对象是研发平台在国产服务器软硬件栈上的可用性与稳定性，核心结论是“这套组合能否支撑上线”。它检验的是平台与国产 CPU、操作系统、数据库、中间件、运行时之间的配合是否成立，包括功能是否跑得通、性能是否扛得住、数据是否对得上、接口是否连得通、运维是否管得了、安全是否过得去。
验收结论要能直接支撑两类决策：一是上线与否，二是上线前需要整改哪些项。因此验收结果不能停留在“基本可用”这类描述，而要落到具体条目、具体证据和明确判定上。每一条通过或不通过，都应能指向一份日志、一张截图、一次测试记录或一组统计数据。
需要明确的是，适配验收不覆盖业务功能需求本身的验收。某个需求做得对不对、流程设计是否符合业务预期，属于产品功能验收的范畴；适配验收只关心这些功能在国产环境下是否表现一致、是否出现环境相关的异常。两者可以共用测试用例，但判定口径和结论用途不同。把边界写进验收方案，可以避免后期因“功能不满意”与“环境不适配”混在一起而难以归责。
验收范围与环境基线怎么定
验收范围含糊，结论就不可比。制定验收项目的第一步，是把环境基线固定下来，形成一份可留档的清单。基线应至少覆盖服务器 CPU 架构、操作系统发行版与版本号、数据库类型与版本、中间件、JDK 或运行时版本、客户端浏览器。每一项都要写到具体版本，只写品牌名称不足以支撑复测。
环境基线需要区分主用环境与兼容环境。主用环境是团队日常使用、承担主要负载的那套组合，验收标准最严；兼容环境是备选或过渡期的组合，验收重点在于核心流程可用。两类环境分别记录、分别判定，避免用主用环境的结论去推断兼容环境的表现。
| 基线项 | 记录内容 | 留档要求 |
|---|---|---|
| 服务器 CPU | 架构、品牌、型号 | 型号与固件版本截图 |
| 操作系统 | 发行版名称、版本号、内核版本 | 系统信息输出留档 |
| 数据库 | 类型、版本号、部署形态 | 版本查询结果留档 |
| 中间件 | 名称、版本、关键配置 | 配置文件快照 |
| JDK / 运行时 | 发行方、版本号 | 版本命令输出 |
| 浏览器 | 名称、版本、内核 | 版本信息截图 |
基线清单确定后即冻结，验收期间不随意升级或替换组件。若验收中途必须变更某一项，应记录变更时间与原因，并对受影响条目重新执行。环境版本一旦变化，原结论即失效，这一点要提前写进方案。
验收项目分几类、每类看什么指标
验收项目按六类拆分，每类给出可核验的指标口径。分类的作用是保证覆盖完整，避免只测了登录和首页就宣布适配成功。
功能可用类看核心流程通过率。先列出研发平台的关键流程，例如需求创建与流转、代码提交与关联、构建触发、测试用例执行、报表查看，再逐条在国产环境上执行，统计通过条数占应执行条数的比例。流程清单要在验收前由业务方确认，不能事后挑选。
性能类看响应时间、并发承载和资源占用。响应时间取关键操作的端到端耗时，注明统计的是平均值还是分位值；并发承载看在设定并发数下错误率与响应时间是否仍在可接受范围；资源占用记录 CPU、内存、磁盘 I/O 在典型负载下的峰值。这三项都要写明测试场景和数据规模，脱离场景的性能数字没有比较意义。
数据类看迁移或导入后的记录数与字段一致性。核对源端与目标端的记录总数、关键字段取值、附件与关联关系是否完整。数据类验收要保留核对脚本或查询语句，便于复算。
集成类看与代码仓库、CI 流水线、单点登录等外部系统的接口连通。每个接口记录调用是否成功、返回是否符合预期、异常时是否有明确错误信息。
运维类看安装部署、备份恢复、日志与监控。安装部署记录从零到可用的步骤数与耗时；备份恢复做一次真实恢复演练并核对数据；日志检查关键操作是否可追溯；监控确认核心指标是否可采集。
安全类看权限、审计、传输加密等可核验项。逐项检查角色权限是否按预期生效、关键操作是否留审计记录、传输通道是否启用加密，并保留配置证据。
每项验收的证据与通过标准怎么写
指标只有落成可判定的通过标准才有用。定量项要写清公式、分子分母、统计时间窗、单位和阈值来源。例如核心流程通过率＝通过流程数 ÷ 应执行流程数 × 100%，统计时间窗为单轮验收执行期，阈值由业务方与运维方在验收前共同确认。阈值不能套用通用达标线，不同平台、不同数据规模下的合理值差异很大，写清确认人和确认日期，比写一个漂亮数字更重要。
定性项要写检查动作、证据形式和判定人。例如“单点登录可用”应写成：使用测试账号从统一认证入口登录，检查是否免二次输入进入平台，证据为登录成功页面截图与认证日志片段，判定人为运维负责人。检查动作、证据、判定人三者齐全，结论才可复核。
分母为零或样本不足时要事先约定处理规则。应执行流程数为零说明清单本身有问题，应回到范围定义阶段；样本量过小导致比例波动大时，可约定以绝对条数判定，或延长观察窗口，并在报告中注明样本量。规则写在验收方案里，执行时照做，避免事后解释。
| 验收项 | 判定方式 | 证据形式 |
|---|---|---|
| 核心流程通过率 | 定量，比例阈值 | 逐条执行记录与截图 |
| 关键操作响应时间 | 定量，分位值阈值 | 压测报告与原始数据 |
| 数据一致性 | 定量，差异条数为零或约定上限 | 核对查询语句与结果 |
| 接口连通 | 定性，逐接口判定 | 调用日志与返回示例 |
| 备份恢复 | 定性，恢复成功且数据核对一致 | 恢复演练记录 |
| 权限与审计 | 定性，逐项检查 | 配置截图与审计日志 |
验收执行步骤与一个算例
执行顺序建议固定为：准备环境、部署平台、逐项执行、记录证据、复测、出具结论。准备阶段按基线清单核对环境并留档；部署阶段记录步骤与耗时，同时暴露安装环节的环境问题；执行阶段按验收项清单逐条推进，边执行边归档证据，避免事后补材料；复测针对未通过项和整改项，在同一环境下重跑；结论阶段汇总证据清单，形成通过、整改、观察三类结果。
以一个算例说明计算过程。假设某轮验收确定应执行核心流程 40 条，实际执行 40 条，其中 37 条通过、3 条因环境相关异常未通过，则核心流程通过率＝37 ÷ 40 × 100%＝92.5%。若约定阈值为不低于 95%，该项判定为不通过，3 条未通过流程进入整改项，整改后在同一环境复测这 3 条，复测全部通过则该项复测通过率＝3 ÷ 3 × 100%＝100%，但整体结论仍应同时记录首轮 92.5% 与复测结果，不能只报复测数字。以上数据仅作方法演示，不代表任何实际平台的表现。
接口成功率可用同样方式计算：成功调用次数 ÷ 总调用次数 × 100%，统计时间窗写明是单轮测试期还是连续若干小时。时间窗不同，结果不可直接比较，报告中必须注明。
验收项、证据和整改在执行过程中会产生大量待办与附件。这类跟踪可以放到研发管理平台里承载：把每个验收项建成工作项，关联证据文档与责任人，未通过项转为整改任务并记录复测结果，使证据清单与结论一一对应。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，并支持质量统计报表与自动生成测试报告，可用于承载适配验收的用例与结果记录，具体字段配置以实际版本为准。若平台本身部署在信创环境，ONES 信创版适配鲲鹏、飞腾 CPU，银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统以及达梦数据库，可作为环境基线核对时的参考，具体型号与版本组合仍需向厂商确认。
结果怎么解读、哪些限制要写进报告
验收结果按阻断项、整改项、观察项三类表达。阻断项指影响核心流程或数据安全、不解决不能上线的问题；整改项指可用但存在明确缺陷、需限期修复的问题；观察项指当前不影响使用、但需持续关注的风险，例如高负载下资源占用接近上限。三类分别列出条目、证据和责任人，结论才有行动指向。
单项指标不能代表整体适配水平。核心流程通过率高，不代表性能和运维项也达标；某一类全部通过，也不能推断其他类没有问题。报告应呈现分类结果和总体判定，避免用单一数字概括。
环境版本变化后结论失效需复测。操作系统打补丁、数据库升级、JDK 更换都可能改变表现，报告中要写明结论对应的基线版本和有效期，变更后按影响范围重新执行相关条目。
厂商适配声明与互信认证材料是准入参考，不能替代本环境实测。厂商声明说明产品在某一范围内做过适配，而验收要证明的是“你这套环境”下的实际表现。报告中应把厂商材料列为参考依据，把实测证据列为判定依据，两者分开呈现。ONES 信创版已与主流信创软硬件完成互信认证，并具备等级保护三级、ISO27001、SOC2 Type2 等资质，这些材料在准入阶段有参考价值，验收时仍应索取证书原件核对范围与有效期，并以本环境实测结果作为最终结论。
常见问题
验收期间环境必须升级或更换组件，已完成的条目怎么处理？
先记录变更时间、变更内容和原因，再按影响范围判断哪些条目需要重跑。操作系统打补丁、数据库升级、JDK 更换这类变更通常影响面较广，建议对功能可用、性能、集成三类条目重新执行；仅浏览器版本变化时，可先复测前端相关流程，再决定是否扩大范围。
报告中要写明每条结论对应的基线版本，变更前的数据保留但标注为旧基线结果，不能与新结果混在一起统计。
厂商提供了适配认证证书，验收时还需要做实测吗？
需要。认证材料说明产品在某一范围内完成过适配，验收要证明的是“你这套环境”下的实际表现，两者用途不同。建议把证书原件作为准入参考，核对认证覆盖的产品范围与有效期，同时按验收项清单在本环境执行实测，以实测证据作为判定依据。
如果证书覆盖的版本与你的环境基线不一致，更要以实测结果为准，并在报告中注明差异。
团队规模小、验收人力有限，六类验收项目可以裁剪吗？
可以按风险裁剪，但裁剪要有依据并写进方案。功能可用、数据、安全三类通常不建议省略，它们直接关系核心流程能否跑通和数据是否可信；性能类可先做关键操作的响应时间抽测，并发承载留到上线前压测补充；运维类至少完成一次安装部署和一次备份恢复演练。
裁剪掉的条目要在报告中列为未覆盖范围，说明后续补测计划，避免结论被误读为全部达标。
性能指标没有历史数据，阈值怎么定？
先在本环境做一轮基线测量，用实测结果作为讨论起点，再由业务方与运维方结合使用人数、数据规模和高峰时段共同确认阈值。阈值要写明确认人和确认日期，并注明对应的测试场景与数据规模。
没有基线数据时，不宜直接套用其他平台或其他环境的数字，报告中应说明阈值的确定过程，便于后续复测时对比。
验收项、证据和整改任务用什么方式跟踪比较稳妥？
核心是让每个验收项都能对应到证据和责任人。可以把验收项建成工作项，关联证据文档，未通过项转为整改任务并记录复测结果。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，并支持质量统计报表与自动生成测试报告，可用于承载适配验收的用例与结果记录，具体字段配置以实际版本为准。
如果平台本身部署在信创环境，ONES 信创版适配鲲鹏、飞腾 CPU，银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统以及达梦数据库，可作为环境基线核对时的参考，具体型号与版本组合仍需向厂商确认。
