研发平台兼容性验证要围绕信创目标环境建立一套可复现的流程：先锁定操作系统、CPU架构、数据库、中间件、浏览器与运行时等环境基线，再把平台拆成可验证的功能与集成点，逐项设计用例并在目标环境执行，记录证据与缺陷，最后形成验证报告和准入结论。只做一次安装演示就判定兼容，往往会在上线后暴露问题；把“环境基线、验证项、用例、证据、结论”五类信息固定下来，验证结果才可复现、可追溯。
要点总览（TL;DR）
- 验证前先冻结环境基线：操作系统、CPU架构、数据库、中间件、浏览器与运行时都记录到实际版本号，确保他人能据此复现同一环境。
- 验证对象按安装部署、核心功能、权限组织、报表导出、接口集成五层拆解，集成点单独列清单并写明对接系统与责任人。
- 执行按环境搭建、安装初始化、功能用例、集成点验证、缺陷复测与报告五步推进，每步有输入、输出和完成标志。
- 验证结论只对报告中记录的环境组合有效；版本升级或补丁变更后需评估影响并重跑相关用例。
- 把环境基线、用例、缺陷和报告纳入研发管理平台留痕，形成用例到缺陷再到复测的可追溯链路。
先定验证范围：环境基线、平台组件与集成点
验证开始前，先把“在什么环境验证什么”写成一张表。范围不清会导致两种常见浪费：环境版本反复变更，已执行的用例作废；验证对象遗漏，集成点在上线后才暴露问题。范围表建议由平台运维与测试负责人共同确认，经架构或技术负责人审核后冻结，后续变更走记录。
环境基线字段
环境基线要记录到可复现的程度，即他人依据这张表能搭出同样的环境。建议至少包含以下字段，并注明实际版本号而非产品名称：
| 类别 | 记录字段 | 填写要求 |
|---|---|---|
| 操作系统 | 发行版名称、版本号、内核版本、CPU架构 | 区分服务器端与客户端，注明是物理机、虚拟机还是容器环境 |
| 数据库 | 产品名称、版本号、字符集、部署模式 | 注明是否主备或集群，连接参数与驱动版本一并记录 |
| 中间件 | Web容器、消息队列、缓存等组件及版本 | 记录关键配置项，如端口、线程数、超时设置 |
| 浏览器 | 浏览器名称、版本号、内核版本 | 列出实际使用的全部浏览器，含国产浏览器及其兼容模式 |
| 运行时 | JDK或其他运行时版本、启动参数 | 记录内存参数、编码设置等影响行为的配置 |
平台侧验证对象
平台侧按“能否装起来、能否用起来、能否连起来”三层拆解验证对象：
- 安装部署：安装包完整性、依赖组件检查、初始化脚本、升级与回滚路径。
- 核心业务功能：按业务主流程选取高频功能，覆盖创建、编辑、查询、流转等基本动作。
- 权限与组织：用户、角色、组织结构的创建与授权，跨角色访问的权限边界。
- 报表与导出：统计报表生成、大数据量导出、文件格式在目标浏览器中的打开效果。
- 接口与集成：平台对外提供的接口、平台调用的外部接口，以及数据在两个系统间的流向。
集成点清单
集成点单独列清单，每个集成点写明对接系统、协议方式、认证方式和责任人。常见集成点包括代码仓库、CI/CD流水线、单点登录、消息通知和第三方业务接口。信创环境下，单点登录和消息通知往往涉及证书、加密算法或国产中间件，需要优先纳入验证。
明确排除项
范围表要写明本轮不验证的内容，例如尚未上线的模块、非目标环境的组合、性能与容量指标。排除项不是永久不做，而是本轮不纳入结论，避免验证报告被误读为覆盖全部场景。
本节交付物为《兼容性验证范围与环境基线表》，包含环境字段、验证对象清单、集成点清单和排除项，经评审后作为后续执行的依据。
核心验证步骤：从环境搭建到结论输出
验证按顺序推进，每一步都有明确的输入、动作、输出和完成标志。完成标志未达成时不进入下一步，避免问题层层叠加后难以定位。
步骤一：搭建目标环境并记录环境快照
输入是范围表中的环境基线。动作是按基线搭建服务器、数据库、中间件和客户端环境，安装完成后逐项核对实际版本与配置。输出是环境快照，包括版本信息、关键配置、网络拓扑和账号说明。完成标志是快照内容与基线表逐项一致，差异项已记录原因。
步骤二：执行安装与初始化
输入是安装包、部署文档和环境快照。动作是按文档执行安装、初始化数据库、导入基础数据、启动服务。过程中记录依赖缺失、脚本报错、编码异常、权限不足等所有异常，即使最终通过也要记录处理方式。输出是安装记录与异常清单。完成标志是服务正常启动，管理员可登录，初始化数据完整。
步骤三：按功能清单执行核心用例
输入是验证对象清单和设计好的用例。每条用例写明前置条件、操作步骤、预期结果。执行时记录实际结果、通过或失败、截图与日志位置。失败用例要记录报错信息和复现步骤。输出是功能用例执行记录。完成标志是清单内用例全部执行完毕，每条都有明确结论。
步骤四：验证集成点连通性与数据流向
输入是集成点清单。动作是逐个验证对接：单点登录能否完成认证、代码提交能否触发流水线、消息能否送达、接口调用返回是否符合预期。除连通性外，还要验证数据流向的正确性，例如字段映射、编码转换、时间格式。输出是集成点验证记录，含接口地址、请求与返回示例、异常处理方式。完成标志是清单内集成点全部有验证结论。
步骤五：汇总缺陷、复测并形成报告
输入是功能与集成验证记录。动作是将失败项登记为缺陷，标注严重程度与影响范围，由研发修复后安排复测，复测记录关联原缺陷。全部缺陷处理完毕后汇总形成验证报告，给出准入结论：通过、有条件通过或不予通过。有条件通过须写明遗留风险、影响范围和风险接受人。完成标志是报告经评审签字，结论与证据可对应。
本节交付物为《兼容性验证执行记录》与《兼容性验证报告（含准入结论）》。执行记录按步骤留存，报告在执行记录基础上汇总，两者不互相替代。
角色分工与交付物：谁验证、谁签字、谁修复
兼容性验证跨运维、测试、研发和业务多个角色，职责不清时最容易出现“环境没人管、缺陷没人复测、结论没人签字”。建议在验证启动时确定各角色和交接时点，并写入范围表。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 平台运维/环境负责人 | 按基线搭建环境、记录版本与配置、维护环境稳定 | 环境快照、环境变更记录 | 环境搭建完成后移交测试；验证期间环境变更须通知测试 |
| 测试负责人 | 设计用例、组织执行、登记缺陷、跟踪复测 | 用例集、执行记录、缺陷清单 | 执行完成后移交研发修复；复测完成后提交报告 |
| 研发负责人 | 分析缺陷原因、修复、配合复测 | 缺陷修复说明、修复版本 | 修复完成后通知测试复测 |
| 架构或技术负责人 | 确认集成点验证方案、主持准入评审 | 集成验证结论、评审意见 | 报告提交后组织评审并签字 |
| 业务代表 | 确认核心业务功能在目标环境下可用 | 业务验收确认意见 | 功能用例执行完成后确认 |
分工中有两个边界需要提前说清：环境问题由运维定位，平台功能问题由研发定位，测试负责记录现象和复现步骤，不承担根因判断；风险接受由业务或技术负责人书面确认，测试不代替业务接受风险。交接时点建议与步骤节点对齐，每次交接留下记录，便于回溯。
示例：一次数据库与浏览器替换的验证记录
以下为演示情景，用于说明记录字段的填写方式，具体产品与版本以实际项目为准。
环境基线与验证项填写
场景设定为将平台使用的数据库和客户端浏览器替换为目标信创版本。基线表填写示例：操作系统记录发行版与内核版本；数据库记录产品名称、版本号、字符集和部署模式；浏览器记录名称、版本号和内核版本；运行时记录JDK版本与启动参数。验证项勾选安装部署、核心业务功能、报表导出、单点登录四项，排除项写明本轮不验证性能容量。
一条功能用例的执行记录
| 字段 | 内容示例 |
|---|---|
| 用例编号 | FUNC-012 |
| 前置条件 | 已使用管理员账号登录，目标浏览器为新版本，数据库中已有测试项目数据 |
| 操作步骤 | 进入项目报表页，选择按状态统计，点击导出为表格文件 |
| 预期结果 | 报表正常渲染，导出文件可打开，数据与页面一致 |
| 实际结果 | 报表渲染正常；导出文件在目标浏览器中打开时中文列名显示为乱码 |
| 结论 | 失败，登记缺陷，附截图与导出文件 |
一条集成点验证记录
集成点记录示例：接口为单点登录回调，请求方式与参数按对接文档填写，返回结果为认证成功并跳转至平台首页；异常处理记录为证书链不完整时登录失败，补充证书后复测通过。记录中保留请求与返回的关键字段，便于后续排查。
缺陷登记与复测闭环
上述导出乱码登记为缺陷，写明环境、复现步骤、影响范围（仅影响导出文件，页面显示正常）和严重程度。研发修复后提交修复版本，测试在同一环境复测，复测记录关联原缺陷编号，结论为通过。复测通过后缺陷关闭，报告中引用该缺陷编号作为证据。
从示例可迁移的写法规律是：每条记录都能独立复现，包含环境、前置条件、操作、预期、实际和结论；缺陷与用例、复测之间用编号关联，报告只引用编号，不重复粘贴细节。
完成检查：判定验证通过的条件与证据
验证是否结束，按以下清单逐项核对。任一项不满足时，结论应为有条件通过或不予通过，并写明遗留事项。
| 检查项 | 通过标准 | 证据要求 |
|---|---|---|
| 环境基线 | 基线表已记录，与实际环境逐项一致，差异有说明 | 环境快照、版本核对记录 |
| 核心功能用例 | 清单内用例全部执行，每条有通过或失败结论 | 用例执行记录、截图与日志 |
| 集成点验证 | 清单内集成点全部验证，连通性与数据流向有结论 | 接口请求与返回记录、异常处理说明 |
| 缺陷处理 | 缺陷已修复并复测通过，或已明确风险接受人与接受范围 | 缺陷记录、复测记录、风险接受确认 |
| 验证报告 | 报告已评审，给出准入结论与适用范围 | 评审记录、签字意见 |
| 证据可追溯 | 用例、日志、截图与报告条目一一对应 | 编号索引或关联关系 |
需要提醒的是，验证结论只对报告中记录的环境组合有效。环境版本升级、数据库补丁变更或浏览器大版本更新后，应评估影响范围，必要时重新执行相关用例，而不是沿用原结论。
把验证过程纳入研发管理：记录、评审与留痕
验证过程涉及大量工作项、文档和评审节点，散落在个人电脑和聊天记录里，复测和审计时很难还原。把验证纳入研发管理平台，重点解决三件事：工作项可追踪、文档有版本、评审有留痕。
具体承载方式可以这样设计：环境基线作为独立工作项或文档记录，每次环境变更更新版本并注明变更人；验证用例按功能模块建立工作项，执行结果以状态和附件形式记录；失败用例直接创建缺陷任务并关联原用例，复测时在缺陷下追加记录，形成用例到缺陷再到复测的链路；验证报告作为文档管理，评审意见和准入结论在评审节点留存，报告版本与评审记录对应。
ONES 在需求、任务、缺陷、文档与评审流转中提供承载能力，可用于上述管理动作。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环，未通过的用例可快速创建缺陷任务，这与验证记录中“用例—缺陷—复测”的关联需求相对应。对于信创环境本身，ONES 信创版已完成全栈信创适配，适配信创主流基础软硬件，覆盖芯片、操作系统、数据库等核心模块，并已与主流信创软硬件完成互信认证；官网列出的适配项包括鲲鹏 CPU、飞腾 CPU、达梦数据库，以及银河麒麟、麒麟信安、统信、OpenEuler、龙蜥等操作系统。这些信息可作为确定验证范围的输入，具体版本组合与认证清单仍需向厂商逐项确认，并以本地目标环境的实测结果作为准入依据。
工具承载的是记录与流转，验证方法本身不变：环境基线、验证项、用例、证据、结论五类信息固定下来，无论用哪种方式管理，都应保证他人能依据记录复现验证过程、依据证据复核结论。
常见问题
信创环境里组件版本升级后，之前的兼容性验证结论还能用吗？
验证结论只对报告中记录的环境组合有效。操作系统补丁、数据库小版本升级或浏览器大版本更新后，建议先评估变更影响范围：涉及运行时、驱动或加密算法的变更，通常需要重跑安装部署与集成点用例；仅界面层变更，可重跑受影响的报表与导出用例。评估结论和重跑范围写入环境变更记录，与原报告关联，避免沿用旧结论造成误判。
厂商页面列出了适配的操作系统和数据库，是否还需要在本地重新验证？
需要。厂商适配清单可以作为确定验证范围的输入，但清单通常只列产品名称，具体版本号、补丁级别和组合方式仍需逐项确认。本地目标环境的实测结果才是准入依据，尤其是数据库字符集、浏览器兼容模式、单点登录证书链这些容易在具体配置下出问题的环节。建议把厂商清单与本地基线表对照，差异项单独标注并优先验证。
验证过程中发现的问题，怎么区分是环境问题还是平台缺陷？
建议按现象定位责任方：服务无法启动、依赖缺失、端口冲突、证书配置错误，先由环境负责人排查环境侧；功能报错、数据计算错误、页面渲染异常，在环境确认无误后登记为平台缺陷。测试负责记录现象、复现步骤和日志，不承担根因判断。定位过程中若发现是环境配置导致，也应在记录中写明处理方式，避免同一现象被重复登记。
有条件通过的结论需要写清楚哪些内容？
有条件通过至少要写明三项：遗留问题清单及对应的缺陷编号、每个遗留问题的影响范围（涉及哪些功能、哪些用户角色、是否影响主流程）、风险接受人和接受时间。风险接受应由业务或技术负责人书面确认，测试不代替业务接受风险。报告评审时同步确认遗留问题的后续处理计划，例如在哪个版本修复、修复后是否需要补充复测。
验证用例和缺陷数量较多时，如何保证证据可追溯？
关键是建立编号关联：用例有唯一编号，失败用例创建缺陷时在缺陷中引用用例编号，复测记录再关联缺陷编号，报告只引用编号不重复粘贴细节。用例执行时同步保存截图与日志，并在记录中写明文件位置或附件关联。借助测试管理工具承载时，用例与需求、任务关联，测试计划与迭代关联，未通过的用例可直接创建缺陷任务，链路在系统内自然形成，复测和审计时按编号即可还原全过程。
