网易云音乐测试实习生笔试拆解：从场景题到用例设计

网易2018实习生招聘笔试题回忆与拆解云音乐测试岗到底在考什么参加过2018年网易云音乐测试实习生笔试的人应该都记得那道关于播放器卡顿的题目。当时我在考场上盯着那道题忽然意识到测试实习笔试考的并不是“你记住了多少概念”而是“你敢不敢像一个真正的测试工程师一样拆解一款正在运营的音乐App”。网易云音乐本身是集播放器、社区、歌单、推荐算法于一体的复杂产品测试实习生要面对的笔试题自然不会是简单的“什么是黑盒测试”这类填空题。这篇文章我会结合当年笔试的题型特点、知识点权重和云音乐业务场景把整张卷子拆开揉碎给以后想投测试岗的朋友一个完整的备考参照。网易云音乐的测试笔试题本质上是在用最短的时间筛选“有测试思维的人”。它不要求你背熟所有测试理论但要求你能在具体场景里发现问题、设计用例、给出合理的排查思路。尤其是那些挂着“云音乐”名字的场景题往往就是面试官眼中区分“学过测试”和“能做测试”的分水岭。下面我从出题逻辑、题型分类、业务场景题解法、隐藏考点、备考路线五个方面把这场笔试聊透。1. 当年这道笔试是怎么出题的云音乐测试岗位的考查逻辑1.1 为什么云音乐测试笔试格外看重场景设计能力网易云音乐不是单纯的播放器它有每日推荐、歌单、评论、动态、直播、K歌等一大堆功能模块。一个测试实习生入职后大概率不是只测“播放/暂停”按钮而是会被扔进某个业务组里从需求评审开始跟到版本发布。所以笔试出题人必须排除那些只会背概念的人转而用具体的产品场景来考察候选人的分析能力。以当年最常见的“播放器卡顿”场景题为例题目通常会给你一段描述“用户在4G网络下播放一首320kbps的歌曲出现卡顿请写出你的排查思路。”大多数人第一反应是“提示用户切换网络”但这不是测试工程师该做的事。正确思路应该拆分为先复现、再定位。复现时要区分是偶现还是必现网络环境是弱网还是正常手机型号和系统版本是什么播放的是在线资源还是本地缓存。然后要进一步判断是网络请求超时、音频解码性能不足、内存抖动导致卡顿还是服务端下发的资源链路有问题。这些分析过程比一个标准答案更能反映真实能力。1.2 实习生笔试的三个核心筛选维度网易的测试实习笔试官方没有发布过详细考纲但从当年考生流传出来的题目和我自己的一些经验来看筛选维度可以归纳为三层第一层基础理论是否扎实。知不知道测试分类功能、性能、安全、兼容性、生命周期、用例设计方法、Bug等级划分。这些是必考项但占比通常不会超过40%。第二层工程能力是否入门。会不会Linux基本命令、SQL查询、抓包工具、简单的Python或Java脚本。笔试会通过选择题或编程题来考察。第三层产品思维是否具备。面对一个具体功能能不能跳出“正常流程”去考虑异常场景、边界条件和用户体验。这一层的考察形式就是云音乐相关场景题。有意思的是很多自认为技术很强的同学会挂在第三层。原因很简单他们习惯用“开发视角”去找代码bug而不是用“测试视角”去找产品缺陷。而网易的测试团队在业内出名地重视质量文化和用户反馈笔试自然会把这一点嵌入题目里。2. 从基础题到送命题四类必考题型逐一拆解2.1 选择题和填空题覆盖计算机基础与测试理论这一类是开胃菜目标是过滤掉完全没准备的候选人。常见考点包括操作系统进程与线程区别、死锁条件、内存管理基本概念。计算机网络TCP三次握手、HTTP状态码含义、Get和Post的区别、DNS解析过程。数据结构与算法栈、队列、链表特性基本的排序算法时间复杂度。数据库SQL查询语句select、where、group by、having、order by、索引基本概念。测试理论黑盒白盒测试区别、等价类划分、边界值分析、因果图、场景法、错误推测法。这些题难度不高但范围广。如果你是非科班转行测试可能需要花一到两周把计算机基础过一遍。我个人觉得最有效的复习资料是“软考软件评测师”的基础知识部分虽然内容偏传统但覆盖的考点和网易笔试的重复度相当高。2.2 简答题用测试用例设计题检验业务敏感度简答题可以说是云音乐笔试的“主菜”。典型出题形式有请为网易云音乐的“每日推荐”功能设计测试用例。这种题没有标准答案面试官看的是你能否分层思考。我当时写的是功能层面推荐列表是否正常加载、点击歌曲能否播放、推荐结果是否与用户偏好相关、是否有刷新机制。异常层面网络异常时是否有提示、列表为空时是否有兜底文案、加载中点击重复操作是否会导致崩溃。性能层面列表滑动的帧率、首屏加载时间、图片资源的缓存策略。兼容性层面不同分辨率、不同系统版本的显示效果。安全与权限未登录状态下是否能使用用户点击不感兴趣后是否不再推荐。写完之后我自己都觉得有点啰嗦但后来跟面试官交流他说这题最怕看到只写“播放、暂停、下一曲”这类流程性用例的人。测试用例设计的关键在于“测试意图”和“分层覆盖”而不是把操作步骤写满。2.3 编程题不是考算法而是考写脚本的能力对实习生而言笔试里的编程题不会太难。常见的是实现一个简单的字符串处理、数组去重、二分查找等。但如果你以为这就够了那就错了。更重要的一类是“用代码实现一个冒烟测试脚本”或“写一段Linux命令完成日志过滤”。比如有一份nginx访问日志格式为IP 时间 URL 状态码。请用一条命令统计出访问量最大的前10个IP。这就是典型的工程能力考察。如果你熟悉awk和sort几秒钟就能写出来awk {print $1} access.log | sort | uniq -c | sort -rn | head -10当时我旁边就有人卡在这题上因为他不知道uniq -c是干什么的。说到底测试实习生不是纯开发岗但需要具备快速分析日志、定位问题的能力所以Linux命令和脚本语言至少要熟练一种。建议重点掌握Python和Shell。2.4 附加题/进阶题考察自动化测试与性能测试的基础认知2018年那会儿自动化测试已经很火了笔试题里偶尔会出现“你对Appium了解多少”或“如何设计一套接口自动化测试方案”这种附加题。这不是强制要求但如果你能写出一两点印象分会明显提升。我印象比较深的一道题是如果让你为云音乐的“评论功能”做一个自动化测试你会怎么设计这题其实是对“测试设计能力”的延伸。我当时从UI自动化和接口自动化两个角度分别作答UI层用Appium模拟用户登录、进入歌曲页、输入评论、点击发送、验证提示接口层用Python的requests库构造评论接口的请求校验返回值和数据库落库状态。同时还考虑了测试数据和用例隔离比如是否要每次跑完都清理评论数据以免污染线上环境。这种思路未必完全正确但至少能让面试官看到你具备“测试开发”的雏形意识。3. 云音乐场景题实战播放器、评论、歌单的用例设计思路3.1 播放器模块从状态机角度拆解而不是机械地“点点点”播放器是云音乐的核心笔试场景题几乎绕不开。题目通常要求你为“在线播放”设计测试用例。很多人的第一版答案是点击播放按钮能播放点击暂停按钮能暂停点击下一曲能切换这种答案太扁平化了没有体现播放器的复杂状态。播放器本质是一个状态机至少包含未开始、加载中、播放中、暂停中、缓冲中、播放完成、播放失败。每个状态都需要测试而且状态之间的跳转逻辑更需要测试。所以我建议按照状态转换来设计用例当前状态操作预期状态关注点未开始点击播放加载中是否显示loading是否有超时限制加载中点击暂停未开始是否取消加载任务期间是否可返回播放中断网缓冲中或失败有无提示文案恢复网络后是否续播播放中来电暂停音乐是否暂停挂断后是否恢复缓冲中点击暂停暂停是否停止重试再次播放是否重新缓冲这些用例看似简单但每一个都对应实际开发中容易出现的bug。比如“播放中断网”就涉及播放器SDK的网络状态监听、缓存策略和错误回调不同Android机型可能表现完全不一样。我当时能在笔试里想到这些是因为真的在模拟器上折腾过各种网络场景建议你也亲自动手用Charles或Fiddler模拟弱网和断网观察播放器的行为。3.2 评论功能别忽略UGC内容最核心的三类风险社区是云音乐区别于其他播放器的重要标签。评论功能的测试除了常规的发布、回复、点赞、删除之外更关键的是考察“内容安全”和“数据一致性”。我记得有一道题是“用户发表一条包含敏感词的评论系统会如何处理”这题考查的是对内容审核机制的理解。正确的测试方向包括敏感词被拦截并给出提示还是直接发布后再被删除如果评论在审核状态发布者本人能否看到审核期间的评论是否会计入评论数若审核失败评论是回到草稿箱还是直接消失另一个重要方向是“数据一致性”点赞数、评论数在列表页和详情页是否一致删除一条评论后二级回复是否也被删除网络异常时重复点击发布按钮是否会造成重复评论。这些点如果平时没测过UGC产品很难想到。3.3 歌单功能边界条件和数据同步是重灾区歌单的笔试题目也很有云音乐特色。常见考点包括创建歌单时歌单名称支持多少字符为空或全是空格时怎么办歌单内歌曲数量上限是多少达到上限再添加歌曲时如何提示把歌单分享到社交平台分享链接在无权限访问时展示什么同一个账号在多端登录修改歌单顺序后其他端是否实时同步离线下载场景一首歌在VIP有效期内缓存到本地VIP过期后还能不能继续听这些题其实没有特别高深的技术就是看你知不知道“边界值分析”和“场景法”。比如歌单名称的边界值至少要考虑0个字符、1个字符、恰好最大长度、超过最大长度、包含emoji等。数据同步则要考虑多端同时修改时冲突如何处理。这些都是在真实测试中高频出现的问题笔试出这样的题说明网易是在找“能直接上手做测试”的人。4. 那些年我们一起踩过的坑笔试题里的隐藏考点与避坑指南4.1 你以为在考技术其实在考“定位问题的优先级”笔试里有一类题目表面上是问“请你列出导致App崩溃的所有可能原因”实际上是在看你的排查优先级。如果你一上来就说“内存溢出”“数据库死锁”而忽略了“先确认是否必现”那基本没戏。我当时遇到的一道题是这样的用户反馈“听歌时使用微信语音音乐声音会变小但退出微信后音乐没有恢复”请简述你的排查思路。敏感一点的测试人员应该立刻想到“音频焦点Audio Focus”问题。Android系统里多个应用同时播放音频时需要通过音频焦点来协调但很多国产ROM对音频焦点的处理方式并不标准。正确的排查思路是先识别该问题是否只在特定机型出现是否是系统级audio focus处理逻辑差异是否有第三方音效增强软件介入再确认是客户端未处理焦点丢失回调还是系统bug。如果你直接回答“让用户重启手机”那面试官只能认为你不适合做测试。这种题给我们的启示是平时测App的时候不要只盯着功能逻辑还要关注系统级交互。比如来电、闹钟、低电量、存储空间不足、通知栏响铃这些都属于测试范围。面试题往往不直接点明但考察的就是你有没有这些“环境敏感性”。4.2 网络相关题目不要只会说“网速影响”云音乐是重度依赖网络的产品笔试中网络相关题目几乎必出。但很多人的答案停留在“网络慢导致加载失败”。如果你能多走一步提到“弱网下的用户体验”和“网络切换的处理”就会显得专业很多。比如这样一道题用户在Wi-Fi环境下播放歌曲走出门后变成4G网络请问播放器应该如何表现合理的预期设计是正在播放的歌曲应该继续播放不需要重新加载如果当前歌曲未完成下载后续片段用4G网络加载但需要提示“当前使用流量播放”如果App检测到当前不是Wi-Fi应暂停自动下载高清品质或MV避免消耗用户流量。围绕这些点展开才算抓住了云音乐的网络测试精髓。另外要留意HTTP与HTTPS的区别、缓存策略、超时设置。笔试中可能让你“说出至少三种抓包工具并说明使用场景”这属于基本常识。我的建议是至少熟练使用Charles和Chrome DevTools并了解一下Fiddler。能否抓到手机App的包、能否破解SSL Pinning都是加分项但不要为了炫耀而在笔试里写太深避免踩到合规红线。4.3 常见丢分点用例设计缺少“异常流”我见过很多人写测试用例时写满了“正常流程”“输入歌名搜索点击结果播放验证播放正常”。这其实只覆盖了快乐路径。真正的测试用例设计必须把“异常流”摆在和“正常流”同等重要的位置。拿“搜索歌曲”来说正常流是搜索成功并展示结果。异常流至少包括搜索后无结果应显示什么网络超时应有什么提示输入框为空时点击搜索是否无响应搜索关键词包含特殊字符如%、_时是否会导致SQL注入搜索词过长是否截断清空搜索词后列表是否恢复展示热门推荐。这些点才是面试官希望你写的。所以备考期间训练自己“每个功能必想三个异常场景”的习惯。比如一个登录按钮除了输对账密还要想密码错误、用户不存在、网络异常、重复点击、密码含空格、纯数字密码、未注册手机号等。时间久了你的测试敏感度就会训练出来笔试自然不慌。5. 备考路线与时间分配从理论到实战的进阶策略5.1 针对测试实习生的“四周准备法”如果你从现在开始准备网易云音乐这类公司的测试实习笔试我建议按四周来规划不需要拉太长战线更不需要报什么付费课程。第一周夯实计算机基础与测试理论。每天两小时把数据结构、计算机网络、操作系统、数据库刷一遍。测试理论重点看等价类、边界值、场景法、因果图。不需要刷题海但要确保每个概念都能用口头例子解释。第二周死磕Linux与SQL。测试日常要翻日志、查数据库Linux命令和SQL是基本功。面试会问能用什么命令看进程怎么统计日志中某个关键字出现的次数怎么写一个多表查询这些必须张口就来。建议每天在Linux虚拟机上练习20分钟。第三周主攻移动端测试工具与自动化基础。安装Appium跑通一个简单的自动化脚本了解adb常用命令和Monkey测试。不要求你会写框架但至少要知道自动化用例怎么组织、POM模式是什么、pytest和unittest的区别。这一周能帮你应付笔试里的“附加题”和面试问答。第四周模拟实战。找几款知名的App尝试自己设计测试用例特别是音乐类App直接拿网易云音乐练手。试着把“播放器”“歌单”“评论”“搜索”四个模块的用例都写出来然后对照实际产品功能补充遗漏。有条件的话可以租一台真机配合Charles做弱网测试主动制造网络异常观察App表现并记录成文档。这份文档就是你面试时可以讲的“项目经历”。5.2 笔试之外的加分项如何准备“面试型”提问笔试通过后紧接着是面试。跟笔试不同面试更看重你对一份测试经历的复盘能力。如果你没有任何实习经历就一定要把自己做的练手项目包装得像样。不是让你编造而是把一个简单的“网易云音乐评论接口自动化测试”做成体系测试环境怎么搭、用例怎么设计、断言怎么处理、数据怎么清理、报告怎么生成每一步都要能说出“为什么这么做”。我当时面试官问我的第一个问题是“你做自动化测试时如何解决接口依赖”我讲的是先梳理接口依赖关系有些需要登录的接口用登录态管理有些需要动态参数的接口通过上一个接口的返回数据拼接。同时还要考虑测试环境数据如何初始化如何避免脏数据影响。面试官听完后点了点头接着问“如果登录接口挂了你的自动化用例会不会全挂”我说会所以需要加一个冒烟测试层先判断关键依赖接口是否正常再执行后续用例。这种思路不是从书本上背来的而是你在真正动手做的时候才会发现的。笔试或许不需要写这么深但面试时这类细节非常加分。5.3 关于热词中那些“测试工具”的正确看待方式每次搜索“测试实习生笔试”总会跳出Appium、pytest、Jenkins、Tessy、渗透测试、车载测试等一堆名词。很多同学会焦虑觉得自己没学完。作为过来人我的建议是实习生笔试不是招聘“全能工具人”工具只是载体面试官更看重你的逻辑思维和快速学习能力。Appium会基本操作即可pytest能写用例断言即可Jenkins知道流水线概念即可。真正重要的是你面对一个陌生功能时能不能快速梳理出“测什么、怎么测、出了问题怎么排查”。当然你也不能一问三不知。知道主流工具的定位和适用范围是底线。比如“冒烟测试”不是一种工具而是一个测试阶段指的是每次版本提交后用最短时间验证核心功能是否可用的过程。类似的安全测试、性能测试、兼容性测试这些概念都应该能解释清楚。热词里提到的“设备老化测试全自动执行脚本”听起来很玄乎但本质就是通过自动化脚本定时采集系统性能数据判断设备在长期运行后是否出现卡顿、掉帧、App无响应等问题。这类知识如果你有精力可以作为扩展了解但它们不是笔试核心。写在最后测试实习笔试的底层逻辑其实只有一句话回过头来看2018年网易云音乐测试实习生的笔试题它既没有超纲也没有故意刁难人。它只是把一款真实产品日常测试中会遇到的问题浓缩成一张卷子。出题人并不期待你答出完美答案而是想看到你有条理的分析过程。你不需要背下所有标准答案你需要的是建立一套“发现问题—拆解问题—定位问题—验证问题”的思考链路。如果你接下来要投测试岗请一定记住别把时间浪费在纠结“哪个工具更热门”上而是真正打开一款App从用户角度去“折腾”它。去看你点击播放时发生了什么断网后再恢复时发生了什么评论区里发一条特殊字符时发生了什么。当你有了这种好奇心笔试和面试都只是顺带的事情。