每年的校招季总有一批测开方向的候选人栽在笔试环节。刚帮一位学弟复盘完 TME 2024 校园招聘系统测试/测试开发方向的笔试题第 II 套我发现很多人对这场笔试的认知存在相当大的偏差要么把它当成纯八股文背诵现场要么当成力扣周赛结果两边都没捞着分。这份笔试考察的确实是“系统测试 测试开发”双线能力但它的出题逻辑和市面上流传的常规测试面试题区别不小——更偏工程实践、更看重测试思维同时对代码功底的要求也不含糊。今天这篇就把卷子拆开聊透考什么、为什么考、怎么答才能拿分、哪些地方最容易丢分以及笔试之后该如何衔接面试。不管你是正在准备 TME 的后续批次还是打算瞄准其他大厂测开岗这套复盘思路都值得参考。1. 笔试的整体战局题型分布与时间策略1.1 题型构成的底层逻辑先说结论TME 这套测开笔试II整体可以拆成三大块——计算机基础与测试理论、编程题、场景分析与设计题。三者不是平均用力而是有明确的权重倾向。从近两年的考情回溯来看纯理论概念的占比在逐年压缩取而代之的是“给你一个具体场景让你设计测试方案”或者“给一段有缺陷的代码让你定位问题”这类题。这个变化本身就说明了企业对测开岗位的预期不是找一个只会写用例、执行用例的人而是找一个具备开发视角、能钻进代码里排查问题、能通过自动化手段提升测试效率的人。题型和时间的匹配关系也很重要。一套卷子总时长通常在 90 到 120 分钟之间题量大概在 40 到 50 道客观题加 2 到 3 道大题。客观题部分建议控制在 40 分钟内完成因为真正的重头戏是后面的编程题和场景设计题那才是拉开差距的地方。我见过太多人前面概念题抠得太细一道题纠结两三分钟结果最后编程题只剩十分钟白送的分没拿到。这里有两条经验可以抄拿不准的客观题先标记不要恋战凭第一直觉选一个之后跳到下一题最后如果有时间再回来推敲编程题优先选自己最熟练的语言不要在现场临时切换语言风格思路顺畅远比语言特性炫技重要。1.2 每一分考点的得分权重参考我把这套卷子的考点分布整理成了一张参考表基于多个批次的考后反馈汇总得出虽然不是官方数据但方向上有参考价值考点模块大致占比常见题型系统测试基础理论测试流程、用例设计、缺陷管理20%-25%单选、多选、场景题数据结构与算法20%-25%编程题、选择题数据库与 Linux10%-15%选择题、SQL 手写题编程语言基础Python/Java10%-15%改错题、代码阅读题自动化测试与持续集成概念8%-10%选择、简答网络与操作系统基础8%-10%选择、简答从这张表能看出一个关键信号测试理论知识不能丢但绝对不是全部。编程和计算机基础加起来的分量已经跟测试理论旗鼓相当了。准备的时候如果只抱着《软件测试的艺术》啃完全不管算法和数据库那笔试卷面会很难看。2. 系统测试的知识边界考点其实比你想的更“杂”2.1 高频理论考点清单系统测试作为笔试的基本盘考查内容大致落在下面几个区域软件生命周期模型中的测试活动V 模型、W 模型、敏捷开发中的测试节奏测试用例设计方法等价类划分、边界值分析、因果图、判定表、正交实验法、场景法缺陷管理流程Bug 从提交、确认、修复、回归到关闭的完整流转以及缺陷报告应该包含哪些字段测试计划的编制内容、测试报告的关键指标回归测试策略什么改动需要全量回归什么改动做冒烟加定向回归就够了性能测试基础响应时间、吞吐量、TPS/QPS、并发用户数、性能瓶颈的分析思路兼容性测试、易用性测试、安全测试的基础概念。其中最容易翻车的是用例设计方法的概念辨析。比如“等价类划分”和“边界值分析”到底有什么区别很多人说不清。等价类划分是把输入域按规则分割成若干互不相交的类别每一类取一个代表值来测试核心是“用最少的数据覆盖尽可能多的有效输入”边界值分析则专门盯着等价类边界两侧的数据做验证大量实践表明程序最容易出错的地方恰恰在边界。笔试里经常给一个输入条件比如“年龄在 18 到 60 岁之间”让你选出符合边界值分析原则的用例集合——正确答案往往是 17、18、60、61 这四个值而不是 18 和 60 两个值。另一个高频考点是测试计划。题干经常给一个具体的项目背景比如“一个面向 C 端用户的音乐播放器 App三周后上线目前开发进度已经过半人手只有两名测试人员请你列出测试计划的关键要素”。这种题表面上在考知识点的罗列能力实际上考的是“测试策略的取舍能力”。一个高质量的答案绝对不是把测试范围、资源、进度、风险四要素背一遍就完事而是需要你给出自己的判断人手只有两人自动化投入必须控制比例优先保障核心主流程的冒烟测试和 P0/P1 级别的用例执行兼容性测试可以借助云真机平台来摊薄人力成本。2.2 场景题的答法从需求到用例设计的完整链路第 II 套卷子里的场景题非常典型。给你一个“发表文字动态”的功能描述让你设计测试用例。这类题人人都会写几条但拿高分的少。关键差别在于你有没有“结构化的测试思维”。一个完整的用例设计应该从以下几个维度展开功能维度正常发布、发布后列表展示、删除、编辑、同步到个人主页输入维度文字长度边界比如 0 字、1 字、上限字数、上限字数加 1、特殊字符emoji、HTML 标签、纯空格、超长连续字符界面交互维度发布按钮的可用态切换、输入框计数提示、键盘弹起遮挡、草稿箱提示兼容维度不同操作系统版本、不同屏幕分辨率、深浅色模式异常网络维度断网发布、弱网发布、发布过程中切换网络、请求超时后的重试机制数据一致性维度发布成功后快速下拉刷新是否出现重复数据、服务端返回失败但客户端显示成功的脏数据场景权限与安全维度未登录用户是否能进入发布页、发布内容是否经过敏感词过滤、是否可能被越权读取。如果你能在考场里把上述七个维度用表格化、结构化的方式写出来阅卷人对你的测试素养会有相当正面的评价。更重要的是这种结构化思维不仅是笔试需要的它本身就是测试工程师日常工作的基本功。2.3 缺陷管理题的“潜规则”关于缺陷管理的题目表面上是考“一个 Bug 的生命周期”实际上暗藏了好几个潜规则。第一Bug 状态流转不是单向的。开发修复后要回到“待验证”验证不通过要重新打开Reopen不是一路“已关闭”到底。第二Bug 严重等级和优先级不是一回事。一个“界面文案错了一个字”的 Bug可能是 P1 显示在首页上比“某个冷门功能崩溃”的优先级更高这两个维度必须分清楚。第三一份标准的缺陷报告至少要包含标题、前置条件、复现步骤、实际结果、预期结果、严重程度、优先级、版本号、截图或日志。笔试如果让你补全缺陷报告字段注意别漏了“前置条件”和“版本号”这类细节它们最容易漏也最能体现专业性。3. 测试开发的硬核分水岭数据结构、SQL、Linux 与自动化脚本3.1 代码题考什么难度很多人都把测开的编程题想象得很难实际上 TME 这套笔试的编程题难度整体落在 LeetCode 中等题偏下到中等题偏上之间没有特别偏怪的压轴题。高频考点集中在数组与字符串处理最长无重复子串、两数之和、字符串反转、括号匹配链表反转链表、环形链表判断、删除倒数第 N 个节点二叉树层序遍历、最近公共祖先、二叉树深度栈与队列用两个栈实现队列、有效的括号排序与查找快排、归并、二分查找变体哈希表应用字母异位词分组、多数元素重点不是刷难题而是把中等题刷到“肌肉记忆”级别。测开岗和算法岗对编程题的要求有本质区别算法岗希望你展示最优解和复杂度推导测开岗更在意你能否写出“正确、健壮、可读”的代码。哪怕你的解法不是最优只要思路清晰、边界处理完整、测试用例覆盖到位分数不会差到哪里去。我建议备考时专门练一个习惯每做一道题都在本地 IDE 里补上 3 到 5 组测试用例包括空输入、边界值、大数据量。这个习惯在笔试里可能不会直接加分但如果你想尝试投内推而不是走统考通道加分项往往是这些工程细节。3.2 SQL 题比想象中更难拿满分SQL 题几乎是测开笔试必考内容。这套卷子里的 SQL 题不算难基本停留在单表或两表连接层面但得全分的人不多。常见考点有分组聚合GROUP BY 与 HAVING 的配合多表连接INNER JOIN 与 LEFT JOIN 的选用场景子查询IN、EXISTS 的用法与性能差异窗口函数ROW_NUMBER / RANK 排序以及去除重复记录数据更新UPDATE 与子查询联动。我印象最深的一道题是给定两张表员工表和部门表要求“查询每个部门薪资最高的员工信息”。很多人第一反应是写 GROUP BY department_id然后取 MAX(salary)但这样只能拿到部门号和最高工资拿不到最高工资对应的员工姓名。正确思路是用窗口函数SELECT department_name, employee_name, salary FROM ( SELECT d.department_name, e.employee_name, e.salary, ROW_NUMBER() OVER (PARTITION BY e.department_id ORDER BY e.salary DESC) AS rn FROM employees e JOIN departments d ON e.department_id d.department_id ) t WHERE rn 1;关键考点有两个一是嵌套子查询的结构二是窗口函数的使用。如果你只会 GROUP BY 不会窗口函数这道题大概率只能拿一半分。3.3 Linux 命令题的实战倾向Linux 命令考查方向非常工程化不是让你背命令选项而是给你一个实际日志文件让你分析问题。比如从一堆日志里统计出每个接口的调用次数、出错的 IP Top 10、某个时间段内的请求量变化。这类题其实就是考察你平时排查线上问题的能力。最常用的命令组合要烂熟于心查看实时日志tail -f、grep 关键字过滤数据统计awk {print $N} | sort | uniq -c | sort -nr查看进程ps -ef / top端口监听netstat -tlnp / ss -tlnp磁盘占用df -h / du -sh *文件检索find、grep -r举个例子统计一个日志里出现次数最多的 10 个 IPawk {print $1} access.log | sort | uniq -c | sort -nr | head -10这道命令题如果说要写一行命令解决那上面这个就是标准答案。很多人会忘记 sort 这一步直接在 uniq -c 之前不做排序导致统计结果一塌糊涂——因为 uniq 只对相邻重复行生效不排序就统计是典型的低级错误。3.4 自动化脚本题一道必拿的送分题这套笔试里有一道自动化测试相关的代码题往年还出现过让你阅读一段 Selenium 脚本找问题、或者用 Python 写一个接口测试断言的题目。别小看它这类题是实打实的“送分题”只要你写过真实项目基本不会失分。接口测试断言的经典写法大概是这样的逻辑发送请求、检查 HTTP 状态码、解析响应体、断言关键字段、失败时打印错误信息。如果面试者还能顺带考虑超时设置、重试机制和日志输出说明他具备真实的接口测试经验。Selenium 读代码找错的题目最容易藏雷的是隐式等待和显式等待混用导致等待策略冲突定位表达式写得太脆弱一旦页面结构微调就会失效没有处理 window 切换或 iframe 切换直接对元素操作用 thread.sleep 固定等待来替代显式等待整个脚本稳定性大打折扣。4. 典型真题的拆解与示范不只是“会做”而是“会拿分”4.1 测试用例设计题朋友圈“发表文字动态”这类题的答题策略讲究“横向铺开、纵向挖深”。横向铺开是把功能拆成不同维度纵向挖深是对每个维度再层层细化直到覆盖到边界和异常。具体到“发表文字动态”这个功能我建议从下面这张表展开。功能层面要覆盖最基本的流程点击发布按钮、进入发布页面、输入文字、点击发布、动态出现在列表。输入层面要覆盖正常值、边界值、异常值。比如“允许输入的最大字数是 2000 字”那用例就应包含 1999 字、2000 字、2001 字、空字符串、纯空格、emoji 组合、HTML 标签、SQL 注入片段。界面层面注意按钮状态切换、字数统计等逻辑。网络层面要覆盖断网、弱网、超时、网络切换等场景。兼容性层面要覆盖不同操作系统、不同分辨率、深浅色模式。数据一致性层面要覆盖重复提交、服务端延迟、下拉刷新等场景。安全层面则要涉及未登录状态、敏感词过滤、越权访问等。答题时如果能直接画出这样一个六到七个维度的框架阅卷人一眼就能看出你的测试思维是成体系的。4.2 算法手撕题最长无重复子串题目给定一个字符串请你找出其中不含有重复字符的最长子串的长度。这题在 LeetCode 上是第 3 题属于最高频的面试题之一。测开笔试中考到的概率极大必须能用滑动窗口在 O(n) 时间内做出来。一个完整的参考解法是用字典记录每个字符最近一次出现的位置左指针维护当前无重复窗口的左边界。遍历字符串时如果当前字符已经在窗口内出现过就把左指针移到上次出现位置的下一个位置然后更新当前字符的最新位置用当前索引减左指针加一更新最大长度。整个过程只遍历一次时间复杂度 O(n)空间复杂度 O(字符集大小)。手写代码时按下述结构来逻辑清晰阅卷体验好def length_of_longest_substring(s: str) - int: char_map {} left 0 max_len 0 for right, ch in enumerate(s): if ch in char_map and char_map[ch] left: left char_map[ch] 1 char_map[ch] right max_len max(max_len, right - left 1) return max_len边界测试用例别忘了空字符串返回 0全重复字符串“aaaa”返回 1全不重复字符串“abcde”返回 5。这三个用例如果都过逻辑大概率没毛病。4.3 SQL 场景题与压测分析题的标准答法SQL 场景题上面已经举了“每部门薪资最高员工”的例子不再重复。这里想说另一个高频题型给你一段业务描述让你指出查询语句的优化空间。常见答案方向包括避免使用 SELECT *、为 WHERE 条件和 JOIN 字段建立合适的索引、分页查询使用延迟关联、避免在 WHERE 子句中对字段做函数运算导致索引失效、大数据量排序时考虑覆盖索引。这些点不需要多深答出两三条就能拿分。压测分析题也值得留意。题干经常是“某接口压测时随着并发数从 100 升到 500TPS 先升后降请分析可能原因”。答法先分层网络层可能带宽打满连接数达到服务器上限应用层可能线程池耗尽、Full GC 频繁、数据库连接池不够数据库层可能是慢 SQL 打满 CPU、行锁竞争、缓存失效雪崩。另外还需要问一句压测机的性能是否成为瓶颈机器本身资源打满也会影响结果。把分层思路写出来哪怕具体原因不吻合整体框架也是完整的。4.4 线上问题排查题的“定位链”思路有一类比较新的题型给出一个线上反馈比如“用户反馈支付成功后订单状态仍然显示待支付”让你写出排查步骤。这种题没有标准答案但有一条标准的排查链路第一步明确影响范围。是个别用户还是大面积用户是特定版本还是全量先判断是代码缺陷还是配置问题。第二步收紧时间窗口。去查支付成功回调到订单状态更新的日志看回调有没有到达到达后有没有处理异常。第三步核对数据流。订单服务调用支付服务支付回调写库如果写库前发生异常可能导致状态没更新。第四步检查补偿机制。是否有定时任务对账或者消息队列重试如果这些机制都没有那这本身就是一个系统设计缺陷。这道题考查的是“问题定位的思维链路”而不是具体技术细节。答题时把排查路径写清楚每走一步说明为什么这么走比直接丢一个“查看数据库订单状态”的答案要靠谱得多。5. 挂掉的人也挂在这些地方五个容易吃暗亏的细节5.1 用例设计只写正常流程不写异常流程我刷过不少测开笔试的答案发现一个规律能拿高分的用例设计通常在“异常流程”上写得很有层次。什么叫异常流程不只是报错提示。纯空格输入、超长输入、网络中断、重复提交、权限不足、后端超时、返回数据格式异常都算。很多人一写用例就是“输入正常内容点击发布发布成功”这类用例设计分数基本不会高。拿“登录功能”举例普通人的用例可能写正确的用户名密码登录成功、错误的密码登录失败、空用户名登录失败。而高分用例还会写密码输错五次之后账号锁定、登录成功后短时间内重复登录、弱网下登录超时如何处理、Cookie 过期后操作跳转登录页、重新登录后回到原页面。同样是三个字“写用例”两种作答的区别就是思维深度的区别。5.2 编程题不处理输入输出边界不少人在本地 IDE 里写得很好一进笔试环境就挂了。原因很常见没有处理输入的异常情况。比如题目说“输入一个整数数组”就有人默认所有元素都是有效整数忽略了数组为空的可能。笔试的判题机真的会跑空用例这不是吓唬人。一些固定的编程题防坑手法可以在备考阶段就形成条件反射所有从输入读取的数据先判空再处理数组类型题目先把长度提取出来提前处理 n 0 的情况涉及数组访问的循环注意索引越界涉及到除法或取模注意除数为零的场景题目没说数据范围时变量类型优先选可以覆盖更大范围的语言内置类型。5.3 黑盒白盒概念混淆查漏补缺要趁早概念题是这套笔试里最不应该丢分的区域但每年都有人栽。最常见的混淆情况黑盒测试是“不考虑内部结构只验证输入输出”常被误写成“不需要知道需求”白盒测试是“基于代码结构和逻辑来设计用例”常被误写成“需要登录数据库”单元测试大多属于白盒范畴而系统测试和验收测试更偏向黑盒静态测试不运行程序动态测试需要运行程序很多人把 code review 归为动态测试这是错的。这些基础概念题通常出现在选择题前几道难度不大主要是白送分。准备阶段把术语辨析梳理清楚就行但一定要做。否则你前面错一道等于后面编程题白写一道。5.4 自动化和性能测试术语一知半解自动化和性能方向题目不多但错误率很高。混的最多的三个概念是并发用户数和 TPS 的关系、QPS 和 TPS 的差异、持续集成和持续交付的区别。简单梳理一下QPS 是每秒查询数TPS 是每秒事务数一个事务可能包含多个查询所以 QPS 往往大于 TPS但在纯查询接口场景下两者差距很小。持续集成CI侧重代码合并后自动构建测试持续交付CD侧重通过自动化部署把代码发布到类生产环境。如果笔试问你“下面哪项属于持续集成阶段的操作”选“提交代码后自动触发单元测试和构建”基本没问题选“一键部署到生产环境”就歪了。5.5 计划分配不合理这个可能不算一个考点但我觉得比任何单个考点都重要。笔试不是知识竞赛它是在有限时间内评估综合能力。我见过太多人花 15 分钟纠结一道 2 分的选择题最后编程题拿空白卷。一套好的作答节奏应该是客观题 40 分钟编程题 30 分钟场景题 20 分钟剩下的时间检查遗漏和补充细节。如果一上来就在某道题卡住果断跳过别让一题毁掉全局。6. 从笔试到面试一份可抄作业的备考路线图6.1 第一阶段1-2 周测试理论集中扫盲这个阶段的目标是把系统测试的框架搭起来不求深但求全。建议按每周一个知识主题推进先过一遍软件测试基础教材的核心章节把测试流程、V 模型、W 模型、敏捷测试的基本概念建立起来。然后专门整理一份自己的“测试用例设计方法”笔记把等价类、边界值、因果图、判定表、场景法各自适用场景浓缩成一张表每天花 20 分钟背诵并默写一遍。最后花一天时间了解缺陷管理流程和测试计划模板搞清楚 Bug 生命周期每个节点。这个阶段不需要做太多题重点是“知道测试工程师日常在干什么”以及“为什么这么干”。比如为什么单元测试通常由开发来写而不是测试来写为什么回归测试要放在每次代码改动之后。把逻辑理顺了概念题自然就不容易错。6.2 第二阶段3-4 周算法与代码题强化备考过技术岗的人都知道算法刷题没有捷径但可以有策略。测开岗的刷题范围没有必要追求难题重点覆盖数组、字符串、链表、二叉树、哈希表、栈队列、滑动窗口和二分法这八类常考题型。每天保持两到三道题的量一刷时注重 AC二刷时注重“能不能第一时间想到思路”三刷时只练高频题的手速和边界处理能力。同时每天抽 10 分钟在纸面手写代码。职场上你不是天天手写但笔试环境有时对在线编辑器不熟悉提前练一练手写方案的逻辑梳理即便打字失误率也会更低。这里我个人的经验是平时做题时多写一些“防御性代码”从输入校验开始不要直接进入核心逻辑。笔试时这个习惯能帮你避开判题机隐藏用例的坑。6.3 第三阶段5-6 周SQL 与 Linux 实战训练SQL 题就刷力扣数据库题库的入门到中等题重点覆盖分组聚合、多表连接、子查询、窗口函数这四类。不要只看别人的题解一定要自己写完并跑通。每次写完 SQL 后用 EXPLAIN 看一眼执行计划——虽然笔试不考执行计划但这个习惯能让你真正理解索引和 JOIN 的开销逻辑。Linux 命令不需要背很偏的选项把上面列出的常用命令练熟就够用。自己可以从网上下载一份开源项目的日志样例实际跑几个统计分析需求如统计某个时间段内请求数量、按状态码分组统计、筛选出响应时间超过 300ms 的请求。这种练法比死记命令选项有趣也更有用。6.4 第四阶段7-8 周自动化与实战项目复盘这个阶段要把自己过往的测试相关经历梳理成可讲述的项目故事。不管是实习项目、课程项目还是自学的开源项目准备一个“Star 法则”模板的版本重点说清楚项目背景、面临的技术难点、你的解决思路、最终效果。测开面试官几乎必问的问题是“你在这个项目里做的自动化测试是怎么设计断言的覆盖率大概是多少稳定性怎么保障”如果完全没有项目经验建议自己动手写一个简单的接口自动化测试 Demo用 Python 加 requests 加 pytest对某个公开 API 做断言测试。项目不需要大但一定要做完整的包括用例分层、数据驱动、测试报告输出。写好后能讲清楚设计思路面试时就会比空口说“我会自动化测试”有说服力得多。6.5 第五阶段9-12 周真题模拟与查漏补缺最后一个阶段重点做三件事刷历年真题模拟卷、整理错题集、做限时训练。每周至少做两套完整的模拟卷严格按照 120 分钟的时限来模拟真实笔试的紧张感。每次模考后把错题按模块归类分析错误原因到底是知识点漏洞还是时间分配问题。如果是知识点漏洞就回到对应的专题章节去补如果是时间问题就调整做题顺序把分值高的题先拿下。6.6 面试衔接的一些心得笔试通过后紧接着的面试通常会有几轮一面技术面、二面综合面、终面 HR 面。一面重点问测试基础和项目经历二面更关注你的系统设计能力、自动化测试思路和沟通推动能力。笔试阶段积累的用例设计结构化思维和问题定位思路在面试中可以继续复用。我建议在准备面试时专门准备一个“Bug 排查经历”的故事。面试官很喜欢问你遇到过一个最复杂的线上问题是什么是怎么排查的按照现象描述、影响范围、排查过程、根因确认、修复验证、事后复盘这六个环节来组织就会是一个完整且有说服力的回答。关于简历上测试技能的描述有一条建议是尽量少写“熟悉自动化测试”而是写具体框架和具体落地场景比如“基于 Python Pytest Selenium 搭建了 Web 端自动化回归框架覆盖核心链路 200 条用例单轮执行时间从 2 小时缩短到 40 分钟”。量化数据永远比形容词有说服力。我自己的体会是测开这个方向笔试也好、面试也好本质上都在检验两件事你有没有扎实的测试思维你能不能把测试思维转化成工程能力。这两件事都不是考前突击能解决的需要长期的积累和不断的复盘。备考是一场长期战但也没必要把它想得太复杂。把基础打扎实、把真题刷透、把细节抓好再把每次练习的错题真正消化掉上岸就只是时间问题。
