上个季度我带队做了一批鸿蒙人脸识别门禁的集中验收十个点位分布在不同园区里有室内闸机也有室外铁门中间踩了不少坑。说实话门禁项目难的不是把人脸识别算法跑通而是验收边界太容易模糊——到底算识别通过还是算整机开门通过以及鸿蒙系统、应用层和平台服务之间的分工合同里常常一句话带过。所以这次想把自己整理的一套专用于鸿蒙人脸识别门禁项目的验收与性能评估清单摊开来说给同样做集成商的朋友一个可以抄作业的框架也让甲方技术负责人在评审时知道该关注哪些指标。文章会从项目拆解、评测维度、实操流程、问题排查到报告留存一条线讲完重点解决“测什么、怎么测、怎么判”这三件事。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、系统版本、算法版本、底库数量、补光灯型号、现场照片全部整理到一份“设备台账”里。看起来只是多花了半小时可一旦交付后客户报故障对照台账能快速判断是哪一批硬件或哪一版软件的问题省掉的沟通成本远超当时那点投入。人脸识别门禁项目做到最后拼的不是算法多酷而是这套细致程度。