“笔试一结束，群里不少同学都说‘题目不算难，编程题也都写出来了’，可最后通过率却低得离谱。这不是个例，而是测开岗笔试中最典型的错觉——感觉全会，分数全废。”这句话是我每年校招季都会跟身边学弟学妹重复一遍的话。测试测开工程师的笔试题，表面上考察的是基础知识和编码能力，实际上考的是你对“测试”这件事有没有系统性的理解。尤其是网易有道这轮正式批笔试，题目范围横跨语言基础、数据结构、网络、数据库、Linux、自动化测试框架，如果不清楚它的考察逻辑，很容易栽跟头。
这篇内容就围绕网易2023校招笔试中测试测开工程师岗位的考察方向，结合我自己的笔试经验、带应届生时总结的高频失分点，以及测试行业日常工作中真正会用到的那部分技术栈，拆一拆这轮笔试里的门道。文章既适合正在准备大厂测开笔试的应届生，也适合想从功能测试转测开、想系统梳理测试知识体系的朋友。下面讲的每一个模块，我都会给出具体的答题思路、易错点和复习优先级，可以直接拿来对照自己的准备情况查漏补缺。
1. 这场笔试的真实难度与考察版图
1.1 为什么“感觉不难”却拿不到面试
很多同学考完测开笔试后最大的困惑是：明明选择题大部分都认识，编程题也AC了，为什么连面试通知都等不到？我当年也有一段类似的经历，后来跟几位参与过校招命题的同行聊完，才把这个问题想透。
测开岗的笔试筛选逻辑，和纯后端开发岗不一样。后端岗位的笔试重点看算法能力，一道题没写出来可能就挂了；但测开岗的笔试，更像是一次“能力画像”扫描。命题人想通过一份卷子，判断你未来能不能胜任“既要懂开发、又要懂测试、还要能搭建工具链”的复合型角色。所以卷子里通常会出现好几类题目：计算机基础选择题、测试理论题、代码题、数据库题、Linux场景题，甚至还有一部分针对测试工具的客观题。
“感觉不难”的根本原因，是多数题目考察的是广度而不是深度。每个知识点都只考一层皮，但覆盖面非常宽。这也意味着，如果你只在某一个方向上准备得很深，比如刷了大量LeetCode，其他模块的分数就会拖后腿。笔试通过看的不是某一题有没有做对，而是整体分数在所有候选人中的排位。你感觉不难的题，别人也感觉不难，那比拼的就是谁更稳、谁的错误率更低。很多同学挂在选择题上，其实不是不会，而是对概念的理解停留在“背得下来”的层面，换一种问法就露馅了。
1.2 从岗位定位反推考题范围
要理解测开的笔试考什么，得先想清楚这个岗位在团队里干什么。我见过不少团队里测开工程师的日常工作，大致可以分为几块：写自动化测试脚本、搭建和维护测试平台、做性能测试和压力测试、参与代码评审和单元测试、开发测试工具、处理持续集成流水线。这些工作内容直接决定了笔试的考察方向。
举个例子，为什么测开笔试里一定会出现Linux题？因为测试环境部署、日志排查、服务状态检查，全部依赖命令行操作。为什么数据库SQL题几乎必考？因为测试场景里需要造数据、验证数据、核对数据一致性。为什么自动化测试框架如pytest、Selenium、Appium会出现在考察范围里？因为这是测开日常最核心的工具。所以复习的时候，不要把这些模块当成孤立的知识点，而是围绕“测开日常工作需要什么”来重新组织知识体系。
网易的笔试风格，我个人感觉比较务实，题目不会故意出偏题怪题，但会结合真实业务场景来出题。比如给你一个简单的登录功能，让你设计测试用例；或者在Linux题里给你一段日志文件，让你找出某个时间段的错误记录。这类题目考查的已经不是记忆，而是你在真实工作中会不会用这些知识。
2. 算法与编程题：拉开差距的第一道分水岭
2.1 高频题型的临场应对策略
测开笔试的编程题，整体难度比后端开发岗低一到两个档次，但绝对不能掉以轻心。从我了解到的情况来看，这轮笔试的代码题大概在两道左右，以中等偏简单为主，偶尔会出现一道需要动点脑筋的题。
出现频率最高的题型有这些：字符串处理、数组操作、链表基础题、简单的动态规划（比如斐波那契数列、爬楼梯）、二叉树遍历、排序算法的变种。测开岗位的代码题更倾向于和测试业务场景结合，比如让你实现一个函数，判断某个字符串是否符合某种规则，或者对一个数据结构进行特定条件的筛选。这类题本质上还是在考语言基本功和逻辑能力。
我建议准备的时候，以LeetCode的简单题和中等题为主，不要死磕难题。每天保持两到三道的刷题量，重点练那些和字符串、数组、哈希表相关的题目。笔试的时候如果遇到不太有思路的题，先跳过做后面的，等全部题目过一遍再回来想。有些时候，前面选择题里会给出一些代码思路的提示，回头再做代码题反而会有灵感。
2.2 读题准确度比代码速度更重要
这里要特别强调一个测开岗笔试和其他岗位不一样的地方：代码题的问题描述往往比后端岗更长、更啰嗦，里面会夹杂很多业务背景信息。有些同学看到一大段题干就慌了，或者草草扫一眼，抓住几个关键词就开始写代码，结果写出来的代码完全不符合要求。
比如一道题可能描述了这样一个场景：给定一个订单列表，每个订单有金额和状态，请筛选出状态为“已支付”且金额大于100的订单，并按照金额降序排列。如果你只看到“订单列表”和“金额”，忽略了状态筛选条件，这道题就废了。我的习惯是，先花两分钟把题干读两遍，把关键条件用注释的形式写在代码编辑器里，然后再动手写。宁可多花两三分钟读题，也不要写完了才发现理解错了。
另外，笔试时编程题的环境通常是白板式的，没有IDE的自动补全和编译提示。这意味着你平时就要习惯在没有语法提示的情况下写代码。考前一个礼拜，我建议用文本编辑器配合终端编译运行的方式刷题，而不是一直在IDE里写。这样能提前适应笔试环境，也能锻炼一次写对的能力。
2.3 时间复杂度的隐性考察
测开笔试的代码题，数据规模通常不会特别大，所以对最优解的要求没那么苛刻。但这不代表你可以随便写一个暴力解法就交差。有些题目会明确告诉你数据量级，比如数组长度是10^5，这时候如果你写的是O(n^2)的双重循环，很可能在超大数据集上超时。
我见过不少同学笔试代码题只过了部分测试用例，原因不是逻辑错了，而是复杂度太高导致运行超时。所以做题的时候，一定要养成估算复杂度的习惯。看到题目先想一下数据规模，如果是10^5，基本就要考虑O(n)或O(n log n)的解法；如果数据量在100以内，O(n^2)通常没问题。
在语言选择上，C++和Java在笔试环境里运行效率更有优势，Python写起来快但有时候会卡在性能上。我的建议是：如果你对Python更熟练，就用Python，但一定要有意识地使用高效的数据结构和操作方式，比如用字典代替列表遍历查找，用集合去重而不是自己写循环。笔试不是比谁的语言更高端，而是比谁能在有限时间内写出正确高效的代码。
3. 测试理论题：别只会背八股，要会“有逻辑地表达”
3.1 用例设计题：等价类、边界值怎么答才高分
测试理论方面的题目，是测开笔试区别于其他技术岗的核心部分。其中最常考的就是测试用例设计题，给你一个功能或者一个输入框，让你写出测试用例。这类题的得分差距非常大，因为很多人写的用例零散、没有章法，想到哪写到哪。
一个高分答案，一定要体现出测试用例设计的方法论。以“登录功能”为例，如果只是凭感觉写五六条用例，分数一定不高。但如果你从等价类划分入手：有效等价类（合法用户名+合法密码）、无效等价类（非法用户名、非法密码、空用户名、空密码），再补充边界值分析：密码长度上限、用户名长度上限、密码长度下限附近的情况，然后加上异常场景：网络超时、账户被锁定、验证码错误、数据库异常，这样呈现出来的答案就是结构化的，阅卷人一眼就能看出你受过正规的测试训练。
我建议大家准备几个经典的用例设计场景，反复练习：登录框、注册页面、购物车功能、文件上传、搜索功能、订单支付流程。每个场景都按照“功能测试-异常测试-边界测试-兼容性测试-性能测试”的维度去拆。这样不管笔试遇到什么题目，你都能套用一套成熟的思考框架，而不是临场硬想。
3.2 测试流程与V模型：从开发视角理解测试
笔试里经常会出现关于测试流程的题目，比如“谈谈你对测试V模型的理解”“单元测试、集成测试、系统测试、验收测试有什么区别和联系”。这类题不难，但很多同学答得过于概念化，一看就是背的课本内容。
我建议从实际项目协作的角度来理解V模型。V模型的左边是开发过程：需求分析、概要设计、详细设计、编码；右边是测试过程：验收测试、系统测试、集成测试、单元测试。V模型的核心思想是测试贯穿于开发的全流程中，而不是等代码写完了才开始测试。理解了这条主线，回答的时候自然能延伸出“需求阶段的验证对应验收测试”“设计阶段对应系统测试”这层逻辑。
另外还要注意几个容易混淆的概念：冒烟测试和冒烟测试不是一回事，冒烟测试是新版本提测后第一轮快速验证，看主流程能不能跑通，如果冒烟不通过，直接打回开发返工；回归测试则是在修改bug或新增功能后，验证已有功能没被破坏。有一年笔试里出现过一道场景题：开发修复了一个支付相关的bug，问你需要做哪些测试。答案里除了验证这个bug是否修复，一定要包含回归测试，检查支付流程的其他环节是否正常。这类题目考的就是你能不能把测试理论用到实际工作中。
3.3 缺陷处理与bug定位思路
笔试中还会考察缺陷管理的相关内容，比如“如何描述一个bug”“bug的优先级和严重级别怎么区分”“一条完整的bug记录应该包含哪些字段”。这些知识看起来简单，但很能反映一个人的专业素养。
在我的团队里，一条合格的bug记录至少要包含：环境信息（操作系统、浏览器版本、设备型号）、前置条件、复现步骤、预期结果、实际结果、严重程度、优先级、截图或日志。笔试不会让你写这么细，但会让判断“在什么都不缺的情况下，这个bug记录缺少了什么关键信息”。
我在面试应届生时经常发现，很多人能把bug的要素背得很流利，但是拿到一段线上报障描述，却不知道怎么分析。比如用户报障说“下单失败”，这条信息显然是不完整的。需要追问的是：什么页面、什么操作、是偶发还是必现、有没有报错信息、用的是什么网络。所以笔试里出现这类题的时候，尽量把自己代入测试工程师的角色，想想你真的在排查这个问题时，需要什么信息才能继续推进。这样答出来就不是套话，而是实实在在的排查思路。
4. 自动化测试与技术栈：测开的“吃饭家伙”
4.1 pytest：从装饰器到fixture的高频考点
自动化测试相关的内容，是测开笔试最有区分度的模块。一个只做过功能测试的同学和真正接触过自动化测试的同学，在这部分的答案质量上会有非常明显的差距。而pytest作为目前Python生态里最主流的测试框架，几乎是必须掌握的知识点。
pytest考察的方向一般集中在几个方面：断言怎么写、fixture怎么用、参数化怎么做、conftest.py的作用是什么、如何生成测试报告。如果你在简历里写了熟悉pytest，那笔试里关于它的题目你最好一个字都不要丢分。
举个例子，参数化是一个高频考点。pytest.mark.parametrize装饰器允许你用一组数据执行同一个测试用例，这在接口自动化测试里非常常用。笔试可能会给你一段代码，让你判断运行结果，或者问fixture的scope参数有几个选项、分别代表什么含义。scope参数有function、class、module、package、session五种，默认是function。理解这几个作用域的区别，比死记硬背更有用，因为面试环节也经常会追问。
我给你的建议是，不要只停留在“会用pytest跑用例”的层面，要能说清楚pytest的用例收集规则。默认情况下，pytest会递归查找当前目录下所有test_.py或_test.py的文件，然后在文件中找test_开头的函数或方法。这些机制都是笔试选择题的常见素材，也是实际工作中每天都在用的东西。
4.2 Appium与移动端测试的考察方式
移动端测试在测开岗的笔试中出现频率也很高，尤其是Appium相关的知识。因为很多互联网公司的核心产品都是App，移动端测试是测开团队绕不开的工作内容。
Appium考察的重点主要有几个：它的工作原理、Desired Capabilities是什么、元素定位有哪些方式、如何等待元素加载完成。其中Desired Capabilities是一个很容易考的点，你可以把它理解成一组“告诉Appium我要测什么”的配置参数，比如platformName指定平台、deviceName指定设备名、appPackage和appActivity指定要启动的应用。笔试时可能会给你一段缺失参数的配置，让你选出正确的答案。
元素定位方式方面，Appium支持id、class name、xpath、 accessibility id等多种方式。考试中常考的是id定位和xpath定位，要能分辨在什么场景下用哪种方式更合适。比如有些元素没有固定的id，就需要用xpath通过层级关系定位；但如果元素有稳定的id，优先用id定位，性能更好、代码更稳定。
另外，移动端测试里还有一个常见的考察点是等待机制。我在实际开发自动化脚本时，最讨厌的就是那种一上来就sleep五秒的写法。笔试里如果问到元素等待，你要能说出显式等待和隐式等待的区别，并且知道WebDriverWait配expected_conditions的写法才是推荐方式。这些细节是区分“用过Appium”和“理解Appium”的关键。
4.3 接口自动化与测试框架设计思路
测开笔试里还有一个容易出现的大题方向：接口自动化测试。可能会让你设计一个接口自动化测试框架的架构，或者给一个接口，让你写测试脚本。这类题目没有标准答案，但可以通过回答看出你对整个测试技术栈的理解深度。
一个合格的接口自动化方案，至少要考虑这几个维度：测试数据从哪里来（写在代码里、存在JSON/YAML文件里、还是从数据库读取）、断言怎么做（状态码断言、业务码断言、数据库校验）、测试报告怎么生成、失败重试机制怎么做、怎么和CI/CD集成。我在笔试时遇到这类问题的时候，习惯先画一个清晰的数据流：测试用例文件被pytest收集，然后通过requests库发起接口调用，返回结果和预期值做对比，最后用allure生成测试报告。如果让我用文字描述，我会按照这个顺序来组织答案。
接口测试中，有一个很细节但常考的点需要提醒大家：请求的校验和签名。很多公司的接口并不是裸奔的，会在请求头里带上签名参数或token。笔试如果给你一个需要MD5加密或时间戳签名的接口，你要能写出来。我在实际项目中就遇到过因为时间戳格式不对导致签名校验失败的情况。所以写接口脚本时，和开发确认清楚签名规则，比闷头写代码更重要。
5. 数据库与Linux：测开日常离不开的两板斧
5.1 SQL联表查询：测开笔试的必拿分项
数据库几乎是测开笔试的必考内容，因为测试工作离不开数据验证。笔试里的SQL题目不会特别难，但很考察基础扎不扎实。多表联查、子查询、聚合函数、分组排序，这几样基本覆盖了90%以上的考题场景。
以“查询每个用户的订单数量”为例，涉及两张表：用户表和订单表。这个需求就要求你掌握LEFT JOIN（或INNER JOIN）和GROUP BY的组合使用。笔试常见的陷阱是：使用INNER JOIN时把没有订单的用户过滤掉了，但如果题目需要的是“所有用户的订单数，没有订单的显示0”，就必须用LEFT JOIN。这种细节最能拉开差距。
还要注意一个高频考点：HAVING和WHERE的区别。WHERE是在分组前过滤数据，HAVING是在分组后过滤分组。有一次我让候选人写“查询订单数量大于5的用户”，好几个人把HAVING写成了WHERE，这就是典型的对SQL执行顺序不理解。WHERE先执行、GROUP BY次之、HAVING在后面、最后是ORDER BY，把这条执行顺序记熟，SQL题基本不会选错。
另一个容易被忽视的是去重查询和子查询的写法，比如“查询有过购物记录的用户ID”，本质上是SELECT DISTINCT user_id FROM orders。有些同学喜欢用GROUP BY来实现去重，功能上也可以，但DISTINCT更直观、性能也更好。笔试里能写出更优解法，也是一种得分优势。
5.2 Linux命令：从日志排查到服务状态检查
Linux已经是测开日常工作中无法回避的工具，笔试里对这一块的考察一般分为两个方向：一是直接问命令的参数和用途，二是给一个实际场景让你给出排查命令。
场景题是重点。比如“线上服务出现了报错，日志文件在/var/log/app/error.log，如何实时查看最新的错误信息？”正确的思路是先用tail -f实时跟踪日志输出，然后用grep过滤出包含ERROR的行，如果日志量特别大，还可以加上tail -n 100先看最后100行。有些同学直接背了tail -f的语法，但是到实际场景中不会结合grep一起用，这就比较吃亏。
常考的命令还有：查看CPU和内存使用情况的top和free、查看磁盘空间的df -h、查看进程的ps -ef和netstat -tlnp、文件权限修改的命令chmod。特别是netstat -tlnp，用于查看端口占用情况，在测试环境部署服务时几乎天天用。笔试时如果遇到端口被占用的问题，“怎么找到是哪个进程占用了8080端口”，答案就是netstat -tlnp | grep 8080，然后通过输出的PID再用ps查看进程详情。
我这里给你一个备考方法：不用死记硬背所有命令，但要能用命令完成几个标准操作——在日志文件里找关键字、查看进程、查看端口、查看磁盘和内存、修改文件权限、压缩和解压文件。把这几个场景反复练熟，面试时如果被问到Linux相关的问题，也能做到张口就来。
6. 从笔试到面试：最后冲刺阶段的避坑清单
6.1 时间分配与做题顺序策略
测开笔试的题量通常比较大，选择题、判断题、大题混在一起，时间并不宽裕。我见过不少同学在选择题上纠结太久，导致后面的编程题和用例设计题没时间写。这属于战术上的重大失误。
我的建议是，拿到卷子先花一两分钟把题目整体扫一遍，对题量和难度有个大概判断。然后先做自己有把握拿分的题，比如SQL题、Linux命令题、测试理论题，这类题答案明确、得分概率高。选择题如果遇到拿不准的，不要恋战，先选一个自己认为最合理的答案并做好标记，等全部题目做完有时间再回头纠结。编程题虽然分高，但如果放在最后时间不够写，可以先写下核心思路和伪代码，也能拿到部分分数。
时间分配上，我倾向于给编程题留出40%的时间，给用例设计题留出20%，其他客观题占40%。这个比例可以根据自己的强弱项调整，但核心原则是：不要在低性价比的题目上消耗大量时间。测开笔试的通过线是综合排名，每一分都很关键，先保证该拿的分全部拿到，再考虑攻克难题。
6.2 经常被忽视的失分点
最后集中梳理几个我在辅导应届生过程中最常见的失分点，也算是帮你们考前排雷。
第一个失分点是代码题没有写注释。笔试代码题虽然不要求你把注释写得多规范，但关键的逻辑步骤加上注释，一方面能在你自己思路乱的时候起到梳理作用，另一方面也能让阅卷人更轻松地理解你的代码。如果代码运行结果不完全正确，清晰的注释和变量命名有时能帮你保住“印象分”。
第二个失分点是测试用例设计题只写正常流程。前面我反复强调过边界值和异常场景，但考场上还是有很多人只写“正确的输入能正常通过”这一类用例。记住，测试用例设计的核心价值之一，恰恰是发现那些“没想到会出问题”的边界和异常情况。
第三个失分点是自动化测试的题只答概念不答落地。如果笔试问“你对接口自动化有什么理解”，不要只写“可以提高测试效率、减少重复工作”这类没有信息量的话。要把具体的实现路径写出来：用什么框架、怎么组织数据、怎么处理依赖、怎么集成到CI。能不能写出一套可落地的方案，是阅卷人区分“知道名词”和“真做过”的重要标准。
第四个失分点是SQL语句不检查执行顺序和逻辑。写SQL题的时候，写完一定要回头看一眼：关联条件有没有写对，是不是应该用LEFT JOIN却用了INNER JOIN，分组有没有用对列。这些低级错误在考场上出现的频率，比你想象的高得多。
最后一个失分点是英语题目和术语翻译。有些笔试会直接给英文术语，或者把概念用英文缩写表示，比如SDK、API、CRUD、CI/CD、RESTful。平时接触到的中文资料居多，很多同学对英文缩写不敏感，遇到RESTful API的题一时反应不过来。复习的时候，建议把常用测试术语的英文名称也顺带记一下。
6.3 笔试结束后：错题复盘比估分更重要
可能有些同学觉得笔试结束就万事大吉，等着出结果就行。我自己经历过多轮校招，包括后来带实习生，越来越觉得笔试后的复盘才是提升能力的关键环节。考完当天趁着记忆还清晰，把不确定的题目和完全不会的题目整理下来，逐一查资料弄明白，这比多刷十道题都有用。
对测开岗来说，笔试的很多知识在面试里还会被二次考察。你在笔试时做得不理想的题，如果面试前还没搞懂，大概率会在面试现场被追问到。所以我不建议笔试结束后就把卷子丢到一边，尤其是“测试用例设计”和“自动化测试框架”这两类题，它们几乎是面试官最爱的追问素材。
复盘的时候也别只关注正确答案是什么，更要想清楚自己当初为什么选错。是因为概念混淆、题目没看清，还是知识盲区？把错因分类记录下来，考前集中看一遍自己的错题本，比翻十本教材效率都高。这个习惯我从找工作一直保留到现在，带团队做评审时也一直很受益。
如果你正在准备测开方向的校招笔试，不妨按这篇文章里提到的模块逐个排查一下自己的知识覆盖情况：编程题每天保持手感，测试理论和用例设计形成自己的答题框架，pytest和接口自动化多写几个小demo，SQL和Linux命令反复练到条件反射。这样走进考场的时候，你不会是靠运气，而是靠实力。祝你们都能拿到心仪的offer。
