嵌入式测试开发工程师面试题：板卡自动化与故障留证

准备嵌入式测试开发工程师面试，应练习把测试对象、输入刺激、结果判定和设备状态连成一条可复现的链路。只会列 C 语言知识点或背测试术语，难以解释自动化台架为什么会误判。下面用8道自拟场景题，练习固件版本核对、串口日志、设备互斥、超时分类和失败留证，最后给出一份面试前可填写的项目记录。

这些题是编辑团队设计的练习，不是任何企业的内部题库，也不表示出现频率。适用于需要接触板卡、固件和自动化脚本的测试开发岗位；具体接口、仪器和安全要求应以目标产品及 JD 为准。

1. 给一块开发板，怎样设计第一条自动化测试？

先询问可验证的需求。例如要求是“启动后能通过指定接口返回固件版本”，还是“传感器读数满足某项误差条件”？两种需求需要不同的输入和判据。第一条测试宜选择环境清晰、结果明确、不会损坏设备的功能，并写下板卡型号、硬件版本、固件构建标识、连接方式和预期输出。

回答可按这条顺序展开：预约设备，确认电源及连接，核对待测版本，执行输入，采集输出，按需求判定，保存记录并释放设备。每一步都要能报告未完成的原因。接口打不开时，不能继续执行后面的断言，再把空结果标成产品失败。

2. 主机单元测试、仿真和真板测试怎样分工？

可独立运行的解析、算法和状态转换，适合先在主机环境快速验证；依赖特定外设、电气行为或真实启动过程的需求，需要对应硬件证据。仿真有助于扩大回归范围，但某个仿真用例通过，不能自动证明真实板卡上的接口时序或功耗符合要求。选择层级时，应说明该层能观察到什么，以及明确看不到什么。

如果使用 Zephyr，可参考其Twister 官方文档了解构建、平台选择和测试运行方式。面试中应说明自己的项目实际使用了哪种执行环境，不要把工具支持的所有能力都写成自己的实践经验。

3. 串口出现“PASS”，就能判定本轮成功吗？

不能仅匹配一个孤立单词。它可能来自上次运行的缓冲、启动脚本，或另一项测试。应先建立本轮身份：本轮启动后产生的新会话标记、确认过的固件构建标识、测试开始与结束标记。如果产品支持请求编号，还可将回复与该编号关联。不能修改固件时，需要说明现有边界，例如重建串口会话、核对启动记录并限定采集区间。

还要定义完整成功条件：预期步骤是否全部发生、输出值是否有效、结束标记是否出现，以及是否存在应使本轮失败的错误。Zephyr 的console harness支持按正则表达式检查控制台输出；匹配方式是机制，哪些输出足以代表业务成功仍需要测试设计者确定。

4. 两个 CI 任务同时使用一块板，怎么避免互相干扰？

把设备当作需要独占分配的资源，而不是让两个脚本同时尝试打开串口。分配记录至少应关联设备、任务、占用开始时间和释放条件。串口、电源控制口、调试探针若对应同一块板，应作为一个资源组管理，否则一个任务可能在另一个任务采集日志时触发复位。

解释异常退出后的处理也很关键：先保留占用记录及现场，再按可核实的任务状态决定是否回收。固定时间一到就强制释放，可能把仍在执行的任务误判为失效。若仅在单机实现文件锁，就明确其作用范围，不宣称已经解决多主机资源调度。这里考察的是资源所有权与执行边界，而不只是“用了一个锁”。

5. 同一个“超时”，怎样判断是不是固件缺陷？

将构建、烧录、启动等待、命令响应和测试执行分开计时。构建未完成、调试器不可用、板卡没有启动，和正确启动后业务响应超时，是不同的现象。先报告发生在哪一层及已有证据，不急着给根因结论。

超时阈值应来自需求或明确的实验约定。没有依据就先写待确认，不用一次正常运行的耗时随意推导产品上限。不要通过不断增加等待时间掩盖稳定性问题。

6. 如何设计异常输入和恢复测试？

先从接口规范中列出正常值、边界值、无效值以及状态不允许的操作，再给每项写预期行为。例如自拟的串口命令练习可以包含缺少参数、超出允许范围、未知命令和连续输入；预期可能是明确报错、保持原状态或要求重新输入。不能用“没有崩溃”代替全部判据。

恢复测试也要有条件：发生错误后，设备能否执行下一条有效请求？配置是否意外改变？日志是否保留错误原因？涉及断电、压力、电压或温度变化的测试，必须先有获准的设备操作范围和保护措施；面试推演可以说明方案，不能把未经执行的操作写成实测成果。

7. 为什么重跑通过也不能直接关闭缺陷？

先保留首次失败，再比较重跑时哪些条件变了：是否重新烧录、复位了设备、更换了线缆、改变了测试顺序或主机负载。重跑通过说明该轮没有复现同一现象，不能证明首次失败不存在。报告应同时保留首次结果、重跑结果和触发重跑的原因。

可以提出隔离实验：固定固件版本，单独执行失败用例，再恢复原来的用例顺序；一次只改变一个条件，观察是否与某个前置状态相关。描述关联时保持谨慎，若只是某个条件下更易复现，就先写观察结论，不将它包装成已经确认的根因。

8. 怎样组织框架，让失败后也能留下可查的记录？

将设备准备、测试动作、断言和清理分开，并明确哪些准备失败时不能进入正文。pytest 的fixture 文档说明了测试准备与清理的组织方法；清理路径也需要考虑准备阶段部分成功后发生异常的情况。不要把全部资源申请放在一大段操作里，却只在最后安排释放。

Zephyr 的pytest 集成文档介绍了通过 harness 组织测试与设备交互的方式，同时提示集成仍有平台支持范围。项目若采用这一方案，写清实际使用的平台与版本。选择其他框架也可以，重要的是解释如何关联固件、设备、用例和本轮结果，而不是背一个工具名。

用一个案例把8题串起来

以下为虚构练习案例，未进行硬件实测。某温度采集板的串口测试偶尔显示成功，但测试记录里的固件版本仍是上一版。不要先得出“缓存问题”的结论。可以提出三种待验证假设：新固件没有完成烧录、旧日志被当成本轮输出、另一任务使用了同一块板。每个假设分别需要烧录回执、采集区间及设备占用记录来检查。

你的回答可以这样组织：“我先暂停该设备继续进入新任务并保留现有日志，再确认当前运行版本与预期构建是否一致。随后检查本轮开始标记和设备分配记录。定位后补充一条能重现该误判的回归用例，验证版本不一致时不会继续报告业务通过。”这是一种推演思路，实际处置必须遵守项目流程，不能冒充已经完成的排查经历。

面试时先讲一个你实际做过的流程，再用这份记录回答追问。没有台架经验就明确说明自己完成的是主机模拟或课程练习。整理项目责任可参考项目角色怎样填写，需要把经历写入简历时可访问AI简历姬，逐项核对事实后再提交。

本文由AI简历姬编辑团队整理，官方技术资料核验于2026年10月24日。示例用于准备方法和测试设计练习，不构成产品认证或真实面试记录。