每年校招季都会有一批测开岗的同学拿着往年的大厂笔试真题刷题备考。我也是从那个阶段过来的当年为了准备校招把能找到的测试笔试题目翻来覆去啃了好几遍。最近偶然翻到硬盘里存的“360公司-2019校招笔试-测试工程师客观题合集”重新看了一遍发现这批题虽然已经过去好几年但里面的命题逻辑、考点分布、甚至很多题目的设错方式放到今天依然很有参考价值。所以我打算把它拉出来写一篇复盘向的拆解从一份客观题集出发聊聊测试工程师校招笔试到底考什么、怎么筛人、哪些题是看似送分实则杀手的以及从2019年到今天测试工程师的能力要求发生了哪些变化、哪些底层能力始终没变。如果你正在准备测试工程师或测试开发工程师的校招或者在考虑转行做测试但不知道怎么搭知识体系这篇文章应该能给你一个比较完整的坐标系。1. 一份2019年的笔试题集凭什么现在还值得复盘1.1 校招笔试客观题在招聘漏斗中的位置先想一个问题360这种体量的公司一届校招收到的简历少说几万份测试工程师岗位最终可能只招几十到上百人。在这套招聘漏斗的第一道关卡面试官不可能靠人力逐一筛选于是笔试成了性价比最高的手段。笔试里一般分客观题和主观题客观题又是第一道筛网的“硬网格”——它有标准答案批量判卷能快速把候选人按分数切分。所以客观题不指望你能答出什么惊世骇俗的深度内容它的核心目标是在100个候选人里用50道题快速划出那些“基础扎实、逻辑清晰、没有明显硬伤”的人。笔试答得好不一定说明你是一个优秀的测试工程师但笔试答得差大概率说明你在某些基本功上是欠账的。理解了这个定位你就知道刷这份题集时的重点不是“背答案”而是“检测自己的基本功有没有漏洞”。1.2 为什么是客观题而不是全问答题有人会问测试工程师最重要的能力是测试思维和解决问题能力这种能力用主观题、开放性题目去考察不是更有效吗理论上确实如此但现实中存在两个限制。第一是批改成本。一个校招岗位的笔试可能有几千人参加如果全是开放问答题需要资深工程师人工批改这个人力成本完全划不来。而客观题可以上机器判卷标准的格式化和规模化决定了客观题必然是海选的首选。第二是横向对比的一致性。开放题怎么写都有道理张三的答案和李四的答案很难用同一把尺子衡量分数难免带主观性。客观题则不同对就是对错就是错成绩单拉出来一目了然。所以在真实的企业招聘里常见的设计是一轮客观题海选二轮技术面里再用场景题、编程题、项目深挖来做主观判断。客观题是“漏斗第一层”只做粗筛不做精挑。1.3 复盘的真正价值看命题人怎么理解测试工程师我刷这份题集时最大的感慨是它其实是一份“企业测试工程师能力模型”的映射。命题人出什么一定程度上就代表这家公司认为测试工程师需要懂什么。从这份2019年的题集来看覆盖面大概可以分成六七个模块软件测试基础理论、计算机通识数据结构/操作系统/网络、数据库与SQL、编程语言基础、逻辑推理、安全常识、以及少量带场景性质的测试判断。把这些模块连起来看你会得到一份很清晰的画像企业要的测试工程师不是一个“会点点点的人”而是一个“懂业务需求、懂技术原理、能设计测试方案、能和研发平等沟通”的角色。这个画像放在今天依然成立只是技术栈从单纯的“理论基础”延伸到了自动化、性能、安全、AI辅助等领域。关于这部分演进我在第5章会展开聊。2. 客观题的命题地图六类考点与筛选意图因为我自己没有保留这份题集的完整原题为了还原出有代表性的复习方向我去翻了市面上流传的几套同年度大厂测试笔试合集并按下述分类整理了它们的共性考点。你可以把它当作一份知识点地图逐项对照自检看看哪些模块是你的盲区。2.1 软件测试基础理论基本功扎不扎实一问便知这一块是所有测试笔试的重头戏常见考察点包括软件生命周期模型V模型、W模型、敏捷模型以及测试在各个阶段的介入时机测试类型分类功能测试、性能测试、兼容性测试、安全测试、易用性测试等能不能准确区分概念测试用例设计方法等价类划分、边界值分析、判定表法、因果图法、场景法、正交实验法缺陷的概念、缺陷生命周期New、Open、Fixed、Closed等状态流转、缺陷的严重级别和优先级区分回归测试、冒烟测试、探索性测试的定义与适用场景。这类题的考察方式通常是给出了一段描述让你选出“这属于哪类测试”“该用哪种用例设计方法”“这个缺陷的严重级别是哪一个”。如果只是背定义很容易在做题时产生混淆。因为出题人不会直接考定义本身他会把定义嵌入到一个具体的项目场景里让你判断。举个例子题目描述“版本发布前针对主流程跑一遍快速验证确认核心功能没有被破坏”选项是回归测试、冒烟测试、探索性测试、压力测试。很多人会选回归测试因为“核心功能没有被破坏”听起来太像回归了。但这里关键字是“版本发布前”和“快速验证”它是典型的冒烟测试。类似的模糊地带很多所以这一块的复习策略不能是死记硬背而是要把每个概念的核心特征和区分点吃透。2.2 计算机通识基础能不能和研发平等对话的分水岭测试工程师如果完全不懂计算机底层原理工作中会非常被动。这一点在笔试里也有直接体现操作系统和网络是高频考点。常见题目包括进程和线程的区别多线程下的同步与死锁死锁产生的四个必要条件互斥、持有并等待、不可剥夺、循环等待TCP和UDP的区别TCP三次握手和四次挥手的过程HTTP常见状态码的含义比如200、301、302、403、404、500、502DNS域名解析的基本流程数组、链表、栈、队列的基础结构常见排序算法的时间复杂度。出题人考察这些不是希望你背教科书而是因为测试工作里会遇到实实在在的场景。举个例子测一个Web系统的登录功能测试人员发现偶发登录失败研发排查后说“这是网络拥塞导致的”。如果你听不懂TCP握手和连接超时的概念就只能被这句话糊弄过去而如果你理解TCP建立连接的机制你就可以进一步追问“是握手阶段超时还是数据传输阶段丢包”“服务端有没有被动关闭的大量连接”——这样才有可能推动问题解决。类似地如果不理解数据库事务的ACID特性就测不好一个涉及多表更新、需要保证数据一致性的功能。计算机通识不是笔试才需要它是测试工作的基础设施。2.3 数据库与SQL构造数据和验证数据的基本功数据库考察在校招测试笔试中出现频率很高常见题型有给定两张表要求写出查询SQLSELECT语句的条件过滤、GROUP BY分组、HAVING过滤分组、ORDER BY排序多表联查INNER JOIN和LEFT JOIN的区别索引的作用和索引失效的常见场景事务的ACID特性以及四个隔离级别删除表数据的DELETE、TRUNCATE、DROP区别。为什么测试工程师要考SQL因为一个Web应用从前端页面到后端接口最终数据都落在数据库里。测试人员要构造测试数据、验证数据库层面的增删改查结果、排查线上问题时查日志和数据这些都离不开SQL。举个例子测试一个订单系统要验证“每个用户的累计订单金额”是否正确你就得自己写一条分组统计SQL去和前端页面的展示比对。如果不会SQL等于把验证手段废了一半只能依赖研发给的查询结果缺乏独立判断的能力。笔试里考SQL面试里也会考这是测试岗位躲不掉的基本功。2.4 编程语言基础哪怕不写代码也要能读懂代码2019年校招测试笔试的客观题一般不要求手撕代码但会出现阅读代码、找bug、判断程序输出结果的题目。常见考察点是变量的作用域和类型转换循环和递归的执行过程Python中列表、字典的常用操作数组越界、空指针、无限循环等典型代码缺陷一段代码的时间复杂度分析。我见过很多纯功能测试背景的同学一看到代码题就头大觉得“反正我是做手工测试的写代码是开发的事”。这个想法在校招阶段特别吃亏。因为即便是纯测试岗笔试里也会用少量代码题检验你的逻辑严谨性——这是测试工程师的核心竞争力之一。而到了今天测试开发的分工越来越普遍“会写脚本”已经是基本要求了。Python是最主流的选择它上手快写测试脚本、自动化用例、数据处理都方便。如果你还没开始学建议从Python的数据结构、文件读写、异常处理和基础函数式编程开始打底。2.5 安全常识测试工程师需要有点“攻击性”安全测试在大厂的测试笔试中会占一定比例虽然不深但会考察一些常识性的东西。比如什么是SQL注入如何通过输入框拼接SQL语句造成数据泄露什么是XSS攻击反射型与存储型的区别什么是越权访问水平越权和垂直越权怎么区分HTTPS和HTTP的区别加密握手的基本过程。很多做功能测试的同学觉得安全测试是安全工程师的事和自己无关。实际上当你测一个登录注册模块时如果你没有“这个输入框会不会被SQL注入”“未登录用户能不能直接访问登录后的接口”这样的安全测试意识那就只能测到表面功能。笔试中出这类题本质上是在筛选有安全敏感度的测试候选人。2.6 逻辑推理与智力题筛选空间拆解能力逻辑推理题是各大厂测试笔试的标配也是很多人觉得最头疼的部分。常见的有天平称球问题8个球里有1个次品最少称几次能找出次品倒水问题只有一个5升和一个3升水壶如何精确量出4升水赛马问题25匹马、5个赛道最少比几场能找出最快的3匹与或非逻辑推理题。这类题目真的有必要吗我的理解是测试工程师日常工作中相当一部分时间是在做“空间的拆解与覆盖”。需求文档描述的是一个功能空间你需要在有限的资源下设计最少的用例覆盖最多的输入空间并在出bug时快速推理可能的根因空间。天平称球题的解题过程本质上就是“在有限次操作中通过信息量最大化缩小未知空间”的思维训练。所以智力题不是搞数学竞赛它是在测量你的穷举能力和剪枝能力。3. 高频题型的解题思路拆解从标准答案到出题逻辑这一章我挑几类高频题型的代表题目把完整的推导过程摆出来。你有基础的话可以直接跳看结论新手建议顺着推导走一遍——这个推导过程本身就是测试思维的一个缩影。3.1 等价类与边界值一道登录框题目的完整推导题目形式大概是用户名输入框需求规定“长度为7到20位只能包含字母和数字”请选择最合理的测试用例设计方案或从选项中选出必要的测试用例。这道题考的是等价类划分和边界值分析。先做等价类划分有效等价类长度7到20位、只包含字母或数字无效等价类长度小于7位长度大于20位包含特殊字符包含中文为空。再看边界值分析长度为7位和20位是上确界6位和21位是无效边界因此这些值的组合一定要出现在用例里。很多人的误区是只测了“abc123”和“123456789”这种常规值忘了覆盖边界。边界恰恰是最容易出bug的位置——开发在写正则或长度判断时常常在“等于边界值”那一步写错逻辑。这与其说是一道笔试题不如说是在考察你有没有实战中踩过边界bug的直觉。这道题真正的坑在隐性需求。比如“只能包含字母和数字”通常中文输入法的全角数字、全角字母算不算“数字”和“字母”用户用粘贴的方式输入带空格的内容时系统要不要自动去掉首尾空格系统是否允许首字符是数字这些在真实测试中都是要拉开发/产品确认的点。出题人有时候会把其中一个选项设计成“包含特殊字符但长度合法”来考察无效等价类是否覆盖所以读题时先看需求边界再考虑等价类和边界值而不是凭感觉猜。3.2 阅读代码判断题一段有坑的代码这类题常见形态是给你一段代码或伪代码问“输出结果是什么”或者“这段代码存在什么问题”。下面用一段简单的Python代码做例子类似题目在历年校招里经常出现a [1, 2, 3] b a b.append(4) print(a)很多没踩过坑的同学会以为输出是[1, 2, 3]因为“改的是b不是a”。但实际输出是[1, 2, 3, 4]因为列表是可变对象b a只是把b指向了a所引用的同一块内存地址。如果要做真正的拷贝应该用b a.copy()或b a[:]。这类题考察的不是语法背诵而是你有没有真正理解变量的引用与内存语义。测试工程师经常需要验证接口返回的数据是否被意外修改、前端传参是否被后端篡改如果对这类副本和引用的概念不敏感很容易漏掉深层次的缺陷。再举一个常见的坑for i in range(5): pass print(i)输出是4因为Python的循环变量在循环结束后仍然保留最后一个值。很多人以为Python的for循环变量是局部于循环的实际上它存在于外部作用域。如果你在测试脚本里用了类似写法很容易在后续断言时踩到错误数据的坑。3.3 数据库查询题联表统计的两种写法数据库题里最常见的一类是分组统计与多表联查。假设两张表员工表 employee(id, name, dept_id, salary)部门表 department(id, dept_name)。题目要求统计“每个部门的人数和平均工资且只显示平均工资大于8000的部门”。正确答案SELECT dept_id, COUNT(*) AS cnt, AVG(salary) AS avg_salary FROM employee GROUP BY dept_id HAVING AVG(salary) 8000;这里有两个高频考点第一WHERE和HAVING的区分。WHERE是在分组前对原始记录过滤HAVING是在分组后对聚合结果过滤。如果写成WHERE AVG(salary) 8000SQL引擎会直接报错因为聚合函数不能出现在WHERE子句里。但有些数据库方言会做兼容处理这正好是测试人员需要关注的边界——不同数据库对SQL语法的执行一致性并不是100%。第二GROUP BY的联动问题。如果SELECT的列没有被聚合函数包裹且不在GROUP BY子句中在某些数据库比如MySQL的ONLY_FULL_GROUP_BY模式下会报错或返回不可预测的值。这是测试人员构造SQL数据时容易忽略的点也是研发在开发统计功能时最常踩的一个坑。3.4 智力题的通用解法状态空间的穷举思维以经典的“8个球其中1个稍轻用无砝码天平最少称几次能找出次品”为例答案是2次。做法是先分成3、3、2三堆称3和3如果一边轻则次品在轻的那堆3个里再称其中1个和1个即可判断如果3和3平衡则次品在剩下的2个里称一次就出来了。这个解法背后的思维是每次天平称重结果有三种可能左轻、右轻、平衡一次称重最多可以区分3种情况两次称重最多可以区分9种情况而8个球只有8种可能的次品位置所以2次理论上足够。信息论里面的“最大化每次操作的信息量”正是测试用例设计中判定表法、正交实验法的底层思路。再比如倒水问题只有5升和3升水壶如何量出4升水解法是5升壶装满倒入3升壶5升壶中剩2升将3升壶倒空把2升水倒入3升壶再将5升壶装满倒入3升壶直到满3升壶还差1升满5升壶中剩下的就是4升。这道题的本质是“在有限的状态空间里寻找从初始状态到目标状态的一条操作路径”这跟我们在测试功能时设计操作步骤、在复杂系统里复现一个间歇性bug在思维模式上是高度一致的。4. 看似送分实则杀手的题目场景化测试思维的隐性考察如果说上一章节的题目是“考点明确背到就会”那下面这些题就属于“看着都会对答案时才发现掉坑里了”的类型。这类题不会直接考概念而是把测试理念放进真实场景中暗中考察你有没有实战的感觉。4.1 判断题里的大坑绝对化表述与边界条件判断题是客观题里考生普遍觉得“最容易”的题型但也是出题人埋雷的重灾区。最典型的特征就是题干中出现绝对化词汇“所有”“一定”“永远”“只要……就……”。比如“只要进行了充分的测试就能保证软件没有缺陷。”这句话是错的因为测试不可能穷尽所有输入路径和场景测试只能证明软件存在缺陷无法证明没有缺陷。如果你没在真实项目里为“测试放行后发现线上bug”背过锅很容易被这种看似正确的表述带偏。再比如“回归测试只需验证新功能相关的模块。”这也是错的回归测试的核心恰恰是验证改动是否波及了原有功能。事实上出现这类绝对化表述的判断题大概率是错的但有一种特例必须注意——概念性定义、标准定义类题目它们天然带有绝对化表述但本身是对的。这就是大厂的“文字陷阱”套路考你能不能区分“理论定义”和“实践断言”。4.2 测试用例选择题多选项的“全对困境”另一种高频考法是给一个功能模块然后给你四个测试用例选项让你选出“最合理/最完整”的一组。这类题目的设计重点不在于哪个选项“有道理”而在于哪个选项覆盖了需求中的关键风险。举个例子测试一个注册页面的邮箱输入框需求说明“支持标准邮箱格式”。下面四个选项A. 输入testqq.comB. 输入abc无符号C. 输入test缺域名D. 以上都合理但需区分A为有效等价类B和C为无效等价类如果你只选了A说明你只考虑了有效输入忘了无效输入同样要验证系统的错误处理能力。测试用例设计的第一性原理就是有效输入要测无效输入也要测系统要能优雅地给出提示而不是直接崩溃或把脏数据写入数据库。在这个例子里B和C不是“不合理的用例”而是针对无效等价类的用例。所以选项里如果同时出现“A、B、C都需要覆盖”那才是最佳答案。这类题对纯靠背题刷题的人特别不友好因为每个选项单独看都有自己的道理你必须从“覆盖是否充分”这个更高的维度去选答案。你的身份要从“执行测试的人”切换成“设计测试策略的人”。4.3 缺陷报告的优先级判断从“我觉得”到“标准动作”还有一类让我印象很深的题是给出一堆bug描述要求你按照严重程度和优先级排序。这类题表面上是送分题实际上筛掉了一堆凭直觉答题的人。举个典型例子三个bug用户支付成功后订单状态没有更新资金已扣但页面仍显示未支付个人中心页面底部有一处错别字正常网络环境下首页图片资源加载平均耗时从300ms上升到500ms。正确的排序思路是bug1影响核心交易链路且造成用户经济损失严重性和优先级都最高bug3是性能问题不影响正确性但影响用户体验优先级次之bug2是界面文案疏漏严重性最低可排在最后。这个排序背后的判断标准有两个维度严重性对用户和系统影响的范围与程度和优先级修复的紧迫程度通常结合业务目标和发布计划来决定。一个只能看到“严重性高就优先修”的测试人员和能综合“上线风险、用户投诉概率、开发成本”来排优先级的测试人员在成熟团队里的价值是完全不同的。笔试出这种题就是在提前分流这两类人。4.4 场景题给一个需求文档选择要补充的测试点最后这类题可以说是客观题中的“压轴大题”它不给标准的功能列表而是让你针对一个需求文档选出那些“容易被忽略但必须覆盖”的测试点。举例需求是“支持手机号验证码登录的Web系统”。题目给了几个测试点选项手机号格式校验验证码正确/错误/过期短信发送频率限制同一手机号连续发送验证码的时间间隔异地登录时的安全提醒验证码接口是否可被暴力破解。如果只盯着功能流程你会选前面两三项正确思维方式是把测试维度分层功能层、安全性层、性能层、兼容性层。验证码这种设计天然和短信服务商耦合所以测试时还必须考虑“短信服务商接口超时或返回失败”“高并发下短信网关是否会限流”等场景。这其实已经是在考系统性的测试策略了而不是单点功能验证。阅卷人不是在找“标准答案”而是在找“思考了不止一层的人”。这类题你选多了不扣分选少了反而容易暴露出经验盲区。5. 从2019笔试到2025面试测试工程师的能力进阶路径5.1 当年的笔试坐标系 vs 今天的面试技能栈回到开头的问题一份2019年的笔试题现在还值得刷吗刷的价值在于基本功训练但你不能只看它而不看行业的变化。用一张表对照一下2019年测试校招笔试和2025年测试工程师面试的典型能力要求你会更直观地看到变化能力维度2019年校招笔试常见要求2025年测试岗位面试常见要求基础理论测试基础、用例设计方法、缺陷管理理论依然要考但更多以场景题/案例题出现编程能力能读懂简单代码、会基本的逻辑判断要求手写Python脚本、编写自动化用例自动化了解自动化概念个别岗位要求熟悉Pytest、Selenium、Appium等框架有项目实践接口测试较少涉及必考Postman/Requests 接口用例设计性能测试了解概念即可能用JMeter或Locust设计并执行压测会分析结果安全测试了解常见攻击类型能识别越权、SQL注入等常见漏洞懂主流安全扫描工具AI辅助无会用AI工具辅助生成测试用例、分析缺陷、提升效率技术栈变宽了门槛提升了这是好事还是坏事我觉得对认真准备的人来说是好事因为“测试工程师”这个岗位正在从“低成本的功能验证员”往“懂代码、懂业务、懂质量的综合角色”迁移行业价值在提升拿到的回报也在提升。5.2 客观题时代留下的“肌肉记忆”依然有效但也要提醒一句别被“技术栈升级”吓到更别因此忽视了基本功。我看到不少小朋友准备面试时一上来就学Selenium、学JMeter结果被问到“登录功能你怎么设计测试用例”这种基础题反而答得稀烂。这里有个残酷的现实自动化框架可以速成但测试思维速成不了。等价类划分、边界值分析、判定表法、场景法这些用例设计方法在AI时代依然是测试工程师的核心内功。你可以用AI工具帮你生成用例但如果你自己都不知道一个功能应该覆盖哪些维度的风险你连“怎么给AI下好提示词”都做不到。换句话说客观题练出来的那套“穷举输入空间、分析边界条件”的思维方式恰恰是你在AI辅助测试时代最有价值的竞争力。5.3 给当下准备测试工程师面试的人四个层级建议基于近年面试候选人的表现我总结了一个四个层级的准备路径你可以在准备面试时对照第一层把理论打牢这是性价比最高的复习项。软件生命周期、测试类型、用例设计方法、缺陷管理流程不仅要会背还要能在具体场景里举出例子。面试官问“怎么测一个登录框”你如果能从功能用例、异常用例、安全用例、兼容性用例几个层次去回答就已经胜过一大半人了。第二层掌握一门编程语言加SQL。语言建议Python不需要很深的算法但要能写数据处理脚本、调用接口、看懂日志报错。SQL要能写多表联查和分组统计。这一层是测开岗位的“入场券”也是自动化测试的基础。第三层完整跑通一个自动化项目。项目不用大但闭环要完整。比如选择一个开源项目或公司练习环境用Pytest加Selenium做一套Web UI自动化用例或用Requests做一套接口自动化用例然后把它放到Git仓库有基本的CI触发。项目经历写在简历上你的面试素材就立住了。第四层主动拥抱AI工具但别被工具牵着走。用AI生成测试用例、分析缺陷根因、生产测试数据这些能力会越来越重要。但你要具备一个基本判断力AI给出来的用例可能是错或不全的你需要用自己的测试知识去校准和补充。这又回到了“基本功”的层面。5.4 别把刷题当终点用“项目复盘知识树”建立长期竞争力刷题只是手段不是终点。我见过太多候选人笔试题刷了好几遍但问他“你最喜欢的一个测试项目是什么难点在哪里你怎么解决的”他说不上来。这种候选人即使笔试分数高在面试关也会被淘汰。我的建议是一边刷题一边把自己的项目经历实习、课程设计、甚至一个开源工具的自测练习按“需求分析→测试计划→用例设计→执行→缺陷报告→总结”的完整流程复盘一遍。复盘时思考三个问题这个项目最大的测试风险在哪你是如何发现这个风险的如果重做一遍你会在哪里投入更多的测试精力把这些沉淀成文档或思维导图面试时讲出来的效果远比背一百道题要好。同时建一棵个人知识树把笔试题里做错的、模糊的知识点登记上去按“理论—编程—SQL—网络—安全—自动化”几个分支组织定期复习和补充。笔试可以考完就忘但知识树是能持续生长的长期资产。很多三五年经验的测试工程师之所以成长速度差很多就是因为他们没有把“刷过的题”和“做过的项目”沉淀成体系化知识而是让它们溜走了。最后聊点我自己的个人体会。我看着这份题集发现里面的大部分题目考察的不是“你知道多少”而是“你怎么思考”。很多人喜欢问“这个题标准答案是多少”但真实工作中的测试问题往往没有标准答案只有“在当前条件下最合理的答案”。所以我在面试候选人的时候不怎么看对方笔试考了多少分但特别看重一件事你能不能把一道客观题的答案“为什么选它”讲清楚。能讲清“为什么”的人基础通常很扎实也很可能是一个愿意深究底层逻辑的人而只记得“答案是选C”的人哪怕分数再高在真实项目里遇到一个模糊需求时也容易手足无措。如果你现在还在刷题阶段不妨把每一道错题都研究透问问自己“这道题考的是哪个知识点我为什么做错换个场景我还能不能做对”。刷十套题若能把每一道错题的意义都榨干效果足以撑起一场不错的面试。祝备考顺利。