从我当年收到的笔试链接说起吧。那年秋招我投的是小米的测试开发工程师岗简历刚过初筛邮箱里就躺着一封标题为“小米2020校招测试开发工程师笔试题一”的测评通知。当时心里其实没底因为网上关于小米测试开发岗的真题回忆实在太少大部分人在聊的都是研发岗笔试测试方向的帖子经常被埋没。我硬着头皮点开链接限时作答考完之后最大的感受是这套题不是来考你会背多少面试题的它真正在筛的是“愿不愿意用开发思维做测试”的人。这篇文章不是什么官方答案是我结合当年考场上的回忆、后来带测试团队时给新人出的模拟题以及这几年接触小米生态链产品测试的经验做的一份复盘式解析。如果你正在准备小米的测试开发校招或者想从功能测试往测试开发方向转这篇文章应该能帮你少走不少弯路。1. 从投递简历到收到笔试链接这套题到底在筛什么人1.1 笔试不是考背诵是考“测试脑回路”很多第一次参加测试开发岗笔试的人会犯一个错误把复习重点放在死记硬背概念上比如“什么是软件测试”“V模型和W模型的区别”。但小米这套笔试题一给我的第一印象是——它默认你已经知道这些基础概念不再单独问你“测试的定义”而是直接给你一个场景看你怎么拆解、怎么验证、怎么用代码提高验证效率。我记得当时系统弹出来的说明写得很清楚笔试包含基础题、编程题、测试用例设计题和综合题总时长120分钟。这跟研发岗笔试的纯算法题风格完全不同。测试开发岗的算法题占比不高但一定会考你手写脚本处理测试数据、设计用例覆盖异常场景。这就筛掉了两类人一类是只会“点点点”的纯手工测试另一类是只会刷LeetCode但对产品质量没有感觉的纯编码选手。1.2 整张卷子的题型分布与时间压力先还原一下我印象里的卷面结构不一定跟每一场完全一致但大致是这个比例题型题量建议用时考察目标单选题10题15分钟计算机网络、Linux、数据库、数据结构、Android基础多选题5题10分钟测试概念、性能指标、异常场景识别编程题2题40分钟Python/Java脚本能力重点是测试数据加工和接口校验测试用例设计题1题25分钟功能拆解、边界覆盖、异常场景、可执行性综合题1题30分钟智能硬件或系统级测试方案设计时间上其实非常紧张。选择题里有些是“以下哪个Linux命令能实时查看日志”有些是“TCP三次握手中第二次握手携带的标志位是什么”如果你对这些不熟很容易每道题磨两分钟等做到编程题时发现只剩半小时。我当时的策略是选择题遇到拿不准的直接标记先把后面的大题保住回头再靠排除法处理。这套策略让我在时间截止前把编程题和用例设计题都写完了最后选择题反而有几道是靠第一印象蒙的。补充一个细节这套题虽然是2020年的但它的出题思路到现在依然适用。尤其是智能硬件相关的综合题把“Python miio 小米网关”这类关键词搬进题目里非常符合小米的业务形态。所以准备时不能只刷通用软件测试题还得了解小米生态链产品的测试特点。2. 基础题Linux、数据库、网络一个都没少2.1 Linux命令测试开发的基本盘小米笔试的基础题里Linux相关题目出现频率很高。原因很简单测试环境大多是Linux服务器日志在Linux上CI在Linux上跑性能测试工具也在Linux上跑。你连日志都查不明白后面根本没法定位问题。我记得有一道题大概是某个服务出现异常需要实时查看日志并过滤包含“ERROR”的行应该用下面哪个命令选项里有tail、grep、awk、sed的组合。答案是tail -f app.log | grep ERROR。这里有几个考点tail -f是实时跟踪文件新增内容不是简单查看末尾几行grep ERROR是过滤关键字管道符|把前一个命令的输出交给后一个命令处理。如果你只知道tail -n 100这道题就容易被干扰项带偏。后来我在实际工作中排查线上问题时最常用的也是这套组合再加上grep -E支持正则awk {print $NF}取最后一列基本能应对90%的日志分析场景。再补一道容易考的统计日志文件总行数。答案是wc -l app.log但笔试里可能会混入cat -n、ls -l这种看着像但不对的选项。cat -n是给输出加行号不是统计行数别踩坑。2.2 SQL聚合查询和多表关联是高频考点测试开发笔试里的SQL题通常不会让你写特别复杂的存储过程但一定会考聚合函数和分组统计。原因也好理解——测试过程中需要比对数据库数据比如订单状态、用户信息、设备上报记录你写不出正确的查询语句就没法验证测试结果是否符合预期。小米这套题里有一道类似的有两张表一张是设备信息表device(id, type, model)一张是设备上报记录表report(id, device_id, report_time, status)要求统计每种型号设备上报成功的次数。核心SQL大概是SELECT d.model, COUNT(*) AS success_cnt FROM device d JOIN report r ON d.id r.device_id WHERE r.status success GROUP BY d.model ORDER BY success_cnt DESC;考点有三个JOIN关联条件不能写错WHERE要放在GROUP BY之前COUNT统计的是关联后的行数不是设备表里的行数。很多人会漏掉JOIN直接在report表里按device_id分组这样只能看到设备ID看不到型号等于白做。我当时笔试时其实没有百分之百确定表结构但我会在答案旁边注释“假设device.id与report.device_id为外键关联”这样阅卷人能看懂我的思路。校招笔试很多题并没有唯一标准答案逻辑清晰比结果正确更重要。2.3 计算机网络与数据结构高频但不用死磕计算机网络在测试开发笔试里几乎是必考的HTTP状态码、TCP握手、DNS解析都是常见考点。小米题里我记得有一道问“HTTP 502 Bad Gateway表示什么”选项有“服务器内部错误”“网关或代理服务器收到无效响应”“请求资源不存在”“请求超时”。正确答案是“网关或代理服务器收到无效响应”。这跟测试工作关联很大——你调接口时如果看到502大概率不是被测服务本身挂了而是前置的Nginx或其他网关层出了问题。所以测试开发不能只知道200和404至少要知道5xx这一段的含义500是服务端内部错误502是网关问题503是服务不可用可能过载或维护504是网关超时。数据结构部分我印象中有一道栈相关的题给定入栈顺序1,2,3,4,5问哪个出栈顺序是不可能的。这类题考的是栈的LIFO特性。测试开发岗不需要你手写红黑树但栈、队列、哈希表、链表的基本特性得清楚因为后面设计测试用例时你经常要判断一个数据结构的边界行为。3. 编程题手写一个能跑起来的测试工具3.1 接口返回JSON字段校验脚本编程题是整套卷子的重头戏。小米2020这套题里的编程题不是让写算法而是非常接地气的“测试脚本”。我回忆最清晰的一道题是这样的有一个接口返回JSON数据结构如下{ code: 0, message: success, data: { device_id: 123456, device_name: 米家网关, online: true, firmware_version: 1.4.6_0062 } }要求写一个Python脚本校验以下条件code必须等于0device_id必须是非空字符串且长度不超过32online必须是布尔类型firmware_version必须匹配“数字.数字.数字_数字”的格式如果校验失败打印失败原因如果全部通过打印“PASS”。这道题完全就是测试开发日常工作的缩影。接口联调时不能只看状态码还要校验返回字段的值和类型尤其是布尔类型在Python里1 True是成立的很容易埋雷。我当时是这样写的import re import json def validate_response(resp_text): try: data json.loads(resp_text) except json.JSONDecodeError as e: print(FAIL: JSON解析失败, e) return if data.get(code) ! 0: print(FAIL: code ! 0) return device_id data.get(data, {}).get(device_id, ) if not isinstance(device_id, str) or len(device_id) 0 or len(device_id) 32: print(FAIL: device_id不合法) return online data.get(data, {}).get(online) if not isinstance(online, bool): print(FAIL: online不是布尔类型) return fw data.get(data, {}).get(firmware_version, ) if not re.fullmatch(r\d\.\d\.\d_\d, fw): print(FAIL: firmware_version格式不正确) return print(PASS) # 测试数据 resp_text {code:0,message:success,data:{device_id:123456,device_name:米家网关,online:true,firmware_version:1.4.6_0062}} validate_response(resp_text)这里有几个加分项用json.loads并捕获异常说明你考虑了异常输入用isinstance校验布尔类型而不是直接if online:因为None、0、空字符串都会走False分支没法区分“字段缺失”和“字段值确实是False”用re.fullmatch而不是re.match确保整个字符串都匹配而不是只匹配开头打印了具体失败原因方便定位问题而不是简单输出一个“False”。3.2 日志文件聚合统计第二道编程题我印象里和日志有关让你统计一个接口的耗时分布。文件里每行格式类似2020-09-15 10:00:01 INFO request_idabc123 api/device/status cost123ms 2020-09-15 10:00:03 INFO request_idabc124 api/device/status cost245ms 2020-09-15 10:00:05 ERROR request_idabc125 api/device/status cost500ms要求统计所有请求的平均耗时和P99耗时。这道题考点有两个一是文本解析二是理解百分位数的概念。P99不是说取平均值而是把所有耗时排序后处在99%位置的那个值表示99%的请求耗时都小于等于这个数。我当时的解题思路是先按行解析出cost字段放到列表里然后排序直接取索引为int(len(times) * 0.99) - 1的元素。当然更严谨的做法是用statistics.quantiles但校招笔试环境下手写排序取值更直接也更能体现你理解原理。这道题在性能测试里特别常用因为P99能暴露长尾问题——平均耗时可能很漂亮但总有一小部分请求特别慢这就是用户体验里的“少数派灾难”。3.3 笔试现场怎么写代码才能拿分校招笔试的编程题阅卷通常不是跑一堆测试用例来判分而是人工看代码逻辑。所以有几个习惯会明显加分先写注释标明这个函数输入是什么、输出是什么、校验什么对输入做防御性处理比如空值、null、JSON解析失败变量命名有意义别用a、b、c如果时间不够写完整代码也尽量写伪代码加注释至少让阅卷人看到思路完整。我见过很多同学笔试时一上来就闷头写结果写到一半发现逻辑不对整段划掉重来时间全浪费了。正确做法是先在草稿纸上列清楚校验点再动手写。毕竟测试开发的核心能力之一就是在动手前先想清楚“测什么”。4. 测试用例设计题给你一个功能你从哪下手4.1 用例设计题的标准答题框架整套题里最能拉开差距的是那道测试用例设计题。它没有标准答案但考察的是你有没有一套稳定的测试方法论。我记得题目类型是给一个功能模块要求写出覆盖功能、边界、异常、性能、兼容性的测试用例。我总结的答题框架是五层覆盖法功能层这个功能正常情况下的输入输出边界层最大值、最小值、空值、超长值、特殊字符异常层网络异常、断电、第三方依赖超时、服务端返回错误码性能层大量并发请求、弱网、低内存兼容层不同操作系统版本、不同屏幕尺寸、不同硬件平台。光写“点击按钮看是否跳转”这种用例是拿不到高分的。你需要按照这五层去拆解并且写清楚前置条件、操作步骤、预期结果。哪怕是同一个操作也要区分“首次进入”“重复点击”“连续快速点击”这些场景。4.2 以“小米智能网关添加设备”为例拆解边界与异常我当时在试卷上写的是“米家网关添加子设备”的用例设计现在回忆起来这个场景太适合用来展示测试素养了。因为智能网关涉及App端、云端、设备端三端交互远比单纯测一个网页按钮复杂。功能层至少要有网关处于配网模式时App搜索设备能发现网关输入正确Wi-Fi密码后网关能成功连接网络添加成功后App设备列表出现新网关状态显示“在线”。边界层要想到Wi-Fi密码为空、密码错误、密码包含特殊字符网关距离路由器极远信号只有一格多个网关同时处于配网模式App能否区分设备网关固件版本过低App是否提示先升级。异常层一定要覆盖添加过程中网关断电添加过程中手机切到飞行模式云端响应超时网关已被其他账号绑定App是否给出明确提示。性能层可以写100台设备同时上报状态网关是否出现延迟或丢包快速切换App页面设备列表是否有卡顿。兼容层要写iOS和Android系统版本小米手机和其他品牌手机2.4G Wi-Fi和5G Wi-Fi很多智能设备只支持2.4G这一点特别容易遗漏。如果你想拿更高的分还可以补充一句“网关升级固件后已添加设备是否保持绑定关系”这种场景。这种用例能暴露你在真实项目中踩过坑阅卷人一看就知道你不是只背了书。4.3 从用例设计里看工程素养用例设计题看似考的是细节其实考的是工程判断力。你可以写一百条用例但如果全是低价值的重复场景反而显得没有重点。我在实际带测试新人时经常说不要求你一条不漏但要求你能说出“我先测什么、为什么先测它”。优先级判断依据一般是影响面大的功能先测比如设备添加不了后面全都不用测出现概率高且影响用户操作的场景先测最容易出问题的边界和异常场景要专门列出来低频但致命的问题比如数据丢失、设备失联必须有一席之地。我在卷面上特意把“网关已被其他账号绑定”这种场景标注为“高优先级异常”因为这个场景几乎每个智能家居用户都可能遇到处理不好就会产生大量客诉。这种细节比堆砌五十条无关用例更打动人。5. 小米生态特色题智能硬件与系统级测试5.1 用Python miio操控小米网关的题目原型小米笔试题的独特之处在于它会结合自己的业务出题。我那次笔试的综合题里就有智能硬件相关的内容后来网上也能搜到一些关于“pythonmiio连接小米网关”的讨论说明这类题目并不是个例。这类题一般是给你一个场景你需要在测试环境中用Python脚本控制一台米家网关实现开关操作、获取设备状态并完成自动化验证。miio是很多人常用来跟小米智能设备通信的Python库它封装了设备通信协议。一个最基本的脚本大概是这样的from miio import Gateway gateway Gateway(192.168.1.100, abcdef123456) status gateway.status() print(status)笔试不要求你记住这个库的API但你至少应该知道测试智能硬件时很多操作不能只靠手工点App你需要通过脚本去控制设备才能实现自动化回归。所以题目如果提到“请设计一个自动化验证网关开关状态的方案”你就要往这个方向答通过miio库或App后端接口控制网关开关读取设备上报状态断言目标状态与实际状态一致异常场景加入“设备离线时下发命令”验证是否超时或返回错误重复操作N次验证稳定性。我当年对miio并不熟但我在答案里写了“如果网关支持局域网协议可以通过Python库直接控制否则需要通过云端Open API下发指令”。这说明思路是对的不一定非要写对具体API名称。5.2 固件升级与稳定性测试的考察点综合题里还有一个跟固件升级相关的考察点题目大意是如果新版本的网关固件存在概率性断连问题你作为测试开发工程师会怎么设计测试方案这道题想听的不是“多做几轮回归”而是一套完整的稳定性测试方案。我会从这几个维度展开压力测试模拟大量设备同时在线观察网关在连接数达到上限时的表现长时间老化测试设备持续运行7天甚至更久记录内存占用、连接稳定性、日志是否有异常告警间隔性操作测试模拟用户每天不同时段使用观察是否出现“长时间待机后首次操作无响应”升级回退测试固件升级失败或升级后异常能否自动回滚或手动回滚到上一版本弱网测试用Wi-Fi干扰或网速限制工具模拟弱网环境观察网关重连机制是否完善。如果你能把这些维度写出来阅卷人会认为你不只是会执行测试用例而是能设计测试方案。这恰恰是“测试开发”和“功能测试”的分水岭。5.3 解锁BL锁、刷机与系统测试的联系小米社区里关于“怎么root小米9”“小米pad6pro怎么解bl锁”这类问题的热度一直很高。但从测试开发的角度看BL锁BootLoader锁和刷机不只是玩机话题它和系统级测试有直接关系。测试开发工程师在系统测试中经常要覆盖不同的系统状态。比如用户是否解锁BL锁会直接影响系统升级、应用权限、OTA完整性测试新版本系统时如果设备处于BL锁状态某些底层日志可能无法直接抓取需要调整抓取方案刷机是系统测试的常用手段通过线刷或卡刷把设备恢复到指定版本才能复现“用户从旧版本升级到新版本后出现问题”的场景不同渠道包稳定版、开发版、内测版的测试重点不同稳定版更关注兼容性开发版更关注新功能。我当时在综合题里还写了一句话“如果设备刷机后出现无法开机需要先判断是刷机包本身问题还是用户操作顺序问题再决定是否提单给固件组。”这种对问题归属的判断也是测试开发该有的能力。需要注意的是这种题不会让你写具体的刷机命令而是考察你对“系统状态变化带来的测试风险”有没有感知。所以准备笔试时别只盯着App测试也要看一些系统级测试方案。6. 性能与自动化测试开发岗的“开发”二字体现在哪6.1 性能测试工具选型与指标计算考试中有一道简答题我印象很深如果要测试一个App冷启动时间你会怎么测请列出工具和判断指标。这题看起来简单但很多人会掉进“用手表掐秒”的坑。稍微专业一点的答法是Android平台用adb shell am start -W获取冷启动耗时iOS平台用Xcode Instruments的App Launch模板如果做自动化采集可以把启动命令接入CI每次构建后自动跑一轮汇总到报表。判断指标不只是“平均启动时间”更关键的是P50、P90、P95、P99以及启动时间的分布。我经常打一个比方平均耗时3秒听起来不错但如果P99是10秒就说明有1%的用户每次打开App都要等十秒这部分用户可能已经在卸载边缘了。所以性能测试一定要看长尾指标。笔试如果考性能指标计算常见的有吞吐量QPS请求总数除以总时间平均响应时间所有请求耗时和除以请求数错误率失败请求数除以总请求数P99将耗时排序后处于99%位置的值。我前面编程题里写的P99计算逻辑放到这里就是同一套思路。笔试题目之间往往有这种潜在联系如果你能联想起来答题会更有整体感。6.2 自动化测试框架的设计思路简答题部分还会出现“自动化测试框架如何设计”这种题。我当时写的是基于Appium的PO模式Page Object Model核心思想是把页面元素定位和业务操作分开。页面元素放Page类里业务操作放TestCase里这样页面只要变化只改Page类测试用例不用大规模改动。一个简单的PO示例class DeviceListPage: def __init__(self, driver): self.driver driver self.add_device_btn (id, com.xiaomi.smarthome:id/add_device) def click_add_device(self): self.driver.find_element(*self.add_device_btn).click()笔试也许不要求你写出完整代码但你得说清楚设计原则分层、复用、数据驱动、可维护。如果还能提一句“测试数据用外部文件管理不要写死在代码里”就显得更专业。另外自动化用例不是越多越好。我见过有团队把一堆没多大价值的自动化用例堆到CI里每天跑出来一堆误报最后大家都不看结果了。真正有效的自动化应该是冒烟测试用例少而精核心回归用例才上全量执行。这个思路在校招笔试里说出来会很加分。6.3 持续集成与测试左移小米的研发流程里一定有持续集成所以笔试里出现“你在CI中如何安排测试”这种题也很正常。可以从三个层次回答提交代码后触发单元测试和静态代码扫描尽量早发现低级问题构建完成后自动部署测试包跑冒烟自动化用例冒烟通过后再安排完整的回归测试包括自动化用例和必要的手工探索测试。“测试左移”这个概念当时可能不是所有候选人都知道但你只要表达出“测试不是等开发做完才开始而是从需求评审、代码评审阶段就要介入”阅卷人就会知道你有一定实战认知。这个概念听起来高大上本质上就是别等问题到测试手里才暴露而是想办法让问题在更早的环节被拦截。笔试不需要长篇大论但一定要有这条意识。7. 复盘与建议给准备小米测试开发岗的同学7.1 时间分配策略整套题做下来我最大的经验是一定要先做编程题和综合题再做选择题。原因很简单编程题和综合题是按点给分的你写了思路就有分而选择题选错就是零分。如果时间不够选择题可以靠经验蒙但大题空着基本就凉了。我建议的时间分配是开始先花2分钟扫一遍所有题目判断哪些题有把握先做编程题40分钟宁可代码不完整也要把核心逻辑写出来再做测试用例设计题25分钟列要点为主然后做综合题30分钟写方案框架最后留20分钟做选择题剩余时间检查大题有没有漏掉关键点。7.2 最容易踩的坑准备过程中和实际考试时有几个坑值得单独提醒。第一个坑是忽略异常输入。很多同学写代码时只考虑正常情况比如解析JSON时认真处理了正常结构但没考虑如果接口返回的是一个空字符串、一个数组而不是对象、或者字段缺失脚本会不会直接崩溃。测试开发的日常就是跟各种非预期输入打交道所以代码里一定要有异常处理。第二个坑是测试用例写得太泛。比如写“验证添加设备功能正常”这种用例等于没写。好的用例要写清楚设备型号、网络环境、操作路径、前置条件、预期结果这样别人拿过来就能直接在真实环境里执行。笔试阅卷人最怕看到一堆正确的废话。第三个坑是准备方向跑偏。我在章节开头提过网上有很多关于“小米OS4内测答题”“Beta版申请资格答题”的热搜词这些跟校招笔试题不是一回事。校招笔试考的是测试基础、编程、用例设计和系统方案设计不是考内测资格题。复习时不要被这些关键词带偏老老实实打牢基础即可。第四个坑是手写代码时忘记Python的缩进。笔试平台通常是网页编辑器缩进错误会导致语法报错但你肉眼又看不出来。我的建议是写完代码后从头到尾读一遍确认每个if、for、def下面的缩进层级都一致特别是空行后有没有多按Tab或空格。这个细节很多人栽过。7.3 我个人实际操作的体会如果让我用一句话总结这套题我会说它不是想招一个“会点按钮的人”而是想招一个“能自己造工具来测产品的人”。测试开发工程师的核心竞争力是你能不能用代码把重复劳动干掉能不能在设计用例时想到别人想不到的边界能不能在系统出现概率性故障时拿出一套可复现的压测方案。当年我笔试时Python和miio那部分其实并不熟练但我把自己会的思路都写清楚了接口返回字段要校验什么、设备控制脚本要覆盖哪些异常、固件升级要怎么设计稳定性验证。实际拿到的反馈是“逻辑清晰基础扎实”。所以不要担心自己某个工具没用过笔试看的是你的分析框架不是工具收藏夹。最后分享一个小技巧准备这类笔试时可以用自己的手机和电脑搭一套最小测试环境。比如在电脑上装Python拿到任何一个公开接口就试着写脚本做字段校验和状态断言或者把智能家居设备连上用脚本去读设备状态。这种动手练习比刷一百道选择题都有用。等你坐在考场里看到“给一个JSON写校验脚本”这种题时你会发现它就是你平时练习的翻版。