深圳自动门门禁联调怎么验：把授权、开门、保护与状态回读分开核对

先确认测试的是同一扇门、同一个方向

给门位设置一个在平面图、门禁平台、设备标签和验收记录中都能找到的编号。若平台一条记录管理多扇门，先把对应关系拆开。进门与出门也分开说明，不能用“门禁已通”概括两个方向。

对每个方向记录：谁有权限、通过什么方式请求、允许在哪些时段使用、是否需要访客审批、过期后如何失效。公开的测试记录使用匿名角色，如员工、访客、无权限人员，不存储真实人脸图像、证件号或个人通行明细。

还要标出测试时的模式。正常营业、非营业锁闭、临时常开和维修停用，可能会改变同一输入的结果。切换模式前后由谁确认，测试结束恢复到什么状态，都要留下记录，防止为了联调打开的权限一直保留。

把一条“开门成功”拆成五个观察点

表中状态应由对应设备或专业人员确认。例如某个系统只能给出控制指令，不能给出门扇实际到位反馈，就如实写明这个限制。不要为了让界面“看起来完整”，把命令发送成功显示成物理开门成功。

联调时先完成各部分的必要检查，再验证整条通行链。单机条件都不具备就跨系统试动作，出现问题很难定位，还可能掩盖锁具、门机或检测装置本身的异常。

测试矩阵至少覆盖允许、拒绝与到期

正常路径可以从一名已授权角色开始，确认在指定门位、方向、时段能按预期通行。随后换成无权限角色，记录系统在哪一步拒绝，以及现场是否仍存在其他未经说明的开启入口。两条路径都要检查，不能只拍一次刷卡开门的视频。

访客权限应验证生效前、有效期内和失效后的行为。权限修改由有权人员按正式流程进行，测试角色仅供测试，完成后撤销。若平台与本地设备存在同步过程，让供方说明同步状态如何观察；不能把后台保存成功直接当成门位权限已更新。

方向差异也要单列。某个方向允许自由离开，并不自动说明另一方向的授权和锁闭同样正确。涉及疏散等要求，执行经批准的设计与专业核验，不按本文设定一种适用于所有门位的放行逻辑。

断网、断电和消防状态，不合并写“应急正常”

每种异常分别写明触发条件、预期状态、观察位置、恢复步骤和责任方。断网后权限在哪里判断、离线状态怎样提示、恢复后旧权限怎样同步，交由系统供方按实际架构说明。不能把一处网络图标恢复，当作整条业务恢复。

停电与锁具失效状态要结合门位用途、锁具结构、供电方案和批准设计核对。它们不能从锁具名称或自动门驱动原理直接推导。专业人员在项目允许的条件下组织验证，避免随意切断公共系统或影响其他门位。

涉及消防联动时，由项目相应专业人员依据批准文件组织，记录信号来源、门位响应、锁具状态、反馈和恢复权限。测试结束后确认系统退出测试状态。不能通过短接安全输入、屏蔽告警或临时常开，把尚未解决的异常包装成通过。

失败先找断在哪一段，不先调速度和延时

如果授权通过但门不动作，先保留当时的模式、时间和显示记录，再由各责任方核对链条。可能停在权限同步、门锁释放、指令输入或门机自身条件等环节。这里不凭现象直接给某个端子或元件下结论。

如果门已开启而平台仍显示关闭，核对的是反馈来源、反馈定义和显示更新，不应立即改门机动作参数。如果平台显示开门而门扇没有实际移动，也应区分平台记录的是授权事件还是物理状态。

一次只改变已确认需要改变的条件，保留原值、变更原因、执行人和回退办法。修复后，重跑受影响的允许、拒绝和异常恢复项，防止解决一个时段的通行问题，同时放宽了另一个时段的权限。

交接示例：访客二维码过期了，门位仍然接受

以下为假设的联调问题，不是某个项目案例。平台页面显示访客权限已过期，但现场测试仍能进入。此时不能仅截图平台状态就签“权限到期功能通过”，也不应先认定自动门控制器损坏。

记录测试角色、门位、方向、时段和平台操作时间，由门禁方确认权限下发与本地处理，再核对实际触发开门的是哪个入口。也许测试时门位处于常开模式，也许使用了另一项权限；这些都需要证据确认，不能靠猜测替代排查。

问题关闭时应同时保留处理说明与复验结果：同一测试条件下，过期角色是否被拒绝，有效角色是否仍能使用，现场模式是否恢复。只写“重新同步后正常”，不足以向接班人员解释修复了什么。

交付资料要能支持换一家维护单位继续查

建议留下门位图、最终接口点表、型号与版本、角色测试矩阵、模式切换说明、问题与复验记录，以及各方受理范围。账号授权与密钥通过安全渠道移交，不放进公开文档。现场调试账号及时撤销，保留撤销完成记录。

接口说明参看自动门接口点表；保护功能的测试边界参看自动门防夹安全核验。相邻资料帮助准备问题，不能替代深圳具体门位的接口批准与现场验收。