研发平台兼容性验证报告用于记录信创环境下逐项验证的范围、条件、结果与证据，便于复核和追溯。这份模板资料提供三张可直接复制填写的表格：报告基本信息、兼容性验证明细、结论汇总，并配套字段说明、必填规则、完整填写示例和维护方法，适用于研发平台在国产操作系统、CPU、数据库等环境中的适配验证场景。
要点总览（TL;DR）
- 模板由报告基本信息、兼容性验证明细、结论汇总三张表组成，按“先定报告、再记明细、最后汇总”的顺序填写。
- 验证项按操作系统、CPU架构、数据库、中间件、浏览器与终端、外设与打印、集成接口七类拆分，环境配置记录到版本号与补丁级别。
- 验证项、环境配置、实际结果、证据编号、结论为必填；缺项标注“待补充”，不适用项标注“不适用”，均不留空。
- 结论为通过、受限、不通过时必须有可定位的证据编号；受限项需在遗留问题中写明适用条件与复验安排。
- 平台版本升级、补丁升级、新增集成接口或硬件更换后按变更类型确定复验范围，模板修改需记录版本与变更内容。
可复制空白模板：兼容性验证报告主表
模板按“先定报告、再记明细、最后汇总”的顺序组织。填写时先完成基本信息表，确认验证对象和环境边界；再逐条填写明细表，每条记录对应一个验证项在一个环境配置下的验证结果；最后根据明细统计结论汇总表。三张表使用同一套编号，明细表的证据编号与结论汇总表的统计口径能够互相对应。
表一：报告基本信息
| 字段 | 填写内容 |
|---|---|
| 报告编号 | |
| 报告名称 | |
| 验证对象（产品/平台名称） | |
| 验证对象版本号 | |
| 验证环境概述 | |
| 验证开始日期 | |
| 验证结束日期 | |
| 验证人 | |
| 审核人 | |
| 报告版本 | |
| 关联项目/需求编号 |
表二：兼容性验证明细
| 序号 | 验证项 | 验证类别 | 环境配置 | 验证方法 | 预期结果 | 实际结果 | 证据编号 | 结论 | 遗留问题 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 | |||||||||
| 4 | |||||||||
| 5 |
表三：结论汇总
| 统计项 | 数量/内容 |
|---|---|
| 验证项总数 | |
| 通过项数 | |
| 受限项数 | |
| 不通过项数 | |
| 未验证项数 | |
| 总体结论 | |
| 限制条件说明 | |
| 后续动作 | |
| 结论确认人 | |
| 确认日期 |
字段说明：每个字段记录什么、怎么填
字段口径统一，不同验证人员填出的记录才能相互比较、被审核人复核。下表按三张表的顺序说明每个字段的含义和填写要求，其中“验证项”“环境配置”“证据编号”“结论”四个字段决定报告能否被追溯，填写时需要格外注意。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 报告编号 | 报告的唯一标识 | 建议采用“项目代号-验证对象-年份-序号”格式，同一项目内不重复 |
| 验证对象与版本 | 被验证的研发平台及其版本 | 写到具体版本号；若验证的是补丁版本，一并注明 |
| 验证环境概述 | 本次验证覆盖的环境范围 | 概括列出操作系统、CPU架构、数据库、中间件等类别，详细配置写进明细表 |
| 验证项 | 一条可独立判断的验证内容 | 按“对象+动作+场景”描述，例如“平台登录页在统信操作系统下的页面渲染”，避免写成“操作系统兼容性”这类无法判断的笼统表述 |
| 验证类别 | 验证项所属的环境层次 | 从操作系统、CPU架构、数据库、中间件、浏览器与终端、外设与打印、集成接口等类别中选择；项目可按实际部署范围增删类别 |
| 环境配置 | 该验证项实际运行的环境 | 记录到版本号与补丁级别，例如操作系统发行版本、数据库小版本、中间件版本、浏览器版本；同一验证项在不同配置下验证时，拆成多行分别记录 |
| 验证方法 | 用什么操作得到结果 | 写可复现的操作步骤或检查方式，例如“安装部署后执行登录、创建项目、上传附件三项操作”，避免只写“测试” |
| 预期结果 | 验证前设定的通过标准 | 写成可观察的现象或可核对的数据，例如“页面元素完整显示，操作无报错” |
| 实际结果 | 验证中观察到的现象 | 如实记录，出现异常时写明报错信息、发生位置和复现次数 |
| 证据编号 | 支撑实际结果的证据标识 | 与截图、日志、测试记录等证据文件的编号一致，证据存放位置在报告附注或证据清单中统一说明 |
| 结论 | 该验证项的判定 | 取值为通过、受限、不通过、未验证；受限指在特定条件下可用，需在遗留问题中写明条件 |
| 遗留问题 | 未解决或需跟踪的事项 | 写明问题描述、影响范围和跟踪责任人；无遗留问题时填“无” |
| 总体结论 | 本次验证的整体判定 | 根据明细统计得出，并说明适用的环境范围；存在受限项时写明限制条件 |
| 后续动作 | 结论之后的处理安排 | 列出复验、问题修复、环境调整等动作及责任人和时间 |
必填与选填：哪些字段不能空
必填字段是支撑结论成立的最小信息集。缺少任一必填字段，该条明细就不能作为结论依据；确实无法获取时，按缺项规则标注，不能留空或凭推测填写。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 报告编号 | 必填 | 报告归档、引用和复核的唯一依据 |
| 验证对象与版本 | 必填 | 结论只对特定版本成立，缺版本则结论无法界定适用范围 |
| 验证日期、验证人 | 必填 | 确定验证时点和责任人 |
| 审核人 | 必填 | 结论需经独立复核，审核人签字后报告生效 |
| 验证项、验证类别 | 必填 | 决定验证范围和统计口径 |
| 环境配置 | 必填 | 兼容性结论依附于具体环境，缺配置则结果不可复现 |
| 验证方法、预期结果 | 必填 | 没有方法和预期标准，实际结果无法判定 |
| 实际结果 | 必填 | 结论的直接依据 |
| 证据编号 | 必填（结论为通过、受限、不通过时） | 结论必须可追溯到证据；未验证项可不填 |
| 结论 | 必填 | 填写前置条件是实际结果已记录、证据编号可定位 |
| 遗留问题 | 必填（无问题时填“无”） | 避免“空着等于没问题”的歧义 |
| 关联项目/需求编号 | 选填 | 需要与项目管理系统关联时填写 |
| 报告版本 | 选填 | 报告多次修订时填写，首次发布可省略 |
| 限制条件说明 | 选填（存在受限项时必填） | 说明受限项的具体适用条件 |
| 结论确认人、确认日期 | 选填 | 需要额外审批环节时填写 |
缺项与不适用项的标注方式需要区分：因资料缺失无法填写的，标注“待补充”并注明缺失原因和补充责任人；该验证项在当前项目中不适用的，标注“不适用”并简述理由，例如“本项目未部署中间件，该类别不适用”。两种标注都不能用空白代替，也不能用“通过”掩盖未完成验证的内容。
填写示例：一份信创环境验证记录
以下示例为演示情景，用于说明各字段的填写方式，其中的环境配置、结果和证据编号均为示意，不代表任何厂商的实际验证结论。示例假设某研发平台在国产操作系统与国产数据库组合环境下开展适配验证。
示例基本信息
| 字段 | 填写内容 |
|---|---|
| 报告编号 | XM-A-2025-001 |
| 报告名称 | 研发平台信创环境兼容性验证报告 |
| 验证对象 | 研发管理平台（演示） |
| 验证对象版本号 | V5.2.1 |
| 验证环境概述 | 国产操作系统、国产CPU服务器、国产数据库组合环境，客户端使用国产浏览器 |
| 验证日期 | 2025-03-10 至 2025-03-14 |
| 验证人 | 张工 |
| 审核人 | 李工 |
| 报告版本 | V1.0 |
| 关联项目/需求编号 | PRJ-2025-018 |
示例明细行
| 序号 | 验证项 | 验证类别 | 环境配置 | 验证方法 | 预期结果 | 实际结果 | 证据编号 | 结论 | 遗留问题 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 平台服务端安装与启动 | 操作系统 | 国产服务器操作系统（演示版本，含最新补丁） | 按部署手册安装，启动服务并检查进程状态 | 安装无报错，服务正常启动 | 安装完成，服务启动正常 | EV-01 | 通过 | 无 |
| 2 | 平台在国产CPU服务器上的基础功能运行 | CPU架构 | 国产CPU服务器（演示型号） | 执行登录、创建项目、提交任务三项操作 | 三项操作均成功，响应时间在可接受范围 | 三项操作成功，任务提交响应偏慢 | EV-02 | 受限 | 任务提交响应时间约3秒，需在性能调优后复验 |
| 3 | 数据库连接与数据读写 | 数据库 | 国产数据库（演示版本，含补丁） | 执行建表、写入、查询、备份恢复操作 | 读写正常，备份可恢复 | 读写正常，备份恢复成功 | EV-03 | 通过 | 无 |
| 4 | 平台页面在国产浏览器中的显示与操作 | 浏览器与终端 | 国产浏览器（演示版本） | 打开主要页面，检查布局、表单和附件上传 | 页面布局完整，表单可提交，附件可上传 | 页面布局完整，附件上传成功 | EV-04 | 通过 | 无 |
| 5 | 与统一身份认证系统的单点登录 | 集成接口 | 统一身份认证系统（演示版本） | 配置接口后从认证系统跳转登录平台 | 跳转成功并正确识别用户身份 | 跳转成功，用户身份识别正确 | EV-05 | 通过 | 无 |
| 6 | 报表导出打印 | 外设与打印 | 国产操作系统自带打印组件 | 导出报表并发送至打印机 | 导出文件格式正确，打印内容完整 | 导出正常，打印内容完整 | EV-06 | 通过 | 无 |
示例结论汇总
| 统计项 | 数量/内容 |
|---|---|
| 验证项总数 | 6 |
| 通过项数 | 5 |
| 受限项数 | 1 |
| 不通过项数 | 0 |
| 未验证项数 | 0 |
| 总体结论 | 在本次验证覆盖的环境配置下，平台基础功能可用；任务提交性能存在受限项 |
| 限制条件说明 | 结论仅适用于示例所列操作系统、CPU、数据库和浏览器版本；任务提交响应时间需优化后复验 |
| 后续动作 | 由性能优化负责人于两周内完成调优并安排复验，复验结果更新至本报告V1.1 |
| 结论确认人 | 李工 |
| 确认日期 | 2025-03-17 |
示例与字段说明保持一致：第2行演示了“受限”结论的写法，实际结果记录现象，遗留问题写明条件和复验安排；证据编号EV-01至EV-06对应截图和日志文件，存放位置在报告附注中统一说明。审核人复核时，按证据编号逐条核对实际结果，再确认结论汇总的统计数量与明细行数一致。
当验证记录需要多人协作时，可以把每个验证项登记为工作项，将证据文档集中存放在团队文档空间，并与项目关联。ONES 信创版适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，已与主流信创软硬件完成互信认证；官网公开页面列举的适配对象包括鲲鹏CPU、飞腾CPU、达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统。具体版本号、补丁级别和认证证书编号需向厂商索取后填入报告的“环境配置”和“证据编号”字段。ONES Wiki 可用于集中存放验证报告与证据文档，并与项目、任务等工作关联，便于审核人按编号追溯。
调整与维护方法：按项目裁剪并持续更新
模板的价值在于长期复用。项目部署范围不同，验证项需要增删；环境版本变化后，旧结论会失效，需要触发复验。维护工作围绕验证项清单、复验触发条件、模板版本和归档复核四条线展开。
按验证范围增删验证项
- 以项目实际部署架构为起点，逐层核对操作系统、CPU架构、数据库、中间件、浏览器与终端、外设与打印、集成接口七类环境，部署了哪类就保留哪类验证项。
- 未部署的环境类别标注“不适用”并写明理由，保留在模板中作为记录，便于后续项目对照。
- 新增集成接口、外设或安全组件时，同步新增对应验证项，并补充验证方法和预期结果，不能只加一行验证项名称。
- 裁剪后的验证项清单由验证负责人确认，作为本次报告的验证范围基线。
版本升级或环境变更后的复验触发条件
| 变更类型 | 复验范围 | 处理方式 |
|---|---|---|
| 研发平台版本升级 | 全部验证项 | 重新执行明细表验证，更新实际结果和证据编号，报告版本号递增 |
| 操作系统或数据库补丁升级 | 受影响类别及关联集成项 | 复验对应明细行，结论变化时同步更新结论汇总 |
| 新增中间件或集成接口 | 新增项及依赖项 | 补充验证项和方法，完成验证后纳入报告 |
| 硬件或终端更换 | CPU架构、浏览器与终端、外设与打印 | 按新配置重新记录环境配置并复验 |
| 遗留问题修复 | 对应受限项或不通过项 | 复验后更新结论，遗留问题栏注明关闭情况 |
模板版本与变更记录
| 模板版本 | 变更日期 | 变更内容 | 变更人 | 审批人 |
|---|---|---|---|---|
| V1.0 | 初始版本，含三张主表 | |||
模板本身的修改需要记录版本和变更内容，例如新增验证类别、调整结论取值、修改必填规则，都要在变更记录中说明原因。报告引用模板时注明模板版本，避免用旧模板填写的报告与新模板口径混用。
归档与复核责任
报告完成后由验证人提交、审核人复核签字，按报告编号归档，证据文件与报告一并保存。归档后如需修订，保留原版本并生成新版本，不覆盖历史记录。建议每季度检查一次已归档报告的有效性：核对验证对象版本是否仍在用、环境配置是否发生变化、遗留问题是否关闭。发现环境变更的报告，按复验触发条件安排复验。验证负责人对验证项清单和结论口径负责，审核人对证据完整性和结论一致性负责，两者分离可以保证复核的独立性。
常见问题
验证项在不同环境配置下都要验证，明细表怎么记录？
同一验证项在不同环境配置下验证时，拆成多行分别记录，每行填写对应的环境配置、实际结果和证据编号。这样结论汇总时按行统计，每个结论都能对应到一组具体配置，不会出现一行里混写多个环境、结论无法界定适用范围的情况。
验证过程中发现的问题还没解决，报告可以先出吗？
可以先出。把该验证项的结论填为“受限”或“不通过”，在遗留问题栏写明问题描述、影响范围和跟踪责任人，并在结论汇总的后续动作中列出修复与复验安排。报告版本随复验结果更新，历史版本保留，不覆盖原记录。
信创环境里操作系统或数据库打了补丁，原来的报告还有效吗？
补丁升级后，原结论对升级后的环境不再直接适用。按复验触发条件，对受影响类别及关联集成项重新验证，更新对应明细行的实际结果和证据编号；结论发生变化时同步更新结论汇总。报告版本号递增，并在变更记录中说明触发复验的原因。
报告和证据文件分散在多人手里，审核时怎么核对？
建议把每个验证项登记为工作项，证据文档集中存放在团队文档空间，报告中的证据编号与文档编号保持一致。审核人按证据编号逐条核对实际结果，再确认结论汇总的统计数量与明细行数一致。ONES Wiki 可用于集中存放验证报告与证据文档，并与项目、任务等工作关联，便于按编号追溯。
项目没有部署中间件，模板里这一类验证项怎么处理？
标注“不适用”并简述理由，例如“本项目未部署中间件，该类别不适用”，保留在模板中作为记录，便于后续项目对照。不适用项不计入通过项数，在结论汇总中单独说明，不用空白代替，也不用“通过”掩盖未验证的内容。
