1. 验收与交付总览
在LabVIEW自动测试项目中，代码写完、程序能跑，并不等于项目结束。真正决定项目能否顺利收尾的，是“验收与交付”这一段常被低估的工程过程。它要回答三个问题：客户凭什么确认系统合格？我们交出去的东西是否完整、可复现、可维护？双方在什么节点上完成责任与资产的转移？本章先建立一张全局地图，后续章节再逐项展开。
一、验收与交付不是同一件事
很多团队把“验收”和“交付”混为一谈，导致后期扯皮。二者目标不同、判据不同、参与人也不同。
- 验收（Acceptance）：以技术指标是否达标为核心，依据验收大纲和测试记录，对系统的功能、精度、节拍、稳定性做出合格判定。主导方通常是客户的技术/质量代表与项目测试负责人。
- 交付（Delivery）：以资产与责任的转移为核心，把源码、可执行程序、配置文件、文档、标定数据、备件与权限正式移交，并完成培训与签字确认。主导方通常是项目经理与客户接口人。
一句话概括：验收解决“行不行”，交付解决“给没给全、会不会用、出了问题谁负责”。两者往往交叉进行，但里程碑和签字文件必须分开管理。
二、完整流程与关键里程碑
一个典型的LabVIEW自动测试项目，从开发完成到客户签收，通常经历六个阶段。下图给出各阶段的输入、关键动作、输出物与里程碑判定点，可作为项目收尾的路线图。
三、验收大纲：把“合格”写成可执行的判据
验收能否顺利，八成取决于验收大纲是否在开发阶段就与客户对齐。大纲不是简单罗列功能，而是把每条指标写成“测试条件 + 方法 + 判据”。以某电源模块自动测试台为例，可这样写：
| 测试项 | 测试条件 | 方法 | 合格判据 |
|---|---|---|---|
| 输出电压精度 | 负载 50%，25℃ | 标准表读取 10 次取均值 | 偏差 ≤ ±0.5% FS |
| 测试节拍 | 单件全项测试 | 连续测 20 件计时 | 平均 ≤ 45 s/件 |
| 连续运行稳定性 | 常温，满负载 | 连续运行 8 h | 无死机、无通信中断 |
| 数据完整性 | 任意一次测试 | 核对数据库与界面 | 记录条数与结果一致 |
注意判据要可量化、可复现。像“运行稳定、界面友好”这类描述无法作为验收依据，应转化为可观测的指标或明确的检查项。
四、现场验收的典型动作与观察点
现场验收一般按“功能核对 → 精度比对 → 节拍测量 → 连续运行 → 异常注入”推进。以精度比对为例，实际操作是：用标准源或标准表作为参考，在同一测试点下让LabVIEW系统与被测台同时读取，记录偏差。若标准表读数为 12.003 V，系统显示 12.001 V，则偏差为 2 mV，对照判据判断是否合格。
异常注入是容易被忽略但极有价值的一步：拔掉通信线、模拟传感器断线、故意输入超限值，观察系统是否给出明确报警、是否安全停机、是否记录故障码。这一步能暴露“正常工况下看不出来”的健壮性问题，也是客户最关心的安全底线。
五、交付物清单与齐套检查
交付不是把文件打包发过去就完事。推荐按六类做齐套检查，每类明确“有没有、对不对、能不能用”：
- 程序资产：LabVIEW源码（含项目文件.lvproj）、生成的可执行程序、必要的驱动与运行引擎安装包、第三方库及授权说明。
- 配置数据：硬件配置文件、通道映射表、标定系数、报警限值、测试项参数文件。这些往往决定系统能否在新环境复现。
- 测试文档：验收大纲、验收报告、原始测试记录、缺陷整改记录。
- 使用文档：操作手册、维护手册、常见故障处理指南、版本说明。
- 验收文件：验收报告签字页、遗留问题清单、客户签收单。
- 培训与备件：培训签到与记录、备件清单、易损件更换说明。
六、常见风险与应对
收尾阶段最常见的三类风险是：指标口径不一致（客户理解的精度与合同定义不同）、版本漂移（现场改了一版程序但没记录）、遗留问题无限拖延（小缺陷卡住签收）。应对方式分别是：验收大纲提前书面确认；冻结版本并建立变更记录；对不影响签收的缺陷列入遗留清单，约定整改期限后先行签收。