2021年小米秋招测试开发方向第二场笔试说实话已经过去几年了但这份卷子的参考价值到现在依然很高。每年到秋招季都有人翻出这套题来问我说网上只有零星回忆版想让我完整复盘一下题型分布、考察重点和答题思路。这篇文章我尽量把当时考完记录的东西、后来复盘的知识点、以及这些年带新人时对照题目反推出来的考察意图都梳理清楚给正在准备测试开发方向校招的同学一个尽量贴近真实的参考。先交代一下整体感受这份卷子不是那种纯刷八股文就能过的它明显在筛选两类人——一类是基础扎实、对测试理论有系统理解的人另一类是能动手写代码、能根据实际场景设计测试方案的人。如果你只会背概念、背框架API大概率会卡在测试设计题和编程题上。这一点和很多公司测试开发岗笔试“重理论轻实践”的风格有明显差异值得单独拿出来研究。1. 这份卷子的题型分布与时间节奏先说全局。整场笔试安排在牛客网进行我记得是2小时题型大概分四块单选、多选、测试设计题、两道编程题。总分100分但分值分布印象里不是平均的——测试设计题和编程题占比很高客观题反而分值没有想象中大。一个重要的提醒小米的笔试系统是分模块计时的。单选和多选共用一个时间段提交后进入测试设计题再做编程题。也就是说你不能跳回去检查之前的客观题每个模块时间到了自动交卷。这一点特别容易坑人我当年就见过有同学在客观题上磨蹭太久结果编程题只剩20分钟。具体时间分配我建议这样规划客观题部分约16道控制在30分钟以内测试设计题20分钟剩下至少50分钟给两道编程题留10分钟做整体检查。编程题的分值是最高的任何客观题都不值得你花超过2分钟去纠结不会就凭排除法先选一个把时间留给后面的设计题和代码题。从难度曲线看客观题覆盖的范围比较广但深度不大设计题是整份卷子的分水岭考的是测试思维而不是背概念编程题一难一易第一题属于 LeetCode 简单到中等第二题会稍微绕一点但绝不是竞赛题那种难度。整体判断是这份卷子核心考察的不是“你会不会写代码”而是“你有没有测试开发的思维模式”。2. 客观题的高频考点Linux命令、计算机网络与测试基础客观题部分我按记忆尽量还原一下考察方向不一定每个选项都记得准确但考点覆盖是可以确定的范围。这份卷子的客观题集中在四块Linux、计算机网络、数据库和软件测试基础理论。2.1 Linux命令不是问你“怎么用”而是问“怎么排查”Linux相关的题大约有4-5道这在我做过的测试开发笔试里属于占比很高的。但注意它不是直接考ls、cd这种入门命令而是把命令放在具体场景里。印象比较深的一道题是关于日志排查的给出一段日志文件里面有空行、有带ERROR关键字的行问用哪个命令组合能高效过滤出所有含ERROR且非空的日志行。正确思路应该是grep -v ^$ xxx.log | grep ERROR选项里还混着grep -n、sed -n、awk的干扰项。这里考察的其实是真实的日常排障场景。做测试开发经常要上服务器看日志如果你只知道tail -f遇到这种题就只能靠猜。建议备考时不要只背命令参数要把这些命令放到实际场景里去用查看某个端口是否被占用用netstat -tunlp实时监控日志分流用tail -f | grep统计日志中某个关键词出现次数用grep -c文本按某列排序用sort -k去重用uniq -c。2.2 计算机网络HTTP协议和三次握手是必考点网络这块大概有3-4道题集中在HTTP协议和TCP连接上。有一道选择题我记得很清楚问的是HTTP状态码的含义给了200、301、302、403、500但选项交叉设了坑。比如301是永久重定向302是临时重定向很多人会把这两个混在一起。作为测试开发接口测试返回码是每天都在打交道的东西这个分丢掉了比较可惜。另外还有一道关于TCP三次握手过程的题问的是第二次握手时客户端和服务端的状态分别是什么。答案是服务端收到SYN后返回SYNACK此时服务端进入SYN_RCVD状态客户端收到后进入ESTABLISHED状态。说实话这种题考得比较基础但注意它把坑埋在“状态名”上比如SYN_SENT、SYN_RCVD、ESTABLISHED这几个状态要分清楚。2.3 数据库多表查询和索引失效场景都要会数据库考察了大概2-3道题重点在多表联查和索引。有一题是给两张表——用户表和订单表要求用SQL查出每个用户的订单总数需要用LEFT JOIN加分组合计。这题相当于SELECT u.name, COUNT(o.id) FROM user u LEFT JOIN orders o ON u.id o.user_id GROUP BY u.id考的是LEFT JOIN和INNER JOIN的区别——如果直接用INNER JOIN订单为0的用户会被过滤掉。还有一道索引题问的是哪个写法会导致索引失效。选项中大约有WHERE name LIKE %张、WHERE age1 20、WHERE status ACTIVE答案是前两个左边模糊查询和列做运算都会导致索引失效。做测试开发经常要构造SQL查数据来验证结果这个基础不能有盲区。2.4 测试基础理论等价类、边界值这类必考测试理论大约占5-6道这个占比在互联网公司笔试里感觉比较正常。考察点集中在等价类划分、边界值分析、场景法、白盒测试覆盖标准这些上面。最好拿分但也是最容易翻车的。举个实例一道题目要求判断一个“用户输入年龄合法范围是18-60岁”的用例设计问哪一组数据是最合理的边界值用例。正确答案应该是17、18、60、61但选项里混了一个18、 60、一个17、18、60、还有个16、17、18、60、61。这里考察的是边界值分析的标准做法——取边界值和刚过边界的值而不是把所有边界附近的值都取一遍。当年很多人在这种题上过度思考选了一个包含过多数据的选项反而错了。等价类和边界值这两板斧价值不仅在笔试在实际用例设计里也无比重要。还有一个比较有意思的考察点是白盒测试的“判定覆盖”和“条件覆盖”区别。简单说判定覆盖是让每个分支的真假都执行一次条件覆盖是让每个条件的真假都执行一次。如果一层判定里有多个组合条件这两者的覆盖率差异就很大。这个知识点面试的时候经常问笔试里也会出选择题值得理清楚。3. 测试设计题一道购物车用例设计题的完整复盘这部分的题目是我印象最深的。它是全场唯一一道纯手写设计题给了一个非常简单的购加车添加商品功能描述要求你针对这个功能设计测试用例上限写10条。一道功能点设计上限10条用例。乍一看简单但从阅卷者角度讲这个题的本质不是看你写得多而是看你覆盖得全不全。不是说写满10条就行而是看你能否覆盖功能、异常、边界、兼容性、性能、安全这些维度。如果10条全是正常路径跳转验证哪怕写得再详细也拿不到高分。我当时写下的大致几类你们可以参考3.1 需要关注的六大维度写用例之前先分类这个至关重要。我建议从这几个维度出发功能维度加购商品后数量是否正确、库存不足时能否加购、未登录时点加购会不会弹登录框、同一商品重复加购会不会合并成一条并累加数量、加购不同规格比如颜色、尺码会不会分成两条等。边界维度加购数量为1、上限值、上限加1、0、负数。这里需要结合具体功能描述去判断上限是9还是99还是不做限制。异常维度网络断开时点加购、服务器超时、后端返回超卖错误、库存扣减失败、切换到后台进程被杀后购物车数据是否保留等。兼容维度在不同操作系统、不同浏览器或不同机型的表现是否一致。性能与体验维度连续快速点击加购10次是否会造成重复提交、弱网状态下界面是否卡死或重复跳转。安全相关加购请求是否可以篡改价格参数、是否可以绕过库存校验直接下单。这通常在接口层验证但笔试中写出来是加分项。3.2 我当时是怎么组织答案的我的答题策略是不堆描述用极简的“步骤预期结果”结构。例如商城首页点击商品进入详情页验证商品信息展示正确。点击“加入购物车”按钮验证购物车角标数量1。商品库存为1时加购成功库存减为0后再次加购验证不能加购且提示库存不足。不登录状态下点击加购验证跳转登录页登录后回跳原页面且加购状态不丢失。选择商品规格后加购再次进入购物车验证商品规格信息正确。这样写的好处是阅卷人在极短时间内就能看到你的覆盖宽度。每一行都是一个独立可执行的验证点。如果你有时间再补一条弱网场景的用例写“通过Charles模拟网络超时点击加购验证前端有loading或toast提示不会重复提交”这个就是一个很好的加分项说明你考虑到了实际测试环境中的网络因素。3.3 拿高分的隐藏加分项这道题的高分关键在于尽可能覆盖非功能维度。大多数应届生只会写功能用例如果你能写出1-2条兼容性、性能、异常恢复或安全类用例就已经拉开了差距。笔试不是面试没有追问机会所以越早展示你的思考维度越好。此外写用例要避免一个问题过于具体导致复用性差比如“iPhone 12上验证加购成功”——这种用例只覆盖了一个设备没法形成系统性的矩阵。更好的写法是“在iOS最新系统版本上验证”虽然也不能穷举但至少体现你有版本兼容意识。4. 两道编程题数据结构的底子在测试思维是加分项编程题一共两道。小米的编程题允许用 C/Java/Python我自己用的Python运行环境是牛客在线编译器没有IDE那种调试辅助所以平时写代码习惯依赖编译器提示的同学要提前适应。4.1 第一题字符串处理考的是基础第一题基本是 LeetCode 简单到中等水准类似“给定一个字符串找出最长无重复字符子串的长度”。这类题用滑动窗口是标准解法Python 代码量不大大概这个难度def length_of_longest_substring(s: str) - int: from collections import defaultdict window defaultdict(int) left 0 ans 0 for right, ch in enumerate(s): window[ch] 1 while window[ch] 1: window[s[left]] - 1 left 1 ans max(ans, right - left 1) return ans这题在牛客上写有个坑需要自己处理输入输出。也就是input()读取字符串最后print()输出结果别把函数写完忘了加主流程调用这几乎是每年大量人丢分的重灾区。另一个坑是边界情况比如字符串为空、字符串只有一个字符你的代码也要能输出正确结果。实际阅卷时不可能所有样例都人工过都是自动判题机跑测试用例。所以你要特别注意别只过示例就提交自己要先在脑子里跑几个边界用例。字符串题边界如果没处理往往一挂就挂掉一半测试点。4.2 第二题模拟优化考的是工程化能力第二题我需要说一句它不只考数据结构和算法还考你对“测试”的理解。我印象里是一道关于“日志统计”的题目大意是给一段包含时间戳和操作类型的日志记录要求统计某个时间段内每种操作出现的次数并且输出特定排序。核心难点在时间解析和高效统计。这道题的正确答案不是唯一的。你可以用split解析时间用defaultdict做计数最后排序输出。但如果你把每一条日志都存下来再遍历在数据量大时会超时正确思路是只存需要的字段边读边统计。这恰恰是测试开发日常要做的事情——分析海量日志、定位错误分布、统计关键字频次——它更接近“用编程解决测试中遇到的问题”。其实这种题的考察意图非常明显它想确认你有没有能力用脚本工具去处理实际测试工程里的日志分析需求。如果你只会刷题而不会把代码落地到具体场景第二题很容易写出一个能过示例但遭不住大数据量的方案。第二题的加分写法是在主逻辑旁边写一个简易的测试入口用几行自测用例验证结果的正确性。这是我后来跟很多同学复盘时特意强调的一点笔试编程题不仅考你写也在考你的自测意识和测试习惯。你在本地写好一个if __name__ __main__:的测试入口把所有示例和常见边界数据放进去跑一遍这虽然不是评测加分项但它能帮你在提交前及时拦住低级错误避免因为粗心丢掉本可拿到的分。4.3 笔试编程题的通用复盘从这两个题往回看我觉得小米的笔试编程题不追求偏难偏怪重心在于能不能用代码解决实际工作中会遇到的场景型问题。字符串处理、日志处理、数据统计——这些恰好是测试开发日常最常写的代码类型。所以备考时与其死磕困难题不如多刷字符串、数组、哈希表、排序、滑动窗口、双指针这六类题型。它们出现频率最高性价比也最高。5. 从这套题反推测试开发岗的能力要求考完之后我复盘了很久觉得这套题虽然知识点杂但背后有明确的能力模型在支撑。做测试开发不是单维度地看你会不会写代码或者会不会做手工测试而是看你能否把这两者融合起来。5.1 懂业务也懂实现细节测试开发的工作不只是点点点你要能理解一个功能的用户价值和技术实现。购物车加购用例设计为什么要把“库存不足”“未登录”“重复点击”都考虑到因为它本质上覆盖了用户真实使用时的各种状态。一个好的测试工程师是在替真实用户走查产品同时把关技术边界。写用例时如果只写“点击加购成功”这一类正常路径说明你没有代入用户角色去思考失败路径和异常路径。5.2 会用工具也会写工具许多测试开发岗位日常工作其实分成两块一部分是功能测试设计和执行另一部分是自动化脚本、测试平台工具的开发。小米这套卷子客观题考基础、设计题考用例、编程题考脚本能力已经很明确地在告诉你这个岗位需要的是既能理解测试设计又具备代码执行能力的人。你不需要是算法高手但你需要在接到“帮我统计线上日志错误分布”这类需求时能快速写个脚本去处理。5.3 排查问题的能力是隐藏考点这份卷子里Linux、日志分析、网络状态这些看似零散的知识点拼在一起其实就是一条完整的排查链路——发现问题用例设计→ 定位问题日志分析→ 确认影响范围网络/数据库→ 验证修复。测试开发岗的高阶能力就是这条链路的效率。笔试不可能像面试一样让你现场排查问题但它可以用知识点组合的方式考察你有没有这条链路的意识。6. 我对备考思路的几条参考建议现在小米的笔试题大概率已经更新换代了但考试风格和能力模型应该是延续的。结合这份试卷我说几条自己在辅导过程中比较认同的备考建议不一定适用于所有人但方向没错。第一建立自己的知识框架而不是背题。测试开发的考点范围其实很固定无非是计算机网络、操作系统、Linux、数据库、数据结构与算法、测试理论基础、自动化工具和框架。但如果只是零散地背遇到灵活题很容易宕机。建议按模块梳理每个模块下面列高频考点和面试可能出现的追问。比如计算机网络模块不仅要记三次握手状态码还要想想为什么不两次、不四次这些在面试里也是连环追问的话题。第二代码能力每天保持一定量的练习重质不重量。只刷难题但基础题不稳定笔试很容易翻车反过来如果简单题都能稳定AC一份笔试已经赢了一半以上的人。建议以数组、字符串、哈希、栈/队列、二叉树基础、简单动态规划为主每天3-5道但每道都尽量写清楚、跑全边界、复盘时间空间复杂度。第三把知识应用在项目里才能真正内化。很多同学的问题是知识点都会但一问“你测试过程中遇到印象最深的Bug”就答不上来。建议在校期间找一个具体的测试项目实操一下——哪怕是做一个简单的Web登录功能也完整地梳理一遍功能测试用例、接口测试用例、自动化脚本的思路把这些沉淀成自己的项目经验。第四客观题没必要花太多时间准备偏门的冷知识点。压的是高频重点比如TCP状态码、SQL常用语法、Linux日志排查命令、HTTP状态码。性价比极高。冷门题目就算没见过靠排除法也能蒙一部分不必因此焦虑。最后想说一句测试开发这个方向在校招面试里最看重的往往不是你掌握了多少工具而是你是否具备“站在用户角度保证质量站在工程角度提升效率”的思维方式。笔试只是这种思维最初步的一种筛选方式。如果你能理解这一点那么你准备的每一道题、写的每一条用例、留的每道边界用例都会更有方向感。