先说结论2025年想进小米做测试拼的不再是谁会点工具而是谁能在业务链路里“扛住质量”。这两年我陆续帮几个朋友和小辈做过小米测试岗的面试复盘自己也长期跟进大厂测试团队的招聘趋势发现面试题的侧重点已经明显从“会不会用Postman”变成了“你怎么保证这个功能在真实场景下不出事”。尤其小米这种业务线极宽的公司手机、IoT、汽车、大家电、互联网服务全都有测试岗面试题的覆盖面非常广但高频考点其实非常集中。这篇文章我把2025年小米测试岗面试里反复出现的题目按类别拆开每道题都会讲清楚面试官想考察什么、怎么回答能拿高分、哪些坑不能踩。无论你是准备校招、社招还是打算跳槽到智能硬件方向这篇都可以直接当复习提纲用。1. 2025年小米测试岗面试的底层逻辑从“会点工具”到“能扛质量”先说个真实的观察小米的测试面试题和字节、腾讯那种纯互联网公司的问法有明显差异。互联网大厂偏重高并发、分布式、推荐算法这类纯后端质量的场景而小米因为有硬件业务面试题里大量夹杂“设备和服务的联动”“多端一致性”“跨团队协作质量”这类问题。你会发现同一个测试理论在小米会被带到硬件场景里反复追问。具体到2025年面试官的核心考察逻辑可以概括成三句话第一要懂测试体系不是会某个工具。你说自己会用Selenium面试官下一个问题大概率不是“Selenium怎么定位元素”而是“如果页面从原生切换到H5你的自动化脚本怎么处理这种混合场景”。工具只是起点体系才是重点。第二要有业务敏感度。小米的业务链路太长了一个功能从手机端发起经过云端再到另一个设备响应中间可能涉及推送、账号、网络、协议兼容。面试官会刻意用“多设备联动”“弱网环境”“兼容性矩阵”这类场景来测你对业务链路完整性的理解。第三要有工程化思维。2025年了测试早就不只是提bug。CI流水线上自动跑用例、用例失败自动分析日志、测试数据自动构造恢复这些工程化能力在面试里被反复验证。我见过不少技术不错的候选人挂在第三个维度上。他们能写很漂亮的自动化用例但你问他用例在Jenkins里怎么稳定跑起来失败了怎么定位是环境问题还是代码问题他就答不上来了。这类人面试评价往往是“测试能力OK但工程意识欠缺”。所以这篇文章的题目拆解我特意把“工程化实践类问题”的占比调高了。你在准备时也要注意不要只看题目本身要顺着题目往深处准备两三层。比如一道看似简单的“怎么做接口测试”展开后完全可以延伸到“接口测试和UI测试的数据怎么打通”“接口用例怎么在流水线里串起来”“接口变更时你的用例怎么同步维护”。提示备战小米测试岗别按照“功能测试、自动化测试、性能测试”这种教科书分类去准备。按“业务链路”“工程能力”“底层原理”三个维度准备命中率会高很多。2. 语言与自动化框架Python是入场券框架原理才是分水岭小米测试岗的面试里编程语言几乎是必问项。绝大多数岗位要求Python部分客户端测试岗位会问Java或Kotlin。但2025年面试官问编程题的方式明显升级了不再是“列表推导式怎么写”而是直接把问题嵌到测试场景里。2.1 高频题目Python闭包与装饰器在测试框架里的应用这道题几乎是必考。面试官确实会问装饰器的基本语法但真正的分水岭是你能不能举出测试领域的实际应用场景。可以参考的回答思路装饰器在测试框架里最常见的应用是“失败重试”和“用例前置后置处理”。比如你自己封装一个retry装饰器当断言失败或网络抖动导致用例失败时自动重跑两次第三次仍然失败才真正标记为失败。这比每个用例手动写try except要优雅得多。你最好能现场写出核心代码import functools import time def retry(times3, interval1): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for i in range(times): try: return func(*args, **kwargs) except Exception as e: if i times - 1: raise e time.sleep(interval) return wrapper return decorator写完这段之后面试官通常会追加一个问题“这个装饰器如果用在pytest里和pytest自带的flaky插件有什么区别”你要能答出来flaky插件是pytest生态的标准方案支持按次数重试和按特定异常重试而你手写的装饰器更轻量适合不需要引入额外依赖的小项目。这个对比能体现你对框架生态的了解。另一个高频考点是with上下文管理器这个一般会结合文件读写和数据库连接来问。比如“你用Python做接口测试怎么保证每个用例用完的测试数据都被清理掉”一个优秀回答是用yield实现fixture在用例结束后自动执行清理逻辑这恰好是pytest fixture的核心机制。2.2 高频题目pytest的fixture作用域与conftest设计pytest是小米测试岗面试里出现率最高的框架没有之一。基础问题包括function、class、module、session四个作用域的区别conftest.py的层级加载机制fixture的参数化等。但高分回答需要往工程实践上靠。比如面试官问“你的自动化项目里fixture怎么划分”你可以给出一套完整的分层方案session级fixture启动浏览器驱动、建立数据库连接、初始化全局配置整个测试过程只执行一次。module级fixture加载某个模块共用的测试数据比如订单模块的所有用例都需要预置一批订单数据。function级fixture每个用例独立的前置条件比如登录态、页面跳转、接口mock。这个分层方案的背后逻辑是“执行效率和数据隔离的平衡”。session级fixture最省时间但数据容易互相污染function级fixture最安全但每个用例都重新初始化耗时成倍增长。你给出这个分析面试官就能判断你不是只背了概念而是真的设计过测试框架。再补充一个加分亮点pytest.mark.parametrize数据驱动和fixture结合的使用方式。面试官问你“一个登录接口想测10组账号密码怎么设计用例”标准答案是参数化import pytest pytest.mark.parametrize(username,password,expected, [ (admin, 123456, 200), (admin, wrong, 401), (, 123456, 400), ... ]) def test_login(username, password, expected): resp login_api(username, password) assert resp.status_code expected参数化背后的思想是“测试数据与测试逻辑分离”这正是接口自动化测试的核心设计原则。你主动把这个原则讲出来面试官会认为你对测试框架设计有体系化认知。2.3 实操经验Appium在小米业务场景里的考察重点Appium在热搜词里出现了这很符合小米的情况——大量测试岗位涉及MIUI、米家App、小米汽车App的客户端测试。Appium类题目的高频考点有三个元素定位策略原生页面用resource-id或xpathWebView页面用uiautomator或chromedriver两种混合场景怎么切换context。等待机制implicitly_wait、WebDriverWait、sleep三者的区别以及为什么推荐显式等待而不是固定sleep。真机与模拟器的差异Appium连真机时有哪些坑比如驱动版本不匹配、USB调试权限、网络代理导致无法访问测试环境。这题还有个进阶版本“小米手机上的Appium脚本在MIUI系统上跑偶尔会弹出系统权限弹窗导致元素定位失败怎么处理”参考思路是在用例初始化时通过adb shell appops批量授权或者对弹窗建立统一的处理机制更彻底的做法是在测试环境预置配置文件从源头避免弹窗。3. 接口测试与协议层HTTP之外更要懂业务链路接口测试是测试面试的保留项目但小米的接口测试题喜欢结合真实业务场景来问不会让你干巴巴地答“Postman怎么做断言”。3.1 高频题目从登录接口的token机制拆解到全链路测试“你怎么测试登录接口”这个问题幼儿园级别但面试官会一层层往里挖直到把你的知识边界挖出来。第一层正常的接口测试思路——参数校验、异常参数、密码加密、验证码逻辑、token鉴权。这一层大家都会。第二层token机制细节。面试官会问“token在客户端存哪里怎么防止被抓包泄露如果token过期了用例怎么自动续期”你需要答出token一般存在本地存储更新时通过接口返回的refresh_token重新获取自动化测试中需要封装一个get_token的公共方法用例调用前先判断当前token是否在有效期避免每条用例都重新登录。第三层业务链路层面。登录接口连接着账号系统、风控系统、推送系统、多设备同步。面试官会问“如果用户在新设备上登录老设备上的登录态应该怎么处理”这不是纯接口测试问题而是全链路测试问题。高分的回答是需要同时验证新设备登录成功、老设备收到下线通知、用户的云同步数据在新设备上正常拉取、风控系统识别到设备变更。这一层能答好你和普通功能测试的区别就体现出来了。3.2 高频题目mock与依赖解耦线上问题排查Mock几乎是必考题因为真实的测试环境里你很难保证所有依赖服务都可用。面试官常问“被测服务依赖的第三方支付接口不稳定你怎么继续测试”标准答案是引入mock服务把支付接口替换成预设返回。但高分答案要补充两层内容。第一mock必须分场景。正向场景mock返回成功异常场景mock返回超时或余额不足这样能覆盖到真实接口难以模拟的边界条件。第二mock不能滥用。如果整个测试环境全是mock那测出来的结果真实性很有限。所以mock的核心原则是“只mock不可控的依赖业务逻辑仍然走真实链路”。线上问题排查类题目同样高频。比如“用户反馈支付成功但订单状态没更新你怎么排查”。参考链路先看订单服务日志确认支付回调有没有到达再看消息队列确认回调是否被正确消费最后看数据库确认订单状态更新语句是否执行成功。每一层都要说明用什么工具查、怎么过滤日志关键字、怎么判断是代码bug还是数据问题。3.3 接口测试的工程化实践从单接口到全链路回归基于我和团队的实践接口测试工程化有个常见误区每个接口单独写脚本导致用例之间完全割裂业务链路根本跑不通。面试官会问“你们接口自动化怎么处理业务链路依赖”你要能答出三种常见模式数据准备前置通过调用上游接口或者直接操作数据库把链路前置条件准备好。比如测试订单流转你先调用创建订单接口拿到订单号再继续走支付流程。动态参数传递用全局变量字典存储接口间的依赖数据后续接口从字典里取值。断言分层次接口调用成功后先断言状态码再断言关键业务字段最后拉上数据库确认数据落库正确。这三个模式有一个总原则接口测试要按业务流程组织不要按接口文档目录组织。按文档目录组织看似覆盖率高但很多用例是无效的——它能证明每个接口本身没问题却证明不了业务链路能走通。我建议你们在项目里按“用户主链路”来组织接口自动化用例比如“注册→登录→浏览商品→下单→支付→查询订单”这条主链路把它打造成一条完整的自动化冒烟用例集每次发版前跑一遍。这套经验写到简历里面试官会很感兴趣。4. 性能、稳定性与兼容性测试的深水区小米业务对性能、稳定性、兼容性的要求比纯软件公司高得多。手机发烫掉帧、App在低端机上卡顿、多设备互联时网络抖动——这些场景在小米的面试里高频出现。4.1 高频题目内存测试与设备老化测试热搜词里“内存测试”“设备老化测试全自动执行脚本”直接点出了小米业务的两个方向。内存测试的考察重点是怎么定位App内存泄漏。Android场景下的回答思路是用adb shell dumpsys meminfo抓取内存快照反复操作目标页面对比内存占用是否持续增长进一步用LeakCanary接入自动化测试让泄漏检测自动上报。设备老化测试本质上是长时间运行的稳定性测试。面试官会问“如果让你设计一个老化测试方案你会怎么设计”参考回答框架明确老化场景长时间播放视频、反复切换页面、连续拍照录像、多App并行切换。监控指标CPU占用率、内存占用、页面帧率、温度、crash率。自动化执行用Monkey或自研脚本进行长时间随机操作全程采集性能和稳定性数据。结果分析设置阈值比如内存持续增长超过30%判为疑似泄漏帧率低于某阈值判为卡顿。如果能再讲一下“全自动执行脚本怎么处理中途的崩溃和恢复”这个回答就完整了。一般的做法是脚本里加入守护进程检测到App crash后自动拉取日志、记录现场、重启App继续执行整个老化过程无人值守。4.2 高频题目弱网测试与连接数测试小米的产品大量依赖网络连接。路由器、智能家居设备、手机一切换网络就掉线的场景在面试里都是绝佳考题。弱网测试的高频问法是“你用什么工具模拟弱网你关注哪些指标”你至少要知道Charles和Fiddler可以模拟弱网Android端还可以用adb shell配合Linux的tc命令设置延迟和丢包率。但2025年的面试官会更关注你“关注哪些指标”常见的有弱网下的请求超时时间、重试机制、数据一致性、页面loading态的交互表现。连接数测试更偏底层。面试官可能问“一个智能家居路由器同时连接50台设备你怎么测试稳定性”这个问题的核心不是单台设备的功能而是整个系统的资源占用和调度能力。你需要关注路由器CPU和内存占用、设备重连机制、新设备接入时老设备是否掉线、设备长时间在线后内存是否泄漏。涉及嵌入式设备测试时如果路由器本身提供了命令行接口通常还会用脚本批量模拟设备连接观察设备连接数的上限和系统的资源变化。4.3 实操经验兼容性测试矩阵怎么设计小米既有手机又有电视、手表、音箱对兼容性测试的重视程度远高于普通互联网公司。面试官会问“一个功能要在小米全系设备上线你怎么设计兼容性测试方案”你要答出三个维度设备选择不可能全设备测试要按市场占有率、屏幕尺寸、系统版本、硬件配置做正交分析选出覆盖度最高的机型组合。系统版本覆盖不同Android版本对权限管理、后台机制、推流协议的处理不同至少要覆盖最高、最低、主流三个版本段。多端联动场景这是小米特有的兼容性测试场景。比如一个“手机投屏到电视”的功能要覆盖手机不同分辨率、电视不同系统版本、连接方式不同DLNA、Miracast、私有协议几种组合。回答完毕后如果你能主动补充“推广到其他品牌设备时如何兼容”说明你有跨品牌视野会比只盯着小米设备的候选人强很多。5. 小米特色业务方向智能座舱、车载与IoT测试小米造车之后测试岗位的需求量明显增加智能座舱测试、车载测试相关面试题成了新热点。热搜词里有“车载测试”“智能座舱测试”“汽车电子测试”“智能网联汽车道路测试与示范应用安全通行规范”这绝对不是偶然。5.1 高频题目车载测试和普通App测试的差异这道题基本是车载测试岗位的必问题。参考回答要点安全等级不同车载功能直接关系驾驶安全测试对缺陷的容忍度极低有些严重缺陷甚至需要上升到功能安全等级来管理。系统环境不同车机系统很多场景下不能简单重启关机开机流程很长测试环境搭建复杂度高。交互模式不同驾驶场景下更多依赖语音交互和实体按键要专门测试语音识别准确率、方向盘按键操作响应速度。网络环境不同车辆在行驶过程中网络切换频繁地库无信号、高速移动切换基站、隧道内弱网网络测试的优先级极高。升级机制不同车机系统升级不像手机重启就能完成还涉及整车电子系统之间的兼容测试要覆盖不同版本之间的回退和保留数据场景。每次听到候选人只会答“做功能测试和自动化测试”我就会觉得可惜。这道题最好答出“测试策略因场景而变”的思路在车载场景里安全优先、稳定优先功能测试要围绕这些来设计。5.2 高频题目智能座舱的多屏交互测试智能座舱的核心特点是多屏多端仪表盘、中控屏、副驾娱乐屏、后排屏、手机投屏多个屏幕之间还可能联动。面试官会问“中控屏播放视频副驾屏同时导航两个屏的交互怎么测试”参考思路功能维度每个屏幕单独的功能要测通多屏同时使用的资源竞争要测比如同时播放视频会不会导致系统卡顿或声音串扰。交互维度多屏联动逻辑要重点测。用户在中控屏操作后副驾屏的状态是否正确刷新副驾屏请求导航是否覆盖了中控屏当前内容。性能维度多屏同时工作时的CPU、内存、GPU占用、帧率变化。异常维度某一屏出现异常是否影响其他屏正常工作。这道题的加分项是提到“分心驾驶”场景——驾车过程中副驾屏和后排屏的内容不应该导致驾驶员分心所以某些娱乐功能必须在行车状态下被限制。这体现了你对行业场景的理解而不只是技术层面的测试设计。5.3 智能网联汽车的“道路测试”与“台架测试”“智能网联汽车道路测试与示范应用安全通行规范”挂在热搜词里说明这块内容在2025年的关注度确实高。面试官问“道路测试怎么测”时你要能区分台架测试和道路测试台架测试在实验室环境模拟整车状态测试转向、制动、动力、自动驾驶算法等。优点是环境可控、可重复适合开发和回归。道路测试在真实道路环境验证系统功能、可靠性、安全性。优点是场景真实但不可控因素多重复成本高。一个高质量的测试方案应该两者结合先用台架测试跑大量自动化场景再用道路测试做重点验证。面试时可以展开讲一下道路测试前需要准备的checklist比如测试路线规划、天气要求、安全员配置、数据采集设备、应急预案等。这些细节能看出你不是只会纸上谈兵。6. 测试深度题与场景设计题测试思维决定你能走多远不同于前面的知识类问题这类题目没有标准答案面试官考察的是你的测试思维、逻辑完整性和对测试本质的理解。这类题答得好不好往往直接决定你的定级结果。6.1 高频题目给你一个功能你怎么设计测试用例这是最经典的场景设计题。举个例子面试官说“设计一个温度计功能App根据位置和天气显示当前温度”很多人就开始罗列显示温度对不对、单位能不能切换、定位准不准……然后面试官追问“如果温度传感器数据返回异常你怎么办”很多人就卡住了。高分回答要掌握一个核心方法论从“输入-处理-输出”三个维度做穷举再从“正常-异常-边界”三个状态做深度挖掘。拿温度计功能举例你至少能拆出这些测试点正常场景定位成功、温度正常返回、UI显示正确。异常场景定位被拒绝、天气接口超时返回、接口返回空值、网络断开。边界场景温度极高比如50度、温度极低比如零下40度、用户切换到国外城市显示非摄氏温度。联动场景城市切换后温度是否刷新、系统语言切换后温度单位是否变化。再用“正常路径→异常路径→灾难路径”happy path, sad path, disaster path三层法做第二轮挖掘正常路径是用户顺利看到温度异常路径是后台接口报错但App给了友好提示灾难路径是整个后台服务宕机App是否有兜底方案。面试官在这个环节看的不是你能列多少条用例而是你的用例是否形成了完整的逻辑闭环有没有明显的遗漏面。6.2 高频题目自动化用例稳定性的治理方案最近我被问到最多的面试题是“自动化用例今天能过明天不能过怎么排查和治理”这道题之所以高频是因为几乎每个公司都面临同样的痛点。如果你能给出完整的分析框架面试官会立刻把你归到“有实战经验”的那一类。参考回答框架第一层分层定位先把不稳定用例按原因分桶。典型的有数据问题测试数据被改变或未清理、环境问题依赖服务不可用或网络抖动、等待问题元素加载慢但脚本等得不够、代码问题产品本身有bug或脚本断言写错。第二层精确治理数据问题通过测试数据自动准备和清理机制解决环境问题通过健康检查脚本在套件执行前先确认环境可用等待问题统一替换成显式等待并设置合理超时时间。第三层机制兜底失败用例自动重跑一次并且将重跑结果和首次结果同时记录在报告里方便区分“偶发失败”和“真实失败”。第四层持续运营每次跑完自动生成稳定性报告追踪每一条用例的失败率和失败原因定期复盘并优化。这个框架每一条都能展开讲很久。如果你在面试时能在“数据问题”这个环节讲一个真实的案例比如“某个用例依赖订单号订单号被别的用例删了导致查找不到”面试官对你的印象分会大幅提升。6.3 安全测试与渗透测试的入门考察安全测试在小米的招聘需求里越来越常见。如果你面试的是安全测试岗必须准备这些基础内容OWASP Top 10里最常见的Web漏洞都是什么、XSS和SQL注入的区别、HTTPS和SSL/TLS的原理。如果是功能测试岗被问到安全测试面试官通常只关注你有没有安全测试意识。一个比较简单的高频问题“App端的接口被直接抓包调用怎么防护”参考思路核心是加固传输层和服务端校验。一方面用HTTPS加密传输关键字段做签名防篡改另一方面服务端不能只依赖客户端传参要校验token、设备指纹、频率控制。其次是客户端侧的防护比如禁止第三方调试、检测模拟器、关键数据不落地存储。如果候选人还能提到“接口加解密逻辑要放到服务端不要把密钥写死在客户端”说明确实理解安全测试的实质而不仅仅是停留在用Burp Suite抓包的层面。7. 自动化测试进阶从用例到流水线2025年的测试岗位已经很难接受“只会手动点功能”的人了。“自动化测试”四个字在热搜词里反复出现而面试官问自动化一定会问到CI/CD和工程化实践。7.1 高频题目你们公司的自动化测试怎么接入CI流水线这道题几乎是一道分水岭。如果你的答案只有“用例在Jenkins上定时跑”基本等于没答。高分答案要包含这些环节触发策略不是所有用例都进CI。冒烟用例在开发提交代码后立即触发全量回归在每日凌晨跑发布前再跑一次关键链路用例。不同触发策略对应不同的用例集合和运行时长要求。失败处理用例失败后要有失败截图、日志、关键接口返回值的自动收集并且能自动归类到“环境失败”和“业务失败”不能一股脑推给开发。报告展示测试报告要自动推送到团队群包含用例总数、通过率、失败详情、失败截图让开发不看测试平台就能定位问题。环境管理测试环境要做到一键部署、一键恢复保证CI跑之前环境是干净的。环境问题导致的失败要能自动识别并跳过重跑。这个题的背后是团队开发运维一体化的实践。你答得越完整说明你越接近“质量内建”的思路这不只是测试的活而是整个研发链路都在为质量负责。7.2 高频题目测试数据怎么管理测试数据管理是自动化测试落地时最头疼的问题。面试官会问“用例跑之前要准备数据跑完要清理数据你怎么设计”参考方案接口造数通过调用业务接口创建测试数据比如创建订单、添加商品。优势是走真实链路数据完整缺点是比较慢且依赖被测服务可用。数据库直接插入为了测试速度批量往数据库预置数据。优势是快缺点是绕过了业务逻辑造出来的数据可能不符合真实状态。数据模板参数化预先设计一批基础数据模板用模板自动生成带唯一编号的数据防止多次执行时数据互相冲突。预留专用账号和专用数据在测试环境长期保留一批专用数据比如固定账号、固定商品ID用例直接引用这些数据跑完不清除方便排查。面试时把几种方案的优缺点都说清楚再说出“要根据case类型选择方案”面试官就满意了。比如纯接口链路用例用接口造数更可靠大数据量压测用数据库批量插入更快。7.3 面试小技巧结合真实项目讲自动化测试成果围绕自动化测试的最后一类题目是把问题包装成“你做过的项目”比如“你们自动化测试的收益怎么衡量投入产出比怎么算”你可以用数据说话原来手工回归需要3天现在自动化回归只需要2小时线上漏测率下降了多少自动化发现的高级别缺陷有多少个。面试官想听的其实是“你做的自动化到底有没有实际价值”而不是“你用的是什么框架”。框架和技术栈只是手段价值才是核心。8. 面试实战经验总结与心态建议说了这么多题目最后聊点面试实战层面的东西。我自己观察周围拿offer的候选人基本都有一个共同特征回答问题时的思路打开了一个完整的“测试空间”而不是只答一个孤立的点。一个常见的失败案例是面试官问“你怎么测微信的发送图片功能”候选人只答“发一张图看能不能收到”。这就是典型的测试思维没有打开。高分的回答会先搞清楚测的是微信还是公众号里的图片发送再拆解图片本身的类型和大小、发送网络环境、接收端兼容性、异常场景发送中断、图片损坏、多端同步手机发完Pad是否同步显示等。把测试空间撑开面试官一眼就能看出你的测试素养。再给几条实用的准备建议务必准备一个完整深度的项目复盘。把你自己做过的一个测试项目从需求评审到上线回归完整讲清楚包括你负责的范围、遇到的难点、怎么解决的、带来了什么量化收益。这个比刷一百道面试题更有用。小米的面试官喜欢深挖项目细节他会从你项目里挑出很多角度来追问。动手写一个小型测试框架。不用复杂Python pytest requests支持用例参数化、数据驱动、报告生成、失败截图和重试机制。整个过程会让你对各种工具的组合逻辑有更深入理解面试时遇到工具类题目都能举出实例。关注小米自己生态里的App和系统特点。可以提前去看看MIUI的发布说明了解他们在系统更新里调整了哪些测试相关的能力也可以在面试聊到具体业务时提一下你体验过的功能面试官会觉得你是真的对产品有兴趣而不是海投简历。准备两个方向的技术深挖。比如把“弱网测试工具怎么选”“接口自动化怎么做数据隔离”这类题目对应的原理和实践理清楚确保问到细节时能讲满五到十分钟。最后说一个很多人容易忽略的细节面试中问清楚岗位对应的业务线和团队规模。小米的测试岗位分布很广有偏向手机ROM的有偏向IOT设备的有偏向汽车智能座舱的有偏向互联网服务的。每一条业务线的面试题侧重点确实很不一样提前了解投放岗位的业务能让准备更聚焦。祝各位顺利拿到心仪的offer有具体问题可以直接在评论区聊我看到都会回。 2025小米测试岗面试高频题与备战策略
先说结论2025年想进小米做测试拼的不再是谁会点工具而是谁能在业务链路里“扛住质量”。这两年我陆续帮几个朋友和小辈做过小米测试岗的面试复盘自己也长期跟进大厂测试团队的招聘趋势发现面试题的侧重点已经明显从“会不会用Postman”变成了“你怎么保证这个功能在真实场景下不出事”。尤其小米这种业务线极宽的公司手机、IoT、汽车、大家电、互联网服务全都有测试岗面试题的覆盖面非常广但高频考点其实非常集中。这篇文章我把2025年小米测试岗面试里反复出现的题目按类别拆开每道题都会讲清楚面试官想考察什么、怎么回答能拿高分、哪些坑不能踩。无论你是准备校招、社招还是打算跳槽到智能硬件方向这篇都可以直接当复习提纲用。1. 2025年小米测试岗面试的底层逻辑从“会点工具”到“能扛质量”先说个真实的观察小米的测试面试题和字节、腾讯那种纯互联网公司的问法有明显差异。互联网大厂偏重高并发、分布式、推荐算法这类纯后端质量的场景而小米因为有硬件业务面试题里大量夹杂“设备和服务的联动”“多端一致性”“跨团队协作质量”这类问题。你会发现同一个测试理论在小米会被带到硬件场景里反复追问。具体到2025年面试官的核心考察逻辑可以概括成三句话第一要懂测试体系不是会某个工具。你说自己会用Selenium面试官下一个问题大概率不是“Selenium怎么定位元素”而是“如果页面从原生切换到H5你的自动化脚本怎么处理这种混合场景”。工具只是起点体系才是重点。第二要有业务敏感度。小米的业务链路太长了一个功能从手机端发起经过云端再到另一个设备响应中间可能涉及推送、账号、网络、协议兼容。面试官会刻意用“多设备联动”“弱网环境”“兼容性矩阵”这类场景来测你对业务链路完整性的理解。第三要有工程化思维。2025年了测试早就不只是提bug。CI流水线上自动跑用例、用例失败自动分析日志、测试数据自动构造恢复这些工程化能力在面试里被反复验证。我见过不少技术不错的候选人挂在第三个维度上。他们能写很漂亮的自动化用例但你问他用例在Jenkins里怎么稳定跑起来失败了怎么定位是环境问题还是代码问题他就答不上来了。这类人面试评价往往是“测试能力OK但工程意识欠缺”。所以这篇文章的题目拆解我特意把“工程化实践类问题”的占比调高了。你在准备时也要注意不要只看题目本身要顺着题目往深处准备两三层。比如一道看似简单的“怎么做接口测试”展开后完全可以延伸到“接口测试和UI测试的数据怎么打通”“接口用例怎么在流水线里串起来”“接口变更时你的用例怎么同步维护”。提示备战小米测试岗别按照“功能测试、自动化测试、性能测试”这种教科书分类去准备。按“业务链路”“工程能力”“底层原理”三个维度准备命中率会高很多。2. 语言与自动化框架Python是入场券框架原理才是分水岭小米测试岗的面试里编程语言几乎是必问项。绝大多数岗位要求Python部分客户端测试岗位会问Java或Kotlin。但2025年面试官问编程题的方式明显升级了不再是“列表推导式怎么写”而是直接把问题嵌到测试场景里。2.1 高频题目Python闭包与装饰器在测试框架里的应用这道题几乎是必考。面试官确实会问装饰器的基本语法但真正的分水岭是你能不能举出测试领域的实际应用场景。可以参考的回答思路装饰器在测试框架里最常见的应用是“失败重试”和“用例前置后置处理”。比如你自己封装一个retry装饰器当断言失败或网络抖动导致用例失败时自动重跑两次第三次仍然失败才真正标记为失败。这比每个用例手动写try except要优雅得多。你最好能现场写出核心代码import functools import time def retry(times3, interval1): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for i in range(times): try: return func(*args, **kwargs) except Exception as e: if i times - 1: raise e time.sleep(interval) return wrapper return decorator写完这段之后面试官通常会追加一个问题“这个装饰器如果用在pytest里和pytest自带的flaky插件有什么区别”你要能答出来flaky插件是pytest生态的标准方案支持按次数重试和按特定异常重试而你手写的装饰器更轻量适合不需要引入额外依赖的小项目。这个对比能体现你对框架生态的了解。另一个高频考点是with上下文管理器这个一般会结合文件读写和数据库连接来问。比如“你用Python做接口测试怎么保证每个用例用完的测试数据都被清理掉”一个优秀回答是用yield实现fixture在用例结束后自动执行清理逻辑这恰好是pytest fixture的核心机制。2.2 高频题目pytest的fixture作用域与conftest设计pytest是小米测试岗面试里出现率最高的框架没有之一。基础问题包括function、class、module、session四个作用域的区别conftest.py的层级加载机制fixture的参数化等。但高分回答需要往工程实践上靠。比如面试官问“你的自动化项目里fixture怎么划分”你可以给出一套完整的分层方案session级fixture启动浏览器驱动、建立数据库连接、初始化全局配置整个测试过程只执行一次。module级fixture加载某个模块共用的测试数据比如订单模块的所有用例都需要预置一批订单数据。function级fixture每个用例独立的前置条件比如登录态、页面跳转、接口mock。这个分层方案的背后逻辑是“执行效率和数据隔离的平衡”。session级fixture最省时间但数据容易互相污染function级fixture最安全但每个用例都重新初始化耗时成倍增长。你给出这个分析面试官就能判断你不是只背了概念而是真的设计过测试框架。再补充一个加分亮点pytest.mark.parametrize数据驱动和fixture结合的使用方式。面试官问你“一个登录接口想测10组账号密码怎么设计用例”标准答案是参数化import pytest pytest.mark.parametrize(username,password,expected, [ (admin, 123456, 200), (admin, wrong, 401), (, 123456, 400), ... ]) def test_login(username, password, expected): resp login_api(username, password) assert resp.status_code expected参数化背后的思想是“测试数据与测试逻辑分离”这正是接口自动化测试的核心设计原则。你主动把这个原则讲出来面试官会认为你对测试框架设计有体系化认知。2.3 实操经验Appium在小米业务场景里的考察重点Appium在热搜词里出现了这很符合小米的情况——大量测试岗位涉及MIUI、米家App、小米汽车App的客户端测试。Appium类题目的高频考点有三个元素定位策略原生页面用resource-id或xpathWebView页面用uiautomator或chromedriver两种混合场景怎么切换context。等待机制implicitly_wait、WebDriverWait、sleep三者的区别以及为什么推荐显式等待而不是固定sleep。真机与模拟器的差异Appium连真机时有哪些坑比如驱动版本不匹配、USB调试权限、网络代理导致无法访问测试环境。这题还有个进阶版本“小米手机上的Appium脚本在MIUI系统上跑偶尔会弹出系统权限弹窗导致元素定位失败怎么处理”参考思路是在用例初始化时通过adb shell appops批量授权或者对弹窗建立统一的处理机制更彻底的做法是在测试环境预置配置文件从源头避免弹窗。3. 接口测试与协议层HTTP之外更要懂业务链路接口测试是测试面试的保留项目但小米的接口测试题喜欢结合真实业务场景来问不会让你干巴巴地答“Postman怎么做断言”。3.1 高频题目从登录接口的token机制拆解到全链路测试“你怎么测试登录接口”这个问题幼儿园级别但面试官会一层层往里挖直到把你的知识边界挖出来。第一层正常的接口测试思路——参数校验、异常参数、密码加密、验证码逻辑、token鉴权。这一层大家都会。第二层token机制细节。面试官会问“token在客户端存哪里怎么防止被抓包泄露如果token过期了用例怎么自动续期”你需要答出token一般存在本地存储更新时通过接口返回的refresh_token重新获取自动化测试中需要封装一个get_token的公共方法用例调用前先判断当前token是否在有效期避免每条用例都重新登录。第三层业务链路层面。登录接口连接着账号系统、风控系统、推送系统、多设备同步。面试官会问“如果用户在新设备上登录老设备上的登录态应该怎么处理”这不是纯接口测试问题而是全链路测试问题。高分的回答是需要同时验证新设备登录成功、老设备收到下线通知、用户的云同步数据在新设备上正常拉取、风控系统识别到设备变更。这一层能答好你和普通功能测试的区别就体现出来了。3.2 高频题目mock与依赖解耦线上问题排查Mock几乎是必考题因为真实的测试环境里你很难保证所有依赖服务都可用。面试官常问“被测服务依赖的第三方支付接口不稳定你怎么继续测试”标准答案是引入mock服务把支付接口替换成预设返回。但高分答案要补充两层内容。第一mock必须分场景。正向场景mock返回成功异常场景mock返回超时或余额不足这样能覆盖到真实接口难以模拟的边界条件。第二mock不能滥用。如果整个测试环境全是mock那测出来的结果真实性很有限。所以mock的核心原则是“只mock不可控的依赖业务逻辑仍然走真实链路”。线上问题排查类题目同样高频。比如“用户反馈支付成功但订单状态没更新你怎么排查”。参考链路先看订单服务日志确认支付回调有没有到达再看消息队列确认回调是否被正确消费最后看数据库确认订单状态更新语句是否执行成功。每一层都要说明用什么工具查、怎么过滤日志关键字、怎么判断是代码bug还是数据问题。3.3 接口测试的工程化实践从单接口到全链路回归基于我和团队的实践接口测试工程化有个常见误区每个接口单独写脚本导致用例之间完全割裂业务链路根本跑不通。面试官会问“你们接口自动化怎么处理业务链路依赖”你要能答出三种常见模式数据准备前置通过调用上游接口或者直接操作数据库把链路前置条件准备好。比如测试订单流转你先调用创建订单接口拿到订单号再继续走支付流程。动态参数传递用全局变量字典存储接口间的依赖数据后续接口从字典里取值。断言分层次接口调用成功后先断言状态码再断言关键业务字段最后拉上数据库确认数据落库正确。这三个模式有一个总原则接口测试要按业务流程组织不要按接口文档目录组织。按文档目录组织看似覆盖率高但很多用例是无效的——它能证明每个接口本身没问题却证明不了业务链路能走通。我建议你们在项目里按“用户主链路”来组织接口自动化用例比如“注册→登录→浏览商品→下单→支付→查询订单”这条主链路把它打造成一条完整的自动化冒烟用例集每次发版前跑一遍。这套经验写到简历里面试官会很感兴趣。4. 性能、稳定性与兼容性测试的深水区小米业务对性能、稳定性、兼容性的要求比纯软件公司高得多。手机发烫掉帧、App在低端机上卡顿、多设备互联时网络抖动——这些场景在小米的面试里高频出现。4.1 高频题目内存测试与设备老化测试热搜词里“内存测试”“设备老化测试全自动执行脚本”直接点出了小米业务的两个方向。内存测试的考察重点是怎么定位App内存泄漏。Android场景下的回答思路是用adb shell dumpsys meminfo抓取内存快照反复操作目标页面对比内存占用是否持续增长进一步用LeakCanary接入自动化测试让泄漏检测自动上报。设备老化测试本质上是长时间运行的稳定性测试。面试官会问“如果让你设计一个老化测试方案你会怎么设计”参考回答框架明确老化场景长时间播放视频、反复切换页面、连续拍照录像、多App并行切换。监控指标CPU占用率、内存占用、页面帧率、温度、crash率。自动化执行用Monkey或自研脚本进行长时间随机操作全程采集性能和稳定性数据。结果分析设置阈值比如内存持续增长超过30%判为疑似泄漏帧率低于某阈值判为卡顿。如果能再讲一下“全自动执行脚本怎么处理中途的崩溃和恢复”这个回答就完整了。一般的做法是脚本里加入守护进程检测到App crash后自动拉取日志、记录现场、重启App继续执行整个老化过程无人值守。4.2 高频题目弱网测试与连接数测试小米的产品大量依赖网络连接。路由器、智能家居设备、手机一切换网络就掉线的场景在面试里都是绝佳考题。弱网测试的高频问法是“你用什么工具模拟弱网你关注哪些指标”你至少要知道Charles和Fiddler可以模拟弱网Android端还可以用adb shell配合Linux的tc命令设置延迟和丢包率。但2025年的面试官会更关注你“关注哪些指标”常见的有弱网下的请求超时时间、重试机制、数据一致性、页面loading态的交互表现。连接数测试更偏底层。面试官可能问“一个智能家居路由器同时连接50台设备你怎么测试稳定性”这个问题的核心不是单台设备的功能而是整个系统的资源占用和调度能力。你需要关注路由器CPU和内存占用、设备重连机制、新设备接入时老设备是否掉线、设备长时间在线后内存是否泄漏。涉及嵌入式设备测试时如果路由器本身提供了命令行接口通常还会用脚本批量模拟设备连接观察设备连接数的上限和系统的资源变化。4.3 实操经验兼容性测试矩阵怎么设计小米既有手机又有电视、手表、音箱对兼容性测试的重视程度远高于普通互联网公司。面试官会问“一个功能要在小米全系设备上线你怎么设计兼容性测试方案”你要答出三个维度设备选择不可能全设备测试要按市场占有率、屏幕尺寸、系统版本、硬件配置做正交分析选出覆盖度最高的机型组合。系统版本覆盖不同Android版本对权限管理、后台机制、推流协议的处理不同至少要覆盖最高、最低、主流三个版本段。多端联动场景这是小米特有的兼容性测试场景。比如一个“手机投屏到电视”的功能要覆盖手机不同分辨率、电视不同系统版本、连接方式不同DLNA、Miracast、私有协议几种组合。回答完毕后如果你能主动补充“推广到其他品牌设备时如何兼容”说明你有跨品牌视野会比只盯着小米设备的候选人强很多。5. 小米特色业务方向智能座舱、车载与IoT测试小米造车之后测试岗位的需求量明显增加智能座舱测试、车载测试相关面试题成了新热点。热搜词里有“车载测试”“智能座舱测试”“汽车电子测试”“智能网联汽车道路测试与示范应用安全通行规范”这绝对不是偶然。5.1 高频题目车载测试和普通App测试的差异这道题基本是车载测试岗位的必问题。参考回答要点安全等级不同车载功能直接关系驾驶安全测试对缺陷的容忍度极低有些严重缺陷甚至需要上升到功能安全等级来管理。系统环境不同车机系统很多场景下不能简单重启关机开机流程很长测试环境搭建复杂度高。交互模式不同驾驶场景下更多依赖语音交互和实体按键要专门测试语音识别准确率、方向盘按键操作响应速度。网络环境不同车辆在行驶过程中网络切换频繁地库无信号、高速移动切换基站、隧道内弱网网络测试的优先级极高。升级机制不同车机系统升级不像手机重启就能完成还涉及整车电子系统之间的兼容测试要覆盖不同版本之间的回退和保留数据场景。每次听到候选人只会答“做功能测试和自动化测试”我就会觉得可惜。这道题最好答出“测试策略因场景而变”的思路在车载场景里安全优先、稳定优先功能测试要围绕这些来设计。5.2 高频题目智能座舱的多屏交互测试智能座舱的核心特点是多屏多端仪表盘、中控屏、副驾娱乐屏、后排屏、手机投屏多个屏幕之间还可能联动。面试官会问“中控屏播放视频副驾屏同时导航两个屏的交互怎么测试”参考思路功能维度每个屏幕单独的功能要测通多屏同时使用的资源竞争要测比如同时播放视频会不会导致系统卡顿或声音串扰。交互维度多屏联动逻辑要重点测。用户在中控屏操作后副驾屏的状态是否正确刷新副驾屏请求导航是否覆盖了中控屏当前内容。性能维度多屏同时工作时的CPU、内存、GPU占用、帧率变化。异常维度某一屏出现异常是否影响其他屏正常工作。这道题的加分项是提到“分心驾驶”场景——驾车过程中副驾屏和后排屏的内容不应该导致驾驶员分心所以某些娱乐功能必须在行车状态下被限制。这体现了你对行业场景的理解而不只是技术层面的测试设计。5.3 智能网联汽车的“道路测试”与“台架测试”“智能网联汽车道路测试与示范应用安全通行规范”挂在热搜词里说明这块内容在2025年的关注度确实高。面试官问“道路测试怎么测”时你要能区分台架测试和道路测试台架测试在实验室环境模拟整车状态测试转向、制动、动力、自动驾驶算法等。优点是环境可控、可重复适合开发和回归。道路测试在真实道路环境验证系统功能、可靠性、安全性。优点是场景真实但不可控因素多重复成本高。一个高质量的测试方案应该两者结合先用台架测试跑大量自动化场景再用道路测试做重点验证。面试时可以展开讲一下道路测试前需要准备的checklist比如测试路线规划、天气要求、安全员配置、数据采集设备、应急预案等。这些细节能看出你不是只会纸上谈兵。6. 测试深度题与场景设计题测试思维决定你能走多远不同于前面的知识类问题这类题目没有标准答案面试官考察的是你的测试思维、逻辑完整性和对测试本质的理解。这类题答得好不好往往直接决定你的定级结果。6.1 高频题目给你一个功能你怎么设计测试用例这是最经典的场景设计题。举个例子面试官说“设计一个温度计功能App根据位置和天气显示当前温度”很多人就开始罗列显示温度对不对、单位能不能切换、定位准不准……然后面试官追问“如果温度传感器数据返回异常你怎么办”很多人就卡住了。高分回答要掌握一个核心方法论从“输入-处理-输出”三个维度做穷举再从“正常-异常-边界”三个状态做深度挖掘。拿温度计功能举例你至少能拆出这些测试点正常场景定位成功、温度正常返回、UI显示正确。异常场景定位被拒绝、天气接口超时返回、接口返回空值、网络断开。边界场景温度极高比如50度、温度极低比如零下40度、用户切换到国外城市显示非摄氏温度。联动场景城市切换后温度是否刷新、系统语言切换后温度单位是否变化。再用“正常路径→异常路径→灾难路径”happy path, sad path, disaster path三层法做第二轮挖掘正常路径是用户顺利看到温度异常路径是后台接口报错但App给了友好提示灾难路径是整个后台服务宕机App是否有兜底方案。面试官在这个环节看的不是你能列多少条用例而是你的用例是否形成了完整的逻辑闭环有没有明显的遗漏面。6.2 高频题目自动化用例稳定性的治理方案最近我被问到最多的面试题是“自动化用例今天能过明天不能过怎么排查和治理”这道题之所以高频是因为几乎每个公司都面临同样的痛点。如果你能给出完整的分析框架面试官会立刻把你归到“有实战经验”的那一类。参考回答框架第一层分层定位先把不稳定用例按原因分桶。典型的有数据问题测试数据被改变或未清理、环境问题依赖服务不可用或网络抖动、等待问题元素加载慢但脚本等得不够、代码问题产品本身有bug或脚本断言写错。第二层精确治理数据问题通过测试数据自动准备和清理机制解决环境问题通过健康检查脚本在套件执行前先确认环境可用等待问题统一替换成显式等待并设置合理超时时间。第三层机制兜底失败用例自动重跑一次并且将重跑结果和首次结果同时记录在报告里方便区分“偶发失败”和“真实失败”。第四层持续运营每次跑完自动生成稳定性报告追踪每一条用例的失败率和失败原因定期复盘并优化。这个框架每一条都能展开讲很久。如果你在面试时能在“数据问题”这个环节讲一个真实的案例比如“某个用例依赖订单号订单号被别的用例删了导致查找不到”面试官对你的印象分会大幅提升。6.3 安全测试与渗透测试的入门考察安全测试在小米的招聘需求里越来越常见。如果你面试的是安全测试岗必须准备这些基础内容OWASP Top 10里最常见的Web漏洞都是什么、XSS和SQL注入的区别、HTTPS和SSL/TLS的原理。如果是功能测试岗被问到安全测试面试官通常只关注你有没有安全测试意识。一个比较简单的高频问题“App端的接口被直接抓包调用怎么防护”参考思路核心是加固传输层和服务端校验。一方面用HTTPS加密传输关键字段做签名防篡改另一方面服务端不能只依赖客户端传参要校验token、设备指纹、频率控制。其次是客户端侧的防护比如禁止第三方调试、检测模拟器、关键数据不落地存储。如果候选人还能提到“接口加解密逻辑要放到服务端不要把密钥写死在客户端”说明确实理解安全测试的实质而不仅仅是停留在用Burp Suite抓包的层面。7. 自动化测试进阶从用例到流水线2025年的测试岗位已经很难接受“只会手动点功能”的人了。“自动化测试”四个字在热搜词里反复出现而面试官问自动化一定会问到CI/CD和工程化实践。7.1 高频题目你们公司的自动化测试怎么接入CI流水线这道题几乎是一道分水岭。如果你的答案只有“用例在Jenkins上定时跑”基本等于没答。高分答案要包含这些环节触发策略不是所有用例都进CI。冒烟用例在开发提交代码后立即触发全量回归在每日凌晨跑发布前再跑一次关键链路用例。不同触发策略对应不同的用例集合和运行时长要求。失败处理用例失败后要有失败截图、日志、关键接口返回值的自动收集并且能自动归类到“环境失败”和“业务失败”不能一股脑推给开发。报告展示测试报告要自动推送到团队群包含用例总数、通过率、失败详情、失败截图让开发不看测试平台就能定位问题。环境管理测试环境要做到一键部署、一键恢复保证CI跑之前环境是干净的。环境问题导致的失败要能自动识别并跳过重跑。这个题的背后是团队开发运维一体化的实践。你答得越完整说明你越接近“质量内建”的思路这不只是测试的活而是整个研发链路都在为质量负责。7.2 高频题目测试数据怎么管理测试数据管理是自动化测试落地时最头疼的问题。面试官会问“用例跑之前要准备数据跑完要清理数据你怎么设计”参考方案接口造数通过调用业务接口创建测试数据比如创建订单、添加商品。优势是走真实链路数据完整缺点是比较慢且依赖被测服务可用。数据库直接插入为了测试速度批量往数据库预置数据。优势是快缺点是绕过了业务逻辑造出来的数据可能不符合真实状态。数据模板参数化预先设计一批基础数据模板用模板自动生成带唯一编号的数据防止多次执行时数据互相冲突。预留专用账号和专用数据在测试环境长期保留一批专用数据比如固定账号、固定商品ID用例直接引用这些数据跑完不清除方便排查。面试时把几种方案的优缺点都说清楚再说出“要根据case类型选择方案”面试官就满意了。比如纯接口链路用例用接口造数更可靠大数据量压测用数据库批量插入更快。7.3 面试小技巧结合真实项目讲自动化测试成果围绕自动化测试的最后一类题目是把问题包装成“你做过的项目”比如“你们自动化测试的收益怎么衡量投入产出比怎么算”你可以用数据说话原来手工回归需要3天现在自动化回归只需要2小时线上漏测率下降了多少自动化发现的高级别缺陷有多少个。面试官想听的其实是“你做的自动化到底有没有实际价值”而不是“你用的是什么框架”。框架和技术栈只是手段价值才是核心。8. 面试实战经验总结与心态建议说了这么多题目最后聊点面试实战层面的东西。我自己观察周围拿offer的候选人基本都有一个共同特征回答问题时的思路打开了一个完整的“测试空间”而不是只答一个孤立的点。一个常见的失败案例是面试官问“你怎么测微信的发送图片功能”候选人只答“发一张图看能不能收到”。这就是典型的测试思维没有打开。高分的回答会先搞清楚测的是微信还是公众号里的图片发送再拆解图片本身的类型和大小、发送网络环境、接收端兼容性、异常场景发送中断、图片损坏、多端同步手机发完Pad是否同步显示等。把测试空间撑开面试官一眼就能看出你的测试素养。再给几条实用的准备建议务必准备一个完整深度的项目复盘。把你自己做过的一个测试项目从需求评审到上线回归完整讲清楚包括你负责的范围、遇到的难点、怎么解决的、带来了什么量化收益。这个比刷一百道面试题更有用。小米的面试官喜欢深挖项目细节他会从你项目里挑出很多角度来追问。动手写一个小型测试框架。不用复杂Python pytest requests支持用例参数化、数据驱动、报告生成、失败截图和重试机制。整个过程会让你对各种工具的组合逻辑有更深入理解面试时遇到工具类题目都能举出实例。关注小米自己生态里的App和系统特点。可以提前去看看MIUI的发布说明了解他们在系统更新里调整了哪些测试相关的能力也可以在面试聊到具体业务时提一下你体验过的功能面试官会觉得你是真的对产品有兴趣而不是海投简历。准备两个方向的技术深挖。比如把“弱网测试工具怎么选”“接口自动化怎么做数据隔离”这类题目对应的原理和实践理清楚确保问到细节时能讲满五到十分钟。最后说一个很多人容易忽略的细节面试中问清楚岗位对应的业务线和团队规模。小米的测试岗位分布很广有偏向手机ROM的有偏向IOT设备的有偏向汽车智能座舱的有偏向互联网服务的。每一条业务线的面试题侧重点确实很不一样提前了解投放岗位的业务能让准备更聚焦。祝各位顺利拿到心仪的offer有具体问题可以直接在评论区聊我看到都会回。