3. 验收测试核心概念

验收测试核心概念 学习卡片

在Halcon视觉项目的交付链条中,验收测试是甲方与乙方之间最正式的“技术契约”执行环节。它不同于开发阶段的单元测试或集成测试,验收测试的核心目的是回答一个根本问题:“这套视觉系统是否达到了合同约定的可用状态?”。本章围绕四个核心概念展开——验收标准、测试用例、缺陷分类、通过/失败判定准则,它们共同构成了验收测试的“宪法”与“操作手册”。

3.1 验收标准:从合同语言到可测量指标

验收标准是验收测试的源头,它必须将合同中的模糊描述(如“检测准确率高”“运行稳定”)转化为可量化、可复现、可仲裁的技术指标。在Halcon项目中,验收标准通常分为三个层次:

  • 功能指标:检测项是否齐全、分类是否正确、定位精度是否达标。例如“识别PCB板上所有缺件、偏移、极性反贴缺陷,漏检率≤0.1%”。
  • 性能指标:节拍时间、并发处理能力、长时间运行稳定性。例如“单工位检测周期≤2.5秒(含触发、采集、处理、通信)”。
  • 鲁棒性指标:对光照变化、产品型号切换、来料轻微差异的适应能力。例如“在环境照度波动±20%范围内,误检率上升不超过0.05%”。

制定验收标准时,必须遵循SMART原则(具体、可测量、可达成、相关、有时限)。一个常见的错误是直接引用Halcon算子参数作为验收标准,例如“使用shape_model匹配分数≥0.8”,这属于实现细节而非验收标准。正确的表述应为“在标准样品集上,所有合格品的匹配分数均≥0.8,且无漏检”。

实践建议:在项目启动阶段,就应输出《验收标准矩阵》文档,将合同条款逐条映射到具体的测试方法、测试工具、样本数量和判定公式。该矩阵需双方签字确认,避免验收阶段“各说各话”。

3.2 测试用例:验收动作的结构化设计

测试用例是验收标准的具体执行脚本。一个完整的Halcon验收测试用例应包含以下要素:用例编号、前置条件、测试步骤、输入数据(图像/参数)、预期结果、实际结果、判定结论。在设计测试用例时,需要覆盖三类场景:

  1. 典型场景:使用标准样品(Golden Sample)进行测试,验证系统在理想状态下的性能。例如使用20张标准无缺陷图像,验证误检率为0。
  2. 边界场景:使用接近极限条件的样本,验证系统的容差范围。例如检测最小缺陷尺寸(0.3mm²)、最大倾斜角度(±15°)、最暗光照(200 lux)。
  3. 异常场景:模拟非预期输入,验证系统的容错能力。例如输入全黑图像、模糊图像、未触发信号时的行为。

测试用例的设计必须与Halcon脚本的具体实现解耦。验收方不应依赖开发方的内部变量或调试接口,而应通过系统对外提供的输入输出接口(如相机触发信号、图像文件目录、TCP/IP通信报文)进行黑盒测试。以下是一个典型的测试用例模板:

用例编号: AC-OCR-001
测试目标: 验证OCR识别模块对批次号打印质量的鲁棒性
前置条件:
  - 系统处于自动运行模式
  - 标准光源亮度为80%
  - 待测样品为同一批次连续生产的50个产品
测试步骤:
  1. 将50个样品依次放置于检测工位
  2. 触发相机采集,记录每次识别结果及耗时
  3. 对识别失败的样品,人工复核打印质量
输入数据: 50张实时采集图像(含正常、轻微油墨不均、字符断线样本)
预期结果:
  - 字符识别准确率 ≥ 99.5%
  - 单次识别耗时 ≤ 200ms
  - 对油墨不均样本的拒识率 ≤ 2%(即允许拒识,但不允许误识)
实际结果: (填写实测数据)
判定结论: 通过 / 不通过

3.3 缺陷分类:统一语言,分级处理

在验收测试过程中,发现的问题必须进行分类登记,以便确定是否影响验收结论。Halcon视觉项目的缺陷通常分为四个等级:

缺陷等级 定义 典型示例 验收影响
致命(Blocker) 导致系统无法运行或验收无法继续 相机无法触发、Halcon License失效、PLC通信中断 必须修复后重新测试
严重(Critical) 核心功能未达标,但不影响系统启动 漏检率超标、定位精度超差、节拍超时 必须修复后回归测试
一般(Major) 功能可用但存在明显缺陷 误检率略超指标、界面无日志输出、报警信息不准确 可附带条件验收,限期整改
轻微(Minor) 不影响功能实现,但影响体验或维护 代码注释缺失、参数未写入配置文件、界面按钮排列不齐 记录在案,不阻塞验收

缺陷分类的核心价值在于避免“一刀切”。如果所有问题都视为必须修复项,会导致验收周期无限拉长;反之,如果所有问题都视为可接受项,则可能埋下重大隐患。建议在验收启动前,双方就缺陷等级定义达成书面共识,特别是对“严重”与“一般”的边界进行举例说明。

3.4 通过/失败判定准则:组合逻辑与仲裁机制

通过/失败判定不是简单的“所有用例通过即通过”,而是需要设计一套组合判定逻辑。常见的判定模型包括:

  • 全通过模型:所有致命和严重缺陷为0,一般缺陷不超过N个,轻微缺陷不限制。适用于安全关键场景(如医疗、汽车零部件)。
  • 加权评分模型:为不同测试项分配权重,计算综合得分。例如功能测试占60%,性能测试占30%,鲁棒性测试占10%,总分≥85分视为通过。
  • 关键项否决模型:设定若干“一票否决”项(如漏检率、安全功能),只要有一项不达标,整体判定为不通过,无论其他项表现多好。

在实际执行中,推荐采用“分层判定+回归确认”的流程:

第一层:致命缺陷检查
  - 若存在任何致命缺陷 → 整体判定为“不通过”,终止测试
第二层:关键指标检查
  - 漏检率、误检率、节拍时间是否达标
  - 若任一关键指标不达标 → 判定为“不通过”,进入整改
第三层:非关键指标检查
  - 一般缺陷数量是否在约定范围内
  - 若超出范围 → 判定为“有条件通过”,附整改期限
第四层:回归测试
  - 所有修复项必须执行回归测试,确认无副作用

判定准则中还必须明确样本量的统计学依据。例如,若合同要求漏检率≤0.1%,仅测试100个样本(其中1个缺陷)无法从统计学上证明该指标。此时应参考二项分布或泊松分布,计算所需最小样本量。Halcon项目中常用的经验值是:对于0.1%的漏检率,至少测试3000个已知缺陷样本且全部检出,才能以95%置信度确认达标。

常见误区:在验收测试中,使用开发方自己准备的“完美样本集”进行测试。这些样本往往经过筛选,无法代表真实生产中的分布。正确的做法是:由甲方或第三方从实际产线中随机抽取样本,并混合已知缺陷样本与未知样本,由双方共同封样。

3.5 案例复盘:一个定位项目的验收争议

某汽车零部件项目,合同要求“对直径10mm±0.05mm的圆孔进行定位,定位精度≤0.02mm”。开发方在验收时使用Halcon的measure_pos算子,在实验室环境下测得精度为0.015mm,自测通过。但甲方在现场验收时,使用产线实际工件(表面有油污、反光不均)进行测试,精度降至0.035mm,判定不通过。

复盘发现三个核心问题:

  1. 验收标准未定义测试环境:合同未明确“在何种光照、何种工件表面状态下测试”。开发方默认使用理想环境,甲方默认使用实际产线环境。
  2. 测试样本不具有代表性:开发方自测使用的工件是经过清洗的“标准件”,而产线工件表面状态差异极大。
  3. 判定准则缺失:合同只写了“定位精度≤0.02mm”,但未规定是平均值、最大值还是CpK值,也未规定测试次数。

最终解决方案是:双方重新定义验收标准——在产线实际光照下,连续测试200个工件,取定位误差的最大值作为判定依据,且允许对工件表面进行“吹气清洁”预处理。同时,开发方优化了Halcon脚本,在measure_pos前增加了基于频域滤波的预处理步骤,最终将最大误差控制在0.018mm,验收通过。

这个案例说明,验收测试的核心概念不是孤立的术语,而是需要在实际项目中动态平衡的体系。验收标准是“锚”,测试用例是“船”,缺陷分类是“导航图”,通过/失败判定准则是“港口规则”。四者缺一不可,且必须在项目启动初期就同步设计,而非等到验收阶段才临时拼凑。

本章要点回顾:
  • 验收标准必须量化、可测量,并与合同条款一一对应。
  • 测试用例应覆盖典型、边界、异常三类场景,且使用黑盒视角。
  • 缺陷分级(致命/严重/一般/轻微)是控制验收节奏的关键工具。
  • 通过/失败判定需采用组合逻辑,并明确样本量与统计置信度。
  • 任何验收争议的根源,几乎都可以追溯到“标准定义不清晰”或“样本不具有代表性”。