老系统升级改造后怎么做软件验收？回归范围、数据迁移与通过判定要点

系统上线五六年，功能越叠越多。这轮升级改了登录认证和报表导出两个模块，开发方说改动不大、可以直接上线，结果上线一周后财务的月度汇总报表导不出来，甲方拒绝在验收单上签字。这类场景在升级改造项目里并不少见：新开发项目的验收是“从零对照需求”，而改造项目的验收还要回答另一个问题——没改的部分还完好吗？

升级改造项目验收，难点到底在哪

改造类项目的验收争议，大多不是出在“新功能好不好用”，而是出在新旧交替的缝隙里。三类场景出现频率很高：

• 旧功能回归遗漏：改动点波及了共用组件或公共接口，开发方只测了改动的模块，旧链路在验收时才暴露问题；
• 数据迁移差错：老库迁新库时字段映射、金额精度、历史状态出现偏差，业务部门对不上账；
• 性能退化：新加的校验逻辑、更大的数据量让原本流畅的操作明显变慢，用户直观感受就是“越改越卡”。

这三类问题有一个共同点：都不属于新增需求的范畴，却都直接影响验收结论。验收依据如果还停留在签合同时的需求规格说明书，双方很容易各说各话。

验收依据：先把变更后的基线补齐

需求基线与变更记录对齐

升级改造项目启动时，往往伴随多轮需求变更。验收前应把原合同需求、历次变更申请与评审记录、双方确认的**需求说明书合并成一份“现行有效”的验收基线，逐条标注每条需求对应的版本来源。凡是口头答应、没进变更记录的功能，验收时一律不作为判定依据，避免扯皮。

标准依据怎么选

GB/T 28035-2011《软件系统验收规范》明确了各类软件系统验收的组织方式、验收测试与审查要求，流程框架可参考此前梳理过的软件验收流程；质量要求则普遍参照 GB/T 25000.51-2016 的八大质量特性（功能性、性能效率、兼容性、可靠性、信息安全性、易用性、维护性、可移植性）执行。合同或技术协议中约定了具体标准的，按约定执行——依据民法典，合同明确指定的测试标准对双方具有法律约束力，未按约定标准测试，验收结论可能不被认可。

回归范围怎么划：以变更影响分析为起点

回归测试不是“把所有用例再跑一遍”，也不是“只测改动的功能”。GB/T 15532-2008《计算机软件测试规范》对回归测试的要求是覆盖所有受变更影响的功能模块。划定范围可以按三步走：

变更影响分析

从改动清单出发，沿调用链向上向下追踪：改了哪个接口，哪些模块调用这个接口；改了哪个公共组件，哪些功能引用这个组件；数据库表结构动了，哪些报表和查询依赖这些表。把直接影响和间接影响都列入回归清单，形成书面的影响分析记录，再把影响点转化为具体的验收测试用例，作为执行和留痕的依据。

数据迁移验证

涉及数据迁移的改造项目，迁移验证要覆盖三个维度：完整性（记录条数一致、无丢失）、准确性（关键字段值一致，金额类建议全量核对）、一致性（关联关系正确、新旧系统同一业务口径）。做法上可以让新旧系统并行运行一段时间，按业务口径抽样比对，样本要覆盖各种历史状态的数据，不能只挑“好对的”。

性能与安全不回退

性能方面，拿升级前的版本在同等环境下跑一轮基准，记录核心操作的响应时间、并发处理能力和资源占用，升级后同口径复测对比，退化明显就要查明原因。安全方面，升级引入的新组件、新接口需要重新做漏洞扫描，不得存在高危漏洞；老系统上原本已整改的安全项，也要确认没有在改造中被改回去。

通过判定与遗留缺陷的处理

验收判定的尺度要在验收开始前约定清楚，一般包括：

• 致命、严重缺陷必须清零，核心业务流程全部走通；
• 升级过程本身顺利，系统可正常安装、启动和运行；
• 一般缺陷可以登记遗留，但要约定整改期限和复验方式，写进验收报告；
• 文档同步更新：GB/T 8567-2006《计算机软件文档编制规范》要求的用户手册、操作手册等，必须与升级后的版本一致，不少项目栽在“程序是新的、文档还是三年前的”。

对甲方来说，由具备 CNAS、CMA 资质的第三方机构出具验收测试报告，是让回归范围、迁移核对和判定结论有据可查的稳妥做法。北京尚云（尚拓云测）在升级改造类项目的验收测评中，通常会把变更影响分析记录一并归入报告附件，方便结算审计时追溯。

给甲乙双方的行动清单

• 乙方：交付前完成变更影响分析并保留记录，回归范围主动写进测试方案，迁移数据先自核一遍再约验收；
• 甲方：验收前确认文档版本与程序版本一致，把回归范围、迁移核对口径、遗留缺陷处理方式写进验收计划；
• 双方：改造项目建议在验收中安排一段新旧系统并行期，用真实业务数据完成比对后再切换，把风险留在验收之前。

改造项目的验收，本质是证明“改好的部分达标、没改的部分无恙”。把变更基线、回归范围和数据迁移验证做扎实，验收签字时就不会再有意外。