秋招技术测试岗的笔试是我整个求职季里感受最微妙的一次考核。腾讯音乐2023年秋招技术测试岗第一批笔试题型既不是纯粹的程序员算法题也不是标准的技术问答而是把计算机基础、测试理论、业务理解、编程能力和临场逻辑揉在一起的综合卷。如果你以为测试岗等于写用例、点点点那这套题会直接教做人如果你以为测试岗笔试等于刷LeetCode那你多半会在后面的简答题上吃大亏。这篇文章不贩卖焦虑也不搞什么“内部题库”的噱头只把我记住的考点、答题思路和复盘结论整理出来给后面备战同类岗位的同学一个能直接参考的坐标。先说结论这一批笔试的整体风格是“广而不深、杂而不乱”。它的难点不在于某道题有多难而在于你需要在有限时间内同时切换好几种答题状态——刚在选择题里做完二叉树遍历下一秒就要站在真实用户角度设计播放器的异常场景用例再下一秒又得回到纯算法模式写代码。这种切换能力恰恰是测试工程师日常工作的真实写照你既要懂代码也要懂业务还要能快速判断问题出在哪一层。1. 笔试开场题型分布与测试岗出题逻辑的第一印象1.1 整体印象这份卷子想筛出什么样的测试工程师虽然正式笔试已经过去了一阵子但整套卷子的结构我印象依然很深。第一感受是题量比想象中大题型比想象中杂。大致分为四个板块单选题、多选题、简答题以测试用例设计和场景分析为主和在线编程题。选择题主要集中在计算机基础简答题则明显偏向业务理解和测试思维编程题是独立的算法题要在代码编辑器里运行通过。从出题逻辑倒推这份卷子其实是在模拟一个测试工程师的真实工作场景。选择题考的是你的知识底盘——如果连HTTP状态码、进程和线程的区别都搞不清楚后续排查问题时很难定位是客户端的问题还是服务端的问题。简答题考的是你的测试设计能力——给你一个功能你能不能在一个小时内列出有效的测试点。编程题考的是你的代码能力——测试工程师不一定要写多复杂的业务代码但至少要能写自动化脚本、能看懂开发代码里的逻辑漏洞。我当时做完第一版答案后专门留了几分钟把整张卷子的考点做了一个归类大致是这样的题型数量印象主要考点平时最容易忽略的点单选题约15道数据结构、操作系统、网络、数据库Linux基础命令、SQL语法细节多选题约5道测试理论、异常场景判断、网络协议多选漏选、边界条件判断简答题2道左右测试用例设计、Bug定位思路用例覆盖维度不全、表述口语化编程题2-3道哈希表、滑动窗口、动态规划输入边界、时间复杂度过高这份归类不一定和官方评分权重完全一致但从考察密度上能明显看出腾讯音乐这类业务型公司对测试岗候选人的要求是既要基础扎实也要有业务感觉二者缺一不可。1.2 分值权重为什么最容易忽略的简答题才是分水岭很多同学准备校招笔试时习惯把精力全压在编程题上觉得“代码写出来就行”。但我考完这一场之后最深的体会是这一批笔试真正拉开差距的是那些看起来“不用写代码”的简答题。原因很简单。编程题虽然分值占比不低但能完整AC的同学比例其实不高大部分人的编程题都是部分通过或者只过了一个用例区分度反而不如简答题高。而简答题只要你答得有条理、覆盖到关键点就能拿到一个还不错的分数但如果你写得像没做过测试一样只会写“输入正确输出正确”这种用例那基本就在及格线以下了。我记得当时简答题里有一道是给“音乐App的搜索功能”设计测试用例。这道题乍一看很简单很多人可能写“输入关键词点搜索看结果是否正确”就结束了。但如果只写到这里基本拿不到分。因为阅卷人想看的是你有没有考虑过搜索历史、热门搜索、搜索结果排序、空结果、网络异常导致搜索失败、搜索结果页的翻页和加载、特殊字符输入、模糊匹配和精确匹配的差异甚至是无痕模式和游客状态下的搜索权限。这些点踩到了才是一个真正做过测试的人能写出来的东西。2. 选择题里的暗桩算法、操作系统与网络协议的拿分要点2.1 数据结构与算法不只是考“会不会”更考“边界感”选择题里数据结构与算法的占比不低但难度整体友好属于“期末难度”而非“ACM难度”。印象里考到了这几类栈和队列的区别、二叉树的遍历方式、哈希表解决冲突的几种方法、排序算法的时间复杂度对比、二分查找的边界条件。这里有一个很有意思的现象有几道题表面在考算法实际在考边界和异常情况。比如有一道题问“在一个有序数组中用二分查找查找目标值如果目标值不存在会怎么样”大部分人会直接选“返回-1”但题目考的是对左右指针最终位置的理解——当查找失败时left和right停在哪个位置以及基于这个位置能做什么。这其实非常测试思维你写一段逻辑不能只考虑“正常情况”还要考虑“找不到怎么办”“数组为空怎么办”“元素重复怎么办”。我印象比较深的一道题大致是这样的给定一个非空整数数组除了某个元素只出现一次以外其余每个元素均出现两次。找出那个只出现了一次的元素。这道题的标准解法是异或运算但因为出现在选择题而不是编程题所以出题人大概率会把四个选项设成不同思路的时间复杂度。如果你对位运算不熟很容易选成一个“先排序再遍历”的O(n log n)方案而最优解是O(n)遍历O(1)空间的异或做法。这种题不是不会做而是你要在最短路程里选到最优解——这正是测试工程师做代码评审时需具备的能力看懂代码能跑是一回事看出代码的性能隐患是另一回事。2.2 操作系统与网络死锁、进程线程、TCP握手一个都没少操作系统考得比较基础但覆盖面广。进程和线程的区别、死锁产生的四个必要条件、进程间通信方式、虚拟内存和分页机制这些属于高频考点。我觉得最关键的不是死记硬背定义而是能快速判断一个实际场景属于哪类问题。比如题目问“多个线程同时访问同一个共享变量可能导致什么后果”本质上就是在考线程安全、竞态条件和临界区保护。网络部分考了TCP三次握手的状态变化、TCP和UDP的区别、HTTP常见状态码含义。有一个选项设置得特别容易踩坑把“502 Bad Gateway”和“504 Gateway Timeout”放在一起混淆。如果你只是背了“502是网关错误504是超时”但没有进一步了解nginx和后端服务之间的关系很容易在两个答案之间犹豫。这种题对测试岗来说其实很实用因为你在做接口测试时看到502和504意味着完全不同的排查方向。数据库也是选择题里的固定嘉宾。索引失效的场景、事务ACID特性、SQL中的inner join和left join区别都是高频考点。有一道题我记忆很深问“当一个查询条件中的列上建了索引但查询时对列做了函数运算索引会不会失效”。答案是会失效因为对列做运算后数据库无法直接使用该列的索引树。这种题看起来偏开发但对测试岗同样重要——你在构造测试数据时如果对SQL执行计划没有一个基本概念就很难设计出覆盖“慢查询”场景的用例。2.3 多选题测试理论题怎么做到“不多选不漏选”多选题是这套卷子里我最小心的一部分。因为它和单选题的答题策略完全不同单选即使不确定蒙一个还有25%的概率多选如果没有十足把握选多了是0分选少了的得分规则也未必理想。多选题考的核心是测试理论。我记得涉及了黑盒测试方法的分类等价类、边界值、因果图、正交实验等、软件测试的生命周期阶段、回归测试的适用场景、探索性测试的特点。这些内容看似是《软件测试》教科书上的知识点但出题人会故意把一些“感觉对但实际不对”的选项混进去。举个例子有一道题问“以下哪些属于黑盒测试方法”选项里有“等价类划分”“边界值分析”“语句覆盖”“条件覆盖”“因果图”。前两个和最后一个都是黑盒但“语句覆盖”“条件覆盖”是白盒测试里的逻辑覆盖方法。如果你只记得大部分黑盒方法的名字而不清楚它们的分类边界这道题就会漏选或者多选。所以对于多选题的策略我在考场上给自己定的规矩是每一个选项都要能说出“它为什么对”或者“它为什么错”说不出来的一律不选。3. 测试用例设计题的得分关键业务理解与边界覆盖3.1 从“搜索功能”到“登录功能”用例设计题到底在考什么简答题的用例设计是整套卷子里最“软”也最见功力的部分。我印象里有两道一道是给音乐App的搜索功能设计测试用例另一道是给一个视频App的登录功能设计测试用例。两道都来自很常见的业务场景没有刁钻的设计但正因为太常见很多人反而答不到点上。先说搜索功能。我当时的答题思路是先搭一个框架再往里填充细节。框架分成这样几层第一层是功能层。正常搜索、关键词联想、搜索历史、热门搜索、清空历史、搜索结果的排序与分页、搜索无结果时的空态。第二层是交互与体验层。输入框字数限制、特殊字符和emoji的处理、手机键盘的搜索按钮触发、连续快速点击搜索按钮时的防抖处理。第三层是权限与状态层。游客未登录能否搜索、会员和普通用户搜索结果是否有差异、搜索结果页下拉加载更多是否正常。第四层是异常层。弱网条件下搜索超时、断网时从本地缓存读取历史、服务端返回500时前端如何展示、搜索结果图片加载失败时的占位图。第五层是兼容性层。不同操作系统、不同屏幕尺寸、深浅色模式、横竖屏切换等。这五层不一定能在一道简答题里写满但至少要让阅卷人看到你有“分层思考”的习惯。很多同学写用例就是往一个方向堆比如只写功能正常搜索、搜索空结果、搜索非法字符……三条之后就写不下去了。如果你能按“功能—交互—权限—异常—兼容”五个维度展开两页纸很容易就能写满而且质量不低。3.2 我推荐的一种测试用例答案模板五维展开法关于这类题目我后来复盘时总结出一个比较好用的写法适用于大多数功能型简答题。你不需要每一个维度都写特别多但一定要让每个维度都有内容维度关注点示例功能正确性输入、输出、逻辑是否符合预期关键词搜索后返回正确歌曲列表交互与体验UI状态、操作反馈、边界交互搜索中的loading动效、空结果提示权限与角色不同用户状态下的差异行为游客与登录用户搜索结果是否一致异常与容错弱网、超时、服务端错误、中断恢复搜索请求超时后是否能重试数据与状态数据一致性、缓存、历史记录、数据恢复清除缓存后搜索历史是否保留这五个维度其实对应了测试工程师在日常工作中最常关注的几类问题。我后来在公司实习时做需求测试也基本沿用这个框架去设计用例只是会再增加一层“埋点与数据上报”。但笔试阶段不用写那么细把这五个维度写得清晰、有条理得分就稳了。3.3 答题表述的三个细节分点、用词、可执行性简答题除了内容表达方式也很影响得分。我当时给自己定了几个要求也算是一些经验每一个用例都要有可执行性。比如“验证搜索框输入超长字符时前端是否截断”这算一条用例但“验证搜索功能是否好用”这种话基本等于白说。可执行性的判断标准是另一个人拿到你的用例能直接知道“怎么操作、预期是什么”。用“前置条件—操作步骤—预期结果”的结构写关键用例。正式工作中写用例也需要这种结构笔试时不必每一条都这么完整但核心的几条一定要体现出来。比如登录功能你可以写“前置条件用户未注册操作使用未注册的手机号点击登录预期提示用户先注册并跳转注册页”。不要只写正常流程至少三分之一用例要覆盖异常和边界。这是区分“有测试思维”和“只会用软件”的重要分水岭。空值、超长值、特殊字符、网络异常、断电、重复操作、权限不足这些场景哪怕只写两三条也会让阅卷人觉得你是一个有经验的人。4. 三道编程题的完整复盘从审题到AC的思考过程4.1 编程题一哈希表计数送分题也有陷阱第一道编程题比较简单大致是给定一个歌曲ID数组求出出现次数最多的歌曲ID如果有多个返回ID值最小的那个。输入是一个整数数组输出是出现次数最多的整数。这类题一看就知道用哈希表计数但这里有一个容易被忽略的陷阱如果数组非常大用O(n)空间是没问题的但如果你先排序再遍历O(n log n)的时间复杂度在数据量特别大的时候可能超时。另外题里明确说了“有多个返回ID值最小”所以遍历哈希表时要同时维护“最大次数”和“最小ID”两个变量而不能只存一个值。我当时写的参考代码类似这样def most_frequent_song(songs): from collections import Counter counter Counter(songs) max_cnt -1 ans float(inf) for song_id, cnt in counter.items(): if cnt max_cnt or (cnt max_cnt and song_id ans): max_cnt cnt ans song_id return ans这道题真正的考点不在写代码本身而在审题你是不是看到了“返回ID值最小”这个条件很多人统计完直接返回counter.most_common(1)[0][0]在测试用例覆盖到“多个相同最大值”时就会挂掉。测试岗的编程题往往就是这样题目本身不难但边界条件一定要看清。4.2 编程题二滑动窗口把经典题包装成音乐场景第二道编程题明显比第一道上了一个台阶形式是给定一个整数数组表示用户按照时间顺序播放的歌曲ID序列求所有不包含重复歌曲的连续播放序列中最长的那一个的长度。这个题本质上就是“无重复字符的最长子串”只是把字符串换成了歌曲ID数组。我当时的默认思路是滑动窗口用一个左指针维护窗口左边界用哈希表记录每个歌曲最近出现的位置。遍历数组时如果当前歌曲已经在窗口内就把左指针移动到上次出现位置的下一个位置然后更新窗口长度。参考代码如下def longest_unique_playlist(songs): last_pos {} left 0 max_len 0 for right, song_id in enumerate(songs): if song_id in last_pos and last_pos[song_id] left: left last_pos[song_id] 1 last_pos[song_id] right max_len max(max_len, right - left 1) return max_len这道题我复盘时最大的感受是笔试环境里没有IDE提示也没有自动补全代码要手写。所以平时刷题时其实应当刻意练一下“不用IDE、直接在网页编辑器里写代码”的能力包括缩进、函数名拼写、临时的print调试。很多同学平时在本地IDE里写得很溜一到笔试环境就各种小错误归根到底是练习方式的问题。4.3 编程题三动态规划能做出来就是优势第三道编程题难度再往上提了一档考的是动态规划。题目大意是给定一个长度为n的数组表示每天新增的收藏歌曲数量你可以选择“在某一时刻进行一次操作”把从该时刻到数组结尾的所有数字求和并作为本次操作的收益要求选择两个不同的时刻分别操作两次操作范围不能重叠求最大总收益。这道题实际上可以转化为把数组分成两段分别取两段的最大后缀和求它们的和的最大值。我的解法是用两次遍历计算每个位置作为分割点时左右两边的最大区间和。参考代码如下def max_total_gain(arr): n len(arr) # left_max[i]: 0..i 这段内最大后缀和 left_max [0] * n cur arr[0] left_max[0] arr[0] for i in range(1, n): cur max(arr[i], cur arr[i]) left_max[i] max(left_max[i-1], cur) # right_max[i]: i..n-1 这段内最大前缀和 right_max [0] * n cur arr[n-1] right_max[n-1] arr[n-1] for i in range(n-2, -1, -1): cur max(arr[i], cur arr[i]) right_max[i] max(right_max[i1], cur) ans float(-inf) for i in range(n-1): ans max(ans, left_max[i] right_max[i1]) return ans这道题不仅考DP状态设计还考了“是否能想到枚举分割点”这一步。测试工程师做自动化测试框架时经常需要把一段大逻辑拆成多个小步骤本质上和“枚举分割点、各自求最优子结构”的思路很像。这种题能做出来不仅说明你算法基础可以也能侧面体现你的抽象能力。4.4 编程题答题策略先保一题AC再争取第二题我给出一个针对校招笔试的非常现实的策略如果三道题都做优先把第一题和第二题做到AC第三题即使只能写出暴力解法也比空着强。在实际阅卷中部分通过的分数也值钱尤其当第三题难度明显偏高时大部分人都只能写一个暴力解你哪怕只优化了一点就已经超过不少人了。另外特别提一句在笔试前一定要熟悉在线评测平台的输入输出格式。有的平台需要自己处理多行输入有的平台直接给你函数参数。拿到手一道题先看输入输出说明不要想当然地在函数里写print。这个低级错误每年校招笔试都会有一批人犯实在太可惜。5. 业务场景题与逻辑分析音乐App场景下的测试思维5.1 播放卡顿类问题怎么从“偶发卡顿”定位到根因简答题里还有一类非常典型的题给一个线上反馈让你写出排查思路。我记得有一道题大意是有用户反馈“播放音乐时偶尔卡顿尤其在地铁上”让你分析可能的原因并写出定位思路。这道题的核心是“分层排查”。我当时是这样写的第一层是客户端因素。用户的手机性能不足、App版本过旧、本地缓存已满、后台其他应用占用CPU和内存都可能导致播放卡顿。第二层是网络因素。移动网络切换导致连接重建、弱网条件下音质缓冲不足、CDN节点质量不稳定、DNS解析慢、网络代理干扰等。第三层是服务端因素。歌曲文件的CDN回源慢、播放接口响应慢、用户所处地区和最近节点不匹配、服务器过载导致丢包重传。第四层是产品逻辑因素。是否是播放器的缓冲策略太激进、是否开启了超高音质导致码率过高、是否在出现网络切换时没有主动降级。更关键的是“偶发”两个字。偶发意味着大概率不是每次必现的确定性缺陷而是特定环境下的条件触发问题。所以正确思路是做条件拆分是什么时间什么网络什么机型什么歌曲什么操作路径只有把变量控制住才能一步一步收敛根因。这种题没有标准答案但阅卷人希望看到的是一种接近真实工作中排查问题的思路。如果你能按“收集信息—复现问题—分层排除—定位根因—验证修复”这个逻辑来答即便每个环节写得不算深入也会比只写“可能是网络不好”强很多。5.2 推荐不精准类问题数据、策略和用户体验的三角博弈另一类让我印象深刻的业务场景题是“用户反馈每日推荐歌单越来越不准如何分析并解决”。这道题的巧妙之处在于它表面是测试问题实际上是产品和技术结合的开放题。我当时把答案拆成了三个方面首先是数据问题。用户的行为数据是否采集完整播放、收藏、跳过、听完、循环播放这些行为分别代表什么意图有没有被正确埋点上报如果埋点缺失推荐系统拿到的就是残缺的数据。其次是策略问题。推荐算法是否有“重启保护”机制如果用户最近频繁点击了某一类歌曲但从不收藏算法是否会产生过度拟合是否存在“信息茧房”效应导致推荐结果越来越窄最后是验证问题。如何证明推荐结果“更不准”需要建立评估指标比如推荐结果的点击率、播放完成率、收藏转化率、负反馈率。如果没有明确指标所有改进都是空谈。这个问题其实是在考察测试工程师能不能从“功能测试”跳到“数据测试”和“体验测试”。在腾讯音乐这类业务型公司做测试你面对的往往不是单纯的接口和页面而是一套复杂的推荐策略。如何验证推荐系统改版后是否更准本身就是很有挑战性的测试工作。我在笔试时虽然写得不长但尽量体现了“数据驱动”的思路后来想想这大概就是这类题目想看到的。5.3 逻辑推理题天平秤球与二分思维的实测应用逻辑推理题在这批笔试中也出现了基本都是比较经典的老题。比如“有8个外观相同的球其中有1个重量与其余不同且不知道是偏轻还是偏重用一台无砝码天平最少称几次能找出这个球并确定它是偏轻还是偏重”。这题我见过很多次答案是3次。思路是先取6个球3个一组放上天平。如果天平平衡问题球在剩余2个里再用2次即可。如果天平不平衡需要根据偏向进一步二分排除。这类题考的不是数学知识而是“排除法”和“信息量”思维每一次称量最多产生三种结果所以理论上要覆盖足够多的可能性。对测试工程师来说这种思维和用例设计的正交思想高度相关。一个输入组合有很多维度时你不可能穷举所有情况所以要用最少的实验次数覆盖尽量多的可能性。笔试遇到这种题时我的建议是如果之前做过直接按结论写步骤如果没做过也要在草稿纸上认真推演不要凭感觉蒙。6. 考场生存策略时间分配、答题顺序与常见翻车点6.1 我的时间分配方案留出四成时间给编程题腾讯音乐这一批笔试的总时长我记得是两个小时左右题量在20道以上所以时间并不宽裕。我当时给自己定的时间分配是选择题40分钟左右、简答题30分钟左右、编程题40分钟左右、剩下10分钟检查。实际执行下来这个分配还算合理。不同题型的做题节奏差别很大。选择题不能每题都纠结太久遇到拿不准的先标记优先把确定能拿的分拿到之后再回头想。简答题要控制篇幅每道题控制在10到15分钟内写关键点而不是写论文。编程题至少要留足40分钟因为读题、理解、编码、调试都需要时间。如果你前面选择题做得太快导致编程题做完了还剩大把时间那大概率选择题也没认真检查反而是浪费。我做题顺序上有个小偏好先把编程题的整体浏览一遍判断难易程度然后先做选择题再做简答题最后集中精力做编程题。这样做的好处是你在做选择题时会逐渐进入状态而编程题作为最后的大题正好可以在“热脑”状态下做。如果你一开始就做编程题可能因为没进入状态而浪费很多时间。6.2 考试中容易翻车的四个细节从环境到心态在这一批笔试中我观察到四个特别容易翻车的细节这里也一起说一下第一是浏览器环境。在线笔试前一定要检查浏览器是否符合要求、是否安装相关插件、网络是否稳定最好提前十分钟进入等待页面。第二是输入输出格式。编程题如果要求自己解析输入就一定要先print一行样例看看格式不要写完代码才发现输入格式理解错了。第三是缩进和语法细节。手写代码没有IDE的自动缩进提示Python代码尤其要注意for循环里的冒号和缩进层级。第四是心态波动。遇到一道完全没思路的题不要停在那里果断跳过先把后面能拿的分拿完。还有一个比较隐蔽的问题是在线评测系统偶尔会因为代码中有无限循环而报“运行超时”这在暴力解法中非常常见。如果你发现自己的代码在大数据量用例上超时可以先加一个快速失败的边界判断比如数组长度很小就直接返回这样至少能过掉一部分用例。6.3 关于检查至少要留5分钟做“低级错误扫描”最后一轮检查不是把所有题目重新做一遍而是做一次“低级错误扫描”。重点看三件事选择题有没有涂错选项、多选有没有选成单选、编程题有没有把思路中的边界条件漏掉。尤其是多选很多同学在做多选时会因为时间紧张而选成单选这种失误在检查时非常容易被发现。7. 笔试后的复盘与下一步备战方向7.1 从这次笔试反推招聘偏好业务型测试岗看重什么这一批笔试结束后我做了很长时间的复盘。我最大的感受是腾讯音乐作为一家以音乐产品为核心的互联网公司它在筛选测试工程师时不仅仅看你会不会写代码、懂不懂算法更看你对“产品怎么用、用户会怎么想、线上问题怎么查”有没有感觉。你可以从这套卷子里很清晰地看到三个偏好信号。第一业务场景题比重高。搜索、播放、推荐这类题目都是音乐App的高频功能如果你平时用过足够多的音乐产品答起来会更有底气。第二开放题强调逻辑和表达。不管是排查问题还是设计用例阅卷人都在看你有没有一套清晰的分析框架。第三算法题难度适中但边界条件多。这说明他们希望候选人有代码功底但不追求竞赛级难度。7.2 针对测试岗的系统性学习清单复盘完笔试我再给准备校招的同学梳理一份可以直接对照的学习清单内容不限于笔试也覆盖到二面和三面可能考察的知识测试基础掌握等价类、边界值、因果图、场景法、正交实验的基本概念能手写常见功能的测试用例。编程基础LeetCode高频题至少刷100道重点复习哈希表、双指针、滑动窗口、动态规划、二叉树、贪心。计算机基础操作系统、计算机网络、数据结构、数据库的常规考点要过一遍。业务思维把自己常用的App当作练习对象每天挑一个功能写一份测试计划或者排查方案。工具链熟悉Linux基础命令、SQL常用操作、Postman或Apifox做接口测试、Charles或Fiddler抓包、一个自动化测试框架比如pytest或Selenium。7.3 笔试结束不等于万事大吉把答案整理成自己的武器库笔试结束后不管结果如何我建议都趁热打铁做一件事把每一道还记得住的题整理进自己的“秋招题目库”。不用做得多精美但要把题目描述、你的答案、正确答案、错误原因分类记下来。我自己的题库后来逐渐积累成了一本用来复习二面、三面的重要材料因为很多面试官出的题其实就源自这些笔试中的考点。最后再说一个我个人的体会技术测试岗的校招笔试本质上是在找“既有工程师思维、又有用户同理心”的人。代码可以突击算法可以题海战术但那种“看到一个问题就本能地想它的边界条件、异常分支、用户影响”的思维习惯需要靠平时持续的练习来沉淀。这套卷子当然不完美但它在选人这件事上还是挺有一套的。