上个季度我带队做了一批鸿蒙人脸识别门禁的集中验收，十个点位分布在不同园区里，有室内闸机也有室外铁门，中间踩了不少坑。说实话，门禁项目难的不是把人脸识别算法跑通，而是验收边界太容易模糊——到底算识别通过，还是算整机开门通过，以及鸿蒙系统、应用层和平台服务之间的分工，合同里常常一句话带过。所以这次想把自己整理的一套专用于鸿蒙人脸识别门禁项目的验收与性能评估清单摊开来说，给同样做集成商的朋友一个可以抄作业的框架，也让甲方技术负责人在评审时知道该关注哪些指标。文章会从项目拆解、评测维度、实操流程、问题排查到报告留存一条线讲完，重点解决“测什么、怎么测、怎么判”这三件事。
1. 验收前先拆项目：从设备到云端，边界越清楚越好
1.1 搞清楚鸿蒙门禁系统的三个逻辑层
我接手这类项目的第一件事，不是跑到现场去刷脸，而是先把系统拆成三个逻辑层：设备硬件层、操作系统与中间件层、业务应用层。设备硬件层包括摄像头、补光灯、红外灯、读卡模块、锁控模块、门磁、出门按钮、电源板这些物理部件；操作系统与中间件层在鸿蒙门禁里很关键，包括OpenHarmony或HarmonyOS的版本、API能力、驱动框架、网络协议栈、安全存储、OTA组件；业务应用层则是人脸录入App、门禁管理后台、前端识别应用、远程开门接口、访客系统等。
为什么要分这么细？因为验收时每个层都可能出问题。硬件出了问题表现为“灯不亮”“锁不弹”，系统层出了问题表现为“设备重启后配置丢失”“外设驱动没起来”“日志刷屏”，业务层出了问题则表现为“能识别但不开门”“平台查不到记录”“App偶发闪退”。如果不拆层，问题一混在一起，很难正确定位。尤其是鸿蒙这种还在快速迭代的系统，很多设备底层驱动通过HDF驱动框架接入，如果某个外设适配不到位，现象可能时好时坏，非常折磨人。
1.2 从合同需求反推验收基线
很多集成商有一个误区，觉得验收就是把产品功能点过一遍，能开门就算通过。实际上，没有明确验收基线的项目，后面八成要扯皮。合同里如果只写了“支持人脸识别门禁”，那什么叫“支持”？识别率多少算达标？从刷脸到开门几秒算合格？陌生人能不能被挡住？断网能不能继续工作？这些都要在验收前变成可验证的数字。
我的做法是，从合同和需求规格说明书里把功能清单、性能参数、安全要求、对接需求全部摘出来，整理成一张需求追溯表。如果甲方没有给出具体指标，我会主动提出一个建议基线，比如“人脸识别准确率≥99%，误识率≤0.1%，端到端开门响应时间≤1.5秒，支持底库1万人，断电重启后业务自恢复”。拿到甲方书面确认后再开始测试。这一步不是给甲方添麻烦，而是保护双方：集成商知道自己该交付什么，甲方也知道如何验收才算完整。
1.3 现场勘察要提前做的功课
验收不是把设备装好之后才开始的。我在正式测试前，通常会先去现场做一次勘察，重点记录三类环境数据。第一是光照：安装位置是否有直射阳光、是否有逆光、夜间补光灯覆盖范围是否足够，最好用照度计在不同的时间段实测几个数值，避免“白天测了一套参数，晚上全变样”。第二是安装条件：摄像头安装高度、角度，人员通行距离，通道宽度，地面是否有台阶，这些会直接影响人脸可采集角度和距离。第三是网络与供电：设备到交换机的网线距离、是否走PoE、供电是否稳定、是否有UPS，门禁在断电后能否自动恢复。
千万别小看这个环节。我遇到过客户报“人脸识别率低”，到现场一看，摄像头装在门框右上角，人脸俯仰角超过30度，根本不是算法问题，是安装位置问题。如果验收前就把安装约束写清楚，这类问题完全可以避免。
2. 人脸识别性能评估：不是“能开门”就算过
2.1 核心指标和计算公式，建议表格
人脸识别门禁最核心的性能评估指标，说白了就是四个词：识别率、误识率、拒识率、响应时间。很多项目验收报告只写“测试期间开门成功率99%”，这个数字太粗了，它把很多因素混在一起。我习惯把指标拆开算，并让甲方明白每个指标代表什么业务含义。
| 指标 | 定义 | 门禁场景参考 | 测试方法 |
|---|---|---|---|
| TAR（正确识别率） | 注册人员被正确识别的比例 = 正确识别数 / 应识别总数 | 通常要求≥99% | 注册人员在不同条件下刷脸N次，记录识别成功次数 |
| FAR（误识率） | 未注册人员被错误接受的比例 = 错误接受次数 / 非目标比对次数 | 安全场景要求极低，通常<0.1% | 用陌生人脸库反复比对，记录错误开门次数 |
| FRR（拒识率） | 注册人员被拒绝的比例 = 未识别目标数 / 目标总数 | 视用户体验要求，一般<1%~5% | 注册人员连续刷脸，记录被拒次数 |
| 端到端响应时间 | 从刷脸到收到开门指令的时间 | 视项目需求，通常<1.5秒 | 通过日志时间戳或示波器信号测量 |
需要注意，TAR和FRR是相关的，调高算法阈值会降低FAR但可能提高FRR，调低阈值则反过来。验收时不光要看单值，还要看阈值设置在哪个档位。有些厂家为了演示效果好，把阈值调得很松，陌生人照片也能过，这种“高识别率”对门禁来说反而是安全隐患。
2.2 测试集的构建与人脸底库校准
人脸识别测试不能拿几个同事现场刷脸就算数，必须有相对可控的测试集。我一般会准备三类数据：注册底库、目标测试集、陌生人干扰集。
注册底库至少包含合同约定规模的模拟数据，比如目标是支持1万底库，就至少注册1万人脸（不够时用脱敏库补充，必须保证来源合规）。目标测试集覆盖不同年龄段、性别、肤色、是否戴眼镜/口罩/帽子、不同表情。陌生人干扰集则用来测误识率，这些人不能出现在注册底库里，但数量和底库要有一定比例，否则测不出误识风险。
另外要关注模型授权问题。现在很多开源或商用的人脸识别模型都声称“可商用”，但商业授权范围差别很大，有的限定设备数量，有的限定使用场景。集成商在验收时要检查算法模型是否有正规商用授权，避免交付后被告侵权。关于模型选型，目前开源免费可商用的方案确实不少，但项目越大越要找授权清晰、有持续维护的模型，这不是技术问题，是合规问题。
2.3 从刷脸到开锁的完整时延链路
人脸识别门禁的时延，不能只测“摄像头识别那一瞬间”，要从用户触发刷脸开始，到锁控制器输出信号为止。我习惯把时延拆成四段：图像采集与检测、特征提取与比对、业务平台权限校验、锁控信号输出。每一段都可能成为瓶颈。
采集段的问题通常是帧率低或曝光时间长，导致人脸图像模糊，间接增加识别时间；特征提取与比对段的问题是算法复杂度太高或底库检索效率低，尤其底库超过1万人后，比对耗时会明显上升；业务平台校验段的问题是网络延迟和服务器响应慢，如果平台在云端，跨地域调用可能额外增加几百毫秒；锁控输出段的问题是继电器动作时间和门禁控制器协议处理时间不一致，有时候信号发出去但锁要等200毫秒才动作。
测时延建议用日志时间戳，而不是人眼掐秒表。设备端、算法服务、平台、门禁控制器分开记录时间戳，能精确定位哪一段超时。如果你的设备SDK支持注入时间戳，测试前就加上，会给后续排查省很多事。
2.4 活体检测和伪装攻击测试
门禁的安全等级很大程度取决于活体检测能力。现在很多项目还在用最基础的单目摄像头，拿到照片就能刷开，这是验收中绝对不能放过的点。我一般会准备一套“攻击样本”：打印照片、手机屏幕视频、硅胶面具或头模（如果预算允许），再结合不同尺寸和角度进行测试。
活体检测不一定要求100%拦住所有攻击，但至少要能拦住常规照片和视频攻击。验收时要记录活体误杀率和攻击拦截率。很多设备为了拦截攻击，把活体阈值设得很高，导致真人刷脸频繁失败，这就是“安全性和体验打架”。集成商要做的就是帮甲方找到平衡点：可以设计一套阶梯测试，先测照片攻击拦截率，再测视频攻击拦截率，最后测真人通过率。如果三者不能同时满足，至少要在项目需求里明确优先级。
2.5 鸿蒙端侧资源占用和系统稳定性指标
既然是鸿蒙人脸识别门禁，系统层面的性能评估不能跳过。我通常关注四个指标：CPU占用率、内存占用、I/O负载、长时间运行稳定性。
测试方法是让设备连续运行72小时甚至7天，白天模拟正常刷脸，夜间模拟低流量待机，同时用监控工具定时记录资源使用情况。如果是OpenHarmony设备，可以通过hdc shell命令查看进程CPU、内存和内核日志。如果设备长时间运行后内存不断增长，或者出现卡顿、掉线，说明可能有内存泄漏或后台服务异常。设备重启恢复也是一个必测项：断电重启后，人脸识别应用、网络连接、门禁控制服务是否自动拉起？底库数据是否仍然存在？这些都要记录。
3. 实操验收流程：具体到每一步的测试方法
3.1 功能项用例怎么设计才不会漏
很多集成商的测试用例写得太“虚”，比如“验证人脸识别功能是否正常”，这种用例没法执行。我建议用“前置条件+操作步骤+预期结果”的格式，把每一项写成可判定的小实验。比如：
“前置条件：设备已联网，注册人员A的底库图片已上传，系统时间为北京时间。操作步骤：A站在设备前0.5~1米处，正对摄像头，在500lux以上均匀光照下连续刷脸5次。预期结果：每次均在2秒内提示识别成功并触发开门信号，后台生成5条通过记录。”
一套比较完整的功能用例至少覆盖：人脸录入、人脸更新、单人识别、多人同框、陌生人拦截、活体攻击拦截、刷卡/密码开门、远程开门、App联动、平台日志查询、删除人员、权限过期、断网离线开门、断电恢复、时间同步、异常告警等。每一条都要关联具体需求，否则就是无效用例。
3.2 用脚本和压测工具拿到客观数据
人工测试只能覆盖功能和部分性能，真正的并发能力和稳定性还是得靠工具。我常用三类工具组合：
第一类是图像处理和批量测试脚本。比如用Python或C# OpenCvSharp写个简单的人脸图片处理工具，把测试图片统一裁剪成640x640或112x112等模型输入尺寸，做亮度、角度、遮挡等增广处理，再批量喂给算法服务，从而得到一组相对客观的识别结果。这个环节非常有用，它可以避免人工刷脸的疲劳误差。
第二类是接口压测工具。如果系统有后端平台接口，我推荐用JMeter这类工具对“人脸比对接口”或“开门权限校验接口”做并发测试。比如模拟100个用户同时请求开门，循环100次，观察接口吞吐量、平均响应时间、错误率。通过压测结果可以判断平台服务是否存在明显瓶颈，也能提前发现数据库连接池、缓存策略等隐患。
第三类是系统监控工具。在设备端和服务器端部署资源监控，记录CPU、内存、网络连接数、磁盘I/O。压测过程中配合监控，能清楚看到瓶颈在哪一层：是算法服务占了高CPU，还是数据库连接打满了，还是网络带宽不够。
3.3 现场测试组织与数据记录
现场测试最怕的是人多手杂、记录混乱。我习惯把测试分成三个阶段：功能验收、性能测试、稳定性观察。功能验收一般安排一个半天，把所有功能用例跑完，边测边登记结果；性能测试需要单独留出时间，避免和真实人员进出混在一起，否则数据没法分析；稳定性观察则是在功能性能都达标后，让设备保持连续运行，每天固定时间巡检一次，记录异常。
数据记录方面，我强烈建议做“盲测”：让测试人员在不知道底库ID顺序的情况下操作，减少主观期望偏差。所有原始数据要保留截图、日志备份、视频片段，尤其是识别失败和攻击拦截的样本，后面排查问题都需要。如果条件允许，每一台设备都记录硬件SN号、软件版本、算法版本、补光灯型号、安装角度，这些信息在项目交付后是最重要的问题定位依据。
4. 集成商最容易翻车的几个问题与排查记录
4.1 识别日志正常但继电器不动作
这是门禁项目里最典型的“软件正常、硬件拉胯”问题。现象是人脸识别已经提示成功，后台也生成了开门记录，但电锁就是没动作。排查时不要一上来就怀疑算法，而是要顺着链路从日志端往锁控端查。
第一步看平台是否有开门指令下发到设备；第二步看设备是否有继电器输出信号，很多鸿蒙门禁的继电器控制是通过GPIO或串口协议，如果应用层没有正确调用底层驱动，日志一样会显示成功；第三步看门禁控制器或电锁电源是否稳定，继电器触点是否老化，锁的供电功率是否足够。另外特别注意设备时间同步问题，如果鸿蒙设备RTC电池没电或者没有配置NTP，重启后时间会回到出厂值，导致平台签名或证书校验失败，表现为“日志成功但平台不认”，进而不开门。所以我每次验收都会检查设备时间是否和标准时间一致。
4.2 白天没问题晚上频繁拒识
这种问题在室外门禁特别常见。白天光线好，人脸识别成功率很高；一到晚上，要么补光灯角度不对，要么红外模式切换不及时，要么宽动态参数没调好，频繁拒识。解决思路不是只有一个“调算法阈值”，而是先看图像质量。
用调试工具抓取夜间识别失败时的人脸图片，观察是否存在过曝、欠曝、偏色、模糊。如果补光灯太强，近处人脸会过曝，远处人脸又太暗，就需要调整补光灯角度和亮度；如果红外模式切换后有重影，可能是红外灯与镜头不匹配，甚至需要更换硬件。还有一种情况是算法模型本身对红外图像不友好，此时需要在夜间使用RGB+红外双模态融合，或者在夜间切换为红外特征比对。总之，夜间问题要分时段采集图像，再用图像质量指标去倒推原因。
4.3 鸿蒙设备重启后“失忆”和断网不恢复
系统层面的稳定性问题，最典型的就是设备断电重启后配置丢失、人脸底库丢失、网络连接不恢复。出现这类问题，多半是应用层没有做数据持久化，或者系统服务没有设置自启动。
我在验收时会做一轮“断电重启测试”：给设备断电再上电，自动恢复后检查四件事——应用进程是否自动启动、底库和配置是否还在、网络IP是否正常获取、门禁控制服务是否恢复。如果失败，可以通过hdc shell查看开机日志和应用启动日志。有些设备厂商的开发板在OTA升级后，会出现驱动签名失效或系统参数被重置，也需要一并处理。验收阶段把这个问题解决掉，否则交付后客户那边一次停电，门禁就变成摆设了。
4.4 底库过大导致识别时间暴涨
人脸识别门禁如果只是几十个人的底库，很多问题都暴露不出来。一旦底库规模上千甚至上万，比对耗时就可能从几十毫秒变成几百毫秒甚至秒级，这是典型的检索效率问题。
我遇到过一个人脸识别项目，底库到2万人之后，端到端响应时间从0.8秒涨到2.5秒，刷卡开门正常，刷脸开门经常超时。排查后发现算法服务没有使用高效的向量索引，每次都是全量比对。优化方案是改用支持IVF或HNSW的向量检索方案，同时按设备分组做底库分片。验收时要特别注意“底库容量-响应时间”的曲线，不能只测100人底库就下结论。可以通过脚本批量扩充测试底库，记录不同规模下的平均比对耗时，确认在合同要求的最大底库下仍然满足响应时间要求。
5. 验收报告与后续运维基线：把评测结果用起来
5.1 一份能追溯的验收报告应该写什么
验收报告不是简单打钩，而是要能追溯到具体硬件、软件、数据和测试条件。我建议报告至少包含这几部分：项目概况与验收依据、测试环境说明、功能项测试矩阵、性能项测试数据、兼容性测试记录、安全测试记录、问题清单与整改情况、遗留风险与建议。
功能项测试矩阵要列明每个用例的编号、模块、操作步骤、预期结果、实际结果、执行人、执行日期。性能项测试数据要附上原始图表，比如不同底库规模下的响应时间曲线、并发压测的吞吐量、72小时资源监控图。问题清单要分等级：致命问题必须解决后才能验收，严重问题要有明确整改计划，一般问题可以在运维期持续改进，建议类问题只做备注。这份报告签完字就是后续维保的依据，马虎不得。
5.2 把验收数据沉淀为运维基线
验收时测出来的性能数据，不应该测完就归档，而应该成为后续运维的基线。我建议把几个关键指标设为日常监控项：设备在线率、人脸识别日通过率、日拒识率、误识告警数、平均开门响应时间、设备CPU和内存占用。
比如验收时确定“正常时间平均开门响应≤1秒”，那运维阶段如果连续三天响应时间超过1.3秒，就要触发告警排查。性能基线还可以用来评估算法模型升级：下次人脸识别模型升级后，不要直接全量上线，先在测试环境用当时的验收测试集做一次回归，对比TAR、FAR、FRR和响应时间，确认没有回退再灰度部署。这样验收的价值才能延续到整个项目生命周期。
最后说一个自己的习惯：每次验收结束，我都会把每个点位的设备SN、系统版本、算法版本、底库数量、补光灯型号、现场照片全部整理到一份“设备台账”里。看起来只是多花了半小时，可一旦交付后客户报故障，对照台账能快速判断是哪一批硬件或哪一版软件的问题，省掉的沟通成本远超当时那点投入。人脸识别门禁项目做到最后，拼的不是算法多酷，而是这套细致程度。
