参加过互联网大厂校招的朋友应该都有感触测试工程师的笔试题量往往非常大而且覆盖面极广专业知识、逻辑思维、场景设计一个不落。网易2018校招测试工程师笔试卷放在今天看仍然很有代表性。我当年也做过类似的卷子后来也帮部门出过笔试题再看这份卷子的命题思路其实能读出很多“行业通用语言”它不只考你会不会写测试用例更考你面对一个陌生系统时能不能快速拆解、找出风险、设计有效验证手段。这篇文章我结合当年的题目类型和现在的技术趋势把这类笔试卷背后的考察点拆开揉碎聊一聊也会分享一些实操层面的准备方法。1. 内容整体设计与思路拆解1.1 一份笔试卷想筛出什么样的人先聊一个很多人忽略的问题笔试不是用来筛“技术最强”的人的而是用来筛“最适合做测试”的人。网易2018校招测试工程师笔试卷的整体命题风格代表了大厂测试岗位一个很鲜明的倾向——基础扎实、逻辑清晰、思维缜密、有产品意识。卷子一般会分成几个大块计算机基础知识、测试专业知识、逻辑推理与场景设计、编程与算法基础。不同岗位侧重点略有不同比如游戏测试工程师会更偏重场景设计、战斗逻辑、数值平衡的测试思路而服务端测试工程师会更偏重数据库、Linux、网络协议。但无论哪个方向有几项底层能力是共通的第一你对计算机体系是否有结构化认知第二你是否具备“怀疑一切”的测试思维第三你能不能把模糊的需求转化成可执行的验证步骤。当年这套卷子给我的整体感觉是它不要求你把每一个API背得多熟但对“基础概念是否理解到位”抠得非常细。比如网络部分不会直接问你“TCP和UDP有什么区别”而是给一个具体场景让你判断该用哪种协议、可能出现什么问题、如何验证。这种考法考的是你把知识用起来的能力而不是机械记忆。1.2 为什么2018年的题到现在还有参考价值很多同学会问互联网技术迭代这么快2018年的笔试题是不是已经过时了这个问题我确实认真想过。答案是技术框架会过时但基础能力模型不会。2018年到现在测试行业经历了几个明显变化——AI测试工具逐渐普及、全栈测试工程师的概念越来越火、游戏测试对自动化能力的要求也更高了。但回过头看当年的笔试卷考察的计算机网络、操作系统、数据库、Linux命令、测试用例设计方法依然是如今面试中的高频考点。个中原因也很简单这些内容对应的是一个测试工程师的“内功”框架和工具只是招式。招式可以三月速成内功却需要长期积累。而内功恰恰是校招笔试最方便考察、也最能区分候选人的部分。换句话说2025年去刷2018年的题并不是为了押题而是通过这套题理解“大厂面试官到底在考察哪些核心能力”。理解了这一点你再用同样的能力模型去应对最新的题目就会从容很多。1.3 题量、时间与答题节奏的隐藏信息大家拿到试卷的第一反应通常是“题量真大”。网易这类大厂的测试笔试卷题量普遍在30到40道之间加上编程题考试时间通常是90到120分钟。这里其实藏着一个很关键的信号面试官故意留了做不完的余量。为什么这么做因为测试工程师日常工作中经常面临一个现实在有限时间内如何排布测试优先级、如何把资源投入到风险最高的地方。笔试卷的题量设计就是对这种“优先级判断能力”的一次模拟。所以我一直建议身边准备校招的同学拿到卷子之后不要按顺序从头做到尾而是先花2到3分钟把整张卷子扫一遍把有把握的题、分值高的题先圈出来确保基础分拿满再去啃难题。这不是投机取巧而是一个测试工程师面对“测试时间不足”这一经典问题时应该做出的第一反应。2. 核心细节解析与实操要点2.1 计算机网络考点从概念背诵到场景判断计算机网络几乎是所有大厂测试笔试卷的必考模块网易这份卷子也不例外。我当年做完后最大的感受是它非常喜欢借着具体场景来考察协议理解。比如给你一个“视频通话卡顿”的现象让你分析可能的原因并设计排查方案。这道题表面在考网络实际上在考你“如何用分层思路做问题定位”。要答好这类题不能只背“TCP三次握手四次挥手”的结论而是要理解每一层协议出现的背景和解决的问题。比如TCP为什么需要三次握手因为要同时确认双方的收发能力都正常。四次挥手为什么比握手多一次因为TCP连接是全双工的关闭时每个方向都要单独确认。理解了这些底层逻辑面对任何变形的场景题都能顺藤摸瓜。另外一个高频考点是HTTP协议。2018年的题目已经出现了HTTP/2相关的内容放到现在HTTP/3和QUIC也开始进入面试官的视野。这里给大家一个准备建议不要只背状态码的含义而是要把“一个HTTP请求从输入URL到页面渲染的完整链路”走一遍。这条链路里涉及DNS解析、TCP连接、TLS握手、HTTP请求发送、服务器处理、响应返回、浏览器渲染任何一个环节对测试来说都意味着一个可设计的验证点。能把这个链路讲清楚网络部分的场景题基本就稳了。2.2 操作系统考点进程线程与死锁的常见考法操作系统的考察主要集中在进程与线程、死锁、内存管理、文件系统几个方向。网易这张卷子里印象比较深的是关于死锁的题目——不是单纯让你背死锁的四个必要条件而是给了一段多线程并发访问共享资源的伪代码让考生分析是否可能发生死锁如果可能如何修改。这类题目其实非常适合测试工程师去思考因为并发问题正是线上故障的高发区域。我在实际工作中遇到的很多所谓“偶现bug”最终定位下来都是资源竞争、顺序不当导致的。回答这类问题的关键是要抓住四个必要条件互斥、持有并等待、不可剥夺、循环等待。只要破坏其中一个死锁理论上就不会发生。常见的修改思路有加锁顺序全局一致、使用超时机制、尝试获取锁失败后主动释放已持有的锁等。关于进程与线程还有一类必考题是区别比较。这里提醒大家注意一个容易忽略的点进程是资源分配的基本单位线程是CPU调度的基本单位。这句话听起来简单但真正能解释清楚“为什么线程切换比进程切换开销小”的候选人并不多——因为同一个进程内的线程共享地址空间切换时不需要切换页表等资源。这种细节恰恰是笔试容易出选择题考察的地方。2.3 数据库考点索引、事务与SQL编写的实战要求数据库是测试工程师笔试卷的另一座大山。网易这份卷子的数据库题目大致分为三类SQL编写、索引原理、事务特性。SQL编写题相对最基础但也是最容易丢分的——不是因为你不会写而是因为你写的SQL没考虑边界条件。举个例子题目可能要求“查询每个班级成绩最高的学生信息”。很多同学会立刻想到GROUP BY但如果没有处理分数相同的情况或者没有考虑学生表与班级表的关联方式写出来的SQL可能在边界条件上翻车。我建议准备这类题目时养成一个习惯写完之后立刻在脑子里构造几组测试数据跑一遍你的SQL逻辑。这个习惯放在笔试里就是检查时的“测试思维”放在实际测试工作中就是你写SQL验证测试数据时天然具备的严谨性。索引与事务的部分常考的是“什么时候索引会失效”。这几乎是必考中的必考。常见失效场景包括对索引列使用函数、隐式类型转换、LIKE以通配符开头、OR条件中有一个非索引列。这些场景的背后其实是一个统一的原则——优化器判断“走索引不如全表扫描”时就会放弃索引。理解了原则就不需要死记硬背那些零散的失效场景。事务方面则要重点关注ACID特性与隔离级别尤其是“脏读、不可重复读、幻读”分别对应哪些隔离级别能够避免这是面试官反复试探你是否真正理解并发控制的高频切入点。2.4 Linux与shell测试工程师的日常武器如果说编程语言是测试工程师的左手那Linux就是右手。网易的笔试试卷里Linux相关的题目通常不会太难但考察面很广文件权限管理、进程查看与操作、日志分析、网络排查。这些不是背一背就行的知识而是需要在日常学习和工作中反复使用的技能。我印象很深的一道题是给出一个日志文件包含多行请求记录每行有请求时间、URL、状态码要求统计出状态码为500的请求数。这道题说穿了就是考察awk、grep、sort、uniq这些基础命令的组合使用。看起来简单但实际上能把管道符号串起来的候选人都能通过而没实际敲过命令、只是在课本上看过的人往往会在这一步卡壳。因此我的建议非常直白——准备笔试阶段别只看书一定要在虚拟机或者云服务器上实际把常见的命令过一遍。尤其是文件查找find、locate、文本处理grep、sed、awk、进程管理ps、top、kill、网络排查ping、telnet、curl、netstat这些不是属于“知道就行”的层面而是“手要跟得上脑”的硬技能。哪怕笔试不考shell编程这些基础也会在后来的技术面和实际工作中反复兑现价值。3. 实操过程与核心环节实现3.1 测试用例设计题的通用思路笔试卷里最能拉开差距的往往是测试用例设计题。网易2018年笔试里有一道经典的“登录功能测试用例设计”看似简单却是最考验功底的题目之一。很多同学在回答时只写出账号密码正确和错误两个用例然后就没有然后了。而高分答案通常会覆盖功能、界面、兼容性、安全性、性能和异常六大维度。功能测试层面要覆盖正常路径、异常路径、边界值比如密码长度边界、连续输错次数锁定、用户名前后空格处理。界面测试层面要考虑输入框长度限制、错误提示文案是否清晰、按钮置灰状态。兼容性层面要考虑不同浏览器、不同操作系统、不同移动设备。安全性层面要考虑SQL注入、暴力破解、密码明文传输等风险。性能层面要考虑高并发登录时的系统表现。异常场景则包括断网、服务器超时、会话过期等。这里有一个非常重要的心得测试用例设计题没有标准答案面试官看的是你的思考结构是否完整。所以答题时宁可多写、分类清晰也不要只写三五条草草了事。建议采用“先分类、后展开”的写法先写出测试维度再在每个维度里填充具体用例并在关键用例后面标注优先级。这样的回答方式本身就是向面试官展示你具备测试计划思维。3.2 编程题与算法题从暴力解到边界处理网易测试工程师的编程题难度通常会比开发岗低一些但也不是能随便蒙混过关的。常见题型包括字符串处理、数组移动、简单的动态规划或者二叉树遍历。题目不算难但考察的并不只是“会不会写代码”而是能不能写出“正确且健壮”的代码。以我出题的经验来看候选人最常踩的坑有两个第一个是不写边界条件比如处理空数组、只有一个元素的数组、字符串为空等情况第二个是没理解题目要求就急着动手把简单问题做复杂。针对这两种情况大家可以刻意练习一个习惯读题之后先不着急写代码而是在草稿纸上列出输入、输出、特殊场景想清楚整体思路再落手。另外一个容易被忽视的点是笔试环境通常不支持你用IDE的自动补全代码要手写。所以在准备过程中建议大家有意识地在纯文本环境里练一练写代码的手感尤其是对语言里常用的集合操作、字符串API要熟悉到不假思索的程度。编程能力和测试能力其实是互相成就的——能写出代码你才能更深刻地理解代码的哪一层最容易出问题进而设计出更有针对性的测试用例。3.3 场景设计题从需求文档到测试计划的思维路径场景设计题是测试笔试中最有“实战感”的题目类型。网易的卷子里曾经出现过类似“设计一个电梯的测试方案”“设计一个短视频App的测试方案”这类开放性问题。面对这种题很多候选人的第一反应是懵——“这从哪下手啊”解题的关键在于建立一套稳定的分析框架。我的习惯是“用户-功能-数据-环境”四步走。首先明确目标用户和使用场景校园用户和职场用户的使用习惯完全不同其次梳理核心功能模块把功能拆成“登录、浏览、互动、推送”这类主流程再次关注数据层面比如数据一致性、缓存策略、弱网下的数据同步最后考虑环境因素比如不同机型、不同网络、不同系统版本的兼容性。如果按照这个框架去答哪怕你对电梯或者短视频App没有太深入的理解也能输出一份结构完整、逻辑自洽的测试方案。面试官要考察的本来就不是你的业务知识深度而是你有没有一套可复用的分析问题的方法。平时看到生活中的任何一个系统——无论是自动售货机、餐厅排队叫号系统还是公司楼下的门禁——都可以在脑子里过一遍这套框架时间久了就会形成肌肉记忆。3.4 逻辑推理题用测试思维解智力题逻辑推理题在测试笔试中占的比例不高但几乎每年都会出现。常见的类型有数字规律题、图形推理题、策略分析题。这类题对理工科背景的同学来说并不陌生但我要说的是这类题其实也在考察测试思维里的“找规律、验证特例”能力。我印象比较深的一道题是“有一堆球其中有一个重量异常用无砝码天平最少称几次可以找出来”。这道题的本质是信息论——每次称重有三种结果n次称重最多能区分3的n次方种情况。如果你能想到这一层答案就非常清晰了。遇到这类题时别一上来就穷举先想清楚“每次操作能带来多少信息量”很多看似复杂的问题都会迎刃而解。准备这类题没有捷径只能靠平时多刷题。但有一点可以提醒大家笔试时遇到卡壳的逻辑题不要死磕。先跳过去做后面的题等整张卷子做得差不多了再回来看。因为逻辑题一旦陷入思维的死胡同很容易浪费大量时间而这时后面的基础题反而可能因时间不够而丢掉分数。这种取舍能力和测试排优先级的能力是同构的。4. 常见问题与排查技巧实录4.1 基础概念都会做题却总出错这些年我在帮新人做模拟面试时听到最多的一句话就是“我知识点都看了但做题还是错”。这种情况的根因通常不是知识没掌握而是“知道”和“会用”之间有巨大的鸿沟。比如你能够很流利地说出等价类划分和边界值分析的定义但给你一个真实的输入框你能不能快速判断出哪些是有效等价类、哪些是无效等价类很多人在这里就开始含糊了。破解这个问题的方法只有一个刷题之后必须做复盘而且要“情景化复盘”。每道错题不要只看正确答案要追问自己我当时为什么会往那个方向想我的思维在哪一步开始跑偏如果再遇到同类问题我的分析框架应该如何调整把错题当成一次bug分析来对待你会发现自己对知识点的理解深度会有一个质的提升。这个过程和测试工程师做线上故障复盘一模一样定位到表象还不够必须找到根因才能防止问题再次发生。4.2 时间不够用大题没写完笔试时间不够用是很多人的痛点尤其是编程题经常是最后只剩下10分钟匆忙写了个半成品。我在前文提到过测试笔试的题量设置本身就带有压力测试性质。所以策略比蛮力重要得多。我的建议是实战开始前先按分值把题目分个类。对于选择题、判断题这类客观题第一遍快速作答遇到拿不准的直接先标记跳过不要停留超过一分半钟。对于用例设计和场景题先搭框架再填细节保证答题结构的完整性优先于语言的精细度。对于编程题先确认输入输出格式、边界条件再写代码哪怕最后只写出一个能处理典型输入但边界不完善的版本也比交一个编译不通过的代码好得多。这里也顺便提醒一句——编程题即使没写完也要把思路写清楚。很多面试官在批卷时会看你的注释和思路草稿一个逻辑清晰的半成品远比一个胡写的完整体更有价值。这也是测试工程师的核心素养过程可追溯、结论可解释。4.3 针对游戏测试工程师岗位卷子有什么不同如果你是投递游戏测试工程师方向网易的笔试卷还会增加一些游戏相关的内容。这方面有两个常考点一个是游戏核心玩法与数值系统的测试思路另一个是游戏特定场景的测试设计。比如“技能伤害数值异常可能是什么原因、如何排查”这类问题就是在考察你对战斗系统、数值框架和日志分析的理解。游戏测试和普通软件测试相比有一个很大的差异点——游戏对“体验”的要求非常高。很多问题不是功能逻辑错误而是数值平衡失调、表现层不够流畅、操作手感不佳。这类问题很难用传统的“实际结果与预期结果比对”来定义更需要测试者具备一定的游戏理解力和审美判断力。所以在准备游戏测试方向时除了计算机基础和测试理论还建议多体验不同类型的手游和端游有意识地分析一个副本的战斗节奏、一个活动的投放节奏、一个界面的操作路径这些积累会是你在笔试和面试中的隐形加分项。4.4 错题复盘后的知识点查漏补缺最后分享一个我在带新人时经常用的复盘方法把错题涉及的知识点归类按“不熟悉”“概念模糊”“完全不会”三个级别标记然后针对不同级别做差异化复习。“不熟悉”只需要加强相关练习“概念模糊”需要回到课本对应章节重读“完全不会”则需要找资料补体系。这个方法看着简单但确实能帮你避免“刷了100道题会的依然会不会的依然不会”这种低效循环。还有一个小技巧把每个知识块浓缩成一张思维导图或者一份卡片笔记放在手机里利用碎片时间反复看。以网络为例从TCP/IP分层模型出发每一层有哪些协议、常见问题、排查工具一层一层展开比零散地背考点要高效得多。这些知识不只是为了应付笔试更是你未来进入工作岗位后每天都会用到的底盘能力。5. 从笔试到面试题目背后的能力迁移笔试只是一个入口很多在笔试中考察的点会在面试环节被进一步深挖。比如笔试里考了TCP三次握手的过程面试时可能就会追问如果握手报文丢失客户端和服务端分别会如何处理这个问题再延展下去就是一个“如何定位线上连接超时问题”的场景题。所以准备笔试时不妨多想一层“如果我是面试官我会针对这个知识点追问什么”。我见过不少候选人笔试成绩不错但一到面试就显得生硬——因为他们的知识是“块状”的没法在问题之间自由连接。要打破这种状态可以试试“费曼学习法”把每个核心知识用自己的话讲给一个完全不懂的人听看看你能不能讲明白。如果可以说明你真正理解了如果讲着讲着卡壳那卡壳的地方往往就是你的知识盲区。测试工程师这个岗位说到底是在用工程化的方法管理“不确定性”。笔试考的每一个知识点本质上都是某个不确定性来源的分析方法网络可能抖动、系统可能崩溃、数据可能不一致、用户的行为可能完全出人意料。理解了这个底层逻辑你就不会再把笔试当成一场需要“通关”的考试而是把它当成一次“测试能力预演”——你如何面对一个充满不确定性的系统如何在有限信息下做出判断如何用结构化的方式输出你的结论。这恰恰是这份职业最迷人的地方。