信创与国产化适配的验证，需要围绕基础环境兼容、功能完整性、性能与容量、集成与接口、数据一致性与迁移、运维与安全六类项目展开。验证前先确定目标环境组合与判定标准，再按统一口径取数、留证，最后给出通过、有条件通过或不通过的结论。本文给出一套可逐项核对、可复算的评估清单与判定规则。
要点总览（TL;DR）
- 信创适配验证围绕六类项目展开：基础环境兼容、功能完整性、性能与容量、集成与接口、数据一致性与迁移、运维与安全，验证前先确定目标环境组合与判定标准。
- 兼容与功能通过率按“通过用例数 ÷ 有效用例总数”计算，因环境不具备而未执行的用例不计入分母，单独标注为未验证。
- 性能指标以基线环境为参照计算相对变化率，阈值在测试前结合业务高峰要求约定，不套用统一数字。
- 判定分通过、有条件通过、不通过三档，核心业务路径不可用、数据迁移一致性错误等阻断项出现即判不通过，单项通过率高不能抵消阻断项。
- 结论只说明记录环境组合与用例范围内的达标情况，环境要素变化后需重新评估，未验证项写“本次未验证”，不写成不支持。
验证目标：信创适配要回答哪几个问题
信创适配验证的对象是“软件在目标国产环境组合下能否正常承担业务”，验证范围由CPU架构、操作系统、数据库、中间件、浏览器等基础软硬件的组合决定。同一款产品在不同组合下的表现可能不同，因此验证开始前要先列出本次要覆盖的环境矩阵，明确哪些组合必测、哪些组合只在条件具备时抽测。
围绕这个对象，验证要回答四类问题：
- 能不能跑：安装部署是否成功，服务能否正常启动，依赖组件是否齐备。
- 跑得对不对：核心业务路径在国产环境下是否与基线环境等价可用，计算结果、页面展示、流程流转是否正确。
- 跑得够不够快：在目标硬件与国产数据库下，响应时间、并发吞吐、批量处理耗时是否满足约定阈值。
- 运维管不管得住：日志、监控、备份恢复、权限控制是否可用，部署与升级是否可重复执行。
需要区分的是，适配验证回答“在既定环境下是否可用、是否达标”，竞品替换与迁移选型回答“换成谁、怎么换、换的代价多大”。后者涉及功能对标、迁移工作量、许可成本等更广的判断，属于另一项工作。把两者混在一次测试里，容易让适配结论承担它无法支撑的决策责任。
验证项目与指标范围：六类项目怎么拆
六类项目各自对应不同的指标和适用环境，下表给出项目、指标、单位与适用环境的对照，可作为逐项评估的底表。表中指标是建议口径，实际项目可按业务特点增减，但增减要在测试前确定并记录。
| 项目类别 | 典型指标 | 单位/形式 | 适用环境 |
|---|---|---|---|
| 基础环境兼容 | 安装成功率、启动成功率、依赖组件满足率、兼容通过率 | 百分比；用例通过数/有效用例数 | 每个目标CPU+OS+数据库+中间件+浏览器组合 |
| 功能完整性 | 核心业务路径通过率、功能用例通过率、缺陷数量与等级分布 | 百分比；个 | 主推环境组合，其余组合抽测 |
| 性能与容量 | 平均/95分位响应时间、并发用户数、TPS、批量处理耗时、资源占用率 | 毫秒、秒、个、笔/秒、百分比 | 目标硬件与国产数据库环境，对照基线环境 |
| 集成与接口 | 单点登录成功率、消息收发成功率、文件上传下载成功率、第三方接口连通率 | 百分比；个 | 涉及外部系统对接的环境组合 |
| 数据一致性与迁移 | 迁移记录数一致率、字段值比对一致率、字符集与排序正确率、导入导出成功率 | 百分比；条 | 含数据迁移或数据交换的场景 |
| 运维与安全 | 部署脚本可重复执行率、日志完整率、备份恢复成功率、权限校验通过率 | 百分比；次 | 生产形态环境（私有化或容器化部署） |
指标选取要避免两类偏差：一是只测“能装能开”，不测业务路径，导致上线后功能异常；二是只测性能数字，不看功能正确性，导致快但算错。六类项目之间存在依赖关系，基础环境兼容是前提，功能与集成是主体，性能、数据、运维是保障，评估时应按此顺序推进，前一类出现阻断问题时先修复再进入后一类。
数据口径与证据：每项验证要留下什么
结论可复核的前提是每项指标都能追溯到环境、用例和原始记录。建议为每次验证建立一份环境信息记录，至少包含：CPU架构与型号、操作系统名称与发行版本、数据库与中间件名称及版本、浏览器名称与版本、部署方式、被测软件版本号。缺少任一项，结论的适用范围就无法界定。
定量指标要写清口径，包括分子与分母的定义、统计时间窗、并发条件、采样次数。例如响应时间要说明是单用户还是指定并发下测得，取平均值还是95分位，采样多少次后取何种汇总方式；兼容通过率要说明分母是否包含未执行用例。口径在测试前写入测试方案，测试中不随意调整。
定性项要留下可核验的证据形式：界面截图、服务日志、测试执行记录、缺陷单。截图应包含环境标识与时间，日志应能定位到具体操作，缺陷单应记录复现步骤与影响等级。口头确认或“测过了”不作为证据。
缺失值和不可比情况要单独标注，不能以缺失代替通过。常见情形包括：某环境组合因硬件未到位未执行、某接口因对端系统未开放无法联调、某指标因基线环境数据缺失无法对比。这些情况在结论中列为“未验证”并说明原因，与“通过”“不通过”并列呈现。
计算与评估步骤：从用例到结论怎么走
评估按五步推进，每步都有明确产物：
- 确定环境矩阵：列出必测组合与抽测组合，标注每个组合的硬件与软件版本，形成环境清单。
- 设计用例：按六类项目分别设计用例，每条用例写明前置条件、操作步骤、预期结果和所属类别，形成用例库。
- 执行采集：按用例执行并记录结果，定量指标同步采集原始数据，定性项留存证据。
- 计算指标：按约定口径计算各类通过率与性能指标，形成指标汇总表。
- 判定结论：依据判定规则给出通过、有条件通过或不通过，并列出未验证项。
兼容通过率与功能通过率的计算方式一致：
通过率 = 通过用例数 ÷ 有效用例总数 × 100%
分母为有效用例总数，即剔除因环境不具备而未能执行的用例；未执行用例数量单独列出，不计入分母，也不计入通过数。这样处理可以避免“少测即高分”，同时让未覆盖范围清晰可见。
性能指标以基线环境为参照，基线可以是原生产环境或双方约定的参照环境。对比方式为：
相对变化率 =（国产环境指标值 − 基线环境指标值）÷ 基线环境指标值 × 100%
阈值在测试前约定，例如约定95分位响应时间相对基线劣化不超过某一比例、批量处理耗时不超过约定绝对值。阈值应结合业务高峰的实际要求设定，不套用统一数字。
判定规则建议分三档：
- 通过：各类通过率达到约定标准，性能指标在阈值内，无阻断项，未验证项不影响核心业务。
- 有条件通过：核心业务路径可用，但存在非阻断缺陷、部分指标接近阈值或个别组合未验证，需限期整改或补充验证后放行。
- 不通过：出现阻断项，如核心业务路径不可用、数据迁移后出现一致性错误、关键接口无法连通、安全权限校验失效。
阻断项清单要在测试前确定，测试中不因进度压力临时放宽。判定结论应附指标汇总表与未验证项说明，供评审复核。
示例：一次适配验证的指标计算与判定
以下为演示情景，数字仅用于说明计算过程，不代表任何真实产品的测试结果。
设定环境为“鲲鹏CPU + 麒麟操作系统 + 达梦数据库”组合，基线环境为原x86生产环境。共设计用例200条，其中基础环境兼容40条、功能完整性80条、集成与接口30条、数据一致性与迁移30条、运维与安全20条。执行中因中间件版本未到位，有10条集成用例未能执行，有效用例总数为190条。
执行结果：通过170条，失败20条，其中功能类失败12条（含2条核心业务路径失败）、集成类失败5条、数据类失败3条。计算通过率：
整体通过率 = 170 ÷ 190 × 100% ≈ 89.5%
功能通过率 =（80 − 12）÷ 80 × 100% = 85.0%
性能方面，基线环境95分位响应时间为800毫秒，国产环境下测得1040毫秒，相对变化率为（1040 − 800）÷ 800 × 100% = 30%。测试前约定劣化不超过25%为达标，该项超出阈值5个百分点。批量处理耗时基线为120秒，国产环境为138秒，相对变化15%，在约定20%以内。
判定推导：整体通过率接近但未达到约定的90%标准，功能类存在2条核心业务路径失败，属于阻断项，按规则应判不通过。若经排查确认核心路径失败由配置问题导致、修复后复测通过，且性能劣化经调优降至25%以内，则可改判为有条件通过，条件为限期完成剩余10条集成用例的补充验证。这个推导说明：结论由阻断项和指标共同决定，单项通过率高不能抵消阻断项。
解读与限制：结论能说明什么、不能说明什么
一次适配验证的结论，说明的是“在记录的环境组合与用例范围内，软件达到了约定的判定标准”。它不说明软件在长期运行中的稳定性，也不说明在未覆盖的环境组合下同样可用。环境矩阵中任一要素变化，例如操作系统升级发行版本、数据库更换小版本、中间件替换，原结论的适用范围即需重新评估，必要时补充验证。
分母为零或样本不足时，通过率没有统计意义。例如某类用例因环境未到位全部未执行，此时应标注“未验证”，不计算通过率，也不将其视为通过。样本量过小时，性能指标宜给出原始数据与采样次数，供读者判断波动范围。
指标达标不等于业务效果保证。响应时间在阈值内，不代表高峰并发下用户体验一定可接受；功能用例全部通过，不代表覆盖了所有业务分支。验证结论应作为上线决策的输入之一，与业务侧的实际试用、灰度观察结合使用。
对于未取得认证或未验证的项目，表述要准确：写“本次未验证”或“认证证书待厂商提供”，不写成“不支持”，也不把厂商宣传的适配清单直接当作已验证结论。适配清单说明产品声称覆盖的范围，验证结论说明在具体环境下的实测结果，两者用途不同。
验证过程中的用例、缺陷、证据和结论需要在团队间流转并留痕。ONES 信创版适配鲲鹏、飞腾CPU，银河麒麟、统信、OpenEuler等操作系统及达梦数据库，并已与主流信创软硬件完成互信认证；在适配验证项目中，可将六类验证用例建为工作项、把缺陷单与测试记录关联到对应用例、将指标汇总与判定结论沉淀为文档，使评审时能按环境组合追溯每条结论的依据。具体适配的型号、版本与认证证书编号，以厂商提供的清单为准。
常见问题
环境矩阵里组合很多，是否每个组合都要跑完整用例？
不必每个组合都跑全量。常见做法是把主推组合作为全量验证对象，其余组合按风险抽测基础环境兼容与核心业务路径。抽测范围要在测试前写进方案，并说明选择依据，例如业务使用人数、硬件到位情况、与主推组合的差异程度。抽测组合的结论只覆盖所测用例，不能外推到全量功能。
测试中途发现某类用例设计有遗漏，能不能直接补进去再算通过率？
可以补充用例，但要保留版本记录。建议把补充用例单独标记并注明补充原因，通过率分别给出补充前与补充后的结果，避免同一份报告里口径前后不一致。如果补充用例改变了分母，评审时应以最终口径为准，同时说明变化过程，便于复核结论是否仍然成立。
性能指标在国产环境下劣化超出阈值，是否一定判不通过？
要看劣化项是否属于阻断项以及业务能否接受。响应时间超出约定阈值通常判为有条件通过，条件是限期调优并复测；如果劣化导致核心业务路径超时不可用，则按阻断项处理。无论哪种情况，都应在结论中给出原始数据、采样条件和对比基准，让评审方判断阈值是否需要结合业务实际调整。
厂商提供了适配清单和互信认证，是否可以直接作为验证结论？
不能直接等同。适配清单说明厂商声称覆盖的范围，互信认证说明与特定软硬件完成过适配认证，两者都不等于在你的环境组合与业务用例下实测达标。合理做法是把清单作为确定环境矩阵的输入，再按本文口径执行验证。引用认证时写明证书名称与适用范围，具体型号、版本与证书编号以厂商提供的材料为准。
验证用例、缺陷和结论分散在多个工具里，评审时怎么追溯？
关键是让用例、执行记录、缺陷和结论之间保持可关联。可以把六类验证用例建为工作项，缺陷单关联到对应用例，指标汇总与判定结论沉淀为文档，并按环境组合打标签。这样评审时能从一条结论回溯到具体用例和证据。ONES 信创版适配鲲鹏、飞腾CPU，银河麒麟、统信、OpenEuler等操作系统及达梦数据库，并已与主流信创软硬件完成互信认证，可作为承载这类验证过程的平台选项之一。
