这是很多同学对测试开发笔试的普遍误解。我这两年带过不少准备秋招的人也经常被问到“小米这种大厂的测试开发笔试题到底考什么”。说句实在话测试开发岗的卷子尤其是小米这种体量的公司确实会兼顾“测试功底”和“工程编码能力”两块。2022年小米秋招笔试-测试开发-卷2这个系列我印象里刷过好几轮题目不算偏但很考验基础是否扎实。今天我不打算每道题报答案而是把它当样本拆一拆这种卷子背后的出题逻辑、考点权重和临场策略顺便把复习路线捋清楚希望能帮后面准备秋招的同学少走点弯路。1. 卷2的题型配置与时间分配真相1.1 这类卷子通常长什么样小米的测试开发笔试卷子整体分这样几大块专业客观题、简答/设计题、编程题。其中客观题一般是单选和多选混着出覆盖面很广从软件测试理论到计算机网络、操作系统、数据库、Linux命令都有可能出现。编程题一般是两道左右难度中等偏基础不像纯后端岗那样动不动就上困难题但也不是随随便便能AC的难度。卷2这个系列给我的整体感觉是客观题占的比例不低大概在40%到50%左右。这部分题目的特点是“知识面很宽但单个题目深挖不狠”基本就是看你对计算机基础概念有没有印象对测试方法有没有体系化的理解。如果你平时只看源码、只刷算法没系统过一遍测试理论反而容易在客观题上翻车。然后是简答设计题通常会给你一个具体功能模块比如登录注册、购物车结算、文件上传这种让你设计测试用例或者让你回答某个测试框架的原理、某个bug定位的思路。这类题没有标准答案但踩分点很明确考察的是你有没有一套可复用、可解释的测试设计思路。1.2 时间怎么分才够用我见过不少同学死在时间分配上。客观题纠结太久到了编程题只剩二十分钟结果本应拿到的分全丢了。按照常见的时间比例如果一场笔试总时长是90分钟我会这样切前10分钟快速扫一遍全部题目把编程题的难度和题型记在心里让自己的潜意识先热起来。客观题控制在35分钟以内会的直接选不确定的先标记不要反复纠结。多选的策略是“宁缺毋滥”拿不准的选项宁可不选也要保证不因错选倒扣分。简答设计题控制在20分钟左右这类题目写清楚框架和关键点就行不要陷入长篇大论。编程题留25到30分钟先把思路理顺再用暴力解兜底拿部分分最后有时间再优化。这套分配方式我反复用了很多次核心思路就一句话先把确定能拿的分全部拿到再啃不确定的分。因为笔试看的是总分和排名不是看某一道题有没有完美解。2. 编程题背后的算法侧重不只是LeetCode2.1 测试开发岗真正关注哪类算法很多人一提到算法题就慌觉得必须把LeetCode刷个三四百道才能上考场。但实际情况是测试开发岗的编程题往往更实用常见的方向有这么几类字符串处理反转、切分、回文判断、子串查找、字符串压缩。数组操作去重、排序、区间合并、双指针、滑动窗口。哈希表应用找出现次数、两数之和、判断是否有重复元素。链表基础反转链表、环形链表判断、删除指定节点。简单二叉树层序遍历、深度计算、镜像翻转。这些知识点看起来不高端但胜在实用价值高。你想想测试开发日常工作里写自动化脚本、做测试数据生成、处理接口返回值哪个不是跟字符串、数组、哈希表打交道。所以笔试题出这些方向背后是有合理性的——他们希望招进来的人能快速写工具脚本而不是只会默写难题模板的人。2.2 一道典型题的拆解过程拿字符串压缩这类经典题来说。题目大概是给定一个字符串把连续出现的字符压缩成“字符出现次数”的形式比如aabccccaaa压缩成a2b1c4a3如果压缩后的字符串不比原串短就返回原串。我推荐先想清楚边界条件再动手写代码空串输入直接返回空串。单个字符不压缩因为a1比a长返回原串。字符在末尾连续出现的情况遍历完要记得把最后一组计入结果。参考代码可以这样写def compress_string(s: str) - str: if not s: return s res [] count 1 for i in range(1, len(s)): if s[i] s[i - 1]: count 1 else: res.append(s[i - 1] str(count)) count 1 res.append(s[-1] str(count)) compressed .join(res) return compressed if len(compressed) len(s) else s这道题考察的不是你会不会背十种高级算法而是你能不能在一分钟内识别出“这是字符串遍历计数”的问题模型。测试开发的代码题很多时候都是这种“思路不复杂但代码要干净”的类型。能把边界条件处理干净本身就比大多数人强了。2.3 拿到编程题后的固定动作我自己的习惯是不管题目多简单都按下面四步走把题目中给的示例手推一遍确认理解没跑偏。列出自己能想到的边界条件空输入、极端大小、重复元素、负数、溢出等。先用最直白的方法写一版能跑通就行不追求一步到位。跑通之后再优化时间和空间复杂度。这套流程看起来多花时间但实际上非常省时间。它最大的作用不是提升实力而是降低“会但没做对”的概率。测试开发的编程题往往不难真正拉开差距的是提交一次通过的稳定性。3. 测试用例设计题怎么答才能拿分3.1 边界值和等价类永远是主线测试用例设计题一般会给一个功能点让你写测试用例。不少同学上来就一顿操作写个十几条用例觉得自己写得挺全但阅卷人一看就知道你有没有受过专业训练。因为大家考的还是你能不能系统性地用测试设计方法。最常见的套路就是以等价类划分法和边界值分析法为主干。以“用户注册功能”为例假设需求是用户名长度3到20个字符允许字母和数字不允许特殊字符密码长度6到16位。那测试用例应该覆盖这些方向合法等价类一个20位字母数字组合、一个正好3位的用户名、一个16位密码。非法等价类用户名只有2位、包含特殊字符、密码只有5位、密码超过16位。边界值3位、20位、21位、2位这种紧贴边界的数字。空值用户名或密码为空时系统是否有明确提示。注意这还只是输入校验层面的内容。真正完整的用例设计还需要考虑功能逻辑比如同一时间两个用户注册同一个用户名怎么办、注册成功后跳转是否正确、提交按钮重复点击会不会产生重复记录、网络中断时有没有提示。用例要体现功能维度的全覆盖而不只是输入框。3.2 我踩过的坑用例设计没写预期结果这点说起来挺丢人我第一年做在线笔试题的时候用例设计写了一大堆但有一半没写“预期结果”。写的时候觉得“这不显而易见吗”但阅卷人看到的是一堆只有操作步骤没有验证标准的半成品。后来我复盘才明白测试用例和测试步骤的本质区别就在预期结果上它才是判断“用例是否通过”的判据。所以我现在的习惯是每一条用例必须包含三个要素前置条件、操作步骤、预期结果。比如用例编号前置条件操作步骤预期结果TC001已进入注册页面输入用户名test123密码123456点击注册注册成功跳转到登录页TC002已进入注册页面输入用户名ab密码123456点击注册提示“用户名长度需为3-20个字符”TC003已注册用户test123再次注册用户名test123提示“用户名已存在”别看表格简单这种格式的好处是逻辑清晰、可执行性高阅卷人一眼就能看到你的测试设计是否规范。笔试时哪怕时间紧我也会把预期结果那列写完整哪怕写得简短一点也比空着强。3.3 场景法让用例设计更出彩除了等价类和边界值场景法也是简答题的加分项。所谓场景法就是站在用户实际操作的路径上去设计用例。比如“用户A未登录点击结算被引导到登录页登录完成后自动回到结算页” 这类用例不是单纯测输入框而是在测业务流是否顺畅。我通常会在用例设计题目末尾补几条场景流用例刻意体现自己不是只会背方法而是真的懂业务。这种细节在笔试里很讨巧能在分数上体现出“有经验的人”和“新手”的差别。4. Linux、数据库和计算机网络测试开发的基座4.1 Linux必背命令与实际场景测试开发的日常工作基本绕不开Linux服务器。查看日志、启动服务、查看进程、修改权限都是高频场景。考察Linux命令时不会让你干背命令而是给你一个场景让你选择或写出对应命令。这种题关键不是死记硬背而是知道每个场景该用哪条命令。查看某个服务进程是否活着ps -ef | grep 服务名动态查看日志文件最新内容tail -f xxx.log从日志里筛出包含ERROR的行grep ERROR xxx.log统计日志里某个关键词出现次数grep -c Timeout xxx.log查找某个文件并查看大小find / -name config.yaml -exec ls -lh {} \;修改脚本权限为可执行chmod x test.sh我建议不要只背单个命令要组合着练。比如一个典型场景Java服务挂了你SSH到服务器上先看看Java进程还有没有再去看日志的最后100行然后把报错信息复制下来。这个过程中你会自然用到ps、tail、grep练几次就熟了。一定要注意的是Linux命令题不要只会拼写要理解参数的含义。例如tail -f和tail -n 100的区别grep和egrep的关系-E参数什么时候用。这些细节才是拉开分差的地方。4.2 SQL题目的隐藏陷阱数据库在测试开发笔试中出现的频率很高因为做测试时验证数据正确性是家常便饭。SQL题一般考察多表联查、分组聚合、子查询、条件过滤。看似基础但有几个常见陷阱很容易踩。第一个陷阱GROUP BY和HAVING弄混。WHERE是在分组前过滤行HAVING是在分组后过滤组。比如查“订单数量大于10的用户”必须写成HAVING COUNT(*) 10不能写成WHERE COUNT(*) 10。第二个陷阱关联查询时没注意去重。JOIN之后如果关联字段不是唯一的会产生一对多的结果导致统计值翻倍。如果拿这种结果去断言测试结果很容易出现假失败。所以做SQL题时我习惯性先自问一句关联字段是否唯一如果唯一性不确定用DISTINCT或子查询兜底。第三个陷阱排序和分页的顺序。ORDER BY要在LIMIT之前执行逻辑上表示“先排好序再取前N条”。如果顺序反了取出来的数据就是乱序中的前N条语义完全不对。举一个常见写法SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE order_status completed GROUP BY user_id HAVING COUNT(*) 5 ORDER BY order_cnt DESC LIMIT 10;这种题目本身并不难但如果你平时没实际跑过SQL只停留在“看懂了”考场上一紧张就容易漏掉某个关键子句。我建议备考时至少把增删改查、聚合、联表这些操作在本地环境跑一遍形成肌肉记忆。4.3 网络层的常见考点计算机网络是测试开发客观题的大户。最常见的考点包括TCP三次握手、TCP和UDP的区别、HTTP状态码含义、GET和POST的区别、DNS解析过程。我印象很深的是“GET和POST区别”这个点几乎年年出现。常规答案大家都背过GET参数放在URL里POST参数放在请求体里GET更偏向获取数据POST更偏向提交数据GET请求长度有限制。但笔试里如果出多选题往往会出一个容易漏掉的选项“GET请求可以被浏览器缓存POST默认不缓存”。这个选项需要我们真正理解HTTP语义而不是停留在“参数位置不同”。还有个高频考点是TCP三次握手。面试题和笔试题都爱问“为什么是三次而不是两次或四次”。核心原因是要确保双方都能确认对方的收发能力正常。第一次握手客户端告诉服务器“我能发”第二次服务端告诉客户端“我能收也能发”第三次客户端告诉服务端“我能收”。这样双方的能力才得到互相确认。如果简答题里遇到记得把“避免历史重复连接导致的资源浪费”这点也一起写进去会显得有深度。我在备考时有个笨办法把HTTP状态码归成一个表格常考的记熟比如200正常、301永久重定向、302临时重定向、304未修改、401未认证、403禁止访问、404不存在、500服务器内部错误、502网关错误、503服务不可用。这个东西看起来简单但每年都会有同学把403和404弄混白白丢分。5. 从考点反推复习路线距离笔试还有两周怎么安排5.1 优先级排序如果你离笔试还有两周现在开始系统性复习完全来得及但要有优先级。我按照投入产出比给测试开发的备考内容排个序测试用例设计方法这个性价比最高一天就能掌握核心方法简答题直接受益。算法基础刷数组、字符串、哈希表、链表、二叉树五类高频题每天两三道。SQL和Linux结合实操练每天花一小时两周下来绝对够用。计算机网络和操作系统以八股文形式过高频考点每天背一点。测试框架和工具至少了解Selenium、Appium、JUnit/TestNG、JMeter的用途和基本原理因为简答题或面试环节会涉及。排序的逻辑很简单哪些最容易拿分、哪些在笔试里占比高就先花时间搞哪些。测试用例设计是测试岗区别于开发岗的最大加分项但很多同学反而花大量时间刷算法把测试设计荒废了这是本末倒置。5.2 做笔记的正确姿势我备考时有一个习惯每刷一套卷子就整理一张“错题原因归类表”。比如知识盲区这个知识点完全没见过需要去补基础。粗心大意明明是会的但审题不清楚或选项看漏。时间压力后面时间不够仓促作答导致丢分。每次做完题都归个类你就知道自己的薄弱环节究竟是“不会”还是“不稳”。前者靠学习解决后者靠刷题量解决。两者需要的应对策略完全不同。注意做笔记不是抄题而是提炼考点。比如遇到一道考察varchar和char区别的客观题我会记下“char定长varchar变长char适合存储固定长度的身份证号varchar省空间但需要额外存储长度信息”。这样复习时只需要翻笔记不需要重新读一遍原题。5.3 题目做得越多就越好吗很多人认为笔试题海战术就行但其实“做题质量”比“做题数量”重要得多。我见过备考期间刷了两三百道LeetCode的同学笔试成绩反而不如只刷了七八十道但每道题都吃透的人。原因是测试开发的算法题难度相对固定你不需要覆盖所有偏题怪题而是要把高频题型做到熟练。做得慢没关系做完以后把题解思路、边界条件、复杂度分析全部过一遍下次遇到同类题能快速识别出来这才是有效刷题。另外不要只刷不写。很多同学看题解觉得“这题我会”但真到考试时却写不出完整代码。原因在于动态思考到静态代码的转换需要刻意练习。我给自己定的目标是每道题不看答案自己独立写到AC为止如果半小时还写不出来才允许看题解。这种练习方式虽然前期痛苦但进步很快。写在最后的两个小建议第一个建议笔试前一定找一套模拟环境练一次手。很多人第一次用在线笔试系统时不熟悉代码自动补全和样例输入的格式浪费了很多时间。提前适应一下能有效减少临场紧张感。第二个建议所有客观题中多选是最容易丢分的地方。如果题目要求“多选、错选不得分漏选得部分分”那么不确定的选项宁可不选。如果评分规则是“错选倒扣”那更要克制自己的“贪多”心理。看清楚评分规则再做题也是一种测试开发该有的严谨思维。坦白说测试开发笔试不是单纯的算法竞赛更不是死记硬背八股文。它考察的是你有没有能力从系统质量的角度去思考问题同时又能不能用代码把想法高效落地。复习时始终带着这两个视角你准备的每一块内容都会变成笔试分数。 小米测试开发笔试题型全解析与高效复习路线
这是很多同学对测试开发笔试的普遍误解。我这两年带过不少准备秋招的人也经常被问到“小米这种大厂的测试开发笔试题到底考什么”。说句实在话测试开发岗的卷子尤其是小米这种体量的公司确实会兼顾“测试功底”和“工程编码能力”两块。2022年小米秋招笔试-测试开发-卷2这个系列我印象里刷过好几轮题目不算偏但很考验基础是否扎实。今天我不打算每道题报答案而是把它当样本拆一拆这种卷子背后的出题逻辑、考点权重和临场策略顺便把复习路线捋清楚希望能帮后面准备秋招的同学少走点弯路。1. 卷2的题型配置与时间分配真相1.1 这类卷子通常长什么样小米的测试开发笔试卷子整体分这样几大块专业客观题、简答/设计题、编程题。其中客观题一般是单选和多选混着出覆盖面很广从软件测试理论到计算机网络、操作系统、数据库、Linux命令都有可能出现。编程题一般是两道左右难度中等偏基础不像纯后端岗那样动不动就上困难题但也不是随随便便能AC的难度。卷2这个系列给我的整体感觉是客观题占的比例不低大概在40%到50%左右。这部分题目的特点是“知识面很宽但单个题目深挖不狠”基本就是看你对计算机基础概念有没有印象对测试方法有没有体系化的理解。如果你平时只看源码、只刷算法没系统过一遍测试理论反而容易在客观题上翻车。然后是简答设计题通常会给你一个具体功能模块比如登录注册、购物车结算、文件上传这种让你设计测试用例或者让你回答某个测试框架的原理、某个bug定位的思路。这类题没有标准答案但踩分点很明确考察的是你有没有一套可复用、可解释的测试设计思路。1.2 时间怎么分才够用我见过不少同学死在时间分配上。客观题纠结太久到了编程题只剩二十分钟结果本应拿到的分全丢了。按照常见的时间比例如果一场笔试总时长是90分钟我会这样切前10分钟快速扫一遍全部题目把编程题的难度和题型记在心里让自己的潜意识先热起来。客观题控制在35分钟以内会的直接选不确定的先标记不要反复纠结。多选的策略是“宁缺毋滥”拿不准的选项宁可不选也要保证不因错选倒扣分。简答设计题控制在20分钟左右这类题目写清楚框架和关键点就行不要陷入长篇大论。编程题留25到30分钟先把思路理顺再用暴力解兜底拿部分分最后有时间再优化。这套分配方式我反复用了很多次核心思路就一句话先把确定能拿的分全部拿到再啃不确定的分。因为笔试看的是总分和排名不是看某一道题有没有完美解。2. 编程题背后的算法侧重不只是LeetCode2.1 测试开发岗真正关注哪类算法很多人一提到算法题就慌觉得必须把LeetCode刷个三四百道才能上考场。但实际情况是测试开发岗的编程题往往更实用常见的方向有这么几类字符串处理反转、切分、回文判断、子串查找、字符串压缩。数组操作去重、排序、区间合并、双指针、滑动窗口。哈希表应用找出现次数、两数之和、判断是否有重复元素。链表基础反转链表、环形链表判断、删除指定节点。简单二叉树层序遍历、深度计算、镜像翻转。这些知识点看起来不高端但胜在实用价值高。你想想测试开发日常工作里写自动化脚本、做测试数据生成、处理接口返回值哪个不是跟字符串、数组、哈希表打交道。所以笔试题出这些方向背后是有合理性的——他们希望招进来的人能快速写工具脚本而不是只会默写难题模板的人。2.2 一道典型题的拆解过程拿字符串压缩这类经典题来说。题目大概是给定一个字符串把连续出现的字符压缩成“字符出现次数”的形式比如aabccccaaa压缩成a2b1c4a3如果压缩后的字符串不比原串短就返回原串。我推荐先想清楚边界条件再动手写代码空串输入直接返回空串。单个字符不压缩因为a1比a长返回原串。字符在末尾连续出现的情况遍历完要记得把最后一组计入结果。参考代码可以这样写def compress_string(s: str) - str: if not s: return s res [] count 1 for i in range(1, len(s)): if s[i] s[i - 1]: count 1 else: res.append(s[i - 1] str(count)) count 1 res.append(s[-1] str(count)) compressed .join(res) return compressed if len(compressed) len(s) else s这道题考察的不是你会不会背十种高级算法而是你能不能在一分钟内识别出“这是字符串遍历计数”的问题模型。测试开发的代码题很多时候都是这种“思路不复杂但代码要干净”的类型。能把边界条件处理干净本身就比大多数人强了。2.3 拿到编程题后的固定动作我自己的习惯是不管题目多简单都按下面四步走把题目中给的示例手推一遍确认理解没跑偏。列出自己能想到的边界条件空输入、极端大小、重复元素、负数、溢出等。先用最直白的方法写一版能跑通就行不追求一步到位。跑通之后再优化时间和空间复杂度。这套流程看起来多花时间但实际上非常省时间。它最大的作用不是提升实力而是降低“会但没做对”的概率。测试开发的编程题往往不难真正拉开差距的是提交一次通过的稳定性。3. 测试用例设计题怎么答才能拿分3.1 边界值和等价类永远是主线测试用例设计题一般会给一个功能点让你写测试用例。不少同学上来就一顿操作写个十几条用例觉得自己写得挺全但阅卷人一看就知道你有没有受过专业训练。因为大家考的还是你能不能系统性地用测试设计方法。最常见的套路就是以等价类划分法和边界值分析法为主干。以“用户注册功能”为例假设需求是用户名长度3到20个字符允许字母和数字不允许特殊字符密码长度6到16位。那测试用例应该覆盖这些方向合法等价类一个20位字母数字组合、一个正好3位的用户名、一个16位密码。非法等价类用户名只有2位、包含特殊字符、密码只有5位、密码超过16位。边界值3位、20位、21位、2位这种紧贴边界的数字。空值用户名或密码为空时系统是否有明确提示。注意这还只是输入校验层面的内容。真正完整的用例设计还需要考虑功能逻辑比如同一时间两个用户注册同一个用户名怎么办、注册成功后跳转是否正确、提交按钮重复点击会不会产生重复记录、网络中断时有没有提示。用例要体现功能维度的全覆盖而不只是输入框。3.2 我踩过的坑用例设计没写预期结果这点说起来挺丢人我第一年做在线笔试题的时候用例设计写了一大堆但有一半没写“预期结果”。写的时候觉得“这不显而易见吗”但阅卷人看到的是一堆只有操作步骤没有验证标准的半成品。后来我复盘才明白测试用例和测试步骤的本质区别就在预期结果上它才是判断“用例是否通过”的判据。所以我现在的习惯是每一条用例必须包含三个要素前置条件、操作步骤、预期结果。比如用例编号前置条件操作步骤预期结果TC001已进入注册页面输入用户名test123密码123456点击注册注册成功跳转到登录页TC002已进入注册页面输入用户名ab密码123456点击注册提示“用户名长度需为3-20个字符”TC003已注册用户test123再次注册用户名test123提示“用户名已存在”别看表格简单这种格式的好处是逻辑清晰、可执行性高阅卷人一眼就能看到你的测试设计是否规范。笔试时哪怕时间紧我也会把预期结果那列写完整哪怕写得简短一点也比空着强。3.3 场景法让用例设计更出彩除了等价类和边界值场景法也是简答题的加分项。所谓场景法就是站在用户实际操作的路径上去设计用例。比如“用户A未登录点击结算被引导到登录页登录完成后自动回到结算页” 这类用例不是单纯测输入框而是在测业务流是否顺畅。我通常会在用例设计题目末尾补几条场景流用例刻意体现自己不是只会背方法而是真的懂业务。这种细节在笔试里很讨巧能在分数上体现出“有经验的人”和“新手”的差别。4. Linux、数据库和计算机网络测试开发的基座4.1 Linux必背命令与实际场景测试开发的日常工作基本绕不开Linux服务器。查看日志、启动服务、查看进程、修改权限都是高频场景。考察Linux命令时不会让你干背命令而是给你一个场景让你选择或写出对应命令。这种题关键不是死记硬背而是知道每个场景该用哪条命令。查看某个服务进程是否活着ps -ef | grep 服务名动态查看日志文件最新内容tail -f xxx.log从日志里筛出包含ERROR的行grep ERROR xxx.log统计日志里某个关键词出现次数grep -c Timeout xxx.log查找某个文件并查看大小find / -name config.yaml -exec ls -lh {} \;修改脚本权限为可执行chmod x test.sh我建议不要只背单个命令要组合着练。比如一个典型场景Java服务挂了你SSH到服务器上先看看Java进程还有没有再去看日志的最后100行然后把报错信息复制下来。这个过程中你会自然用到ps、tail、grep练几次就熟了。一定要注意的是Linux命令题不要只会拼写要理解参数的含义。例如tail -f和tail -n 100的区别grep和egrep的关系-E参数什么时候用。这些细节才是拉开分差的地方。4.2 SQL题目的隐藏陷阱数据库在测试开发笔试中出现的频率很高因为做测试时验证数据正确性是家常便饭。SQL题一般考察多表联查、分组聚合、子查询、条件过滤。看似基础但有几个常见陷阱很容易踩。第一个陷阱GROUP BY和HAVING弄混。WHERE是在分组前过滤行HAVING是在分组后过滤组。比如查“订单数量大于10的用户”必须写成HAVING COUNT(*) 10不能写成WHERE COUNT(*) 10。第二个陷阱关联查询时没注意去重。JOIN之后如果关联字段不是唯一的会产生一对多的结果导致统计值翻倍。如果拿这种结果去断言测试结果很容易出现假失败。所以做SQL题时我习惯性先自问一句关联字段是否唯一如果唯一性不确定用DISTINCT或子查询兜底。第三个陷阱排序和分页的顺序。ORDER BY要在LIMIT之前执行逻辑上表示“先排好序再取前N条”。如果顺序反了取出来的数据就是乱序中的前N条语义完全不对。举一个常见写法SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE order_status completed GROUP BY user_id HAVING COUNT(*) 5 ORDER BY order_cnt DESC LIMIT 10;这种题目本身并不难但如果你平时没实际跑过SQL只停留在“看懂了”考场上一紧张就容易漏掉某个关键子句。我建议备考时至少把增删改查、聚合、联表这些操作在本地环境跑一遍形成肌肉记忆。4.3 网络层的常见考点计算机网络是测试开发客观题的大户。最常见的考点包括TCP三次握手、TCP和UDP的区别、HTTP状态码含义、GET和POST的区别、DNS解析过程。我印象很深的是“GET和POST区别”这个点几乎年年出现。常规答案大家都背过GET参数放在URL里POST参数放在请求体里GET更偏向获取数据POST更偏向提交数据GET请求长度有限制。但笔试里如果出多选题往往会出一个容易漏掉的选项“GET请求可以被浏览器缓存POST默认不缓存”。这个选项需要我们真正理解HTTP语义而不是停留在“参数位置不同”。还有个高频考点是TCP三次握手。面试题和笔试题都爱问“为什么是三次而不是两次或四次”。核心原因是要确保双方都能确认对方的收发能力正常。第一次握手客户端告诉服务器“我能发”第二次服务端告诉客户端“我能收也能发”第三次客户端告诉服务端“我能收”。这样双方的能力才得到互相确认。如果简答题里遇到记得把“避免历史重复连接导致的资源浪费”这点也一起写进去会显得有深度。我在备考时有个笨办法把HTTP状态码归成一个表格常考的记熟比如200正常、301永久重定向、302临时重定向、304未修改、401未认证、403禁止访问、404不存在、500服务器内部错误、502网关错误、503服务不可用。这个东西看起来简单但每年都会有同学把403和404弄混白白丢分。5. 从考点反推复习路线距离笔试还有两周怎么安排5.1 优先级排序如果你离笔试还有两周现在开始系统性复习完全来得及但要有优先级。我按照投入产出比给测试开发的备考内容排个序测试用例设计方法这个性价比最高一天就能掌握核心方法简答题直接受益。算法基础刷数组、字符串、哈希表、链表、二叉树五类高频题每天两三道。SQL和Linux结合实操练每天花一小时两周下来绝对够用。计算机网络和操作系统以八股文形式过高频考点每天背一点。测试框架和工具至少了解Selenium、Appium、JUnit/TestNG、JMeter的用途和基本原理因为简答题或面试环节会涉及。排序的逻辑很简单哪些最容易拿分、哪些在笔试里占比高就先花时间搞哪些。测试用例设计是测试岗区别于开发岗的最大加分项但很多同学反而花大量时间刷算法把测试设计荒废了这是本末倒置。5.2 做笔记的正确姿势我备考时有一个习惯每刷一套卷子就整理一张“错题原因归类表”。比如知识盲区这个知识点完全没见过需要去补基础。粗心大意明明是会的但审题不清楚或选项看漏。时间压力后面时间不够仓促作答导致丢分。每次做完题都归个类你就知道自己的薄弱环节究竟是“不会”还是“不稳”。前者靠学习解决后者靠刷题量解决。两者需要的应对策略完全不同。注意做笔记不是抄题而是提炼考点。比如遇到一道考察varchar和char区别的客观题我会记下“char定长varchar变长char适合存储固定长度的身份证号varchar省空间但需要额外存储长度信息”。这样复习时只需要翻笔记不需要重新读一遍原题。5.3 题目做得越多就越好吗很多人认为笔试题海战术就行但其实“做题质量”比“做题数量”重要得多。我见过备考期间刷了两三百道LeetCode的同学笔试成绩反而不如只刷了七八十道但每道题都吃透的人。原因是测试开发的算法题难度相对固定你不需要覆盖所有偏题怪题而是要把高频题型做到熟练。做得慢没关系做完以后把题解思路、边界条件、复杂度分析全部过一遍下次遇到同类题能快速识别出来这才是有效刷题。另外不要只刷不写。很多同学看题解觉得“这题我会”但真到考试时却写不出完整代码。原因在于动态思考到静态代码的转换需要刻意练习。我给自己定的目标是每道题不看答案自己独立写到AC为止如果半小时还写不出来才允许看题解。这种练习方式虽然前期痛苦但进步很快。写在最后的两个小建议第一个建议笔试前一定找一套模拟环境练一次手。很多人第一次用在线笔试系统时不熟悉代码自动补全和样例输入的格式浪费了很多时间。提前适应一下能有效减少临场紧张感。第二个建议所有客观题中多选是最容易丢分的地方。如果题目要求“多选、错选不得分漏选得部分分”那么不确定的选项宁可不选。如果评分规则是“错选倒扣”那更要克制自己的“贪多”心理。看清楚评分规则再做题也是一种测试开发该有的严谨思维。坦白说测试开发笔试不是单纯的算法竞赛更不是死记硬背八股文。它考察的是你有没有能力从系统质量的角度去思考问题同时又能不能用代码把想法高效落地。复习时始终带着这两个视角你准备的每一块内容都会变成笔试分数。