设备软件测试的困难，是许多缺陷只有机械、传感器和时序共同参与时才出现，而真机昂贵、危险且数量有限。有效策略不是在单元测试与整机测试之间二选一，而是建立从模型到真实硬件的分层验证体系。
1. 测试金字塔要适合设备软件
底层单元测试验证坐标转换、Recipe 校验、状态转换和数据算法；组件测试验证模块控制器与模拟驱动；集成测试连接真实中间件或部分硬件；Hardware-in-the-Loop（HIL）让真实控制软件面对仿真的被控对象或真实控制器；最终再用真机验证物理性能。
越靠下运行越快、故障越容易定位；越靠上保真度越高、成本也越高。不能用少量真机回归替代大量确定性测试。
2. 好的仿真必须模拟失败和时间
“调用即成功”的 Mock 只能验证正常代码路径。设备仿真应包含动作时长、传感器变化、限位、噪声、通信延迟、卡死和断连，并允许测试精确注入故障。
虚拟时钟能快速推进超时和重试场景，避免测试真的等待几分钟。随机故障要记录种子，保证失败可复现。
3. HIL 补上接口与时序缺口
HIL 可连接真实 PLC、运动控制器、I/O 或通信网关，验证电气信号、协议和控制周期。它适合测试急停之外的联锁逻辑、I/O 极性、状态时序和恢复，但不能证明真实机械碰撞距离、振动或热性能。
安全功能仍需按风险采用专门验证，不应因为仿真通过就跳过现场测试。
4. 用契约和回放保护边界
驱动接口、SECS/GEM 消息和数据文件可以做契约测试，保证升级后字段与语义兼容。生产现场采集的脱敏事件序列和原始图像可用于回放，重现罕见问题并形成回归用例。
回放要保留软件、Recipe、校准和时间上下文，否则只能复现数据，不能复现行为。
5. 验证最终状态而不是调用次数
设备测试应断言晶圆位置、资源占用、数据唯一性、报警状态和恢复结果。某个方法被调用一次并不能证明物理流程正确。故障注入后还应检查系统没有悄悄继续、重复加工或遗留锁。
总结
可测试性必须在架构阶段设计：稳定的硬件抽象、显式状态机、可控时间和故障注入点，决定了设备能否在没有真机时被充分验证。本系列从架构走到 HIL，核心始终相同——让软件对物理状态的承诺可定义、可追溯、可证明。