软件开发如何验收？上线前应该核对的交付清单
软件验收需要确认业务流程、数据权限、性能兼容和资料交接。本文提供可直接用于讨论的验收清单，以订单退款为例说明怎样设置测试条件、记录结果和处理缺陷，帮助企业判断软件是否具备上线条件，避免只看演示页面就结束验收。
先看结论
软件项目验收应以双方确认的需求和交付范围为依据，把业务场景转成可以复现的操作步骤，并记录预期结果、实际结果和负责人。除正常流程外，还要检查异常处理、权限隔离、数据一致性、目标设备和运维交接。是否上线，应根据未解决问题对业务的影响作出明确决定。
验收开始前，先统一版本、范围和环境
验收依据应包含已确认的需求、原型、业务规则和变更记录。对尚未约定的新需求，先单独记录并评估，不要混入本次结果。否则双方可能测试了同一款软件，却对“完成”的定义不同。
同时记录待验收版本、测试环境、账号角色、基础数据和第三方服务配置。测试环境与正式环境有差异时，应列出哪些项目需要在上线前再次验证，例如真实域名、消息通知和正式支付配置。
上线前需要覆盖哪些验收项目？
下面的清单适合用作讨论起点，具体检查项应根据软件用途增减。每一项都需要实际记录，不能只填写笼统的“已测试”。
| 验收范围 | 重点检查 | 建议留存的依据 |
|---|---|---|
| 业务功能 | 主要流程、状态变更和异常处理 | 场景步骤、测试数据、实际结果 |
| 角色权限 | 谁能查看、修改、导出哪些数据 | 不同角色与数据范围的测试记录 |
| 数据一致性 | 订单、库存、金额与报表能否核对 | 预期数据与实际数据的对照 |
| 性能与稳定性 | 约定负载下的响应、错误和恢复 | 负载条件、指标定义、测试报告 |
| 设备兼容 | 目标浏览器、系统和屏幕上的核心操作 | 设备与版本清单、问题截图 |
| 部署与运维 | 备份恢复、告警、日志和回滚路径 | 演练结果、操作说明、负责人 |
| 资料交接 | 约定的代码、文档、账号与配置 | 逐项确认的交付目录 |
怎样把“功能正常”改成可验证的标准？
一条有效的验收用例应说明前置条件、操作步骤和预期结果。例如，“库存不足时不能创建有效订单，并且库存保持原值”，比“下单功能正常”更容易判断。
同一流程至少覆盖正常完成、条件不满足和中途失败三类情况。空列表、重复点击、网络中断和第三方接口失败，往往比演示数据更能暴露真实使用中的问题。让负责该业务的员工参与测试，确认结果符合日常工作规则。
业务示例：订单退款怎样验收？
以下为说明性示例，不代表具体客户项目。假设一笔已付款但尚未发货的订单允许退款，应先明确谁能申请、谁能审批、退多少、什么时候恢复库存。然后验证申请后订单状态、退款记录和报表是否按约定变化。
还应重复提交同一申请，检查是否只产生一次有效处理；模拟退款渠道暂时失败，检查是否保留待处理状态并提供重试路径。最后由另一名无权限员工尝试访问该记录，确认不能越权操作。测试金额与账号应按项目选定的测试环境安排。
安全、性能和兼容性怎样验收才有意义？
安全检查应覆盖登录、会话、权限、数据保护和错误记录等实际风险。OWASP ASVS 提供了应用安全验证要求，可由技术团队按项目范围选取检查项。完成一份清单并不等同于证明系统不存在漏洞，扫描报告也不能替代业务权限测试。
性能指标必须连同条件一起写明，包括数据量、同时操作人数、网络环境、目标操作和统计口径。仅说“页面两秒打开”无法判断是否达标。兼容性则应约定真实用户使用的浏览器、系统及版本；MDN 的测试指南同样强调先确定目标环境，而非声称兼容所有设备。
验收还要确认企业能否持续使用和维护
按已约定的交付范围逐项接收资料。需要交接源代码时，应确认版本对应关系、构建方式和依赖说明；需要交接云服务或平台账号时，应核对管理权限、付费主体和后续负责人。敏感凭据应通过合适的安全渠道传递，避免写入公开文档。
备份成功不代表可以恢复。应在合适的隔离环境中验证恢复步骤，并记录恢复后的关键数据是否完整。上线前还要明确谁监控异常、谁决定回滚，以及回滚可能影响哪些新产生的数据。
发现问题后，怎样形成明确的验收结论？
问题记录应包含版本、账号角色、复现步骤、预期结果、实际结果和证据。修复后需要重新测试原场景，并检查关联流程。例如退款修复后，还要核对订单查询和报表数据。
上线决定应依据问题影响，而不只是问题数量。涉及资金错误、数据损坏、越权访问或核心流程阻断的问题，应作为优先解决的上线阻碍；较轻的体验问题可记录责任人、处理安排和临时措施，再由项目相关负责人确认是否接受。结论应写清通过范围和仍待完成的事项。
常见问题
开发方演示没有问题，就可以验收了吗？
演示可以帮助理解功能，但还需要使用约定角色和接近实际业务的数据独立操作，检查异常、权限和交付资料。演示通过只说明被展示的场景运行成功。
是不是要做到一个问题都没有才能上线？
应按问题影响和上线标准判断。核心流程、数据和权限方面的问题需要优先解决；不影响主要任务的轻微问题可以评估后列入后续安排，并留下明确的确认记录。
上线后还需要继续测试吗？
需要。上线后应检查正式环境中的关键流程、通知、日志与监控，每次更新也应复测受影响的业务。正式环境检查应控制范围，避免测试操作影响真实客户或业务数据。
参考资料与适用范围
以下资料用于核对相关方法或技术能力。项目范围、成本与交付条件仍需根据实际业务确认。
- OWASP：Application Security Verification Standard支撑应用安全验证范围的说明。本文的业务验收清单为通用项目建议，不是完整 ASVS 清单或安全认证结论。
- MDN：Introduction to cross-browser testing支撑约定目标浏览器与设备、按阶段测试以及修复后复测的说明。
