1. 为什么系统测试岗的秋招笔试值得单独拆开聊先交代一下背景。2023年腾讯音乐秋招系统测试岗第一批笔试我当时是全程跟完的那批人之一。那场笔试之后牛客和几个技术群里直接炸了锅——有人说题量太大做不完有人说用例设计题根本不知道从哪个角度下手也有人说Linux题看着眼熟但一写就错。说实话这类反馈每年都有但2023年这批的出题风格确实有代表性不考死记硬背而是把所有考点都藏在具体场景里考察的其实是你能不能像个测试工程师一样思考。系统测试岗的笔试和开发岗完全是两个物种。开发岗考算法、考八股你刷题刷够了基本能应付系统测试岗笔试考的是广度加工程判断力考点散落在操作系统、数据库、网络、Linux、用例设计、测试理论、编程基础各个角落而且题型非常杂有选择、有填空、有简答、有编程、有场景题。你要是按开发岗的思路去准备大概率会在用例设计题上卡壳。那这篇就围绕2023年腾讯音乐秋招系统测试岗第一批笔试把考点分布、答题思路、时间分配、以及怎么把笔试内容变成后续面试的弹药完整拆一遍。我尽量还原当时考完之后的复盘记录再结合我带过的几届校招新人的笔试题整理把这类笔试的底层逻辑讲透。即便你不是投腾讯音乐这套拆解方法对大多数中大厂系统测试岗的笔试同样适用。1.1 从岗位定位反推笔试考察逻辑先看岗位本身。腾讯音乐的测试岗核心产品形态是QQ音乐、酷狗音乐、酷我音乐这类音视频娱乐应用背后还牵扯到直播、社交、长音频、车载场景、IoT设备联动这些业务。系统测试岗日常做什么功能测试、接口测试、性能测试、稳定性测试、兼容性测试、异常场景测试这些都要碰。和纯业务功能测试不同系统测试更强调对整个软件系统的链路理解从前端交互到后端服务再到数据库和中间件整条链路上的问题你都得能定位、能分析、能提bug。从岗位定位反推回来笔试题目就一定有这几个方向通用计算机基础操作系统、网络、数据库这是测试工程师定位问题的底层能力。Linux操作能力测试环境部署、日志排查、服务启停、性能数据采集这些都要在Linux上做。测试理论与工程方法用例设计方法、缺陷生命周期、测试流程、质量度量。编程与脚本能力至少能用一门语言写简单的自动化脚本或者算法题。业务场景理解会结合音乐产品的实际使用场景出题比如播放卡顿、歌词同步、音质切换、歌单加载这种。把这几个方向记住了复习的时候就不至于大海捞针。1.2 2023年第一批笔试的整体框架整体题量和时间我没有办法放出完全精确的官方数据但按当时群里大家反馈拼出来的画像大概是这样的结构第一部分计算机基础选择题约20道左右覆盖操作系统、网络、数据库、数据结构。第二部分Linux与Shell相关题目有选择题也有简答操作题考察常用命令和简单脚本编写。第三部分测试基础与用例设计题通常有一道大的场景用例设计题外加几道测试理论简答。第四部分编程题1到2道难度在LeetCode中等偏下但涉及字符串、数组处理居多。时间上整套笔试给的时间不算宽裕尤其是用例设计题需要写大量文字非常耗时。很多人挂在时间分配上前面选择题磨太久后面编程题和用例设计题草草收场。这个问题后面专门展开聊。1.3 系统测试岗笔试和开发岗笔试最大的不同开发岗笔试本质上是算法竞赛刷够题、练够模板分数基本就有保障。系统测试岗笔试不是。系统测试岗笔试有大量开放性的、没有标准答案的题目尤其是用例设计题。这种题考察的不是你会不会背等价类、边界值这些名词而是你能不能把方法用到具体的业务场景里去。你写出来的用例够不够全有没有考虑到异常场景、并发场景、弱网场景、权限场景这些才是拉分的核心。举个例子为一个音乐播放器的歌曲收藏功能设计测试用例你如果只写点击收藏按钮收藏成功再次点击取消收藏这两条那基本就是不及格水平。面试官想看到的是用户未登录时点击收藏会怎样收藏上限是多少重复收藏同一首歌如何处理收藏后断网会不会丢数据收藏列表的排序规则是什么在不同端上收藏是否同步这些才是系统测试工程师脑子里应该有的东西。所以这篇拆解我更多的笔墨会放在用例设计题和场景题的答题思路上因为那才是这类笔试真正的分水岭。2. 系统测试核心考点拆解这五块必须吃透先把考点一块一块掰开说。不是让大家去背答案而是搞清楚每一块到底在考什么以及用什么姿势复习效率最高。2.1 计算机基础不是刁难你是在筛掉不懂原理的人计算机基础部分的选择题操作系统、网络、数据库三分天下。操作系统高频考点进程与线程区别、进程调度算法、死锁产生的四个必要条件、虚拟内存与分页机制、乐观锁与悲观锁这些就不用说了必考。系统测试岗会稍微倾向I/O相关的题目比如阻塞与非阻塞I/O、同步与异步、select/poll/epoll的差异因为做性能测试的时候这些概念你会天天碰到。网络的高频考点TCP三次握手和四次挥手、TCP和UDP的区别、HTTP状态码语义尤其是301、302、403、404、500、502、503、HTTPS的握手过程、DNS解析流程、Cookie和Session的区别。这些不只是笔试考点你后续做接口测试、抓包分析、弱网模拟全都用得上。数据库的高频考点就三块SQL编写多表联查、聚合函数、分组过滤、子查询、事务的ACID特性与隔离级别、索引失效的常见场景。测试岗对SQL的要求比开发岗还实际因为测试过程中需要造数据、查数据、核对数据写SQL是每天都要干的事。复习建议很直接不用啃大部头教材把大学课件里的重点章节过一遍再刷一遍牛客网和力扣上的计算机基础题库就够了。如果时间紧张优先保证网络和数据库操作系统的I/O部分可以放到后面。2.2 Linux操作题不是背命令是模拟排障Linux部分我觉得是系统测试岗笔试最有区分度的模块。开发岗不太会考你Linux但测试岗会因为测试工程师的日常就是跟Linux服务器打交道。考察方向一般是三层第一层是常用命令的熟练度。cd、ls、cp、mv、rm、ps、top、grep、awk、sed、find、netstat、ss、curl、tail、head、chmod、chown这些得达到不用过脑子的程度。尤其是grep和awk考的概率极高一道题里就让你从一个日志文件里筛出某个关键字再做简单统计你如果写不出来基本分就丢了。第二层是排障命令的组合运用。比如服务起不来你怎么排查你得按这个思路来:先ps查进程在不在再netstat或ss查端口有没有监听然后tail看日志文件报什么错再用curl本地探活最后根据错误类型决定是看磁盘空间df -h、还是看内存free -m、还是看CPU负载top。这个排查链路本身就是一套方法论笔试考你的不是某一个命令而是这一整套思路。第三层是Shell脚本的简单编写。考察for循环遍历文件、if判断、变量赋值、简单文本处理。难度不会太高但至少要能看懂和写基本的脚本逻辑。比如让你统计一个目录下所有.log文件中包含ERROR的行数用一条Shell命令或者一个简单脚本实现。我在实际带新人时发现很多科班出身的学生Linux经验基本为零连vim怎么退出都要百度。这其实是大学教育的一个普遍盲区。所以如果你现在Linux还不熟不用慌花一周时间集中练一遍基本命令和脚本语法是完全来得及的。2.3 测试基础与用例设计拉开差距的地方这一部分我单独用一整个章节来写因为它的重要性值得。先说测试理论部分的常见简答题测试与调试的区别黑盒测试与白盒测试的异同单元测试、集成测试、系统测试、验收测试分别是什么各自关注什么回归测试的意义和策略缺陷的生命周期和状态流转性能测试的常见指标QPS、TPS、并发数、响应时间、吞吐量、P99延迟稳定性测试怎么做Monkey测试的原理这些题目考的其实不是记忆力而是你有没有真正理解测试工作的本质。比如系统测试和功能测试的区别你要是只回答系统测试测整个系统功能测试测功能那等于没说。更好的回答是系统测试是在完整的软硬件环境下对系统的功能性、性能、可靠性、安全性、兼容性等方面进行综合验证关注的是系统作为一个整体的行为是否符合需求和规格说明而功能测试是验证系统功能是否按照需求文档正确实现。系统测试是更上层的验证不仅包含功能还包括非功能属性。至于用例设计题核心方法就那几个等价类划分、边界值分析、场景法、判定表法、错误推测法。但真正的高手是能够根据被测对象的特点灵活组合这些方法。这个我下面单独用一道音乐App的题来演示。2.4 编程题难度不大但别在这里翻车系统测试岗的编程题一般不会太难难度通常控制在LeetCode简单到中等水平。2023年这批反馈下来的题目方向主要是字符串处理和数组操作比如给定一个字符串统计每个字符出现的次数判断一个字符串是否是回文串的变体合并两个有序数组找出数组中出现次数超过一半的元素反转链表这个在简单偏难的位置编程语言可选C、Java、Python都行。这里有个非常重要的建议一定要选自己最熟的语言。我当时用的Python代码量少、写起来快在时间紧张的情况下优势太明显了。你如果C更熟就用C但要注意边界条件处理别在指针上翻车。编程题真正考察的不是算法天赋而是代码规范度和边界思维。很多人在笔试里栽跟头不是因为题不会而是因为没考虑空数组、数组越界、字符串为空、数字溢出这些边界情况。测试岗的编程题尤其看重边界思维——这本身就是测试工程师的核心素养。你写出来的代码连边界条件都不处理面试官凭什么相信你能设计出覆盖边界的测试用例一个小建议编程题做完了如果时间允许自己多写几个测试用例在草稿纸上跑一遍。这不是浪费时间这是在展示你作为测试人员的专业素养——虽然笔试系统不会直接看到你的草稿但代码里如果体现出了对边界的考虑是会反映在正确率里的。2.5 自动化测试与脚本能力面试环节才是真正的检验场笔试阶段专门考自动化测试框架的题目不多但有时会在简答题里带一下比如你了解哪些自动化测试框架selenium的原理是什么pytest的fixture有什么用。这种题考察的是你有没有实际写过自动化脚本。我见过不少简历里写着熟悉Selenium熟悉pytest结果一问三不知。笔试如果没有专门考一般是因为这类能力在笔试里很难量化面试官会把这个问题留到面试环节深挖。所以对自动化这块建议是把基本原理搞清楚有实际项目最好没有的话自己搭个简单的demo跑一遍。我在准备校招时踩过一个坑以为自动化测试笔试不考就不用管结果面试被追问到Selenium的WebDriver原理直接卡壳。后来老老实实把Selenium的底层通信机制WebDriver启动浏览器、绑定端口、通过HTTP协议发送命令、浏览器执行后返回结果啃了一遍才算彻底补上这块缺口。3. 用一道音乐App场景题完整走一遍答题思路这一章是全文的重点我会拿一道非常典型的、符合腾讯音乐产品场景的用例设计题来演示完整的答题思路。这种题目在系统测试岗笔试里几乎必出分值占比又大值得花大力气研究。题目大概是这样的为一个音乐App的歌单搜索功能设计测试用例。乍一看很简单搜索框加个回车能出结果不就行了吗但在系统测试工程师眼里这个问题背后的测试维度非常丰富。别急着动笔先理清思路。3.1 第一层明确测试范围与用户场景拿到用例设计题第一步不是写用例而是先搞清楚被测功能到底是什么以及它在整个系统中承担什么角色。这一层信息会决定你后面测什么、不测什么。歌单搜索是音乐App里的一个相对高频的功能。用户的典型使用路径是打开App进入搜索页输入关键词点击搜索按钮或按回车系统展示搜索结果列表。用户在结果列表中浏览点击某个歌单进入歌单详情页。整个过程横跨客户端UI层、网络请求层、服务端搜索服务、数据处理层最后落回客户端渲染。所以这道题的测试范围至少包括搜索入口的UI交互搜索框、搜索按钮、搜索历史、热搜推荐搜索逻辑关键词匹配规则、结果排序、结果数量搜索结果展示分页、空状态、加载状态、失败状态结果跳转点击歌单进入详情页、数据传递是否正确异常场景断网、超时、服务器异常、弱网环境不同端的兼容Android、iOS、平板、车机等把测试范围画出来你写用例的时候就不会漏东漏西了。3.2 第二层按测试类型穷举而不是零散地乱写这里我把用例按类型分了几个维度每个维度单独展开目的就是让答案看起来有体系、有逻辑而不是想到哪写到哪。功能维度这是基础覆盖功能本身的正常流程和异常流程。输入搜索关键词点击搜索按钮正常展示搜索结果输入搜索关键词按键盘回车键正常展示搜索结果关键词支持精确匹配、模糊匹配、拼音匹配搜索无结果时展示空状态页面且有引导文案搜索歌单、搜索歌手、搜索歌曲、搜索专辑等不同类型的内容搜索结果点击跳转获取详情页数据搜索历史记录正常展示且可删除界面维度测试界面交互和展示逻辑。搜索框默认展示的提示文案是否正确比如搜索歌单/歌手/歌曲搜索框清空按钮的功能搜索按钮的点击态和置灰态搜索结果列表的展示顺序、缩略图、歌单名称、播放量信息搜索结果是分页加载下拉加载更多正常且不能重复加载易用性维度贴近真实用户使用习惯的考虑。搜索结果是否按照相关性排序如完全匹配排最前搜索结果展示的加载速度是否可接受键盘弹出时是否遮挡搜索结果列表取消搜索时返回的页面是否保持原状异常与健壮性维度这里是最能体现测试思维深度的部分。断网状态搜索给出提示不崩溃弱网状态搜索加载超时有重试机制后端超时客户端有超时提示不白屏无响应搜索框输入1万个字符的极限输入App不卡死搜索内容包含特殊字符、SQL注入关键字、XSS脚本服务端能正确过滤连续快速点击搜索按钮不发生重复请求或页面错乱搜索时App前后台切换再回到前台搜索状态不丢失性能与安全维度系统测试重点关注非功能属性。搜索结果列表大量数据加载时内存无明显飙升多用户同时搜索时服务端吞吐量满足预期搜索请求是否走HTTPS防止关键词被中间人窃听搜索结果接口是否做鉴权未登录用户和登录用户使用差异兼容与多端维度Android和iOS搜索结果展示一致不同分辨率屏幕下搜索界面显示正常车机端、平板端的适配这样按维度展开你的用例基本就覆盖了功能、界面、易用性、异常、性能、安全、兼容这七个方面逻辑性很强面试官一眼就能看到你的系统测试思维。3.3 第三层边界值和等价类的组合应用边界值分析和等价类划分是理论基础但光会背没用要能结合场景使用。拿歌单搜索来说关键词长度边界空字符串或纯空格输入1个字符的关键词50个字符的关键词接近长度上限100个字符的关键词超过长度上限看系统是否截断或报错关键词类型等价类中文关键词英文关键词数字关键词中英文混排关键词特殊字符如%、_、\、引号emoji表情搜索行为的边界连续搜索的间隔时间快速切换搜索关键词搜索后立刻点击进入结果页再返回搜索过程中断网再恢复这些边界情况的用例写出来一方面体现你扎实的测试方法论另一方面也表现出你真实体验过这类产品知道用户会怎么折腾。3.4 第四层从用例设计到缺陷预判的升华用例设计的更高境界是在设计用例时就预判出哪里最容易出bug并围绕这些风险点做针对性设计。我当时写这道题时额外加了这些预判热门词搜索并发高服务端会不会因为缓存击穿导致请求全部打到数据库需要设计并发搜索的用例搜索结果的排序和推荐策略可能因不同端、不同账号体系而不同需要分别验证歌单搜索结果里如果包含下架歌曲、无版权歌曲界面展示是否异常搜索历史与用户账号的绑定关系登录态失效后历史记录是否还保留这一层不是必答项但如果你能写出来绝对是加分项。面试官看到的不只是你会写用例而是你对这个系统可能存在的问题有预判能力——这恰恰是系统测试工程师区别于普通功能测试工程师的核心能力。4. 笔试中的时间分配与答题策略这些经验是踩坑换来的笔试不光考你会不会还考你在有限时间内怎么决策、怎么取舍。2023年那批笔试很多同学抱怨题目做不完说实话题目量虽然不小但也没到做不完的地步关键还是策略出了问题。4.1 先做分值高、产出快的题别和难题死磕一套笔试卷子拿到手先花60秒整体扫一遍把每道题的分值占比和难度心里有个数。我的建议顺序是这样的先做编程题。不管编程题在试卷的哪个位置先做。因为编程题如果你会代码量虽然不算少但产出确定性高而且编程题通常分值不低值得优先保障。如果你做到一半卡住了设定一个5分钟的思考上限没有思路果断放弃回头有时间再来处理。再做用例设计题。用例设计题是主观题只要你有思路就能写不需要调用太多记忆分值大一旦开始写就是纯赚。哪怕写得不完美也比空着强。然后是Linux题和简答题。这些题有相对确定的答案能写多少写多少注意别跳步骤。最后是选择题。选择题分值小而且有些题是纯记忆性的到了后面如果时间不够蒙一个还有25%的命中率。4.2 用例设计题的作答模板让阅卷官一眼看懂很多人用例设计题丢分不是不会设计而是答题结构太乱阅卷的人根本找不到得分点。这里分享一个我屡试不爽的模板第一步写被测对象的概述一两句话说明这个功能是什么、用户路径是什么。第二步写测试范围列出涉及的功能模块。第三步按维度分层写用例。每个用例描述清楚前置条件、操作步骤、预期结果。这一步不要写太啰嗦用表格或清单列清楚即可重点是数量要多、覆盖要全。第四步如果有必要补充你认为风险最高的几个场景并说明为什么。这一部是加分项。这个模板的好处是不管阅卷官是快速扫读还是认真细看都能在短时间内get到你的逻辑和覆盖度。4.3 遇到不会的题怎么体面地蹭分笔试过程中一定会遇到不会的题尤其是选择题里的冷门知识点。这时候有几个技巧选择题不会的先排除明显错的选项再在剩下选项里选一个看着靠谱的。如果完全没思路就选包含绝对化词汇少的选项比如含总是所有必须这类词的选项往往是错误选项。这在计算机基础选择题里命中率很高因为很多错误选项都是通过绝对化表述来设置的陷阱。简答题不会的把你对这个词的全部印象按逻辑拼上去。比如问什么是稳定性测试就算你不记得标准定义你也可以从字面推断写在长时间运行下观察系统是否出现内存泄漏、性能下降、功能异常等问题。这种推断性回答只要方向对一般能拿一半分数。编程题不会的把思路和伪代码写上去。有些笔试系统支持手写代码你写不出完整实现至少要写清楚思路哪怕是用中文描述也比空着强。很多阅卷官愿意给思路分。4.4 我最想提醒的五个低级失误第一个失误不检查就交卷。选择题答完至少留3分钟把标记的题目重新看一遍尤其是那些你犹豫过的题。第二个失误用例设计题只写正常流程。明明时间够却只写了十几条用例剩下大半时间在那发呆。一定要记住用例设计题宁多勿少写满了就没有遗憾。第三个失误编程题只写核心逻辑不处理边界。比如字符串为空、数组越界这种代码在有经验的阅卷官眼里一眼就看得出功力。第四个失误简答题回答太短。一道10分的简答题你只写了两行字大概率只能拿2分。哪怕是不确定的题也要尽量多写角度多写几个观点。第五个失误在笔试界面里乱敲代码。有些笔试系统会记录用户的编辑行为你在代码框里反复删除重写虽然不影响最终分但万一系统对代码版本有记录可能会留下不好的编辑画像。正常写就行不用过度紧张。5. 从笔试卷面延伸到面试怎么把笔试答案变成面试谈资笔试不是终点它是面试的序章。这里分享几个我在实际求职和后来带人过程中验证过的方法。5.1 保留答题思路面试官真的会追问很多人笔试考完就万事大吉结果面试被问到你笔试里那道用例设计题是怎么考虑的就直接懵了。这个场景太常见了我自己就经历过多家公司的面试官在面试环节回扣笔试题的情况。所以笔试结束之后趁着记忆还热乎把你写过的用例设计题思路整理下来放到一个文档里留着面试前翻。特别是你觉得答得不错的部分或者答得特别差的部分都要整理。答得好的地方是你在面试里展示实力的素材答得差的地方是你需要补课的重点。腾讯音乐这类公司的面试流程一二面大概率会围绕你的项目经历和测试基础展开笔试题是很好的预热。你可以在面试中主动提一句笔试题里的歌单搜索用例设计我事后又补充了弱网和异常场景的用例这一个动作就能让面试官感受到你的复盘意识。5.2 把笔试暴露的薄弱点补成项目经验笔试最大的价值是暴露了你的知识盲区。如果你在Linux题上丢分那就花时间把Linux命令刷熟然后最好在项目或者日常练习里用起来如果你在用例设计题上没写全那就专门找几个典型的测试对象练手比如登录功能、购物车功能、文件上传功能每个都按我上面说的模板写一遍完整用例。把这些补课的过程整理成文档或者博客面试时就可以作为你最近在学什么的素材。面试官非常喜欢看到候选人有自主学习和复盘的能力这是测试岗位很重要的软素质。5.3 建立自己的测试题库一劳永逸我在准备校招时建了一个自己的测试题库专门用来整理笔试和面试中遇到的题目。分类大概是测试基础、用例设计、Linux、数据库、网络、编程、场景题。每道题记录三部分内容题目描述、我的回答思路、参考的改进答案。每次笔试后更新一次到秋招中后期这个题库已经积累了近百道题目。后来我发现中大厂笔试的题目虽然不会完全重复但考点和出题思路高度相似这个题库的价值远超预期。把笔试当面试的准备材料把错题当学习材料这种心态会让你整个秋招的心态从容很多。你不会再因为一场笔试没发挥好就焦虑因为你知道每一场笔试都在帮你逼近最终的offer。回头再看2023年腾讯音乐秋招系统测试岗第一批笔试它不是什么神题合集它就是把测试工程师该有的基本功换了一层皮来考你。只要你把基础打牢、把用例设计思路捋顺、把时间分配策略定好这类笔试完全可以稳稳拿下。 腾讯音乐秋招系统测试岗笔试全解析：考点、用例设计与时间分配
1. 为什么系统测试岗的秋招笔试值得单独拆开聊先交代一下背景。2023年腾讯音乐秋招系统测试岗第一批笔试我当时是全程跟完的那批人之一。那场笔试之后牛客和几个技术群里直接炸了锅——有人说题量太大做不完有人说用例设计题根本不知道从哪个角度下手也有人说Linux题看着眼熟但一写就错。说实话这类反馈每年都有但2023年这批的出题风格确实有代表性不考死记硬背而是把所有考点都藏在具体场景里考察的其实是你能不能像个测试工程师一样思考。系统测试岗的笔试和开发岗完全是两个物种。开发岗考算法、考八股你刷题刷够了基本能应付系统测试岗笔试考的是广度加工程判断力考点散落在操作系统、数据库、网络、Linux、用例设计、测试理论、编程基础各个角落而且题型非常杂有选择、有填空、有简答、有编程、有场景题。你要是按开发岗的思路去准备大概率会在用例设计题上卡壳。那这篇就围绕2023年腾讯音乐秋招系统测试岗第一批笔试把考点分布、答题思路、时间分配、以及怎么把笔试内容变成后续面试的弹药完整拆一遍。我尽量还原当时考完之后的复盘记录再结合我带过的几届校招新人的笔试题整理把这类笔试的底层逻辑讲透。即便你不是投腾讯音乐这套拆解方法对大多数中大厂系统测试岗的笔试同样适用。1.1 从岗位定位反推笔试考察逻辑先看岗位本身。腾讯音乐的测试岗核心产品形态是QQ音乐、酷狗音乐、酷我音乐这类音视频娱乐应用背后还牵扯到直播、社交、长音频、车载场景、IoT设备联动这些业务。系统测试岗日常做什么功能测试、接口测试、性能测试、稳定性测试、兼容性测试、异常场景测试这些都要碰。和纯业务功能测试不同系统测试更强调对整个软件系统的链路理解从前端交互到后端服务再到数据库和中间件整条链路上的问题你都得能定位、能分析、能提bug。从岗位定位反推回来笔试题目就一定有这几个方向通用计算机基础操作系统、网络、数据库这是测试工程师定位问题的底层能力。Linux操作能力测试环境部署、日志排查、服务启停、性能数据采集这些都要在Linux上做。测试理论与工程方法用例设计方法、缺陷生命周期、测试流程、质量度量。编程与脚本能力至少能用一门语言写简单的自动化脚本或者算法题。业务场景理解会结合音乐产品的实际使用场景出题比如播放卡顿、歌词同步、音质切换、歌单加载这种。把这几个方向记住了复习的时候就不至于大海捞针。1.2 2023年第一批笔试的整体框架整体题量和时间我没有办法放出完全精确的官方数据但按当时群里大家反馈拼出来的画像大概是这样的结构第一部分计算机基础选择题约20道左右覆盖操作系统、网络、数据库、数据结构。第二部分Linux与Shell相关题目有选择题也有简答操作题考察常用命令和简单脚本编写。第三部分测试基础与用例设计题通常有一道大的场景用例设计题外加几道测试理论简答。第四部分编程题1到2道难度在LeetCode中等偏下但涉及字符串、数组处理居多。时间上整套笔试给的时间不算宽裕尤其是用例设计题需要写大量文字非常耗时。很多人挂在时间分配上前面选择题磨太久后面编程题和用例设计题草草收场。这个问题后面专门展开聊。1.3 系统测试岗笔试和开发岗笔试最大的不同开发岗笔试本质上是算法竞赛刷够题、练够模板分数基本就有保障。系统测试岗笔试不是。系统测试岗笔试有大量开放性的、没有标准答案的题目尤其是用例设计题。这种题考察的不是你会不会背等价类、边界值这些名词而是你能不能把方法用到具体的业务场景里去。你写出来的用例够不够全有没有考虑到异常场景、并发场景、弱网场景、权限场景这些才是拉分的核心。举个例子为一个音乐播放器的歌曲收藏功能设计测试用例你如果只写点击收藏按钮收藏成功再次点击取消收藏这两条那基本就是不及格水平。面试官想看到的是用户未登录时点击收藏会怎样收藏上限是多少重复收藏同一首歌如何处理收藏后断网会不会丢数据收藏列表的排序规则是什么在不同端上收藏是否同步这些才是系统测试工程师脑子里应该有的东西。所以这篇拆解我更多的笔墨会放在用例设计题和场景题的答题思路上因为那才是这类笔试真正的分水岭。2. 系统测试核心考点拆解这五块必须吃透先把考点一块一块掰开说。不是让大家去背答案而是搞清楚每一块到底在考什么以及用什么姿势复习效率最高。2.1 计算机基础不是刁难你是在筛掉不懂原理的人计算机基础部分的选择题操作系统、网络、数据库三分天下。操作系统高频考点进程与线程区别、进程调度算法、死锁产生的四个必要条件、虚拟内存与分页机制、乐观锁与悲观锁这些就不用说了必考。系统测试岗会稍微倾向I/O相关的题目比如阻塞与非阻塞I/O、同步与异步、select/poll/epoll的差异因为做性能测试的时候这些概念你会天天碰到。网络的高频考点TCP三次握手和四次挥手、TCP和UDP的区别、HTTP状态码语义尤其是301、302、403、404、500、502、503、HTTPS的握手过程、DNS解析流程、Cookie和Session的区别。这些不只是笔试考点你后续做接口测试、抓包分析、弱网模拟全都用得上。数据库的高频考点就三块SQL编写多表联查、聚合函数、分组过滤、子查询、事务的ACID特性与隔离级别、索引失效的常见场景。测试岗对SQL的要求比开发岗还实际因为测试过程中需要造数据、查数据、核对数据写SQL是每天都要干的事。复习建议很直接不用啃大部头教材把大学课件里的重点章节过一遍再刷一遍牛客网和力扣上的计算机基础题库就够了。如果时间紧张优先保证网络和数据库操作系统的I/O部分可以放到后面。2.2 Linux操作题不是背命令是模拟排障Linux部分我觉得是系统测试岗笔试最有区分度的模块。开发岗不太会考你Linux但测试岗会因为测试工程师的日常就是跟Linux服务器打交道。考察方向一般是三层第一层是常用命令的熟练度。cd、ls、cp、mv、rm、ps、top、grep、awk、sed、find、netstat、ss、curl、tail、head、chmod、chown这些得达到不用过脑子的程度。尤其是grep和awk考的概率极高一道题里就让你从一个日志文件里筛出某个关键字再做简单统计你如果写不出来基本分就丢了。第二层是排障命令的组合运用。比如服务起不来你怎么排查你得按这个思路来:先ps查进程在不在再netstat或ss查端口有没有监听然后tail看日志文件报什么错再用curl本地探活最后根据错误类型决定是看磁盘空间df -h、还是看内存free -m、还是看CPU负载top。这个排查链路本身就是一套方法论笔试考你的不是某一个命令而是这一整套思路。第三层是Shell脚本的简单编写。考察for循环遍历文件、if判断、变量赋值、简单文本处理。难度不会太高但至少要能看懂和写基本的脚本逻辑。比如让你统计一个目录下所有.log文件中包含ERROR的行数用一条Shell命令或者一个简单脚本实现。我在实际带新人时发现很多科班出身的学生Linux经验基本为零连vim怎么退出都要百度。这其实是大学教育的一个普遍盲区。所以如果你现在Linux还不熟不用慌花一周时间集中练一遍基本命令和脚本语法是完全来得及的。2.3 测试基础与用例设计拉开差距的地方这一部分我单独用一整个章节来写因为它的重要性值得。先说测试理论部分的常见简答题测试与调试的区别黑盒测试与白盒测试的异同单元测试、集成测试、系统测试、验收测试分别是什么各自关注什么回归测试的意义和策略缺陷的生命周期和状态流转性能测试的常见指标QPS、TPS、并发数、响应时间、吞吐量、P99延迟稳定性测试怎么做Monkey测试的原理这些题目考的其实不是记忆力而是你有没有真正理解测试工作的本质。比如系统测试和功能测试的区别你要是只回答系统测试测整个系统功能测试测功能那等于没说。更好的回答是系统测试是在完整的软硬件环境下对系统的功能性、性能、可靠性、安全性、兼容性等方面进行综合验证关注的是系统作为一个整体的行为是否符合需求和规格说明而功能测试是验证系统功能是否按照需求文档正确实现。系统测试是更上层的验证不仅包含功能还包括非功能属性。至于用例设计题核心方法就那几个等价类划分、边界值分析、场景法、判定表法、错误推测法。但真正的高手是能够根据被测对象的特点灵活组合这些方法。这个我下面单独用一道音乐App的题来演示。2.4 编程题难度不大但别在这里翻车系统测试岗的编程题一般不会太难难度通常控制在LeetCode简单到中等水平。2023年这批反馈下来的题目方向主要是字符串处理和数组操作比如给定一个字符串统计每个字符出现的次数判断一个字符串是否是回文串的变体合并两个有序数组找出数组中出现次数超过一半的元素反转链表这个在简单偏难的位置编程语言可选C、Java、Python都行。这里有个非常重要的建议一定要选自己最熟的语言。我当时用的Python代码量少、写起来快在时间紧张的情况下优势太明显了。你如果C更熟就用C但要注意边界条件处理别在指针上翻车。编程题真正考察的不是算法天赋而是代码规范度和边界思维。很多人在笔试里栽跟头不是因为题不会而是因为没考虑空数组、数组越界、字符串为空、数字溢出这些边界情况。测试岗的编程题尤其看重边界思维——这本身就是测试工程师的核心素养。你写出来的代码连边界条件都不处理面试官凭什么相信你能设计出覆盖边界的测试用例一个小建议编程题做完了如果时间允许自己多写几个测试用例在草稿纸上跑一遍。这不是浪费时间这是在展示你作为测试人员的专业素养——虽然笔试系统不会直接看到你的草稿但代码里如果体现出了对边界的考虑是会反映在正确率里的。2.5 自动化测试与脚本能力面试环节才是真正的检验场笔试阶段专门考自动化测试框架的题目不多但有时会在简答题里带一下比如你了解哪些自动化测试框架selenium的原理是什么pytest的fixture有什么用。这种题考察的是你有没有实际写过自动化脚本。我见过不少简历里写着熟悉Selenium熟悉pytest结果一问三不知。笔试如果没有专门考一般是因为这类能力在笔试里很难量化面试官会把这个问题留到面试环节深挖。所以对自动化这块建议是把基本原理搞清楚有实际项目最好没有的话自己搭个简单的demo跑一遍。我在准备校招时踩过一个坑以为自动化测试笔试不考就不用管结果面试被追问到Selenium的WebDriver原理直接卡壳。后来老老实实把Selenium的底层通信机制WebDriver启动浏览器、绑定端口、通过HTTP协议发送命令、浏览器执行后返回结果啃了一遍才算彻底补上这块缺口。3. 用一道音乐App场景题完整走一遍答题思路这一章是全文的重点我会拿一道非常典型的、符合腾讯音乐产品场景的用例设计题来演示完整的答题思路。这种题目在系统测试岗笔试里几乎必出分值占比又大值得花大力气研究。题目大概是这样的为一个音乐App的歌单搜索功能设计测试用例。乍一看很简单搜索框加个回车能出结果不就行了吗但在系统测试工程师眼里这个问题背后的测试维度非常丰富。别急着动笔先理清思路。3.1 第一层明确测试范围与用户场景拿到用例设计题第一步不是写用例而是先搞清楚被测功能到底是什么以及它在整个系统中承担什么角色。这一层信息会决定你后面测什么、不测什么。歌单搜索是音乐App里的一个相对高频的功能。用户的典型使用路径是打开App进入搜索页输入关键词点击搜索按钮或按回车系统展示搜索结果列表。用户在结果列表中浏览点击某个歌单进入歌单详情页。整个过程横跨客户端UI层、网络请求层、服务端搜索服务、数据处理层最后落回客户端渲染。所以这道题的测试范围至少包括搜索入口的UI交互搜索框、搜索按钮、搜索历史、热搜推荐搜索逻辑关键词匹配规则、结果排序、结果数量搜索结果展示分页、空状态、加载状态、失败状态结果跳转点击歌单进入详情页、数据传递是否正确异常场景断网、超时、服务器异常、弱网环境不同端的兼容Android、iOS、平板、车机等把测试范围画出来你写用例的时候就不会漏东漏西了。3.2 第二层按测试类型穷举而不是零散地乱写这里我把用例按类型分了几个维度每个维度单独展开目的就是让答案看起来有体系、有逻辑而不是想到哪写到哪。功能维度这是基础覆盖功能本身的正常流程和异常流程。输入搜索关键词点击搜索按钮正常展示搜索结果输入搜索关键词按键盘回车键正常展示搜索结果关键词支持精确匹配、模糊匹配、拼音匹配搜索无结果时展示空状态页面且有引导文案搜索歌单、搜索歌手、搜索歌曲、搜索专辑等不同类型的内容搜索结果点击跳转获取详情页数据搜索历史记录正常展示且可删除界面维度测试界面交互和展示逻辑。搜索框默认展示的提示文案是否正确比如搜索歌单/歌手/歌曲搜索框清空按钮的功能搜索按钮的点击态和置灰态搜索结果列表的展示顺序、缩略图、歌单名称、播放量信息搜索结果是分页加载下拉加载更多正常且不能重复加载易用性维度贴近真实用户使用习惯的考虑。搜索结果是否按照相关性排序如完全匹配排最前搜索结果展示的加载速度是否可接受键盘弹出时是否遮挡搜索结果列表取消搜索时返回的页面是否保持原状异常与健壮性维度这里是最能体现测试思维深度的部分。断网状态搜索给出提示不崩溃弱网状态搜索加载超时有重试机制后端超时客户端有超时提示不白屏无响应搜索框输入1万个字符的极限输入App不卡死搜索内容包含特殊字符、SQL注入关键字、XSS脚本服务端能正确过滤连续快速点击搜索按钮不发生重复请求或页面错乱搜索时App前后台切换再回到前台搜索状态不丢失性能与安全维度系统测试重点关注非功能属性。搜索结果列表大量数据加载时内存无明显飙升多用户同时搜索时服务端吞吐量满足预期搜索请求是否走HTTPS防止关键词被中间人窃听搜索结果接口是否做鉴权未登录用户和登录用户使用差异兼容与多端维度Android和iOS搜索结果展示一致不同分辨率屏幕下搜索界面显示正常车机端、平板端的适配这样按维度展开你的用例基本就覆盖了功能、界面、易用性、异常、性能、安全、兼容这七个方面逻辑性很强面试官一眼就能看到你的系统测试思维。3.3 第三层边界值和等价类的组合应用边界值分析和等价类划分是理论基础但光会背没用要能结合场景使用。拿歌单搜索来说关键词长度边界空字符串或纯空格输入1个字符的关键词50个字符的关键词接近长度上限100个字符的关键词超过长度上限看系统是否截断或报错关键词类型等价类中文关键词英文关键词数字关键词中英文混排关键词特殊字符如%、_、\、引号emoji表情搜索行为的边界连续搜索的间隔时间快速切换搜索关键词搜索后立刻点击进入结果页再返回搜索过程中断网再恢复这些边界情况的用例写出来一方面体现你扎实的测试方法论另一方面也表现出你真实体验过这类产品知道用户会怎么折腾。3.4 第四层从用例设计到缺陷预判的升华用例设计的更高境界是在设计用例时就预判出哪里最容易出bug并围绕这些风险点做针对性设计。我当时写这道题时额外加了这些预判热门词搜索并发高服务端会不会因为缓存击穿导致请求全部打到数据库需要设计并发搜索的用例搜索结果的排序和推荐策略可能因不同端、不同账号体系而不同需要分别验证歌单搜索结果里如果包含下架歌曲、无版权歌曲界面展示是否异常搜索历史与用户账号的绑定关系登录态失效后历史记录是否还保留这一层不是必答项但如果你能写出来绝对是加分项。面试官看到的不只是你会写用例而是你对这个系统可能存在的问题有预判能力——这恰恰是系统测试工程师区别于普通功能测试工程师的核心能力。4. 笔试中的时间分配与答题策略这些经验是踩坑换来的笔试不光考你会不会还考你在有限时间内怎么决策、怎么取舍。2023年那批笔试很多同学抱怨题目做不完说实话题目量虽然不小但也没到做不完的地步关键还是策略出了问题。4.1 先做分值高、产出快的题别和难题死磕一套笔试卷子拿到手先花60秒整体扫一遍把每道题的分值占比和难度心里有个数。我的建议顺序是这样的先做编程题。不管编程题在试卷的哪个位置先做。因为编程题如果你会代码量虽然不算少但产出确定性高而且编程题通常分值不低值得优先保障。如果你做到一半卡住了设定一个5分钟的思考上限没有思路果断放弃回头有时间再来处理。再做用例设计题。用例设计题是主观题只要你有思路就能写不需要调用太多记忆分值大一旦开始写就是纯赚。哪怕写得不完美也比空着强。然后是Linux题和简答题。这些题有相对确定的答案能写多少写多少注意别跳步骤。最后是选择题。选择题分值小而且有些题是纯记忆性的到了后面如果时间不够蒙一个还有25%的命中率。4.2 用例设计题的作答模板让阅卷官一眼看懂很多人用例设计题丢分不是不会设计而是答题结构太乱阅卷的人根本找不到得分点。这里分享一个我屡试不爽的模板第一步写被测对象的概述一两句话说明这个功能是什么、用户路径是什么。第二步写测试范围列出涉及的功能模块。第三步按维度分层写用例。每个用例描述清楚前置条件、操作步骤、预期结果。这一步不要写太啰嗦用表格或清单列清楚即可重点是数量要多、覆盖要全。第四步如果有必要补充你认为风险最高的几个场景并说明为什么。这一部是加分项。这个模板的好处是不管阅卷官是快速扫读还是认真细看都能在短时间内get到你的逻辑和覆盖度。4.3 遇到不会的题怎么体面地蹭分笔试过程中一定会遇到不会的题尤其是选择题里的冷门知识点。这时候有几个技巧选择题不会的先排除明显错的选项再在剩下选项里选一个看着靠谱的。如果完全没思路就选包含绝对化词汇少的选项比如含总是所有必须这类词的选项往往是错误选项。这在计算机基础选择题里命中率很高因为很多错误选项都是通过绝对化表述来设置的陷阱。简答题不会的把你对这个词的全部印象按逻辑拼上去。比如问什么是稳定性测试就算你不记得标准定义你也可以从字面推断写在长时间运行下观察系统是否出现内存泄漏、性能下降、功能异常等问题。这种推断性回答只要方向对一般能拿一半分数。编程题不会的把思路和伪代码写上去。有些笔试系统支持手写代码你写不出完整实现至少要写清楚思路哪怕是用中文描述也比空着强。很多阅卷官愿意给思路分。4.4 我最想提醒的五个低级失误第一个失误不检查就交卷。选择题答完至少留3分钟把标记的题目重新看一遍尤其是那些你犹豫过的题。第二个失误用例设计题只写正常流程。明明时间够却只写了十几条用例剩下大半时间在那发呆。一定要记住用例设计题宁多勿少写满了就没有遗憾。第三个失误编程题只写核心逻辑不处理边界。比如字符串为空、数组越界这种代码在有经验的阅卷官眼里一眼就看得出功力。第四个失误简答题回答太短。一道10分的简答题你只写了两行字大概率只能拿2分。哪怕是不确定的题也要尽量多写角度多写几个观点。第五个失误在笔试界面里乱敲代码。有些笔试系统会记录用户的编辑行为你在代码框里反复删除重写虽然不影响最终分但万一系统对代码版本有记录可能会留下不好的编辑画像。正常写就行不用过度紧张。5. 从笔试卷面延伸到面试怎么把笔试答案变成面试谈资笔试不是终点它是面试的序章。这里分享几个我在实际求职和后来带人过程中验证过的方法。5.1 保留答题思路面试官真的会追问很多人笔试考完就万事大吉结果面试被问到你笔试里那道用例设计题是怎么考虑的就直接懵了。这个场景太常见了我自己就经历过多家公司的面试官在面试环节回扣笔试题的情况。所以笔试结束之后趁着记忆还热乎把你写过的用例设计题思路整理下来放到一个文档里留着面试前翻。特别是你觉得答得不错的部分或者答得特别差的部分都要整理。答得好的地方是你在面试里展示实力的素材答得差的地方是你需要补课的重点。腾讯音乐这类公司的面试流程一二面大概率会围绕你的项目经历和测试基础展开笔试题是很好的预热。你可以在面试中主动提一句笔试题里的歌单搜索用例设计我事后又补充了弱网和异常场景的用例这一个动作就能让面试官感受到你的复盘意识。5.2 把笔试暴露的薄弱点补成项目经验笔试最大的价值是暴露了你的知识盲区。如果你在Linux题上丢分那就花时间把Linux命令刷熟然后最好在项目或者日常练习里用起来如果你在用例设计题上没写全那就专门找几个典型的测试对象练手比如登录功能、购物车功能、文件上传功能每个都按我上面说的模板写一遍完整用例。把这些补课的过程整理成文档或者博客面试时就可以作为你最近在学什么的素材。面试官非常喜欢看到候选人有自主学习和复盘的能力这是测试岗位很重要的软素质。5.3 建立自己的测试题库一劳永逸我在准备校招时建了一个自己的测试题库专门用来整理笔试和面试中遇到的题目。分类大概是测试基础、用例设计、Linux、数据库、网络、编程、场景题。每道题记录三部分内容题目描述、我的回答思路、参考的改进答案。每次笔试后更新一次到秋招中后期这个题库已经积累了近百道题目。后来我发现中大厂笔试的题目虽然不会完全重复但考点和出题思路高度相似这个题库的价值远超预期。把笔试当面试的准备材料把错题当学习材料这种心态会让你整个秋招的心态从容很多。你不会再因为一场笔试没发挥好就焦虑因为你知道每一场笔试都在帮你逼近最终的offer。回头再看2023年腾讯音乐秋招系统测试岗第一批笔试它不是什么神题合集它就是把测试工程师该有的基本功换了一层皮来考你。只要你把基础打牢、把用例设计思路捋顺、把时间分配策略定好这类笔试完全可以稳稳拿下。