2021年小米秋招测试开发方向第二场笔试复盘秋招季又到了每年这个时候都有不少学弟学妹来问我测试开发方向到底考什么、怎么准备。我翻出自己当年参加2021年小米秋招测试开发方向第二场笔试的记录发现很多题型、考点放到现在依然有很强的参考价值。虽然每年题目都在变但考察的核心能力框架其实是稳定的。这篇复盘我会尽量还原当时的题目类型、考点分布以及我在答题过程中的思考和踩过的坑希望能给准备测试开发岗位校招的同学一个清晰的复习方向。不管你是在准备简历阶段还是已经收到了笔试通知正在刷题这篇文章应该都能帮你少走一些弯路。说下我的背景普通211硕士计算机专业当时投的是小米的测试开发工程师岗位。说实话测试开发这个方向在校招里一直有点“既要又要”的味道——既要你有开发的底子又要你懂测试的思路还要你在有限时间内把两者结合起来答题。这场笔试给我的整体感觉是覆盖广、深度中等、时间紧张凡是基础扎实的人应该能过得去但想拿高分需要一定的技巧。1. 整场笔试的宏观复盘题型结构、考点分布与时间分配1.1 试卷整体结构与分值分布我参加的那场笔试线上答题总时长大概120分钟题量在60道左右含编程题。题目类型可以大致分为四块计算机基础选择题、测试理论题、编程题、测试用例设计题。从分值占比来看计算机基础选择大概占40%测试相关理论占20%编程题占25%测试用例设计占15%。这个分值分布其实很有意思。很多同学以为测试开发岗位笔试会重点考测试理论实际上计算机基础的分量更重。这说明大厂测试开发岗位对候选人的代码能力和计算机功底要求很高测试理论更多是“底线要求”而计算机基础才是区分度所在。从考点覆盖来看计算机网络、操作系统、数据结构与算法是绝对主力Linux和数据库知识也会涉及但比重相对小一些。这些内容其实和开发岗位的笔试范围高度重合只是测试开发岗位会额外加一部分测试理论题和测试设计题。1.2 时间分配与答题策略120分钟做60道题平均每题只有2分钟再加上编程题和用例设计题这种需要“大段输出”的题目时间其实非常紧张。我当时的策略是基础选择题控制在1分钟内一题遇到卡壳的立刻标记跳过不在单题上死磕等做完所有有把握的题再回头处理。编程题留出30到40分钟测试用例设计题留出15到20分钟。实测下来这个策略是有效的。因为选择题里总会有两三道偏题怪题比如非常冷门的Linux命令参数、很偏的网络协议细节这些题你花5分钟也不一定想得起来不如把时间留给编程题——编程题的分值高而且只要你思路对了、代码能过用例得分是非常稳的。不过这里有个需要注意的点有些平台的选择题不支持“标记后跳回”或者跳回操作比较麻烦。我建议在正式笔试前一定要去模拟系统里试一下界面搞清楚哪些操作支持、哪些不支持免得考场上手忙脚乱。2. 计算机基础考点精讲网络、操作系统、数据结构的高频题型2.1 计算机网络TCP和HTTP是绝对核心计算机网络这部分我印象最深的是TCP和HTTP相关的题目特别多。有一道题问TCP的拥塞控制在什么情况下会触发慢启动选项涉及超时重传、收到三个重复ACK、发送窗口减小等。这道题其实考的是拥塞控制的状态机理解如果只是死记硬背“慢启动阈值减半”这种结论没理解背后的逻辑很容易选错。正确的理解方式是TCP拥塞控制的核心目标是探测网络的可用带宽当出现丢包时认为网络变拥塞于是降低发送速率。慢启动是连接刚建立或者出现严重拥塞超时时从很小的拥塞窗口开始指数增长快速试探网络容量。而收到三个重复ACK触发的快重传、快恢复虽然也会减小拥塞窗口但不会回到慢启动阶段而是直接进入拥塞避免的线性增长。所以超时重传才会触发慢启动这个区分点要记牢。HTTP相关的题目也考了不少有一道问的是HTTP和HTTPS的区别哪些说法正确。这种题表面上是协议对比题实际上考察你对HTTPS握手过程的理解——HTTPS不是在HTTP上简单加个加密层而是在TCP之上先做TLS握手协商出对称加密密钥后再进行HTTP通信。所以“HTTPS使用对称加密传输数据”这个说法其实是对的因为实际加密用的是对称密钥而非对称加密只在握手阶段用于密钥交换。在备考网络部分时我建议大家按照“TCP三次握手四次挥手 → TCP可靠性机制重传、滑动窗口、拥塞控制→ HTTP报文结构 → HTTP状态码 → HTTPS握手流程”这条主线去复习。另外测试开发岗位和开发岗位有个不同点可能会考到“如何用抓包工具验证某个网络问题”所以对Wireshark、Fiddler这类工具的基本使用要有概念不用太深入但要知道它们能观察哪些信息。2.2 操作系统进程线程、死锁和内存管理操作系统这块进程和线程的区别是必考题。有一道题是关于进程和线程的描述哪个是错误的。选项包括进程是资源分配的基本单位线程是CPU调度的基本单位同一进程内的线程共享地址空间不同进程间的线程无法通过共享内存通信等。前三个都没问题第四个是个陷阱——不同进程的线程当然不能直接共享彼此的地址空间但可以通过共享内存、消息队列等IPC机制通信所以“无法通过共享内存通信”这个说法是错误的。另一道印象深刻的题考的是死锁的四个必要条件互斥、占有且等待、不可抢占、循环等待。题目给了一个场景两个线程分别持有锁A和锁B现在线程1想获取锁B线程2想获取锁A问这是破坏了哪个条件才能避免死锁。答案是循环等待。这种题其实就是背概念加场景套用关键是理解每个条件对应的代码场景长什么样。内存管理方面考了页面置换算法。有一道题给出一个页面访问序列问使用LRU算法时的缺页次数。这种题就是纯计算只要你理解LRU的“最近最久未使用”含义画个表格一步步推就能算出来。我的建议是这类题一定要亲手画表推演几遍不要光在脑子里想因为考场上时间紧张手写推演比脑内演算更不容易出错。还有一道题涉及虚拟内存和分页问的是页面大小的选择对系统性能的影响。我当时选的是“页面过大可能导致页内碎片增加”这个确实是对的。页面大小增大时页表项变少、缺页率可能降低但页内碎片会增大。这种题其实就是操作系统课程的基础内容难度不大只要认真学过OS应该都能答上。2.3 数据结构与算法栈、队列、树和排序数据结构的选择题整体难度中等但考察面比较广。我记得有一道题问的是“用两个栈实现一个队列入队操作的时间复杂度是多少”。这个就是经典题入队时直接push到栈1出队时先把栈1的元素全部pop到栈2再从栈2 pop。均摊时间复杂度是O(1)——因为每个元素最多从栈1移到栈2一次再弹出去一次。这道题考的是对数据结构操作的理解而不是简单的复杂度背诵。树的遍历也是高频考点。有一道题给了二叉树的前序遍历和中序遍历序列要求推出后序遍历序列。这种题属于数据结构里面的基本功但因为是线上笔试没有纸笔画树只能靠心算。我当时的做法是在脑海中按前序序列逐节点“插入”再结合中序序列确定左右子树的位置关系最后再按后序遍历输出。这个过程比较折腾建议这类题平时多加练习做到“看到前序加中序就能立刻写出后序”的熟练度。排序算法有一道题问快速排序在最坏情况下的时间复杂度。这题其实在开发岗笔试里也很常见答案是O(n²)而不是O(n log n)。最坏情况出现在每次选取的基准值都是最大或最小元素时每次划分只减少一个元素。考场上不少同学容易直接选O(n log n)大意了。我提醒一下备考的同学快排的平均复杂度是O(n log n)最坏是O(n²)堆排序和归并排序的最坏才是O(n log n)这几个点必须分清楚。3. 测试理论与测试设计题测试开发岗位的“专业壁垒”3.1 测试基础理论考什么测试理论这块的题目量不大但很能拉开差距因为开发岗位的同学一般不会系统复习这些内容而测试开发岗位的学生如果没有认真准备过也容易在这些送分题上丢分。有一道题是关于测试用例的说法哪个是错误的。选项涉及测试用例应包含预期结果、测试用例应具有可重复性、测试用例只有执行时才有价值、好的测试用例能发现未被发现的错误等。答案是“测试用例只有执行时才有价值”这个说法错误——测试用例本身就是测试设计成果的载体即使不执行也具有评审价值、回归参考价值后续还能用于自动化测试脚本编写。另一道题考的是黑盒测试和白盒测试的区别。黑盒测试不考虑内部实现只验证输入输出是否符合预期白盒测试则关注代码内部路径和逻辑分支。有一道选择题问“语句覆盖、分支覆盖、条件覆盖属于哪种测试方法”答案自然是白盒测试。这类题就是送分的但前提是你对测试的基础概念有框架性的理解而不是零散背概念。还有就是软件生命周期和测试流程相关的题比如瀑布模型、V模型、敏捷开发中的测试角色。有一道题问在V模型中系统测试对应的需求阶段是哪个。V模型左边是需求分析、概要设计、详细设计、编码右边对应的是单元测试、集成测试、系统测试、验收测试系统测试对应的是概要设计阶段还是需求分析阶段这题我当时犹豫了一下。正确的对应关系是系统测试对应需求分析阶段集成测试对应概要设计阶段单元测试对应详细设计阶段。如果记不清楚可以从“越上层的测试越贴近用户需求”这个逻辑去推。3.2 测试用例设计题经典场景与边界值思维测试用例设计题是整场笔试最有“测试味道”的部分。当时有一道题是“请为一个微信红包功能设计测试用例”。这题看起来简单但想答好其实需要系统的测试思维。我当时的答题思路分几条线来写。功能层面正常发红包、收红包、退红包、查看红包详情金额边界0.01元最小金额、200元单笔上限、余额不足时发红包并发场景多人同时抢红包时金额分配是否正确、是否出现超额分配异常场景网络中断、支付超时、重复点击发送按钮。这样分维度答题既展示了广度又体现了结构化思维。这种题怎么练我的建议是平时多看点常见测试题目的解答模板形成自己的“套路框架”。比如拿到一个功能先分功能测试、界面测试、兼容性测试、安全测试、性能测试几个维度再在每个维度下填充具体的测试点。不要看到一个题目就直接罗列——只有从框架到细节层层展开的答案才能让阅卷人看出你有测试思维。另外一个值得注意的点是测试设计题不一定要把所有情况都写完但一定要有逻辑层次。你可以写“本用例主要从功能维度展开性能和兼容性维度暂不深入”这样既控制了答题篇幅又不会让人觉得你思路混乱。3.3 编程题中的测试思维不只是“写对代码”编程题部分除了常规的算法题还有一道题的考察方式很独特要求实现一个函数并写出你用来验证这个函数正确性的测试用例。这种题目在普通开发岗笔试里很少出现但在测试开发岗却非常合理——它直接考察你“能用代码实现功能”和“能从测试角度审视代码”的双重能力。那道题大概是让实现一个判断字符串是否为合法IP地址的函数。写完核心逻辑后还要在代码下面列出测试用例合法的IPv4地址“192.168.1.1”、非法格式“192.168.1”、数字越界“256.1.1.1”、含前导零“01.2.3.4”、输入空字符串、输入null等。说实话这种题比纯算法题更能看出一个测试开发候选人的水平。一个合格的测试开发工程师不只是“能把代码写出来”还需要知道这个代码在什么情况下会出错、边界条件在哪里、异常输入怎么处理。如果你平时刷题时习惯在LeetCode上自己加一些测试用例来验证这种题目对你来说就不难。4. 从这次笔试反推备考路线测试开发岗位怎么准备4.1 复习优先级计算机网络、操作系统、数据结构是基石结合这次笔试的经验我给准备测试开发岗位的同学一个复习优先级建议计算机网络、操作系统、数据结构与算法永远是最重要的三座大山。这三块内容不仅是笔试的重头戏也是后续面试中技术面的核心考察范围。测试开发岗位虽然日常工作中会写自动化脚本、做测试平台开发但代码能力和计算机基础依然是立身之本没有这个底子测试理论学得再好也很难过笔试。具体到复习方法计算机网络重点看TCP/IP协议栈和HTTP协议推荐把TCP三次握手、四次挥手、拥塞控制、滑动窗口这些机制“画出流程并用自己的话讲清楚”而不是单纯背诵。操作系统重点看进程线程模型、死锁、内存管理、文件系统这四大块结合代码场景去理解概念。数据结构与算法则以LeetCode题单为主按数组、链表、栈队列、二叉树、排序、动态规划的顺序刷题保持每天1到2道题的手感。4.2 测试理论复习路线从基础概念到完整测试流程测试理论这块的复习路线我总结为三步。第一步是掌握基础概念软件测试的定义、目的、原则测试用例的要素黑盒白盒测试方法的区别单元测试、集成测试、系统测试、验收测试的边界。第二步是熟悉测试流程从需求评审、测试计划、用例设计、执行测试、缺陷管理到测试报告的完整闭环。第三步是理解不同开发模式下的测试角色比如V模型、W模型、敏捷开发中的测试活动如何嵌入。这一步比较容易被忽视但笔试和面试都可能会问。我当年就遇到过一个面试题“在敏捷开发中测试人员的工作方式和瀑布模型有什么不同”。这类问题如果你只背了测试流程没有真正理解敏捷迭代中测试如何持续集成、持续反馈就很难答出深度。4.3 编程题与SQL题不能放松很多人在软肋上翻车在这份考卷里SQL题虽然占比不大但确实出现了而且考察方式很直接给两张表比如用户表和订单表写SQL查每个用户的订单总数和总金额。这种题如果平时没练过考场上很容易卡壳。我建议大家把SQL常见题型准备扎实单表查询、分组聚合、多表连接、子查询、排序分页、去重。不用刷太多太偏的题目把面试高频几十道题做一遍就够用了。编程题这块除了常规的数据结构和算法测试开发岗还会考一些字符串处理和简单逻辑实现。尤其在笔试中有时会要求写一个函数并写出测试用例这在测试开发方向中显得特别重要。平时刷题时多想一想“这个代码的边界条件是什么”“如果输入异常会怎样”对测试思维的培养非常有帮助。4.4 应对策略总结考研式复习加工程式实战把这次笔试的经验总结成应对策略我觉得可以用一句话概括考研式复习加工程式实战。考研式复习是指计算机基础部分需要系统过一遍知识点不能指望刷题碰运气工程式实战是指测试理论这类型题目只看书是不行的最好去找一些实际项目的测试任务练手比如给某个功能模块写一套完整的测试用例或者用JUnit、pytest写一组自动化测试用例。我个人在备考时的一个心法是把面试官当作“挑剔的同事”——而不是“考官”。笔试和面试本质上都是在向未来团队展示你能否成为一个称职的测试开发工程师。拥有开发能力的测试人员才会在团队里拥有更强的技术影响力和话语权也更有机会去推动整个测试体系向自动化、智能化的方向发展。5. 常见问题与避坑指南我踩过的坑不希望你再踩5.1 时间分配不当导致编程题没做完这是我在模拟笔试阶段就踩过的坑所幸在正式笔试中调整过来了。第一次做模拟卷时我在前面四道选择题上花了将近10分钟结果后面编程题来不及做。之后我给自己定了一条铁律选择题每道题最多90秒超时就标记跳过放到最后再回头想。这个节奏在正式笔试中帮了大忙。这里有个细节想提醒大家笔试平台的选择题如果做错了有的平台会直接扣分有的不扣分有的部分给分。不同平台规则不一样考前一定要看清楚说明。如果是不扣分的规则那所有题都要填一个答案不要留空。如果是倒扣分规则就要权衡一下有没有必要蒙答案。5.2 测试设计题答成“流水账”导致得分不高测试用例设计题很多人容易犯一个毛病想到什么写什么一条接一条地列每一条都差不多没有优先级也没有分类。这种答案在阅卷人眼里就是“没有测试思维的流水账”。正确的答法是分门别类地写。比如前面提到的微信红包测试题可以先写“从功能维度看需要测哪些场景”再用“边界值分析”找边界再补充“异常场景”“兼容性场景”“性能场景”。每一条列举的用例之间要有差异性和递进关系让阅卷人看到你的思考层次。5.3 对选择题中的“偏题怪题”过度纠结笔试中难免会出现一两道完全没见过的选择题比如冷门的Linux命令参数、某种协议的特殊字段含义。我遇到这种情况时最开始会不甘心反复琢磨结果浪费了大量时间。后来我学会了一个取舍策略先选一个“看起来合理”的答案然后立刻跳到下一题。即使这道题做错了也只是一两分但多出来的时间如果能保障编程题拿满分整体收益大得多。5.4 笔试环境与网络问题细节决定成败线上笔试还有一个容易被忽略的坑就是电脑环境和网络稳定性。我参加的那场笔试有一位同学因为网络不稳定掉线了两次重新登录浪费了不少时间。建议在笔试前提前半小时做以下检查浏览器是否为官方指定版本清除缓存关掉所有可能会弹通知的软件比如微信、邮件客户端确保摄像头和麦克风权限正常网络优先使用有线连接没有的话也要找个信号稳定的位置。另外编程题的代码编辑器可能不具备语法提示和缩进美化功能有的甚至连括号自动补全都没有。如果你平时写代码重度依赖IDE的自动提示建议提前在LeetCode或者牛客网的在线编辑器上多练几次适应一下“裸写代码”的手感。6. 一些额外的经验与想法送给正在准备秋招的你从这场笔试复盘来看测试开发岗位的笔试核心其实还是“开发功底测试思维”的组合。很多人对测试开发存在一个误解以为测试开发就是“点点点”的测试工程师加一点自动化脚本能力。实际上从笔试和面试的难度来看测试开发岗位对代码能力和计算机基础的要求已经非常接近甚至持平于开发岗位只是额外增加了测试维度的考察。如果你现在是大三或研一还有充足的时间准备我建议尽早按照“计算机四件套一门语言一个自动化测试框架一套测试理论”的框架来搭建知识体系。计算机四件套指数据结构与算法、操作系统、计算机网络、数据库。语言方面我个人推荐Java或Python两者在测试开发领域都有广泛应用。自动化测试框架可以从Selenium入手后端接口测试则可以用pytest或TestNG。测试理论方面系统性读一本测试入门经典书理解测试分层、用例设计方法和缺陷管理流程。我还有一个小技巧想分享每次笔试结束后不要急着对答案或陷入自我怀疑而是把笔试中遇到的新知识点记录下来整理到自己的错题本里。我当年复习阶段有一个“笔试复盘清单”每参加完一次笔试就往里补充知识点考前拿出来翻一遍效果非常好。小米这场秋招的测试开发方向笔试难度整体来说是比较合理的基础题占大多数只要系统复习过一段时间就能通过。真正拉开差距的是那些需要“想一层”的题目——比如TCP拥塞控制的触发机制、LRU缺页计算、测试用例设计题的结构化表达。这些都需要你在日常复习时就刻意培养深度思考的习惯而不是靠考前突击。你在准备过程中如果遇到什么具体问题比如某类题不知从何下手、某个知识点理解不透欢迎找机会一起交流。测试开发这条路的成长曲线很陡峭但每一步努力都不会白费。祝准备秋招的每一位同学都能收到自己满意的offer。