试产几十台设备中有少量在高温与负载切换时重启。测试认为硬件设计不可靠，硬件认为软件看门狗设置不合理，生产说装配没有问题。面试官想知道你是否能把争论变成可复验的工程证据。

第一步不猜根因，先界定事件

收集发生条件、出现频次、硬件/固件版本、序列号、环境温度、电源配置和重启前日志。定义“重启”的可观测证据：复位原因寄存器、上电复位标志、看门狗记录、电源轨瞬态、异常栈或现场总线记录，不用主观描述代替证据。

NASA工程故障树逻辑拆解范例

为什么要用故障树思考

配图是NASA公开的高层故障树分析示例。它提示我们把“系统重启”顶事件拆解为供电跌落、复位脚干扰、看门狗超时、程序异常等分支，再为每个分支规定能证实或排除的测量手段。它是分析方法示范，并非本项目的实际根因图。

当场应该怎样分工

  • 硬件：检查电源与复位波形，记录负载瞬态并确认探头接法；

  • 软件：保留复位原因及异常现场，增加可回溯日志且避免严重改变时序；

  • 测试：固定温度、负载、操作序列与故障判定；

  • 生产：按批次复核焊接、器件替代、关键工序与追溯记录。

拿什么结束会议

输出问题编号、复现条件、假设清单、负责人与完成日期、测试数据及验证计划。定位后做针对性纠正和回归测试，并评估同批次风险。没有经过复测的“应该没事了”不能视为关闭问题。

面试参考答法

“我不会一开始就判定哪个部门有错，而是先定义重启事件、固化复现步骤，用故障树拆解待验证假设，再安排硬件、软件、测试和生产各自产出数据。整改要有相同条件下的复测结果、版本记录和负责人，最后形成闭环。”

凡亿教育 · 电子工程师面试平台