腾讯音乐秋招技术测试岗笔试复盘：用例设计与编程细节全解析

刚交卷出来的时候我心里其实有点没底。不是怕不会做而是腾讯音乐这套技术测试岗的笔试题跟市面上大多数刷题平台上的测试岗题目有挺大区别它考得非常“具体”具体到你得真了解音乐App在真实场景下会出什么幺蛾子。我准备了大半个月的八股文和算法题反而在用例设计那道大题上犹豫了最久。趁着记忆还热乎把这场2023年腾讯音乐秋招技术测试岗第二批笔试的完整复盘整理出来给后面要考测试开发岗、测试工程师岗的朋友一个参考。这篇文章不会只丢题目和答案我会把每道题背后的考察逻辑、我当时为什么这么答、以及复盘后觉得哪里还可以答得更好都讲清楚希望能帮你绕过一些我踩过的坑。1. 题型布局这批笔试试卷到底考了什么先说整体感受。整张试卷120分钟题量不算特别大但覆盖面非常广大致分为四个板块选择题、用例设计题、编程题和一道偏业务理解的主观题。跟我之前做的其他互联网公司测试岗笔试相比腾讯音乐的这套题有几个明显特点一是选择题特别喜欢结合具体技术场景来出不是单纯背概念二是用例设计题和音乐播放业务强绑定完全没有给你一套通用电商系统让你去设计三是编程题难度适中但边界条件特别容易踩坑。1.1 硬核选择题计网、操作系统、数据库、Python/Java基础选择题大概有20道左右整体难度中等偏上没有白送分的题。计算机网络的考点非常正统TCP三次握手、HTTP状态码、DNS解析流程都考了但出题方式不是让你选“TCP三次握手是几次”而是给定一个典型的请求链路让你判断某一步出现的异常最可能是哪个协议层导致的。操作系统这边进程线程区别、死锁产生的四个必要条件、虚拟内存和分页机制都有涉及。有一道题我印象很深问的是多个线程同时读写一个共享变量使用GIL的Python环境下是否还需要加锁。这道题其实在考GIL的局限性很多人只知道Python有GIL就以为线程安全了实际上GIL只能保证单个字节码的安全不能保证复合操作的原子性所以该加锁还是得加。数据库考了索引失效的几种典型场景、事务隔离级别、一道简单的SQL编写题。这里有个规律测试岗的数据库题目通常不会出特别复杂的多表联查或存储过程但“索引什么时候失效”基本上是必考因为测试同学在排查慢查询问题时这是最基础的判断能力。SQL那题也不难就是查某个时间段的播放记录并统计次数用GROUP BY加HAVING就能搞定。语言基础部分Python和Java各占了一半。Python考了装饰器、列表推导式、深拷贝浅拷贝Java考了HashMap的底层原理、String不可变性、异常处理机制。给我的感觉是考察的深度不需要你读过源码那么深但你必须能说清楚“在什么场景下选择什么数据结构或语法特性”这类带有一定工程判断的问题。1.2 用例设计题音乐App特有场景的考察这道大题是我觉得整个笔试中最能拉开差距的题目。题目大意是QQ音乐近期上线了一个新功能用户可以在歌曲播放页对单曲进行“踩”操作踩过的歌曲在以后每日推荐中不会出现。让你针对这个功能设计完整的测试用例。看到这道题的时候我就明白这不是普通的“登录功能测试用例设计”它考察的是你对一个具体业务模块的理解深度。需要覆盖的点很多权限控制登录/未登录/会员/非会员、重复踩/取消踩、踩过之后推荐流是否真的生效、网络异常时的表现、性能表现、不同端的交互一致性等等。我当时大概写了20多条用例但复盘后发现还是漏了一些细节这个在后面的章节里我详细拆开讲。1.3 编程题不是难题但处处是细节编程题一共两道一道简单一道中等。第一道是字符串处理类的题目大意是给定一个只包含字母的字符串要求按照字母出现的频率降序排列频率相同则按字典序升序。这题用Python的Counter加sorted可以一行核心逻辑写完但容易挂在一个细节上如果频率相同按字典序升序那么sorted的key不能只写lambda x: freq[x]必须写成lambda x: (-freq[x], x)。第二道题稍微有点绕考的是队列或栈的应用题目背景是模拟一个音乐播放器的“下一首”顺序数组表示播放列表但要求实现一种特定规则的轮转和删除逻辑。说实话这题跟LeetCode上某些中等题很像关键是读懂题目的时间。我大概花了10分钟理解题意确认了特殊规则之后才动手写代码量不大大概30行就能搞定但读题不清很容易写偏。1.4 附加题/主观题对测试思维的真实考验最后一题是主观题说是附加题但我觉得对面试筛选的影响很大。题目给了一个线上事故的描述某个版本发布后部分用户反馈“下载歌曲后文件损坏无法播放”需要你分析可能的原因并给出排查思路。这题没有标准答案考的是你的问题定位能力和工程经验。能想到的方向非常多下载协议异常、文件完整性校验缺失、存储服务异常、客户端解压逻辑有bug、不同网络环境下文件传输被截断、CDN缓存脏数据等等。我当时的答法是按“前端客户端、中间链路、后端存储”三层来拆每一层列出可能原因和对应的排查手段最后又补了一个“如何设计监控和告警来提前发现这类问题”的思路。这种题目答得好不好很大程度上取决于你平时有没有真的去处理过线上问题或者至少看过完整的线上事故复盘。2. 用例设计题深度复盘为什么我的20多条用例还是不够全我觉得很多人的问题不是不知道测试用例设计方法而是不知道把方法落到具体业务场景里。拿这道“踩”功能来说等价类、边界值、场景法都能用上但难点在于怎么把音乐App的业务属性融合进去。老实说我笔试交卷的时候觉得答得还不错选择题里我给自己估分还挺高但复盘完这道用例设计题才发现自己漏掉的都是跟“真实业务状态”强相关的场景。2.1 一个“播放器状态”被我完全忽略了我当时设计用例时主要围绕功能逻辑在写登录后踩歌曲、踩完再取消、重复踩同一首、踩完去每日推荐验证。这套路看起来没毛病但实际上漏最严重的一类场景是播放器处于不同业务状态时的表现。比如歌曲正在播放中用户在播放页点了踩那么播放器应该继续播放还是立刻切歌我复盘后觉得正常产品逻辑应该是“继续播放但后续推荐不再出现该歌曲”同时页面上的踩状态需要即时更新。但如果你不把“播放中、暂停中、播放结束、缓冲中、歌词页全屏状态”这些播放器状态作为测试条件列出来这个用例设计就是不完整的。另外还有一个状态是歌单加载状态。如果用户正在加载一个歌单还没加载完就点踩会不会出现数据竞态客户端展示的踩状态和后端记录的踩状态会不会出现短暂不一致这些场景在面试官的评分标准里大概率都是加分项但我笔试时完全没想到往这个方向写。建议后面备考的同学在设计用例时把“当前客户端处于什么状态”作为一个基础维度跟正常流程做笛卡尔积式组合。2.2 从覆盖维度反推评分点比埋头写用例更有效做题的时候最容易犯的错是埋头写用例写完一条想下一条结果写到一半发现前后重复或者维度分配严重失衡。复盘后我重新梳理了一下这道题想得高分至少要从九个维度来拆功能流程维度首次踩、取消踩、重复踩、踩了再取消再踩、不同入口进入踩操作权限维度未登录状态、已登录普通用户、会员用户、游客模式、登录态过期数据状态维度踩的歌曲存在/不存在、歌曲下架/变灰、歌手不可用、版权变更导致歌曲状态变化推荐逻辑维度踩后当日推荐是否生效、次日推荐是否生效、歌单广场是否受影响、其他端是否同步网络异常维度弱网下点踩、断网后点踩、请求超时重试、Wi-Fi和4G切换并发/数据一致性维度多端同时登录、同一账号在不同设备上操作、服务端与客户端状态不一致交互体验维度踩的图标状态变化、Toast提示、动效、无障碍模式性能维度在低端机上点踩的响应时间、连续快速点踩是否卡顿兼容性维度Android/iOS不同版本、平板与手机、不同分辨率下的展示如果我在笔试时能先花两分钟把维度框架列出来再往里面填具体用例至少能比当时多写出10条高质量用例整体结构也会更有条理。这是一个策略问题不是能力问题。考场上最怕的不是你不会而是没有系统化组织答案的意识想到什么写什么最后东一榔头西一棒子看上去写了二十几条实际覆盖度很差。2.3 一个容易翻车的细节预期结果不能写得太抽象我在笔试写用例时犯了一个特别具体的错误——预期结果写得太抽象。比如我写“用户踩成功后该歌曲不再出现在每日推荐中”这句话看起来没毛病但严格来说它不完整。“不再出现”是一个模糊描述应该写成“踩成功后24小时内该歌曲从每日推荐歌单中移除且刷新页面后仍然不出现次日推荐列表生成时排除该歌曲”。预期结果越具体才越能体现你的测试设计能力也让面试官一眼看出你不是在堆用例而是真的想过这个功能上线之后怎么验证效果。还有一个很多人会忽视的地方对“踩”的算法逻辑我们不能只测功能表现还要考虑推荐系统的状态变化是否可回滚。比如用户误踩了一首歌取消踩之后推荐里多久能恢复这首歌这不是一个纯前端交互问题它涉及推荐系统的重新计算逻辑。把这个场景写出来能明显看出你具备跨模块的测试思维而这是高级测试工程师和初级测试工程师的分水岭。3. 编程题里必须钉死的几个细节字符串处理与边界条件编程题这块在技术测试岗的笔试里通常不会考到LeetCode hard级别但恰恰是这种“不难的题”更容易因为一些细节翻车。这场笔试的两道题我复盘下来每个都有至少两到三个细节值得专门拿出来说。3.1 第一题排序的稳定性必须自己控制第一题是典型的字符串频率排序题。输入一个只包含小写字母的字符串要求按字母出现次数从高到低输出如果出现次数一样按字母本身升序。核心代码大概是这样from collections import Counter def frequency_sort(s: str) - str: counter Counter(s) sorted_chars sorted(counter.items(), keylambda x: (-x[1], x[0])) return .join(ch * cnt for ch, cnt in sorted_chars)这里关键就在sorted的key这个位置。如果你只写keylambda x: x[1]那么次数相同的字母会保持它们在Counter中的原始顺序而Counter的原始顺序是第一次出现的顺序不是字典序。实测下来平台给出的测试用例往往会把“频率相同按字典序升序”作为隐藏用例你看起来代码跑通了一两个示例一提交就挂在隐藏用例上非常冤。另外一个小坑是输出格式。题目要求的是“按顺序输出字母每个字母出现几次就输出几次”不是输出“字母:次数”的统计结果。我有一些朋友之前做过类似的题习惯性返回了统计字典结果完全不对题。考场上把这2分钟花在重新读题上很有必要。3.2 第二题与其硬套算法不如先画状态图第二题的题目描述很长放到LeetCode上属于阅读理解题。大意模拟一个播放器的队列每次从队首拿一首歌播放播放完根据规则要么放回队尾要么从队列中移除循环直到队列为空。实际上就是把一个队列操作包装成了音乐播放器场景。我当时的选择是用collections.deque来模拟。因为deque在两端操作的复杂度都是O(1)比用list的pop(0)在数据量大的时候快很多。这里有个很容易被忽略的性能细节如果笔试数据量给到10^5级别你用list模拟队列pop(0)是O(n)整个算法就变成O(n²)直接超时。虽然看起来题目简单但用错数据结构也能让你的代码挂在超时用例上。我复盘后觉得这类题型的解题顺序应该是先把题目里的规则用状态图画出来画完再去写代码。因为队列题最容易出错的地方是“规则判断的先后顺序”比如当前歌曲播放完之后是先判断是否达到移除条件还是先判断是否重新入队这个顺序如果搞错了代码跑起来就完全不对。画状态图能帮你把规则梳理清楚比抱着题目硬写要稳得多。3.3 笔试环境下的调试与提交策略还有一个特别真实的经验教训牛客网这种笔试环境IDE的调试能力跟本地IDE天差地别。本地PyCharm能断点、能看变量线上笔试环境可能只有最简单的print输出。这种情况下我总结了几个实用策略先保证示例测例能过再补边界测试。用print打中间变量来观察deque的变化情况确认规则顺序正确后再提交。边界测试不要只测空输入还要测“队列只有一个元素”和“队列只有两个元素”的情况。很多队列类型的玩法在元素少时行为很特殊容易从边界上漏掉。学会在代码里直接写一个测试用例列表跑一遍批量验证。比如构造一个长度为3的播放列表手动推导出期望的输出序列对比运行结果。这样能避免一次一次手动输入样例的麻烦。这道题实际上没有考到多高深的算法更考的是你在有限环境里对数据结构的掌握以及用工程手段做验证的意识。测试岗的笔试考编程本质上就是想看你能不能写健壮的代码而“健壮”这个词往往就体现在边界条件和数据结构选型里。4. 选择题背后的知识盲区计网和操作系统最容易翻车的地方选择题部分整体来说没有刻意出偏题怪题但复习时如果不注意场景化理解很容易掉进坑里。这里挑几类典型的题目展开说说也帮后面备考的同学划定一个复习重点。4.1 TCP握手与HTTP状态码不是背了就能答对计网部分的两道题让我意识到单背知识点是不够的。比如有一道题大概是问“用户访问一个资源时收到503最可能的原因是什么”选项里有服务器过载、请求路径错误、客户端请求语法错误、资源永久迁移。很多同学如果只背过状态码含义会把503选成“服务器过载”但严格来说503表示服务器暂时无法处理请求可能过载也可能在维护中而504网关超时经常被混淆。这道题提醒我们不能只记数字还要理解状态码对应的实际工程场景。TCP相关的题也是类似。题目描述的场景是客户端不断向服务端发送请求发现某些请求的响应速度明显变慢问可能是哪个机制导致的。答案是一道关于TCP拥塞控制的选择题具体选项涉及慢启动、拥塞避免、快速重传和滑动窗口。单纯的背概念没法答好这种题你需要理解拥塞窗口在链路变差时是怎么收缩的以及收缩之后对上层的表现是什么。我的建议是备考计网时不能只看书要结合抓包工具或者线上报障的经历来复习。你不需要成为网络专家但你必须知道TCP握手失败、连接被重置、超时重传这些在网络层表现各是什么因为测试排查问题时这些就是最常用的线索。4.2 进程与线程、内存管理的高频考法操作系统的选择题里进程和线程的区别是常客。腾讯音乐这套题没有直接问概念而是给了一段“多线程下载同一文件各自写入不同分片最后合并”的场景问这个设计主要利用了进程或线程的哪些特性。这类题本质上是考察“线程共享进程内存空间”这一特点因为只有线程能直接访问同一进程内的共享变量进程之间是相互隔离的。内存管理考的则是虚拟内存和分页。有一道题提到一个进程多次访问32KB的数据但页面大小是4KB问最多会产生多少次缺页中断。这种题其实就是算数32KB除以4KB等于8次。但如果对“缺页”概念不熟悉很容易被绕进去。建议复习时把操作系统里这些经典计算题都过一遍题目本身不难纯属知识盲区的问题。4.3 数据库索引与SQL测试岗必考但往往一错一大片数据库题目大概是整套选择题里最贴近日常测试工作的。有一道题考的是索引失效场景选项是对索引列使用函数、使用LIKE模糊匹配以通配符开头、索引列参与运算、WHERE条件中对索引列进行隐式类型转换。这些都是典型的索引失效场景正确答案是“以上全部”。但考试中作为一个单选题出现就得选择描述最准确或者题目要求选“不能”导致索引失效的那一个。这类题目的坑在于索引失效的知识点非常多有些是80%场景下会触发的有些是特定条件下才出现的。复习时不要死记硬背要理解索引的底层数据结构——B树为什么在“对列使用函数”时不走索引是因为函数改变了列值的原始有序性。SQL题本身不难考的是按时间范围统计播放次数。但有一类SQL题目很容易翻车那就是“查询结果中只显示播放次数大于5的歌曲”。很多同学会在WHERE后面写COUNT(*)5但这在SQL语法上是不合法的聚合函数的条件应该写在HAVING里。这个点几乎每次笔试都能见到属于典型的送命题。我在考场上做完这题还特意检查了一遍确认自己写在HAVING里才交卷。5. 除了刷题这批笔试真正在筛什么如果你只是把笔试当成一次知识测验那复习方向很容易走偏。我在备考这段时间和交卷复盘后最深的感受是技术测试岗的笔试不只考你会不会做题还在考你“有没有测试思维”和“是不是一个工程上靠谱的人”。这两个东西听起来虚但在题目设计里却能实实在在地反映出来。5.1 测试思维与产品理解的权重远超预期从用例设计题和最后那道线上事故分析题来看腾讯音乐笔试对“测试思维”的考察权重相当高。所谓测试思维是一种“把系统当作一个整体来质疑和验证”的思维习惯。它不是只关心功能能不能跑通而是会主动去思考网络断了会怎样、数据异常会怎样、用户手速很快会怎样、两台设备同时操作会怎样。这些思考方式光靠刷题刷不出来更多来自平时在项目、实习、或自己玩技术Demo时积累的“业务状态意识”。我复盘时发现我的用例设计题答案里“推荐流是否会更新”这个维度占了很大篇幅这其实说明我潜意识里仍然是站在功能验证视角而没有站在“用户真实使用场景”视角。真实的每日推荐是服务端算好的结果缓存你踩一脚算法不可能立刻为你去重新计算一遍推荐列表它可能是定时任务或者下次请求时生效。如果没有这层产品理解你设计的用例就缺失了“何时生效”这一块。这不是测试方法能解决的是你对这个业务有没有想透的问题。5.2 时间分配120分钟怎么排兵布阵整张试卷120分钟我个人的时间分配是选择题25分钟编程题45分钟用例设计题30分钟主观题15分钟最后剩下5分钟检查。复盘下来我觉得这个分配还算合理但有一个教训不要在选择题上死磕。我记得有一道关于Python GIL的题我其实拿不准反复纠结了差不多5分钟最后选了B。如果把时间花在后面的用例设计题上至少还能多补两三条用例。后来的建议是遇到拿不准的选择题先选一个你认为最可能的答案并标记出来然后果断跳过。笔试的时间成本是非常高的你在一道两分题上多花5分钟就可能让你在大题上少拿5分。至于编程题如果30分钟内没想出来就应该立刻换一种思路或者先做后面的题不要在一棵树上吊死。对于用例设计题最划算的时间分配是花2分钟列维度框架15分钟填充用例剩下时间用来补“异常场景”。因为用例设计题是按点给分的多写出一条合理场景就多一分所以后面这些“补漏”的时间效率极高。我建议你在平时练习时就有意识地训练这套节奏不要指望考场上有超常发挥。5.3 准备下一批笔试的几点实操建议根据这次笔试的体验如果让我重新准备一次秋招技术测试岗的笔试我会做这几件事刷题之外专门做“场景题训练”。每天挑一个身边的App功能比如说外卖App的退款功能、短视频App的评论功能、音乐App的歌单功能逼自己用九个维度列一遍测试用例。这个过程能极大提升你对业务场景的敏感度。把计算机网络和操作系统的知识“场景化”。不复述概念而是每天看一个线上Bug排查的帖子分析它可能是哪一层的问题。这种训练虽然没有标准答案但比背题库有用得多。编程题复习时每道题强制自己补测至少3个边界用例。这件事不能偷懒因为笔试环境里没有完善的IDE辅助你只能靠自己的边界意识来发现问题。训练时把边界用例写进注释里考场上就能形成条件反射。秋招笔试并不是只筛“谁刷的题多”它也在筛“谁在真实的工程场景里更敏锐”。这一点越早想明白你后面面试阶段的胜算越大。复盘完这套题我最大的收获反而不是具体知识点而是看清了自己在“业务场景测试”上的短板。如果你现在也在准备技术测试岗的笔试建议别只抱着题库刷多拿真实的App功能来练手把自己当作用户也当做一个专门找茬的人。你脑子里的场景越多考场上能写出来的用例就越密。