10.8 小米 SoC 软件测试开发一面面经（35 分钟）

《面试题目》

1. 自我介绍
2. 你对 SoC 软件测试开发这个岗位有多少了解？
3. 你对小米有哪些了解？
4. 你对小米自研芯片了解多少？
5. 集成电路大赛的智能冰箱助手项目中，你具体的贡献是什么？
6. 比赛项目的所有模块你都参与了吗？
7. 你做 SoC 测试的优势和不足有哪些？
8. 实习期间的完整测试流程是怎样的？
9. 实习中你是如何设计测试用例的？
10. 智能测试知识库的搭建思路是什么？如何解决文档缺少的问题？
11. SoC 测试开发中，测试和开发分别涉及哪些内容？
12. 最开始进入公司需要接手的工作有哪些？
13. 测试工作的发版周期是怎么定的？
14. 面试结果一般多久发布？

《参考解析》

「对 SoC 软件测试开发的理解」要拆成三层来讲。 SoC 测试的对象不是单个 App，而是从芯片到系统的一整条链路：底层是驱动与固件（外设、电源、时钟、总线），中间是 HAL 与系统服务，上面是 Android 框架与整机功能。测试开发在其中做两类事——一类是把测试能力做出来，比如自动化框架、用例管理、测试工具与桩件、失败归因平台；另一类是把测试跑起来，比如按模块划分的功能回归、稳定性与压力测试、性能与功耗基线对比。回答时把「测试」和「开发」两条线分开：测试偏用例设计、执行与分析，开发偏框架、平台与工具，两边能力要求不同，这也正好回答了后面的反问。

测试用例设计要给出方法论加一个真实例子。 常用方法有等价类划分、边界值、因果图与判定表、正交实验、场景法，再加上硬件场景特有的组合覆盖（不同机型、不同版本、不同电源状态）。落到智能冰箱助手这类项目上，可以把功能拆成语音唤醒、指令识别、设备控制、异常恢复几条链路，每条按正常、边界、异常三类展开，再补一条长稳测试。面试官真正在意的是两件事：你能不能说明覆盖率够不够的判断依据，以及用例跑挂之后你怎么定位。讲一个「某个失败只在低电量加弱网下复现，最后定位到超时阈值」的例子，比背方法名有说服力得多。

智能知识库的重点是「没有文档怎么办」。 思路通常分三步：先盘点数据来源（现有用例、需求文档、缺陷单、代码注释、接口定义、历史沟通记录），再定结构（按模块、功能、失败模式建立索引，每条知识带出处和更新时间），最后接检索入口（关键词加语义检索，最好能按当前测试任务主动推送相关条目）。文档缺失是常态，可行的补法有三条：从缺陷单和提交记录里反向生成本来没人写的知识；让日常问答在群里自然沉淀并被系统采集入库；只先覆盖几个高频模块，用得上再扩，不要一开始就追求全量。衡量这套东西有没有用的是新人上手时间和重复问题被问的次数，不是入库条数。

履历类问题用「问题—动作—结果」讲，并且只讲自己真做过的部分。 被问「比赛项目的所有模块都参与了吗」，如实说清边界比含糊地全揽更安全——面试官下一句就会追问你没参与那部分的细节。贡献要具体到可验证的东西：负责的模块、写的关键逻辑、解决的具体缺陷，以及结果上的变化（缺陷收敛速度、覆盖了多少场景、省了多少人工）。如果实际做的是集成和联调，就把它当协作与工程能力讲，不硬往算法贡献上靠。

反问环节值得问的是「岗位真实样貌」。 团队在做什么、入职前三个月会接手什么工作、测试与开发的配比、发版节奏怎么定、线上问题怎么处理、结果什么时候通知——这些问题既显得有准备，也能帮自己判断要不要去。前面第 11 到 14 问就是这个方向：问清岗位内容、起步工作、发版周期和结果发布时间，比问薪资细则或加班情况更合适，后者应该通过其他渠道确认。