时间：2025年12月30日
标签：#缺陷分析 #嵌入式测试 #驱动逻辑 #并发测试
1. 缺陷现象
2. 根因分析（Root Cause）
经排查，问题出在底层驱动（.ko）的定时器逻辑上：
- 正常逻辑：应用下发指令 -> 驱动开启蜂鸣器 -> 启动300ms全局定时器 -> 时间到自动关闭。
- 异常逻辑：算法识别速度极快（毫秒级），在第一路指令的 300ms倒计时未结束时，第二路指令到达。驱动层缺乏对“定时器重入”的状态保护，导致新的指令打断/覆盖了正在运行的关闭倒计时，致使“关闭”动作丢失。
3. 解决方案
- 修复方式：更新相关驱动文件（
.ko）。 - 修复原理：在驱动层增加状态防抖与保护逻辑。当定时器正在运行时，若接收到新指令，确保不破坏原有的关闭流程，保证蜂鸣器能正常复位。
4. 测试启示
此次Bug提醒我们在黑盒测试中需关注：
- 硬件并发：不仅关注单次触发，更要验证高频、连续触发下的硬件响应（如蜂鸣器、补光灯）。
- 边界时序：在小于硬件响应周期（如本例300ms）内的重复指令，最容易引发生命周期管理混乱。
附：故障逻辑时序图
[黑光相机触发]↓
[驱动层：蜂鸣器 ON]↓
[启动定时器 (计划300ms后关闭)]↓| (时间流逝仅 100ms...)||-------------> [中辉相机触发 (算法太快，应用层再次下发指令)]| ↓| [驱动层接收新指令]| ↓| [逻辑缺陷：覆盖/打断了正在跑的定时器] 💥 (关键故障点)↓ ↓
(原定的关闭动作失效) (新的定时器也没跑通/状态错乱)↓ ↓
[ ❌ 蜂鸣器 OFF ] [ 🔊 蜂鸣器持续长鸣 ]↓
(直到下一辆车撞线，强行重置状态才会停止)