1. 一道实习生笔试题到底想筛出什么样的人我第一次看到这套小米2018春季实习生测试开发工程师笔试题时第一反应不是这题我会不会而是出题人想在这里拦住谁。那会儿我已经在测试岗上摸爬滚打了一段时间带过几个实习生也帮部门筛过简历。我太清楚笔试环节的定位了它不是为了招一个什么都会的人而是为了在最短时间内筛掉三类人——只会点点点的、只会背八股的、以及连基本逻辑都理不清的。你细品这份试卷的设计逻辑会发现它考察的东西非常聚焦基础功、场景感、以及把问题掰开揉碎的能力。很多人备考测试开发第一反应是去刷算法题、背设计模式、狂看自动化框架源码。但真正到了笔试现场尤其是像小米这种以业务导向见长的公司你会发现题目本身并不会特别偏、特别怪它考的都是你日后工作里天天要用的东西。这套题的价值恰恰在于它给所有想进测试开发这个方向的人划了一条清晰的线你能不能在真实工程场景里发现问题、定位问题、表达问题。这篇文章我想借着这套题把测试开发笔试里最容易拉分、也最值得深挖的几个维度拆开聊。不搞题海战术也不贴一堆标准答案糊弄人单纯从一个过来人的视角聊聊每类题背后的考察逻辑、踩坑点以及真正高效的准备姿势。2. 从这份真题倒推测试开发的核心技术栈大多数应届生对测试开发岗位有个致命误解以为这岗位是开发里懂点测试测试里懂点开发。这句话听着对但实际操作起来很模糊——到底该懂到什么程度优先懂哪一块这份笔试其实已经给了答案。2.1 Linux与命令行这不是加分项是默认项试卷里但凡涉及环境搭建、日志分析、进程排查的题目底层全靠Linux功底撑。我记得这套题里有一道关于查看某个端口被哪个进程占用的问题表面考的是你知不知道netstat/lsof实际上考的是你平时有没有真的在服务器上排过问题。这里给第一次准备笔试的同学提个醒netstat -tlnp | grep 8080这种命令组合要练到条件反射的程度。ss -tlnp是它的现代替代版很多新装系统里 netstat 可能都没默认安装这时候脑子里得立刻切换方案。除了端口排查文件操作和日志处理是另一大高频区。我建议至少把这几组命令练成肌肉记忆查看实时日志tail -f xxx.log | grep ERROR按时间截取日志段sed -n /2024-01-01 10:00:00/,/2024-01-01 10:30:00/p xxx.log统计关键词出现次数grep -c TimeoutException xxx.log或者带上下文grep -A 5 -B 5 Exception xxx.log快速看磁盘和内存df -h、free -m、top -c文本处理三剑客awk {print $NF}取最后一列、sort | uniq -c | sort -nr做频次排序这些命令不是会不会的问题而是快不快的问题。笔试题量通常不小你在这种基础命令上每多花一分钟后面的大题就少一分钟。我见过太多人死在最后的大题上不是不会是前面小题磨太久。平时练命令的时候别光在本地敲想办法给自己搭一个带真实日志的练习环境哪怕自己写个脚本刷几百行日志进去都行。真实环境里你会遇到编码问题、日志轮转、权限拒绝这些刁钻情况才是笔试真正想摸到的细节。2.2 数据结构与算法考察的永远是取舍不是炫技测试开发笔试里的算法题几乎不会让你写一个红黑树或者KMP它的难度更倾向于你知不知道常见数据结构是干什么用的以及遇到具体场景你会选什么。这一点在这套题里有非常清晰的体现它不会给你一个纯数学化的题目而是把算法藏在某个测试场景背后。比如字符串处理相关的问题——判断回文、最长公共前缀、简单正则匹配——这些题的核心不是在考你背了多少API而是考你的边界思维。空字符串怎么处理全角半角要不要区分超长字符串会不会栈溢出这其实和测试用例设计是同一个思维模式只是换了个载体。我给准备笔试的同学一个实用建议不需要硬啃《算法导论》但《剑指Offer》和LeetCode Hot 100里的简单/中等题一定要刷到能默写的程度。因为笔试现场是有时间压力的你不可能指望自己临场推导一个DP转移方程。尤其是这几个高频类型基本是测试开发笔试的常客字符串反转、括号匹配、版本号比较链表反转、环的检测二叉树的前中后序遍历、层级遍历二分查找及其变体找第一个大于等于某值的位置Top K 问题堆排序或快排思想数组去重、合并两个有序数组这题的答题技巧在于先写暴力解再谈优化。哪怕你一时间没想出来最优解先把能跑通的版本写出来往往能拿一半的分。但如果你一直憋着想最优解很可能直接交白卷。考试不是竞赛先得分再谈优雅。而且从测试开发的视角出发你写的代码本身就该带上防御性——入参为空怎么办数组越界怎么办。笔试阅卷人往往都是资深开发或测试开发他们会特别留意你在代码里有没有这种下意识的安全性判断这比一个完美的算法更能打动他们。2.3 数据库与SQL用三层逻辑拆解查询题数据库在测试开发笔试里的地位比很多人想象得高。为什么因为测试开发日常工作中写SQL查数据、验证数据一致性、构造测试数据都是家常便饭。尤其是涉及订单、用户、支付这些核心业务你测一个功能之前必须先在数据库里把前置数据准备好测完之后还要核对落库结果对不对。SQL不熟连数据准备都做得磕磕绊绊。这套题里的SQL考察点我印象里主要集中在JOIN的理解、GROUP BY与聚合函数、子查询。看起来是大学数据库课上学过的基础内容但笔试考得远比课本灵活——它会给你一张订单表和一张用户表让你查每个地区消费金额最高的用户这种题需要你同时掌握联表、子查询、窗口函数或者巧妙的JOIN写法三种技能。我以一个长达八年的测试开发经验告诉你MySQL里这几个知识点一定要吃透LEFT JOIN和INNER JOIN的区别以及什么时候LEFT JOIN会莫名其妙多出重复数据GROUP BY之后只能select被分组的列和聚合函数这个规则很多人笔试时直接踩坑HAVING和WHERE的执行顺序差异前者是在分组后再过滤后者是在分组前过滤窗口函数ROW_NUMBER() OVER(PARTITION BY ... ORDER BY ...)这是解决分组Top N问题的标准答案还有一个特别容易被忽略的索引与慢查询的基本概念。笔试不一定直接考但面试一定会问。你要能解释为什么WHERE name xxx在没索引时会全表扫描以及EXPLAIN里type从ALL到const意味着什么。这背后是你能不能独立排查一个查询为什么慢的问题而这种问题在测试环境里一天能遇到八百回。3. 试卷里最重的大题测试用例设计的实战套路如果说前面的选择题、编程题决定了你能不能进下一轮那测试用例设计题就决定了面试官愿不愿意让你进下一轮。这么说毫不夸张因为这道题直接暴露了你到底有没有测试思维是这套笔试卷里的分水岭。3.1 等价类与边界值人人都懂但拿不到分的写法测试用例设计题最经典的无非是给一个输入框请设计测试用例。很多同学提起笔就能写输入正常字符、输入空值、输入超长字符、输入特殊字符……乍一看好像该覆盖的都覆盖了但这种答案在阅卷人眼里只有60分甚至更低。为什么因为你只展示了等价类这一个维度而且远不够完整。一套拿高分的用例设计至少要覆盖四个维度第一功能维度。你是一个输入框那它校验什么格式手机号是11位且以1开头邮箱必须包含密码长度是否在6-16位校验规则本身有没有歧义这是用例设计的第一步先把需求拆清楚。第二交互维度。输入框有没有默认值清除按钮键盘是否正常粘贴、截断、自动补全这些系统交互会不会破坏格式移动端还要考虑键盘弹出遮挡、自动大写等问题。这些看起来不起眼的点恰恰是测试工程师在真实业务里最容易发现Bug的地方。第三异常维度。网络超时怎么办服务端返回500怎么办数据库连接池被打满怎么办连续点击提交按钮会不会重复下单这些异常场景不可能全部覆盖但一定要在用例里体现几个关键项这代表你有反脆弱的潜意识。第四数据维度。如果这串手机号对应多个订单怎么办如果邮箱中的用户名部分包含SQL注入关键词怎么办输入内容前后有空格算不算非法用过大数据的同学都知道边界值附近永远是Bug高发地。我阅卷时的评分习惯是每发现一个别人没想到的纬度加5到10分。列出二十条用例如果全是等价类里的常规输入那基本就是中庸卷。如果看到输入../../etc/passwd或者粘贴10000个字符检查不崩溃这种我会直接给高分——因为这个人脑子里已经装了真实世界的安全性思维。3.2 从登录框到微信红包用例题的标准解题框架只聊分点还太虚我直接以这套笔试题里出现过的一种典型变体——微信红包功能——来推演一遍完整框架。红包这个话题在测试开发笔试里是老演员了因为它兼顾了功能、金额、并发、支付、通知、限额等大量维度能一次性考察你的综合测试思维。拿到这种题第一件事不是动笔列表格而是先在草稿纸上把需求拆成模块。我习惯按前端交互-后端逻辑-数据存储-外部依赖四层来拆前端交互输入金额整数/小数、0.01、上限200、红包个数1个还是100个、留言内容、塞钱进红包后的弹窗展示、拆红包的动效、过期红包的回收提示。后端逻辑金额拆分算法每个人抢到的金额不能为0、所有金额总和必须等于红包总额、并发抢红包的原子性处理、同一用户在同一红包里只能抢一次、红包24小时未领完退回原账户。数据存储红包记录表、领取记录表、账户流水表的三张表一致性数据库主从延迟时会不会出现抢了显示成功但流水查不到的问题拆红包和入账之间挂了怎么办。外部依赖微信支付网关超时、银行系统限流、消息推送服务挂了红包要不要展示、定时任务做红包过期退款时服务刚好重启了怎么办。一层一层拆完之后你才会有层次感地去列用例而不是零散地想到哪写到哪。我见过一个非常出色的答案这个同学在最后还写了一句以上用例均需补充优先级标注P0为影响资金安全的用例。一句话就体现了他的工程素养阅卷人一眼就能看出来这是个靠谱的人。4. 线上故障排查题的完整答题链除了测试用例设计故障排查类题目也是这套笔试题里很拉分的一块。它通常给你一段场景描述——比如用户反馈下单失败请给出排查思路——然后看你怎么拆解。这类题的核心不是让你背命令而是看你的排查链路是否清晰。4.1 从现象到根因一个典型的接口超时案例我拿一次真实的工作场景举例。当时线上用户反馈下单接口大量超时我先做了什么不是去翻日志而是先看监控大盘QPS有没有突增、平均响应时间是从哪一刻开始升高、是否只影响某个接口还是全站都慢、错误率同步走势如何。这组信息能帮我把问题定位到三个方向之一入口流量问题、服务自身问题、下游依赖问题。笔试里虽然没有真实的监控系统给你点但你的答案里必须体现出这个分层定位的思路。很多同学上来就我看一下日志——这句话本身没有任何信息量谁都知道要看日志关键是看什么日志、按什么顺序看。我推荐的排查顺序是先看基础资源服务器CPU、内存、磁盘IO。一个小脚本导致CPU飙到100%这种情况太常见了再看应用日志找到超时的堆栈看是卡在哪个环节最后查依赖组件Redis慢日志、MySQL慢查询、MQ积压数每一步都有一个典型的元凶苗头你得在答案里把这些苗头对应的判断依据写出来。比如线上发生接口超时如果你是根因怀疑MySQL慢查询你会怎么验证我会看慢查询日志开关有没有开slow_query_log和long_query_time两个参数的值是多少然后直接查询mysqldumpslow或information_schema里排序最顶部的执行计划。笔试答题时写出这种具体的验证路径会显得你很有实战经验。4.2 日志分析题tac grep awk 的实战组合日志分析在笔试里通常以小问的形式出现比如请从日志中统计每个URL的平均访问耗时或者是找出访问量Top 5的IP。这种题目给了你一段模拟日志考验的就是你用Linux命令剖析文本的能力。我在这里分享一个实际的答题套路笔试时极其管用。当你面对一个多行日志文件时永远先对日志格式做探测head -n 5 某条日志.log tail -n 5 某条日志.log wc -l 某条日志.log先看清楚每条日志长什么样、总共有多少行再决定用什么分隔符怎么截取。很多人一上来就直接awk -F 结果字段分割不对越算越乱。正确的做法是先看一行日志的原始结构找到真正需要提取的字段在第几列然后再写完整的命令。这就跟你写SQL之前要先DESCRIBE表结构一样是一个很小但能让你少走大量弯路的操作习惯。最常见的题目组合是grep STATUS access.log | awk {print $1} | sort | uniq -c | sort -nr | head -n 5这行命令的本质是筛选—提取—排序—去重计数—取前几名一套组合拳打完Top IP、Top接口、报错最多的接口类型都可以做出来。如果你能在这个基础上加一句使用uniq -c前必须先排序那就是经验之谈了。很多第一次用uniq -c的人因为没先排序统计出来的数字完全不对这属于典型的环境不熟导致的低级错误。**笔试答题时记得把命令写出来而不是只写思路。**这部分是少数能在纸上完全还原真实工作场景的题型你写的每一个命令都直接等于你日常工作的操作习惯。5. 笔试之外的隐性维度你在试卷上被悄悄观察的事笔试评分除了看答案对不对、命令写得好不好阅卷人还会潜意识地根据你的卷面给一个这个人好不好带、能不能信任的判断。这一点很少人聊但恰恰是实习生笔试里很关键的一环。首先审题的准确度。我见过不少人明明题目问如何设计测试用例他洋洋洒洒写了一堆自动化的代码。答得确实很勤奋但对题目要求的这种偏离让人觉得你没办法准确接收别人的需求。做测试开发接收需求、澄清需求、按需求执行是做事的底层逻辑你在笔试题上都不认真审题谁放心把线上的核心业务交给你测其次答题顺序传达的情绪稳定度。笔试中遇到不会的题很正常但你怎么处理不会的题会传达你的情绪管理能力。我比较欣赏那种先跳过把会做的做完再回来啃难题的答题策略——这种做法的本质是懂得止损懂得优先级管理这在测试工作中特别重要。反观死磕一道题、最后导致后面全没时间做的同学即使某道题答得再漂亮整体卷面的完成度也会拉低分数。再者书写本身就是代码规范的镜子。如果你的代码在纸上就变量命名清晰、缩进整齐、关键步骤有注释面试官会自然而然地觉得你是一个靠谱的工程实践者。反之代码挤成一团、命名全是a/b/c会让面试官对你的代码质量产生直接怀疑。这本身不是笔试题目却比一道算法题更能反映一个人的真实工作状态。我看到这套小米题的时候最大的感受就是它几乎把所有该踩的分层考察点都覆盖了每一类题都能对应到真实工作中的一个具体模块。如果你能做一遍这套题而且每道题都能说出它对应的工作场景那你的备考就已经超越一大半人了。6. 备考节奏怎么安排才不会在考场上手忙脚乱到最后这个部分聊点实用的备考规划。我见过太多简历很漂亮、能力也不错的同学在笔试环节栽跟头回头复盘都是同一个原因重点跑偏了。他们把时间全花在啃偏题怪题上反而忽略了最基础、最常考的板块。针对测试开发这个岗位的特点我建议以两周为一个周期来安排。第一周主打基础底子的查漏补缺——Linux常用命令过一遍哪些命令还不熟立刻补SQL的JOIN、GROUP BY窗口函数刷一遍LeetCode数据库板块算法题专注于字符串、链表、二叉树三个模块的简单到中等题。第二周进入试卷模拟阶段——严格限时做整套真题。这里有个关键点模拟的时候必须手写可以在白纸上写也可以在纯文本编辑器里写就是不要用IDE的自动补全和提示。笔试环境往往没有智能提示你平时依赖IDE越多考前越需要脱稿练习。具体到每天的时间分配我建议早上1小时SQL练习三到五题重点是写完之后看执行计划下午1.5小时算法题两到三题写完一定要自己手动跑测试用例别一提交通过就完事晚上1小时Linux命令实操。给自己找一份真实项目的日志文件模拟线上排查这是一个普通强度但极其实用的节奏。如果你时间充裕周末还可以花半天时间系统地整理一份自己的测试开发常用命令速查表把这两周遇到的所有命令和坑都记在一个Markdown文档里。自己亲手写出来的笔记考试时即使不能带进去你的记忆也会比粗过两遍书要牢固得多。我特别想强调一个点实习生的笔试并不要求你是一个全栈工程师。出题人心里清楚你来实习就是来学东西的他要考察的是你有没有值得培养的底子。所以遇到不会的题别慌把你会的那部分先写上去把思路写清楚哪怕结果是错的也比留白强。阅卷人会看你的推导过程过程比结果更能说明你对一个问题的理解深度。7. 笔试只是入场券真正的测试开发之路从入职才真正开始说句实在话笔试考得好只能证明你具备了基础的工程素养它离一个真正能独当一面的测试开发工程师中间还隔着大量的项目实战。我带过好几个从笔试高分进来的实习生刚上手时照样被真实业务的复杂度震住了——环境怎么搭、数据怎么造、Bug怎么复现、跟开发怎么沟通这些光靠笔试准备是远远学不来的。我在实际带人的过程中发现那些笔试准备做得充分的人往往在入职之后学得也更快。这不是因为他们比别人聪明而是因为在备考过程中已经建立了一套属于自己的学习路径会自己找资料、会归纳总结、会针对性练习。这套方法迁移到真实工作上威力更大。所以如果你正在准备测试开发的笔试不用把分数看得太重但一定要把备考过程当成一次系统学习的机会。你刷过的每道SQL、敲过的每条Linux命令、设计过的每个测试用例都会在未来的某一天成为你解决一个线上问题时的武器。给你留一道思考题吧如果让你给微信的群接龙功能设计测试用例你首先会拆成哪几个模块试试用上面说的四层拆分法拿出草稿纸过一遍。这套思路一旦练成肌肉记忆无论考场上遇到什么样的场景题你都不会慌张。 测试开发笔试通关指南：从Linux命令到用例设计
1. 一道实习生笔试题到底想筛出什么样的人我第一次看到这套小米2018春季实习生测试开发工程师笔试题时第一反应不是这题我会不会而是出题人想在这里拦住谁。那会儿我已经在测试岗上摸爬滚打了一段时间带过几个实习生也帮部门筛过简历。我太清楚笔试环节的定位了它不是为了招一个什么都会的人而是为了在最短时间内筛掉三类人——只会点点点的、只会背八股的、以及连基本逻辑都理不清的。你细品这份试卷的设计逻辑会发现它考察的东西非常聚焦基础功、场景感、以及把问题掰开揉碎的能力。很多人备考测试开发第一反应是去刷算法题、背设计模式、狂看自动化框架源码。但真正到了笔试现场尤其是像小米这种以业务导向见长的公司你会发现题目本身并不会特别偏、特别怪它考的都是你日后工作里天天要用的东西。这套题的价值恰恰在于它给所有想进测试开发这个方向的人划了一条清晰的线你能不能在真实工程场景里发现问题、定位问题、表达问题。这篇文章我想借着这套题把测试开发笔试里最容易拉分、也最值得深挖的几个维度拆开聊。不搞题海战术也不贴一堆标准答案糊弄人单纯从一个过来人的视角聊聊每类题背后的考察逻辑、踩坑点以及真正高效的准备姿势。2. 从这份真题倒推测试开发的核心技术栈大多数应届生对测试开发岗位有个致命误解以为这岗位是开发里懂点测试测试里懂点开发。这句话听着对但实际操作起来很模糊——到底该懂到什么程度优先懂哪一块这份笔试其实已经给了答案。2.1 Linux与命令行这不是加分项是默认项试卷里但凡涉及环境搭建、日志分析、进程排查的题目底层全靠Linux功底撑。我记得这套题里有一道关于查看某个端口被哪个进程占用的问题表面考的是你知不知道netstat/lsof实际上考的是你平时有没有真的在服务器上排过问题。这里给第一次准备笔试的同学提个醒netstat -tlnp | grep 8080这种命令组合要练到条件反射的程度。ss -tlnp是它的现代替代版很多新装系统里 netstat 可能都没默认安装这时候脑子里得立刻切换方案。除了端口排查文件操作和日志处理是另一大高频区。我建议至少把这几组命令练成肌肉记忆查看实时日志tail -f xxx.log | grep ERROR按时间截取日志段sed -n /2024-01-01 10:00:00/,/2024-01-01 10:30:00/p xxx.log统计关键词出现次数grep -c TimeoutException xxx.log或者带上下文grep -A 5 -B 5 Exception xxx.log快速看磁盘和内存df -h、free -m、top -c文本处理三剑客awk {print $NF}取最后一列、sort | uniq -c | sort -nr做频次排序这些命令不是会不会的问题而是快不快的问题。笔试题量通常不小你在这种基础命令上每多花一分钟后面的大题就少一分钟。我见过太多人死在最后的大题上不是不会是前面小题磨太久。平时练命令的时候别光在本地敲想办法给自己搭一个带真实日志的练习环境哪怕自己写个脚本刷几百行日志进去都行。真实环境里你会遇到编码问题、日志轮转、权限拒绝这些刁钻情况才是笔试真正想摸到的细节。2.2 数据结构与算法考察的永远是取舍不是炫技测试开发笔试里的算法题几乎不会让你写一个红黑树或者KMP它的难度更倾向于你知不知道常见数据结构是干什么用的以及遇到具体场景你会选什么。这一点在这套题里有非常清晰的体现它不会给你一个纯数学化的题目而是把算法藏在某个测试场景背后。比如字符串处理相关的问题——判断回文、最长公共前缀、简单正则匹配——这些题的核心不是在考你背了多少API而是考你的边界思维。空字符串怎么处理全角半角要不要区分超长字符串会不会栈溢出这其实和测试用例设计是同一个思维模式只是换了个载体。我给准备笔试的同学一个实用建议不需要硬啃《算法导论》但《剑指Offer》和LeetCode Hot 100里的简单/中等题一定要刷到能默写的程度。因为笔试现场是有时间压力的你不可能指望自己临场推导一个DP转移方程。尤其是这几个高频类型基本是测试开发笔试的常客字符串反转、括号匹配、版本号比较链表反转、环的检测二叉树的前中后序遍历、层级遍历二分查找及其变体找第一个大于等于某值的位置Top K 问题堆排序或快排思想数组去重、合并两个有序数组这题的答题技巧在于先写暴力解再谈优化。哪怕你一时间没想出来最优解先把能跑通的版本写出来往往能拿一半的分。但如果你一直憋着想最优解很可能直接交白卷。考试不是竞赛先得分再谈优雅。而且从测试开发的视角出发你写的代码本身就该带上防御性——入参为空怎么办数组越界怎么办。笔试阅卷人往往都是资深开发或测试开发他们会特别留意你在代码里有没有这种下意识的安全性判断这比一个完美的算法更能打动他们。2.3 数据库与SQL用三层逻辑拆解查询题数据库在测试开发笔试里的地位比很多人想象得高。为什么因为测试开发日常工作中写SQL查数据、验证数据一致性、构造测试数据都是家常便饭。尤其是涉及订单、用户、支付这些核心业务你测一个功能之前必须先在数据库里把前置数据准备好测完之后还要核对落库结果对不对。SQL不熟连数据准备都做得磕磕绊绊。这套题里的SQL考察点我印象里主要集中在JOIN的理解、GROUP BY与聚合函数、子查询。看起来是大学数据库课上学过的基础内容但笔试考得远比课本灵活——它会给你一张订单表和一张用户表让你查每个地区消费金额最高的用户这种题需要你同时掌握联表、子查询、窗口函数或者巧妙的JOIN写法三种技能。我以一个长达八年的测试开发经验告诉你MySQL里这几个知识点一定要吃透LEFT JOIN和INNER JOIN的区别以及什么时候LEFT JOIN会莫名其妙多出重复数据GROUP BY之后只能select被分组的列和聚合函数这个规则很多人笔试时直接踩坑HAVING和WHERE的执行顺序差异前者是在分组后再过滤后者是在分组前过滤窗口函数ROW_NUMBER() OVER(PARTITION BY ... ORDER BY ...)这是解决分组Top N问题的标准答案还有一个特别容易被忽略的索引与慢查询的基本概念。笔试不一定直接考但面试一定会问。你要能解释为什么WHERE name xxx在没索引时会全表扫描以及EXPLAIN里type从ALL到const意味着什么。这背后是你能不能独立排查一个查询为什么慢的问题而这种问题在测试环境里一天能遇到八百回。3. 试卷里最重的大题测试用例设计的实战套路如果说前面的选择题、编程题决定了你能不能进下一轮那测试用例设计题就决定了面试官愿不愿意让你进下一轮。这么说毫不夸张因为这道题直接暴露了你到底有没有测试思维是这套笔试卷里的分水岭。3.1 等价类与边界值人人都懂但拿不到分的写法测试用例设计题最经典的无非是给一个输入框请设计测试用例。很多同学提起笔就能写输入正常字符、输入空值、输入超长字符、输入特殊字符……乍一看好像该覆盖的都覆盖了但这种答案在阅卷人眼里只有60分甚至更低。为什么因为你只展示了等价类这一个维度而且远不够完整。一套拿高分的用例设计至少要覆盖四个维度第一功能维度。你是一个输入框那它校验什么格式手机号是11位且以1开头邮箱必须包含密码长度是否在6-16位校验规则本身有没有歧义这是用例设计的第一步先把需求拆清楚。第二交互维度。输入框有没有默认值清除按钮键盘是否正常粘贴、截断、自动补全这些系统交互会不会破坏格式移动端还要考虑键盘弹出遮挡、自动大写等问题。这些看起来不起眼的点恰恰是测试工程师在真实业务里最容易发现Bug的地方。第三异常维度。网络超时怎么办服务端返回500怎么办数据库连接池被打满怎么办连续点击提交按钮会不会重复下单这些异常场景不可能全部覆盖但一定要在用例里体现几个关键项这代表你有反脆弱的潜意识。第四数据维度。如果这串手机号对应多个订单怎么办如果邮箱中的用户名部分包含SQL注入关键词怎么办输入内容前后有空格算不算非法用过大数据的同学都知道边界值附近永远是Bug高发地。我阅卷时的评分习惯是每发现一个别人没想到的纬度加5到10分。列出二十条用例如果全是等价类里的常规输入那基本就是中庸卷。如果看到输入../../etc/passwd或者粘贴10000个字符检查不崩溃这种我会直接给高分——因为这个人脑子里已经装了真实世界的安全性思维。3.2 从登录框到微信红包用例题的标准解题框架只聊分点还太虚我直接以这套笔试题里出现过的一种典型变体——微信红包功能——来推演一遍完整框架。红包这个话题在测试开发笔试里是老演员了因为它兼顾了功能、金额、并发、支付、通知、限额等大量维度能一次性考察你的综合测试思维。拿到这种题第一件事不是动笔列表格而是先在草稿纸上把需求拆成模块。我习惯按前端交互-后端逻辑-数据存储-外部依赖四层来拆前端交互输入金额整数/小数、0.01、上限200、红包个数1个还是100个、留言内容、塞钱进红包后的弹窗展示、拆红包的动效、过期红包的回收提示。后端逻辑金额拆分算法每个人抢到的金额不能为0、所有金额总和必须等于红包总额、并发抢红包的原子性处理、同一用户在同一红包里只能抢一次、红包24小时未领完退回原账户。数据存储红包记录表、领取记录表、账户流水表的三张表一致性数据库主从延迟时会不会出现抢了显示成功但流水查不到的问题拆红包和入账之间挂了怎么办。外部依赖微信支付网关超时、银行系统限流、消息推送服务挂了红包要不要展示、定时任务做红包过期退款时服务刚好重启了怎么办。一层一层拆完之后你才会有层次感地去列用例而不是零散地想到哪写到哪。我见过一个非常出色的答案这个同学在最后还写了一句以上用例均需补充优先级标注P0为影响资金安全的用例。一句话就体现了他的工程素养阅卷人一眼就能看出来这是个靠谱的人。4. 线上故障排查题的完整答题链除了测试用例设计故障排查类题目也是这套笔试题里很拉分的一块。它通常给你一段场景描述——比如用户反馈下单失败请给出排查思路——然后看你怎么拆解。这类题的核心不是让你背命令而是看你的排查链路是否清晰。4.1 从现象到根因一个典型的接口超时案例我拿一次真实的工作场景举例。当时线上用户反馈下单接口大量超时我先做了什么不是去翻日志而是先看监控大盘QPS有没有突增、平均响应时间是从哪一刻开始升高、是否只影响某个接口还是全站都慢、错误率同步走势如何。这组信息能帮我把问题定位到三个方向之一入口流量问题、服务自身问题、下游依赖问题。笔试里虽然没有真实的监控系统给你点但你的答案里必须体现出这个分层定位的思路。很多同学上来就我看一下日志——这句话本身没有任何信息量谁都知道要看日志关键是看什么日志、按什么顺序看。我推荐的排查顺序是先看基础资源服务器CPU、内存、磁盘IO。一个小脚本导致CPU飙到100%这种情况太常见了再看应用日志找到超时的堆栈看是卡在哪个环节最后查依赖组件Redis慢日志、MySQL慢查询、MQ积压数每一步都有一个典型的元凶苗头你得在答案里把这些苗头对应的判断依据写出来。比如线上发生接口超时如果你是根因怀疑MySQL慢查询你会怎么验证我会看慢查询日志开关有没有开slow_query_log和long_query_time两个参数的值是多少然后直接查询mysqldumpslow或information_schema里排序最顶部的执行计划。笔试答题时写出这种具体的验证路径会显得你很有实战经验。4.2 日志分析题tac grep awk 的实战组合日志分析在笔试里通常以小问的形式出现比如请从日志中统计每个URL的平均访问耗时或者是找出访问量Top 5的IP。这种题目给了你一段模拟日志考验的就是你用Linux命令剖析文本的能力。我在这里分享一个实际的答题套路笔试时极其管用。当你面对一个多行日志文件时永远先对日志格式做探测head -n 5 某条日志.log tail -n 5 某条日志.log wc -l 某条日志.log先看清楚每条日志长什么样、总共有多少行再决定用什么分隔符怎么截取。很多人一上来就直接awk -F 结果字段分割不对越算越乱。正确的做法是先看一行日志的原始结构找到真正需要提取的字段在第几列然后再写完整的命令。这就跟你写SQL之前要先DESCRIBE表结构一样是一个很小但能让你少走大量弯路的操作习惯。最常见的题目组合是grep STATUS access.log | awk {print $1} | sort | uniq -c | sort -nr | head -n 5这行命令的本质是筛选—提取—排序—去重计数—取前几名一套组合拳打完Top IP、Top接口、报错最多的接口类型都可以做出来。如果你能在这个基础上加一句使用uniq -c前必须先排序那就是经验之谈了。很多第一次用uniq -c的人因为没先排序统计出来的数字完全不对这属于典型的环境不熟导致的低级错误。**笔试答题时记得把命令写出来而不是只写思路。**这部分是少数能在纸上完全还原真实工作场景的题型你写的每一个命令都直接等于你日常工作的操作习惯。5. 笔试之外的隐性维度你在试卷上被悄悄观察的事笔试评分除了看答案对不对、命令写得好不好阅卷人还会潜意识地根据你的卷面给一个这个人好不好带、能不能信任的判断。这一点很少人聊但恰恰是实习生笔试里很关键的一环。首先审题的准确度。我见过不少人明明题目问如何设计测试用例他洋洋洒洒写了一堆自动化的代码。答得确实很勤奋但对题目要求的这种偏离让人觉得你没办法准确接收别人的需求。做测试开发接收需求、澄清需求、按需求执行是做事的底层逻辑你在笔试题上都不认真审题谁放心把线上的核心业务交给你测其次答题顺序传达的情绪稳定度。笔试中遇到不会的题很正常但你怎么处理不会的题会传达你的情绪管理能力。我比较欣赏那种先跳过把会做的做完再回来啃难题的答题策略——这种做法的本质是懂得止损懂得优先级管理这在测试工作中特别重要。反观死磕一道题、最后导致后面全没时间做的同学即使某道题答得再漂亮整体卷面的完成度也会拉低分数。再者书写本身就是代码规范的镜子。如果你的代码在纸上就变量命名清晰、缩进整齐、关键步骤有注释面试官会自然而然地觉得你是一个靠谱的工程实践者。反之代码挤成一团、命名全是a/b/c会让面试官对你的代码质量产生直接怀疑。这本身不是笔试题目却比一道算法题更能反映一个人的真实工作状态。我看到这套小米题的时候最大的感受就是它几乎把所有该踩的分层考察点都覆盖了每一类题都能对应到真实工作中的一个具体模块。如果你能做一遍这套题而且每道题都能说出它对应的工作场景那你的备考就已经超越一大半人了。6. 备考节奏怎么安排才不会在考场上手忙脚乱到最后这个部分聊点实用的备考规划。我见过太多简历很漂亮、能力也不错的同学在笔试环节栽跟头回头复盘都是同一个原因重点跑偏了。他们把时间全花在啃偏题怪题上反而忽略了最基础、最常考的板块。针对测试开发这个岗位的特点我建议以两周为一个周期来安排。第一周主打基础底子的查漏补缺——Linux常用命令过一遍哪些命令还不熟立刻补SQL的JOIN、GROUP BY窗口函数刷一遍LeetCode数据库板块算法题专注于字符串、链表、二叉树三个模块的简单到中等题。第二周进入试卷模拟阶段——严格限时做整套真题。这里有个关键点模拟的时候必须手写可以在白纸上写也可以在纯文本编辑器里写就是不要用IDE的自动补全和提示。笔试环境往往没有智能提示你平时依赖IDE越多考前越需要脱稿练习。具体到每天的时间分配我建议早上1小时SQL练习三到五题重点是写完之后看执行计划下午1.5小时算法题两到三题写完一定要自己手动跑测试用例别一提交通过就完事晚上1小时Linux命令实操。给自己找一份真实项目的日志文件模拟线上排查这是一个普通强度但极其实用的节奏。如果你时间充裕周末还可以花半天时间系统地整理一份自己的测试开发常用命令速查表把这两周遇到的所有命令和坑都记在一个Markdown文档里。自己亲手写出来的笔记考试时即使不能带进去你的记忆也会比粗过两遍书要牢固得多。我特别想强调一个点实习生的笔试并不要求你是一个全栈工程师。出题人心里清楚你来实习就是来学东西的他要考察的是你有没有值得培养的底子。所以遇到不会的题别慌把你会的那部分先写上去把思路写清楚哪怕结果是错的也比留白强。阅卷人会看你的推导过程过程比结果更能说明你对一个问题的理解深度。7. 笔试只是入场券真正的测试开发之路从入职才真正开始说句实在话笔试考得好只能证明你具备了基础的工程素养它离一个真正能独当一面的测试开发工程师中间还隔着大量的项目实战。我带过好几个从笔试高分进来的实习生刚上手时照样被真实业务的复杂度震住了——环境怎么搭、数据怎么造、Bug怎么复现、跟开发怎么沟通这些光靠笔试准备是远远学不来的。我在实际带人的过程中发现那些笔试准备做得充分的人往往在入职之后学得也更快。这不是因为他们比别人聪明而是因为在备考过程中已经建立了一套属于自己的学习路径会自己找资料、会归纳总结、会针对性练习。这套方法迁移到真实工作上威力更大。所以如果你正在准备测试开发的笔试不用把分数看得太重但一定要把备考过程当成一次系统学习的机会。你刷过的每道SQL、敲过的每条Linux命令、设计过的每个测试用例都会在未来的某一天成为你解决一个线上问题时的武器。给你留一道思考题吧如果让你给微信的群接龙功能设计测试用例你首先会拆成哪几个模块试试用上面说的四层拆分法拿出草稿纸过一遍。这套思路一旦练成肌肉记忆无论考场上遇到什么样的场景题你都不会慌张。