1. 课程导入与全景认知

软件项目交付验收，是指甲乙双方依据合同、需求规格说明书、技术协议及相关标准，对承建方交付的软件系统进行确认性检查，并据此作出"通过、有条件通过或不通过"结论的正式活动。它既是项目生命周期的收口动作，也是合同履约、付款结算、责任划分的法定依据。很多项目"技术做完了、钱却收不回来"，根源往往不在代码质量，而在验收标准模糊、验收证据缺失、争议处理无章可循。

理解验收，先要区分三组容易混淆的概念。交付是把成果物移交给对方，验收是对方确认成果物符合约定，结算是依据验收结论完成付款。交付不等于验收，验收不等于满意，满意也不等于放弃追责。另一个关键区分是验收测试与系统测试：系统测试由承建方主导，目标是发现缺陷；验收测试由建设方主导或参与，目标是确认需求是否被满足、能否投入生产。二者依据不同、责任主体不同、结论效力也不同。

争议处理的价值，体现在三个层面。第一是止损：争议一旦进入诉讼或仲裁，周期常以年计，双方投入的人力、律师费、机会成本远超争议标的本身，早期结构化处理能显著降低总成本。第二是保交付：争议往往卡在"是否达到验收条件"这一环，若能通过缺陷分级、整改复验、部分验收等机制把大争议拆成小问题，项目就能继续推进而非全面停摆。第三是留证据：无论最终是协商、调解、评审还是诉讼，胜负手都在证据链——需求变更单、会议纪要、邮件确认、测试报告、上线记录，谁在过程中留下了完整痕迹，谁在争议中就占据主动。

本课程的整体框架可概括为"一条主线、四个阶段、两类工具"。一条主线是从签约到收口的全流程验收管理；四个阶段分别是验收准备、验收执行、争议识别与处理、复盘与知识沉淀；两类工具是文档模板类（验收方案、测试用例、缺陷清单、验收报告、争议处理函件）与判断决策类（缺陷分级标准、验收通过判定规则、争议升级路径）。学习路径建议按"先建认知、再学标准、后练处置"推进：先掌握定义与全景，再逐项拆解验收标准与测试设计，然后进入争议场景的识别、沟通、谈判与法律边界，最后通过综合案例完成闭环演练。

把这张全景图落到实际工作中，可以这样理解：验收准备阶段的核心产出是"可执行的验收方案"，它必须把合同中的定性描述翻译成可测量的指标。例如合同写"系统响应快"，验收方案应写成"在 200 并发用户、平均响应时间 ≤ 2 秒、95 分位 ≤ 3 秒，压测持续 30 分钟无错误"。验收执行阶段的核心产出是"带证据的测试报告"，每条用例要有编号、前置条件、操作步骤、预期结果、实际结果、通过与否、截图或日志附件。争议识别与处理阶段的核心产出是"结论与依据"，即明确哪些缺陷属于阻断验收、哪些可限期整改、哪些可作为遗留问题带条件通过。复盘阶段则把本次争议的根因写回模板，避免同类问题重复发生。