2022年秋招季已经过去但这套小米测试开发笔试卷里的门道放到现在依然值得拿出来拆一拆。原因很简单它是国内大厂里少有的、把“智能硬件生态测试”考察得如此透彻的卷子。如果你只刷力扣和八股文就去投小米大概率会在这套题上栽跟头——因为它考的不只是代码更是你对“软硬结合”这条链路有多深的理解。我在复盘这套卷子的时候最强烈的感受是小米的测开岗本质是找“懂硬件思维的测试架构师”。整套卷子从 Python 脚本能力、网络协议专项、系统底层机制到场景化用例设计层层递进。这篇文章我来把每个模块的考察意图、底层原理、以及我实测过的解题思路一次性说透帮你把这类“生态型大厂”的测开笔试题摸清规律。1. 这不是一份普通的测开卷先从岗位画像看考察逻辑在动笔逐题分析之前先花点篇幅聊一个更重要的问题小米的测开笔试到底想筛什么样的人这个问题的答案决定了整张卷子的难易判断标准。1.1 智能硬件厂商的测开岗为什么特别看重“链路思维”互联网公司的测开很多情况下面对的是纯软件系统调用接口、操作数据库、处理前端交互。但小米的测试对象里有大量的路由器、网关、智能摄像头、扫地机器人这类硬件设备。这意味着一个 bug 可能出在 App 端也可能出在设备固件甚至出在云端下发的指令序列上。我记得很清楚笔试里有一道题明确涉及“网关与子设备之间的通信状态异常怎么定位是哪一端的问题”。这就是典型的三层链路排查思维设备端、网关端、云端。如果你之前的工作习惯只是对着接口文档写自动化用例遇到这种题往往会无从下手因为你根本不知道“网关掉线”这种问题应该从哪个日志切入。所以我建议所有准备这类笔试的同学先扭转一个认知小米的测开不是“写自动化测试的开发”而是“懂产品链路质量的负责人”。你的代码能力是基础但更重要的是能不能把一条完整的硬件数据链路拆解清楚。1.2 从热搜关键词反推考点分布规律我整理了一下这份试卷相关的热搜和讨论发现高频词集中在几个方向Python 与 miio 库、小米路由器刷机、BL 锁与 CUST 分区、OS 内测答题机制、上位机开发。这几个关键词看似零散实际上背后对应了三个考察维度Python 与 miio 库对应的是“设备控制协议自动化”能力即能不能用代码和硬件对话。刷机、BL 锁、CUST 分区对应的是“系统底层机制与安全策略”的认知也就是懂不懂设备启动链路、分区布局和权限约束。上位机开发对应的是“测控系统的软件侧构建”能力这在硬件测试岗位里几乎是必须项。明白了这三个维度再回头去看卷面上的每一道题你就会发现小米的出题逻辑非常一致不是考你背过多少 API而是考你有没有真正折腾过设备。哪怕你只是给自己的小米手机解过 BL 锁、刷过第三方固件你在答题时的视角都会完全不一样。1.3 这份卷子的适用人群与准备建议如果你正在准备投递小米的测开岗或者已经在流程中这套卷子的复盘价值极高。它适合以下几类人有测试基础、想往智能硬件方向转型的测开工程师。刚毕业、对“软硬结合”测试感兴趣的校招候选人。已经在做 IoT 产品测试、想系统性补强底层原理的从业者。我的建议是不要只盯着算法题刷。小米的笔试算法题难度通常在中等等级真正拉开差距的是后面那些看似“闲聊”的开放题——它们考的是你平时有没有真的把玩过自己测试的那台设备。这也是为什么很多科班出身、代码很强的候选人反而在这套卷子上分数不理想。2. Python 与 miio 实战笔试里的自动化脚本考的是“能跑通”还是“能落地”Python 是小米测开笔试里雷打不动的语言。我复盘了题目发现它不考语法糖也不考冷门包而是把重点放在了一个具体场景上怎么通过 Python 控制小米生态链设备。最典型的代表就是 miio 这个库的运用。2.1 miio 是什么为什么笔试会考它miio 是第三方开发者维护的 Python 库用于与小米智能家居设备进行局域网通信。它的底层协议不是 HTTP而是基于 UDP 的 MiIO 协议设备通过 token 进行认证。笔试考这个点本质上是想确认你有没有真正接触过设备级编程。你可以这样理解App 控制设备走的是云端 → 网关 → 设备的链路而 miio 让你绕开云端直接在局域网内给设备发指令。这在测试中的价值极其巨大——因为自动化测试需要的是“确定性的输入”如果你每次控制设备都走云端网络抖动、云端策略变更都会干扰你的测试结果。而通过 miio 直连设备你可以稳定复现“设备在特定状态下收到指定指令”的场景。这里我给一个实战中反复验证过的写法import asyncio from miio import Vacuum async def control_vacuum(ip: str, token: str, command: str): vacuum Vacuum(ipip, tokentoken) if command start: vacuum.start() elif command pause: vacuum.pause() elif command home: vacuum.home() else: raise ValueError(fUnsupported command: {command}) asyncio.run(control_vacuum(192.168.1.100, token_here, start))这段代码的亮点在于把“设备控制”抽象成了最简接口。笔试如果让你设计一个设备控制模块这个结构可以直接套用。但请注意我实际测试中发现token 的获取是最大的坑——你不能从 App 里直接拿到需要通过特定工具抓取局域网通信包来提取。这个问题在笔试里经常以“如何安全获取设备 token”的方式出现后面我会专门展开。2.2 从“能 API 调用”到“能处理设备异常”差距在这里笔试的题目如果只是让你写一个“调用设备接口”的脚本那太简单了。真实的题目会把各种边界条件抛给你如果设备不在线怎么办如果指令超时怎么办如果设备返回了非预期的状态码怎么办我统计过一份常见的设备控制异常清单大概是这样的异常类型典型表现排查思路设备离线调用接口直接抛出超时先查局域网连通性再查设备供电状态Token 失效认证失败或返回-9999重新抓取 token确认设备固件升级后是否重置了认证信息状态竞争设备正在执行任务收到新指令后行为异常在脚本里增加状态轮询等设备空闲再下发指令多设备并发同时控制多个设备时部分指令丢失检查是否超过路由器 ARP 表上限考虑分批下发笔试的得分点往往不在主流程而在这些异常分支。我见过太多候选人把主流程写得行云流水但一遇到“设备掉线后怎么恢复”就直接卡壳。小米的测试理念里异常恢复路径跟正常路径同等重要——因为你不能保证产线上的设备永远处于理想状态。2.3 实操中的避坑经验局域网直连三原则在笔试的开放性题目里很可能会让你写一段“设备控制方案”。这里我把实际项目中反复踩坑后沉淀的三个原则分享出来第一控制指令必须幂等。像“开始清扫”这种指令设备端必须保证重复收到不会产生叠加任务。你在设计测试用例时也要特意验证这一点。第二所有指令必须有超时机制。我遇到过扫地机器人在执行任务中死机、局域网请求永久无响应的情况。如果没有超时机制你的自动化脚本会永远卡死在那一行。第三设备状态必须在每次操作后主动查询确认。不要假设指令发出就执行成功了因为 UDP 协议是可能丢包的。这三条原则既是笔试答题的加分项也是你入职后真正写设备测试框架时必须遵守的底线。3. 系统底层与安全机制BL 锁、CUST 分区、刷机流程背后的测试意义如果说 Python 部分考察的是自动化基础那小米试卷里关于系统底层机制的内容就是用来筛选“业余玩家”和“专业选手”的分水岭。涉及 BL 锁、CUST 分区、系统签名校验的内容几乎成了小米测开笔试的必考项。3.1 为什么测开要懂 BL 锁和系统签名机制先讲一个真实的测试场景测试一部手机的系统升级功能时你需要验证“从旧版本 OTA 升级到新版本后用户数据是否完整系统功能是否正常”。但如果是一台已经解了 BL 锁、刷了第三方 Root 方案的设备OTA 升级的校验逻辑可能会因为系统分区被修改而过不了验证直接导致升级失败。这时候如果不懂 BL 锁和系统校验机制你甚至会误判成系统缺陷白白浪费整个测试团队的时间。BL 锁BootLoader 锁在 Android 体系里的作用简单类比就是大楼的门禁系统。门禁锁定时只允许启动经过官方签名的系统镜像解锁后才能刷入第三方固件。测试工程师必须知道锁定的设备能够正常通过 OTA 升级而解锁的设备可能会因为分区被修改导致 OTA 无法通过完整性校验。这不是 bug而是安全机制的预期行为。我建议重点背下这个判断逻辑升级失败时优先查看当前 BL 锁状态。如果设备已解锁先上锁重试升级确认问题是否可以复现再决定是否需要提单。这条排查路径在真实工作中能帮你节省大量时间和不必要的扯皮。3.2 CUST 分区与定制化测试的边界关于 CUST 分区是另一个高频考点。CUST 分区在小米设备里通常用于存放运营商定制、地区定制、系统预置应用的配置数据。它在测试中的意义在于你测试的版本行为可能会因为 CUST 分区的不同而不同。举个例子同样是 MIUI 系统在欧洲版固件上某些功能可能是默认关闭的而在国行版上是默认开启的。如果测试人员不明白 CUST 分区的机制就会在“为什么同一个版本在两个设备上表现不一样”的问题上浪费大量时间。我在笔试题的答案里写过这样一个排查流程分享给大家确认两台设备是否存在 CUST 分区配置差异。可以通过getprop查询当前活跃 CUST 配置。比对各版本间 CUST 内容的差异。重点检查预置应用列表、系统默认值配置文件。验证问题在移除 CUST 差异后是否还能复现。这一步能把“CUST 导致的问题”和“系统代码导致的问题”彻底分开。这套流程在笔试里如果在十分钟内写清楚面试官基本就会把你归类为“有系统级测试思维”的候选人。而不仅仅是“会点自动化”。3.3 刷机与线刷流程中测试人员最容易踩的三个坑刷机在测试日常里太常见了但也是风险操作。我在笔试里涉及“测试环境搭建”的题目时会特别强调以下三个坑第一个坑是高通 9008 深度刷机后的驱动问题。线刷时如果设备进入 EDL 模式但电脑没装对驱动刷机工具会一直报“无法连接设备”。这个问题的排查顺序是检查设备管理器里是否识别到“Qualcomm HS-USB QDLoader 9008”设备如果没有重装驱动而非重装刷机工具。第二个坑是版本匹配问题。很多刚入行的测试拿到一个新包就直接开刷结果因版本不兼容导致设备变砖。正确的做法是刷机前先确认当前设备的版本基线对照发布说明里的“可刷基线版本列表”不在列表里时要先升级到中间版本。第三个坑是 BL 状态导致的刷入失败。如果你在 BL 锁定的设备上强刷非官方固件系统会在 boot 阶段校验失败然后卡在开机 logo。这种问题往往需要重新上锁后完整线刷才能恢复。在笔试中把这些坑写进去实际上是在展示你的风险意识。对于硬件厂商来说测开的一个重要职责就是维护测试设备池的可用性一个总是把设备刷成砖的测试人员是不合格的。4. 网络与上位机从 UDP 组播到设备发现再到测控平台搭建在小米的笔试内容里网络协议部分和上位机开发的能力考察往往是一同出现的。因为我所整理的这份笔试样卷里有一道典型的题目如何设计一个 PC 端工具对某台智能设备进行自动化压力测试。要回答好这类问题你需要同时具备网络协议基础知识和上位机开发经验。4.1 设备发现机制从“人找设备”到“代码找设备”家庭环境里一台手机 App 能自动发现旁边的智能设备依赖的是一种叫 UDP 组播的机制。设备上电后会往局域网内的固定端口发送广播包App 监听这个端口就能收到设备的 IP 和设备类型信息。测试工具要实现自动化设备发现也需要模拟同样的逻辑。我这里给一段简化的 Python 实现思路import socket import json UDP_IP 0.0.0.0 UDP_PORT 54321 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((UDP_IP, UDP_PORT)) while True: data, addr sock.recvfrom(1024) device_info json.loads(data.decode(utf-8)) if device_info.get(device_type) gateway: print(fFound gateway at {addr[0]}:{addr[1]}) break实际项目里这个逻辑会加上“连续监听 N 秒、收集所有设备、去重、维护设备列表”等逻辑。笔试不要求你写出完整的生产级代码但你要能画出这个链路的图设备上电 → 发送组播包 → 工具监听 → 解析 → 设备注册。把这个链路讲清楚面试官就会认可你具备 IoT 测试的基本功。4.2 上位机开发的笔试答题框架上位机这个词对很多纯互联网测开来说可能有点陌生但它在硬件厂商的测试岗里极其常见。简单说上位机就是“跑在 PC 上、用来控制和管理下位机设备的软件”。你在 PC 上写一个工具通过串口或网络给设备发指令、收数据、展示状态这就是最基础的上位机。笔试题目如果让你“设计一个设备压力测试上位机”不要慌直接按这个框架搭答案功能层面设备连接管理、指令下发、状态回读、日志采集、测试报告生成。技术选型层面通信层用 Socket 或 pyserial界面层用 PyQt 或 Web 端数据存储用 SQLite 或 InfluxDB。关键设计层面指令下发采用异步队列避免 UI 卡死数据采集与展示分离异常自动重连机制。我强烈建议在答案里体现“异步”这个设计。因为实际设备通信中串口和网络指令都是 IO 操作如果同步执行测试工具在处理一条慢指令时整个界面都会失去响应。用异步或者多线程是成熟上位机的基本素养这也能证明你确实写过相关工具而不是只会背概念。4.3 压力测试场景下的网络层陷阱上位机开发中最容易被笔试追问的是压力测试场景下的网络层问题。比如你要对一个网关设备做“连续 1000 次重启”的稳定性测试每次重启后工具都要重新建立连接并获取设备状态。这个过程最容易踩的坑有三个第一个是 TCP 连接耗尽。如果你每次重连都新建 socket 而不关闭旧连接不用 100 次系统端口就会被占满。正确做法是每次连接用try...finally确保关闭或者使用连接池。第二个是设备重启后 IP 可能变化。如果设备是 DHCP 获取地址重启后 IP 可能会变。工具不能写死旧 IP而要通过设备发现机制重新确认新地址。第三个是日志缓冲区溢出。长时间压力测试会产生海量日志如果不做按大小滚动切割磁盘爆满是迟早的事。这三个坑我在笔试答题里都写过也在真实项目中全部踩过。说句实话凡是能把这些内容写出来的候选人基本都有过“通宵盯着压力测试工具跑”的经历——而小米需要的正是这样的人。5. 测试题干拆解与开放性答题策略让面试官觉得你“懂产品”除了硬核的技术题这套笔试卷的末尾通常会有几道开放性题目比如“设计一个针对智能门锁的测试方案”“如何验证一款新路由器在弱网环境下的稳定性”等。这类题目没有标准答案但恰恰是拉开差距的地方。5.1 拿到开放题第一步不是写方案而是拆题干我看到很多候选人在写开放题时上来就罗列测试点功能测试、性能测试、兼容性测试、安全性测试……这些都没错但太泛了没有任何区分度。正确的做法是先把题干里隐含的产品定义还原出来。以“智能门锁测试方案”这道题为例拆题干的步骤应该是明确产品形态是直连型还是网关型直连型只走蓝牙和 Wi-Fi网关型还要考虑与家庭网络的联动。明确核心用户场景开锁方式有指纹、密码、NFC、远程临时密码每一种开锁方式的优先级和可靠性要求不同。远程开门涉及云端链路指纹开门涉及本地算法识别两者的测试重点完全不同。明确高危场景非法开锁尝试、低电量下的应急供电、固件升级中断导致变砖等这类场景往往比正常场景更能体现测试团队的价值。当你把题干的隐含信息拆到这个程度你的方案就自然有了层次而不会只是“功能性能兼容”的流水账。5.2 我常用的开放性答题模板用例场景优先技术实现为辅笔试开放性题目没有必要写代码但你需要把“场景设计”和“技术验证手段”结合着写。我自己的答题模板分三段供你参考第一段写测试场景全景图按用户使用频率和风险等级分类高频高风险的场景放最前面。第二段写每一类场景的关键验证点比如弱网场景下重点验证 App 端的超时提示是否友好、设备端本地控制是否不受影响。第三段写自动化实现思路明确哪些用例适合用脚本覆盖、哪些必须手工执行。举个例子路由器弱网稳定性测试我给出的方案是使用可编程衰减器模拟不同信号强度控制丢包率和延迟测试用例覆盖“弱网下的视频流传输”“弱网下的设备管理操作”“网络恢复后的自动重连”。最后再用 Python 脚本周期性地向路由器管理接口发送状态查询验证持续监控能力。5.3 笔试里的加分细节写出你“实际做过”的痕迹最后分享一个重要的应试技巧开放性题目中适当加入你实际操作的细节哪怕是很小的点都能让答案明显区别于那些靠背诵产出的人。比如你在写智能门锁测试方案时提到“指纹识别模组在手指沾水的情况下误识率会显著上升需要通过人工汗液模拟来验证”或者写“在固件升级过程中模拟断电验证 UBIFS 文件系统是否会发生损坏”这些细节会让面试官确信你是真的捣鼓过设备而不是在纸上谈兵。我在自己的笔试复盘里反复强调过一个观点不要试图在答案里讨好面试官而要试图展示你在真实工作中的思维习惯。小米的测开笔试不缺“正确但空洞”的答案缺的是“带着实际操作痕迹、能直接转化落地”的思考过程。6. 复盘后的实战建议用一套自测方法查漏补缺这套卷子复盘到这里我想把最终的收获浓缩成几个可执行的建议给正在准备小米测开offer的同学。6.1 按优先级自测你的短板在哪里你不妨按下面这个清单给自己做个自测每一项如果能在一分钟内说出清晰的技术方案说明基本过关如果卡壳那就是接下来要重点补的方向能不能说清 MiIO 协议与 MQTT 协议在智能家居场景中的区别能不能画出一条“手机 App 远程控制扫地机器人”的完整数据链路能不能解释 OTA 升级过程中系统如何校验固件包的签名和完整性能不能给出一个“上位机通过串口控制设备”的最小代码框架能不能快速定位“设备接入局域网后无法被发现”的常见原因我的建议是如果你的自测结果在“设备协议”和“系统底层”这两块偏弱那花两周时间买一台二手的米家设备用 miio 库写个小工具再试着给手机解一次 BL 锁、刷一次官方固件效果远比你刷三个月八股文要好。6.2 从笔试到面试如何把卷面能力转化为谈吐自信笔试只是门票面试才是真正的战场。但你在笔试中积累的解题思路完全可以无缝衔接到面试问答中。尤其是开放性方案的答题框架你把它用在面试的“自我介绍项目经历”环节效果非常好。比如说你简历上写了“负责智能网关的测试工作”面试官问起“你是怎么做的”别只说“我写了自动化用例”。你可以很自然地带出我是从设备入网 → 配网状态 → 局域网控制 → 云端联动这条链路来设计测试分层先打通协议层的自动化再做场景层的业务覆盖遇到网络波动类问题时会结合抓包工具做数据链路定位。这种回答方式就是因为你对笔试卷里的链路思维和协议基础已经足够熟悉形成了自己的表达框架。6.3 保持一个“测试产品经理”的全局视角最后还是想强调一个容易被忽视的观点小米测开笔试里反复出现的题目其实都在传递同一个信号——测试工程师不能只站在“执行者”的角度而要站在“产品质量负责人”的角度去理解产品。当你拿到一台新设备时第一反应不该是“我能用什么工具测”而应该是“这台设备的核心使用场景是什么、哪些环节最容易出风险”。这种思维方式的转变才是这套试卷真正想考的东西。只要你能建立这个全局视角无论笔试题目怎么变你都能找到合适的答题切入口。
2022年秋招季已经过去但这套小米测试开发笔试卷里的门道放到现在依然值得拿出来拆一拆。原因很简单它是国内大厂里少有的、把“智能硬件生态测试”考察得如此透彻的卷子。如果你只刷力扣和八股文就去投小米大概率会在这套题上栽跟头——因为它考的不只是代码更是你对“软硬结合”这条链路有多深的理解。我在复盘这套卷子的时候最强烈的感受是小米的测开岗本质是找“懂硬件思维的测试架构师”。整套卷子从 Python 脚本能力、网络协议专项、系统底层机制到场景化用例设计层层递进。这篇文章我来把每个模块的考察意图、底层原理、以及我实测过的解题思路一次性说透帮你把这类“生态型大厂”的测开笔试题摸清规律。1. 这不是一份普通的测开卷先从岗位画像看考察逻辑在动笔逐题分析之前先花点篇幅聊一个更重要的问题小米的测开笔试到底想筛什么样的人这个问题的答案决定了整张卷子的难易判断标准。1.1 智能硬件厂商的测开岗为什么特别看重“链路思维”互联网公司的测开很多情况下面对的是纯软件系统调用接口、操作数据库、处理前端交互。但小米的测试对象里有大量的路由器、网关、智能摄像头、扫地机器人这类硬件设备。这意味着一个 bug 可能出在 App 端也可能出在设备固件甚至出在云端下发的指令序列上。我记得很清楚笔试里有一道题明确涉及“网关与子设备之间的通信状态异常怎么定位是哪一端的问题”。这就是典型的三层链路排查思维设备端、网关端、云端。如果你之前的工作习惯只是对着接口文档写自动化用例遇到这种题往往会无从下手因为你根本不知道“网关掉线”这种问题应该从哪个日志切入。所以我建议所有准备这类笔试的同学先扭转一个认知小米的测开不是“写自动化测试的开发”而是“懂产品链路质量的负责人”。你的代码能力是基础但更重要的是能不能把一条完整的硬件数据链路拆解清楚。1.2 从热搜关键词反推考点分布规律我整理了一下这份试卷相关的热搜和讨论发现高频词集中在几个方向Python 与 miio 库、小米路由器刷机、BL 锁与 CUST 分区、OS 内测答题机制、上位机开发。这几个关键词看似零散实际上背后对应了三个考察维度Python 与 miio 库对应的是“设备控制协议自动化”能力即能不能用代码和硬件对话。刷机、BL 锁、CUST 分区对应的是“系统底层机制与安全策略”的认知也就是懂不懂设备启动链路、分区布局和权限约束。上位机开发对应的是“测控系统的软件侧构建”能力这在硬件测试岗位里几乎是必须项。明白了这三个维度再回头去看卷面上的每一道题你就会发现小米的出题逻辑非常一致不是考你背过多少 API而是考你有没有真正折腾过设备。哪怕你只是给自己的小米手机解过 BL 锁、刷过第三方固件你在答题时的视角都会完全不一样。1.3 这份卷子的适用人群与准备建议如果你正在准备投递小米的测开岗或者已经在流程中这套卷子的复盘价值极高。它适合以下几类人有测试基础、想往智能硬件方向转型的测开工程师。刚毕业、对“软硬结合”测试感兴趣的校招候选人。已经在做 IoT 产品测试、想系统性补强底层原理的从业者。我的建议是不要只盯着算法题刷。小米的笔试算法题难度通常在中等等级真正拉开差距的是后面那些看似“闲聊”的开放题——它们考的是你平时有没有真的把玩过自己测试的那台设备。这也是为什么很多科班出身、代码很强的候选人反而在这套卷子上分数不理想。2. Python 与 miio 实战笔试里的自动化脚本考的是“能跑通”还是“能落地”Python 是小米测开笔试里雷打不动的语言。我复盘了题目发现它不考语法糖也不考冷门包而是把重点放在了一个具体场景上怎么通过 Python 控制小米生态链设备。最典型的代表就是 miio 这个库的运用。2.1 miio 是什么为什么笔试会考它miio 是第三方开发者维护的 Python 库用于与小米智能家居设备进行局域网通信。它的底层协议不是 HTTP而是基于 UDP 的 MiIO 协议设备通过 token 进行认证。笔试考这个点本质上是想确认你有没有真正接触过设备级编程。你可以这样理解App 控制设备走的是云端 → 网关 → 设备的链路而 miio 让你绕开云端直接在局域网内给设备发指令。这在测试中的价值极其巨大——因为自动化测试需要的是“确定性的输入”如果你每次控制设备都走云端网络抖动、云端策略变更都会干扰你的测试结果。而通过 miio 直连设备你可以稳定复现“设备在特定状态下收到指定指令”的场景。这里我给一个实战中反复验证过的写法import asyncio from miio import Vacuum async def control_vacuum(ip: str, token: str, command: str): vacuum Vacuum(ipip, tokentoken) if command start: vacuum.start() elif command pause: vacuum.pause() elif command home: vacuum.home() else: raise ValueError(fUnsupported command: {command}) asyncio.run(control_vacuum(192.168.1.100, token_here, start))这段代码的亮点在于把“设备控制”抽象成了最简接口。笔试如果让你设计一个设备控制模块这个结构可以直接套用。但请注意我实际测试中发现token 的获取是最大的坑——你不能从 App 里直接拿到需要通过特定工具抓取局域网通信包来提取。这个问题在笔试里经常以“如何安全获取设备 token”的方式出现后面我会专门展开。2.2 从“能 API 调用”到“能处理设备异常”差距在这里笔试的题目如果只是让你写一个“调用设备接口”的脚本那太简单了。真实的题目会把各种边界条件抛给你如果设备不在线怎么办如果指令超时怎么办如果设备返回了非预期的状态码怎么办我统计过一份常见的设备控制异常清单大概是这样的异常类型典型表现排查思路设备离线调用接口直接抛出超时先查局域网连通性再查设备供电状态Token 失效认证失败或返回-9999重新抓取 token确认设备固件升级后是否重置了认证信息状态竞争设备正在执行任务收到新指令后行为异常在脚本里增加状态轮询等设备空闲再下发指令多设备并发同时控制多个设备时部分指令丢失检查是否超过路由器 ARP 表上限考虑分批下发笔试的得分点往往不在主流程而在这些异常分支。我见过太多候选人把主流程写得行云流水但一遇到“设备掉线后怎么恢复”就直接卡壳。小米的测试理念里异常恢复路径跟正常路径同等重要——因为你不能保证产线上的设备永远处于理想状态。2.3 实操中的避坑经验局域网直连三原则在笔试的开放性题目里很可能会让你写一段“设备控制方案”。这里我把实际项目中反复踩坑后沉淀的三个原则分享出来第一控制指令必须幂等。像“开始清扫”这种指令设备端必须保证重复收到不会产生叠加任务。你在设计测试用例时也要特意验证这一点。第二所有指令必须有超时机制。我遇到过扫地机器人在执行任务中死机、局域网请求永久无响应的情况。如果没有超时机制你的自动化脚本会永远卡死在那一行。第三设备状态必须在每次操作后主动查询确认。不要假设指令发出就执行成功了因为 UDP 协议是可能丢包的。这三条原则既是笔试答题的加分项也是你入职后真正写设备测试框架时必须遵守的底线。3. 系统底层与安全机制BL 锁、CUST 分区、刷机流程背后的测试意义如果说 Python 部分考察的是自动化基础那小米试卷里关于系统底层机制的内容就是用来筛选“业余玩家”和“专业选手”的分水岭。涉及 BL 锁、CUST 分区、系统签名校验的内容几乎成了小米测开笔试的必考项。3.1 为什么测开要懂 BL 锁和系统签名机制先讲一个真实的测试场景测试一部手机的系统升级功能时你需要验证“从旧版本 OTA 升级到新版本后用户数据是否完整系统功能是否正常”。但如果是一台已经解了 BL 锁、刷了第三方 Root 方案的设备OTA 升级的校验逻辑可能会因为系统分区被修改而过不了验证直接导致升级失败。这时候如果不懂 BL 锁和系统校验机制你甚至会误判成系统缺陷白白浪费整个测试团队的时间。BL 锁BootLoader 锁在 Android 体系里的作用简单类比就是大楼的门禁系统。门禁锁定时只允许启动经过官方签名的系统镜像解锁后才能刷入第三方固件。测试工程师必须知道锁定的设备能够正常通过 OTA 升级而解锁的设备可能会因为分区被修改导致 OTA 无法通过完整性校验。这不是 bug而是安全机制的预期行为。我建议重点背下这个判断逻辑升级失败时优先查看当前 BL 锁状态。如果设备已解锁先上锁重试升级确认问题是否可以复现再决定是否需要提单。这条排查路径在真实工作中能帮你节省大量时间和不必要的扯皮。3.2 CUST 分区与定制化测试的边界关于 CUST 分区是另一个高频考点。CUST 分区在小米设备里通常用于存放运营商定制、地区定制、系统预置应用的配置数据。它在测试中的意义在于你测试的版本行为可能会因为 CUST 分区的不同而不同。举个例子同样是 MIUI 系统在欧洲版固件上某些功能可能是默认关闭的而在国行版上是默认开启的。如果测试人员不明白 CUST 分区的机制就会在“为什么同一个版本在两个设备上表现不一样”的问题上浪费大量时间。我在笔试题的答案里写过这样一个排查流程分享给大家确认两台设备是否存在 CUST 分区配置差异。可以通过getprop查询当前活跃 CUST 配置。比对各版本间 CUST 内容的差异。重点检查预置应用列表、系统默认值配置文件。验证问题在移除 CUST 差异后是否还能复现。这一步能把“CUST 导致的问题”和“系统代码导致的问题”彻底分开。这套流程在笔试里如果在十分钟内写清楚面试官基本就会把你归类为“有系统级测试思维”的候选人。而不仅仅是“会点自动化”。3.3 刷机与线刷流程中测试人员最容易踩的三个坑刷机在测试日常里太常见了但也是风险操作。我在笔试里涉及“测试环境搭建”的题目时会特别强调以下三个坑第一个坑是高通 9008 深度刷机后的驱动问题。线刷时如果设备进入 EDL 模式但电脑没装对驱动刷机工具会一直报“无法连接设备”。这个问题的排查顺序是检查设备管理器里是否识别到“Qualcomm HS-USB QDLoader 9008”设备如果没有重装驱动而非重装刷机工具。第二个坑是版本匹配问题。很多刚入行的测试拿到一个新包就直接开刷结果因版本不兼容导致设备变砖。正确的做法是刷机前先确认当前设备的版本基线对照发布说明里的“可刷基线版本列表”不在列表里时要先升级到中间版本。第三个坑是 BL 状态导致的刷入失败。如果你在 BL 锁定的设备上强刷非官方固件系统会在 boot 阶段校验失败然后卡在开机 logo。这种问题往往需要重新上锁后完整线刷才能恢复。在笔试中把这些坑写进去实际上是在展示你的风险意识。对于硬件厂商来说测开的一个重要职责就是维护测试设备池的可用性一个总是把设备刷成砖的测试人员是不合格的。4. 网络与上位机从 UDP 组播到设备发现再到测控平台搭建在小米的笔试内容里网络协议部分和上位机开发的能力考察往往是一同出现的。因为我所整理的这份笔试样卷里有一道典型的题目如何设计一个 PC 端工具对某台智能设备进行自动化压力测试。要回答好这类问题你需要同时具备网络协议基础知识和上位机开发经验。4.1 设备发现机制从“人找设备”到“代码找设备”家庭环境里一台手机 App 能自动发现旁边的智能设备依赖的是一种叫 UDP 组播的机制。设备上电后会往局域网内的固定端口发送广播包App 监听这个端口就能收到设备的 IP 和设备类型信息。测试工具要实现自动化设备发现也需要模拟同样的逻辑。我这里给一段简化的 Python 实现思路import socket import json UDP_IP 0.0.0.0 UDP_PORT 54321 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((UDP_IP, UDP_PORT)) while True: data, addr sock.recvfrom(1024) device_info json.loads(data.decode(utf-8)) if device_info.get(device_type) gateway: print(fFound gateway at {addr[0]}:{addr[1]}) break实际项目里这个逻辑会加上“连续监听 N 秒、收集所有设备、去重、维护设备列表”等逻辑。笔试不要求你写出完整的生产级代码但你要能画出这个链路的图设备上电 → 发送组播包 → 工具监听 → 解析 → 设备注册。把这个链路讲清楚面试官就会认可你具备 IoT 测试的基本功。4.2 上位机开发的笔试答题框架上位机这个词对很多纯互联网测开来说可能有点陌生但它在硬件厂商的测试岗里极其常见。简单说上位机就是“跑在 PC 上、用来控制和管理下位机设备的软件”。你在 PC 上写一个工具通过串口或网络给设备发指令、收数据、展示状态这就是最基础的上位机。笔试题目如果让你“设计一个设备压力测试上位机”不要慌直接按这个框架搭答案功能层面设备连接管理、指令下发、状态回读、日志采集、测试报告生成。技术选型层面通信层用 Socket 或 pyserial界面层用 PyQt 或 Web 端数据存储用 SQLite 或 InfluxDB。关键设计层面指令下发采用异步队列避免 UI 卡死数据采集与展示分离异常自动重连机制。我强烈建议在答案里体现“异步”这个设计。因为实际设备通信中串口和网络指令都是 IO 操作如果同步执行测试工具在处理一条慢指令时整个界面都会失去响应。用异步或者多线程是成熟上位机的基本素养这也能证明你确实写过相关工具而不是只会背概念。4.3 压力测试场景下的网络层陷阱上位机开发中最容易被笔试追问的是压力测试场景下的网络层问题。比如你要对一个网关设备做“连续 1000 次重启”的稳定性测试每次重启后工具都要重新建立连接并获取设备状态。这个过程最容易踩的坑有三个第一个是 TCP 连接耗尽。如果你每次重连都新建 socket 而不关闭旧连接不用 100 次系统端口就会被占满。正确做法是每次连接用try...finally确保关闭或者使用连接池。第二个是设备重启后 IP 可能变化。如果设备是 DHCP 获取地址重启后 IP 可能会变。工具不能写死旧 IP而要通过设备发现机制重新确认新地址。第三个是日志缓冲区溢出。长时间压力测试会产生海量日志如果不做按大小滚动切割磁盘爆满是迟早的事。这三个坑我在笔试答题里都写过也在真实项目中全部踩过。说句实话凡是能把这些内容写出来的候选人基本都有过“通宵盯着压力测试工具跑”的经历——而小米需要的正是这样的人。5. 测试题干拆解与开放性答题策略让面试官觉得你“懂产品”除了硬核的技术题这套笔试卷的末尾通常会有几道开放性题目比如“设计一个针对智能门锁的测试方案”“如何验证一款新路由器在弱网环境下的稳定性”等。这类题目没有标准答案但恰恰是拉开差距的地方。5.1 拿到开放题第一步不是写方案而是拆题干我看到很多候选人在写开放题时上来就罗列测试点功能测试、性能测试、兼容性测试、安全性测试……这些都没错但太泛了没有任何区分度。正确的做法是先把题干里隐含的产品定义还原出来。以“智能门锁测试方案”这道题为例拆题干的步骤应该是明确产品形态是直连型还是网关型直连型只走蓝牙和 Wi-Fi网关型还要考虑与家庭网络的联动。明确核心用户场景开锁方式有指纹、密码、NFC、远程临时密码每一种开锁方式的优先级和可靠性要求不同。远程开门涉及云端链路指纹开门涉及本地算法识别两者的测试重点完全不同。明确高危场景非法开锁尝试、低电量下的应急供电、固件升级中断导致变砖等这类场景往往比正常场景更能体现测试团队的价值。当你把题干的隐含信息拆到这个程度你的方案就自然有了层次而不会只是“功能性能兼容”的流水账。5.2 我常用的开放性答题模板用例场景优先技术实现为辅笔试开放性题目没有必要写代码但你需要把“场景设计”和“技术验证手段”结合着写。我自己的答题模板分三段供你参考第一段写测试场景全景图按用户使用频率和风险等级分类高频高风险的场景放最前面。第二段写每一类场景的关键验证点比如弱网场景下重点验证 App 端的超时提示是否友好、设备端本地控制是否不受影响。第三段写自动化实现思路明确哪些用例适合用脚本覆盖、哪些必须手工执行。举个例子路由器弱网稳定性测试我给出的方案是使用可编程衰减器模拟不同信号强度控制丢包率和延迟测试用例覆盖“弱网下的视频流传输”“弱网下的设备管理操作”“网络恢复后的自动重连”。最后再用 Python 脚本周期性地向路由器管理接口发送状态查询验证持续监控能力。5.3 笔试里的加分细节写出你“实际做过”的痕迹最后分享一个重要的应试技巧开放性题目中适当加入你实际操作的细节哪怕是很小的点都能让答案明显区别于那些靠背诵产出的人。比如你在写智能门锁测试方案时提到“指纹识别模组在手指沾水的情况下误识率会显著上升需要通过人工汗液模拟来验证”或者写“在固件升级过程中模拟断电验证 UBIFS 文件系统是否会发生损坏”这些细节会让面试官确信你是真的捣鼓过设备而不是在纸上谈兵。我在自己的笔试复盘里反复强调过一个观点不要试图在答案里讨好面试官而要试图展示你在真实工作中的思维习惯。小米的测开笔试不缺“正确但空洞”的答案缺的是“带着实际操作痕迹、能直接转化落地”的思考过程。6. 复盘后的实战建议用一套自测方法查漏补缺这套卷子复盘到这里我想把最终的收获浓缩成几个可执行的建议给正在准备小米测开offer的同学。6.1 按优先级自测你的短板在哪里你不妨按下面这个清单给自己做个自测每一项如果能在一分钟内说出清晰的技术方案说明基本过关如果卡壳那就是接下来要重点补的方向能不能说清 MiIO 协议与 MQTT 协议在智能家居场景中的区别能不能画出一条“手机 App 远程控制扫地机器人”的完整数据链路能不能解释 OTA 升级过程中系统如何校验固件包的签名和完整性能不能给出一个“上位机通过串口控制设备”的最小代码框架能不能快速定位“设备接入局域网后无法被发现”的常见原因我的建议是如果你的自测结果在“设备协议”和“系统底层”这两块偏弱那花两周时间买一台二手的米家设备用 miio 库写个小工具再试着给手机解一次 BL 锁、刷一次官方固件效果远比你刷三个月八股文要好。6.2 从笔试到面试如何把卷面能力转化为谈吐自信笔试只是门票面试才是真正的战场。但你在笔试中积累的解题思路完全可以无缝衔接到面试问答中。尤其是开放性方案的答题框架你把它用在面试的“自我介绍项目经历”环节效果非常好。比如说你简历上写了“负责智能网关的测试工作”面试官问起“你是怎么做的”别只说“我写了自动化用例”。你可以很自然地带出我是从设备入网 → 配网状态 → 局域网控制 → 云端联动这条链路来设计测试分层先打通协议层的自动化再做场景层的业务覆盖遇到网络波动类问题时会结合抓包工具做数据链路定位。这种回答方式就是因为你对笔试卷里的链路思维和协议基础已经足够熟悉形成了自己的表达框架。6.3 保持一个“测试产品经理”的全局视角最后还是想强调一个容易被忽视的观点小米测开笔试里反复出现的题目其实都在传递同一个信号——测试工程师不能只站在“执行者”的角度而要站在“产品质量负责人”的角度去理解产品。当你拿到一台新设备时第一反应不该是“我能用什么工具测”而应该是“这台设备的核心使用场景是什么、哪些环节最容易出风险”。这种思维方式的转变才是这套试卷真正想考的东西。只要你能建立这个全局视角无论笔试题目怎么变你都能找到合适的答题切入口。
