2023年腾讯音乐春招测试岗第一批笔试,我完整走了一遍。当时投的是测开方向的校招岗位,收到笔试链接之后大概有一周准备时间,说实话压力不小。腾讯音乐的笔试在牛客网上进行,限时120分钟,题量适中,但考察范围很广,从数据结构、计算机网络、Linux命令到SQL、测试用例设计、编程题都有涉及,和单纯刷LeetCode的思路完全不一样,更强调测试思维和工程落地能力。这篇内容我拖了很久才整理出来,今天把整个笔试的考点、思路和复盘经验一次性讲透,想冲大厂测试岗的朋友可以直接当备考路线参考。
1. 腾讯音乐测试岗笔试的底层逻辑与整体布局
1.1 考试形式与时间分配
先说整体感受。腾讯音乐2023年春招测试岗第一批笔试,线上进行,时间120分钟,题目分三块:客观选择题、简答/设计题、编程题。客观题大概20道左右,覆盖数据结构、算法、计算机网络、操作系统、Linux、数据库和软件测试基础;简答题一般1-2道,重点是测试用例设计,偶尔会问自动化测试框架选型;编程题2-3道,难度从Easy到Medium,个别年份会出现偏难的数据结构题,但整体不会到竞赛级别。
我当时的答题顺序是:先花40分钟做选择题,再花20分钟写测试用例设计题,剩下的60分钟全部留给编程题。这个顺序比较稳妥,选择题里有不少基础送分题,快速拿稳;用例设计题是测试岗的核心竞争力,得分性价比很高;编程题虽然分值最高,但一旦卡住容易心态崩,放到后面做能让前半场手感热起来。
注意:牛客网的笔试系统支持本地IDE编译再粘贴提交,但有个坑——代码题通常要求从标准输入读取,不写输入输出处理直接提交会整体判错。平时练习就要养成写
input()或sys.stdin.read()的习惯,别到考场才手忙脚乱。
1.2 测试岗笔试的考察逻辑
很多人在准备测试岗笔试时有个误区:以为难度肯定比开发岗低,于是疯狂刷LeetCode,忽略了测试理论。实际上大厂测试岗的笔试逻辑完全不一样,他们不指望你成为一个算法竞赛选手,而是要你证明你有“工程判断力”——遇到一个需求知道怎么拆解、怎么设计测试策略、怎么用代码快速验证。
腾讯音乐这批笔试题有个明显的特点是:选择题里大量出现“某个测试场景中,下列哪项测试优先级最高”这类问题,这种题没有绝对正确答案,但背后考察的是你对测试金字塔(单元测试、接口测试、UI测试的投入比例)和风险控制的理解。另外Linux、数据库、网络是测试岗的基础三件套,笔试中约30%的客观题都围绕这三块展开,和Web端、App端测试的实际工作场景高度相关。
2. 核心考点拆解:从测试理论到开发基础
2.1 测试用例设计:不是让你背概念
腾讯音乐笔试的简答题基本离不开测试用例设计,我当时遇到的大意是:为“QQ音乐搜索歌曲功能”设计测试用例,要求从功能、性能、兼容性、安全性几个维度展开。这种题没有标准答案,但得分差距非常大。
我建议按这个框架来写:首先明确被测对象的核心流程,比如输入关键词、点击搜索、展示结果列表、点击结果播放;然后按正向用例、反向用例、边界用例分类;最后再扩展异常场景。以搜索功能为例:
- 功能测试:正常关键词搜索、语音输入搜索、历史搜索记录、搜索为空、搜索词含空格或特殊字符、搜索结果精确匹配与模糊匹配、点击搜索结果跳转播放、搜索热词推荐是否正常
- 边界测试:搜索词长度为1个字符、搜索词达到最大长度上限、连续快速多次点击搜索按钮、清空搜索框后再次搜索
- 性能测试:弱网环境下搜索结果返回时间、大量用户同时搜索时的响应时间、搜索结果图片懒加载是否卡顿
- 兼容性测试:不同手机品牌和操作系统版本、不同分辨率屏幕下结果展示是否错位
- 安全测试:搜索内容包含恶意脚本时是否被转义、用户搜索记录是否加密存储、搜索结果是否过滤违规内容
写用例设计题时还有个技巧:一定要给出优先级分级(P0/P1/P2),说明哪些用例必须覆盖、哪些可以延后。这能向面试官传递出你有风险思维,而不是机械地罗列测试点。我当时就写了“P0用例保障核心链路可用,P1用例保障主流程体验,P2用例作为兼容性覆盖”,后来复盘的时候觉得这个写法应该加分不少。
2.2 Linux命令与Shell:直接上手的那种
选择题里Linux的占比不低,尤其是日志分析、进程管理、文本处理这几类命令。腾讯音乐的题目风格不是“下列哪个命令用于查看文件末尾内容”这种简单送分题,而更像“线上日志文件server.log中统计访问量最高的Top10 IP”该怎么用命令实现。
这类问题考察的核心是grep、awk、sort、uniq、tail的组合使用。以“统计Top10 IP”为例,完整命令是:
awk '{print $1}' server.log | sort | uniq -c | sort -rn | head -10注意几个细节:sort默认按字典序排序,所以先用sort把相同IP聚合;uniq -c统计重复次数后再次排序要用sort -rn,即按数字逆序;最后head -10取前十条。这种命令在笔试中经常以“输出结果中每一列分别代表什么”的形式提问,你一定要清楚第1列是出现次数,第2列是IP地址。
另外高频命令还有:tail -f跟踪日志、top查看进程CPU和内存占用、netstat -tunlp查看端口占用、ps -ef | grep查找进程、chmod和chown修改权限和属主、find和grep组合查找文件内容。笔试中经常给一个场景让你判断哪条命令能实现目标,这几个命令务必牢记。
2.3 计算机网络与数据库基础
网络部分重点集中在HTTP协议、TCP/IP、DNS解析和HTTPS握手。腾讯音乐毕竟做音乐流媒体和在线直播,对网络传输质量比较敏感,所以问了HTTP和HTTPS的区别、HTTP常用状态码的含义、TCP三次握手和四次挥手的过程。其中有个选择题印象深刻:分别是“DNS解析使用的是TCP还是UDP协议”,答案是DNS查询通常使用UDP 53端口,但在区域传输或响应超过512字节时使用TCP。这种细节题光靠背是不行的,得理解网络协议在不同场景下的设计取舍。
数据库部分主要考察SQL编写和索引优化。笔试里不会让你写特别复杂的多表关联,更常见的是单表查询、分组聚合、排序过滤、去重统计。比如常见的题目类型:一张歌曲播放记录表play_record(字段包括user_id、song_id、play_time),统计每首歌的播放次数并排序。答案:
SELECT song_id, COUNT(*) AS play_cnt FROM play_record GROUP BY song_id ORDER BY play_cnt DESC;还可以考察HAVING和WHERE的区别:WHERE在分组前过滤,HAVING在分组后过滤。以及LEFT JOIN和INNER JOIN的结果行数差异,这些都是选择题的热门考点。
2.4 编程基础与Python
腾讯音乐测试岗笔试的编程题支持C++、Java、Python、Go等主流语言,我个人强烈建议用Python提交,因为同样的逻辑Python写起来更短,笔试时间紧张时能省不少书写和调试时间。
编程题一般有两道:一道是暴力或模拟,一道是稍带技巧的算法题。我当时抽到的第一题是“字符串去重并按字典序排序”,第二题是“给定一个数组,找出和为目标值的两个数的索引”。这些都是经典题,LeetCode第一题和类似题目的变形版,难度不大,但要注意边界条件,比如数组为空、目标值不存在、数组中存在重复值时怎么处理。
实操建议:笔试前一定要用牛客网的在线编程环境练习输入输出格式,尤其是Python的
input()读取多行、sys.stdin.readline()和sys.stdin.read()的使用区别。遇到需要处理多行输入时,我习惯直接用sys.stdin.read().split()一次性把全部数据读进来再按索引取值,避免逐行读取时的格式问题。
3. 自动化测试与持续集成方向的高频考点
3.1 pytest框架与接口自动化
作为一个测试岗笔试,自动化测试相关的内容必然会涉及,但奇怪的是笔试中不会让你现场写一个完整的测试框架,而是通过选择题来考察你是否理解框架的核心机制。比如pytest中fixture的作用域、conftest.py的目录层级关系、参数化测试的使用场景、断言失败后如何处理等。
pytest有几个核心机制值得重点关注:
- fixture:用于提供测试前置条件,比如初始化数据库连接、创建临时文件、登录状态复用。作用域有function、class、module、session,笔试常考“哪个作用域的fixture可以被整个测试会话共享”,答案是session。
- parametrize:参数化测试,把多组输入数据一次性传入测试函数,类似如下代码:
import pytest @pytest.mark.parametrize("a,b,expected", [ (1, 2, 3), (0, 0, 0), (-1, 1, 0), (100, 200, 300), ]) def test_add(a, b, expected): assert a + b == expected- conftest.py:pytest会自动发现当前目录及其子目录下的conftest.py并加载里面的fixture,常用于定义全局的登录态或数据库清理逻辑。
接口自动化方面,笔试中常问requests库的常见方法、如何从JSON响应中提取断言字段、如何使用pytest+requests搭建一个完整的接口测试框架。我建议准备一个最小可用的模板:
import requests import pytest BASE_URL = "https://api.example.com" def test_search_song(): resp = requests.get(f"{BASE_URL}/search", params={"keyword": "晴天", "limit": 10}) assert resp.status_code == 200 data = resp.json() assert data["code"] == 0 assert len(data["data"]["songs"]) > 0这个模板虽然简单,但覆盖了接口测试的核心要素:添加测试名称、发送请求、断言状态码和业务返回码、断言数据内容是否合理。笔试问“接口自动化测试的断言应该包含哪些方面”,就可以答:HTTP状态码、业务状态码、关键字段值、响应时间、数据格式。
3.2 Appium移动端测试与模拟器环境
腾讯音乐的客户端包括Android和iOS端,所以移动端测试的知识点在笔试中也会出现。Appium是最高频的考点,考察点集中在:Appium的四大组件(Appium Server、Appium Client、Desired Capabilities、Session)、元素定位方式、和Native App与Web App的自动化差异。
一个典型的Appium脚本流程是这样的:
from appium import webdriver desired_caps = { "platformName": "Android", "platformVersion": "12.0", "deviceName": "emulator-5554", "appPackage": "com.tencent.qqmusic", "appActivity": ".activity.MainActivity", "noReset": True } driver = webdriver.Remote("http://localhost:4723/wd/hub", desired_caps) driver.implicitly_wait(10) driver.find_element_by_id("com.tencent.qqmusic:id/search_edit").send_keys("周杰伦") driver.quit()笔试中常问的“Desired Capabilities里noReset有什么用”——答案是控制测试结束时是否重置应用状态。如果设为True,可以跳过登录等前置操作,但测试环境的一致性会被破坏,容易产生脏数据;设为False则每次从头开始,用例更稳定,但耗时更长。这个取舍题在笔试中出现的频率挺高,建议理解底层的原因,而不是死记硬背。
3.3 Jenkins与持续集成流程
持续集成(CI)是测试工程化的重要一环,笔试中偶尔会问Jenkins在测试流程中的位置和作用。考察方式是“下面的流程中,测试环节应该插入在哪一步”。完整的CI流程一般是:代码提交 → 触发Jenkins任务 → 静态代码扫描 → 单元测试 → 构建 → 部署到测试环境 → 自动化测试(接口/UI)→ 生成测试报告 → 发布通知。
笔试中还会问“自动化测试在CI中的最佳实践”,这里面有个关键点是:CI中的自动化测试必须是稳定、快速、可重复的,如果测试用例在执行过程中经常出现偶发失败(flaky tests),会让CI流水线的可信度大打折扣。答案包括:只跑冒烟测试集、测试用例必须无状态、失败用例要有日志和截图等。
4. 笔试中的高频编程题与SQL实战场
4.1 字符串与数组类题目的通用套路
腾讯音乐笔试的编程题很少出动态规划和图论这种重量级考点,更偏向字符串处理和数组操作,这与测试岗位日常写脚本验证数据的场景是匹配的。以下两类题几乎年年出现,建议熟悉解题模板。
第一类:字符串处理题。比如“给定一个仅包含大小写字母和数字的字符串,将大写字母转换为小写字母,删除所有数字,并反转字符串”。思路很简单:先遍历字符,判断类型并转换,再用切片反转。Python的实现尤为简洁:
def transform(s: str) -> str: result = [] for ch in s: if ch.isdigit(): continue result.append(ch.lower()) return ''.join(result[::-1])但要注意边界:ch.isalnum()会区分中英文字符,笔试中如果明确说明字符串只包含ASCII字符,直接用str.isalpha()更保险,因为isalpha()对中文也会返回True,可能会导致不预期的结果。这类细节很容易成为隐藏扣分点。
第二类:数组与滑动窗口。比如“给定一个整数数组和一个目标值,找出数组中连续子数组和大于等于目标值的最短长度”。这种题可以用双指针滑动窗口解决,时间复杂度O(n):
def min_subarray_len(target: int, nums) -> int: n = len(nums) left = 0 cur_sum = 0 min_len = float('inf') for right in range(n): cur_sum += nums[right] while cur_sum >= target: min_len = min(min_len, right - left + 1) cur_sum -= nums[left] left += 1 return min_len if min_len != float('inf') else 0笔试中不要求你把代码优化到极致,但至少要把暴力解O(n^2)优化到O(n)级别的滑动窗口解法,这种代码能力在简历写“熟练掌握Python”的同学中已经算不错的水平了。
4.2 SQL窗口函数:测试数据对比的利器
除了基础的分组聚合之外,腾讯音乐笔试偶尔会考到窗口函数,典型的题目是“查询每个用户最近一次播放的歌曲ID”。这个用普通GROUP BY不太好搞,但用窗口函数就很顺手:
SELECT user_id, song_id, play_time FROM ( SELECT user_id, song_id, play_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY play_time DESC) AS rn FROM play_record ) t WHERE rn = 1;窗口函数之所以在测试岗笔试中越来越常见,是因为做数据分析型测试时经常需要对比同一分组内不同记录的差异,比如找出连续登录天数、统计每个接口在最近一周的调用量Top N等。建议把ROW_NUMBER()、RANK()、DENSE_RANK()的区别搞清楚:ROW_NUMBER给每个分组内的行一个唯一递增编号,RANK在有并列时会跳过编号(比如1、1、3),DENSE_RANK则不跳过(1、1、2)。这是笔试选择题的高频陷阱。
4.3 测试数据构造与断言逻辑题
有一类编程题比较特殊:题目描述的是一个函数接口,要求你实现该函数,但同时会考察输出是否符合测试断言。比如“实现一个函数,接收一个包含重复元素的列表,返回去重后的列表,且保持元素首次出现顺序”。这类题的核心思想就是让你模拟一个测试驱动开发的流程:先根据题意推测输入输出样例,再实现函数。
我建议这类题先写几个自测用例,再用代码实现。比如以输入[3, 1, 2, 1, 3, 4]为例,期待输出[3, 1, 2, 4]。实现方式很多,Python最简:
def dedupe(lst): seen = set() res = [] for x in lst: if x not in seen: seen.add(x) res.append(x) return res笔试判题系统通常只看最终输出是否正确,但如果你在本地调试时养成“先写断言再实现”的习惯,到了实际工作中写自动化测试时就会非常顺手。
5. 可复用的笔试经验与避坑指南
5.1 时间分配:做题顺序比刷题量更重要
我见过不少同学备考大厂测试岗笔试时,疯狂刷了300道LeetCode,结果在牛客网笔试时栽在了前面的选择题上。大厂测试岗笔试的选择题看似简单,但涵盖了Linux命令、网络协议、数据库索引、测试设计等交叉知识点,如果平时只刷算法题,拿到这些选择题会非常被动。
我的经验是:质量大于数量,且必须按“先卷面分,再难度分”的顺序答题。具体操作方式:先快速过一遍选择题,把有把握的题全部拿下;遇到卡壳超过2分钟的题立刻标记跳过;选择题结束后,马上写简答/用例设计题,这是测试岗的专属送分题,写详细一点就能得分;最后全神贯注做编程题,把前面跳过的选择题再回头补。
时间分配上,我建议:选择题40分钟、简答题20分钟、编程题60分钟,但这只是参考,具体要结合试卷难度调整。如果选择题中有大量完全没见过的知识点,不要恋战,立刻止损切到编程题,因为编程题一题的分值可能抵得上三四道选择题。
5.2 测试用例设计题的加分写法
笔试的测试用例设计题,很多人只能写出一堆零散的测试点,然后没有重点地全部罗列出来。但结合我自己后来实际做测试时的经验,这种写法并不能展示你的专业度。这里分享一个直接可以“抄作业”的模板:
- 被测对象描述:明确说明测试对象是什么,输入、处理、输出是什么。
- 测试环境说明:列出操作系统、浏览器版本、网络环境、设备型号。
- 功能测试用例表:用例编号、测试步骤、输入数据、预期结果、优先级。
- 边界与异常用例:空值、超长、特殊字符、并发操作、权限不足、网络中断。
- 非功能测试:性能(接口响应时间、并发用户数)、兼容性(不同浏览器/设备)、安全(越权访问、恶意输入)。
用表格呈现比大段文字清晰得多。比如:
| 用例编号 | 测试步骤 | 输入数据 | 预期结果 | 优先级 |
|---|---|---|---|---|
| TC001 | 输入正确关键词并点击搜索 | “晴天” | 展示歌曲列表,按相关度排序 | P0 |
| TC002 | 输入不存在的关键词 | “zzzzzz” | 展示“未找到相关结果”的空状态 | P1 |
| TC003 | 输入100个字符的超长关键词 | 100个“a” | 搜索框限制输入长度或正常展示结果 | P1 |
| TC004 | 弱网环境下搜索 | 网络限速至100kbps | 页面出现加载中状态,不崩溃,结果返回后正常展示 | P0 |
这种表格写法不但让阅卷人一眼看到你有多少测试思维,还能在面试时直接拿来做自我介绍的项目亮点,一举两得。
5.3 在线笔试的硬件与网络环境注意事项
说实话,笔试翻车往往不是题目本身难,而是环境出问题。分享几个自己踩过的坑和观察到的教训:
第一,提前1小时检查电脑和网络。牛客网笔试系统对浏览器有要求,建议提前下载最新版Chrome,禁用所有广告拦截插件,否则考试过程中弹窗或者代码编辑器加载异常,非常影响心态。我当时的做法是,在考试前48小时先在牛客网进行一次模拟笔试,确认摄像头、麦克风、屏幕分享这些功能都正常。
第二,关闭所有无关软件。笔试过程中如果检测到切屏或者后台运行其他软件,可能会触发警戒机制。即使不判定作弊,也会在系统里留下记录,影响面试评价。建议把QQ、微信、企业微信、邮件客户端全部退出,专注于考试页面。
第三,准备好本地IDE的同时,提前适应在线编辑器。牛客网的在线编程环境虽然功能上够用,但和本地IDE相比差不少,没有自动补全和报错提示时会严重影响编码速度。平时练习就应该直接在牛客网的在线环境里写代码,不要依赖本地IDE。
第四,考试前模拟一遍输入输出的处理。不同公司的笔试系统对输入格式要求不太一样,有的喜欢单组输入,有的用多组测试数据,有的在输入中带有空行。如果你在牛客网做真题时发现题目描述里写了“多组数据输入”,就可以直接用sys.stdin.read().split()一把梭。
5.4 常见问题排查技巧实录
笔试过程中如果发现代码怎么提交都只有部分用例通过,可能问题不在算法逻辑,而在一些隐蔽的工程细节上。我把自己在练习和考试中遇到的问题整理成了一张速查表:
| 问题现象 | 常见原因 | 排查思路 |
|---|---|---|
| 小数据正确,大数据超时 | 算法复杂度太高 | 检查是否有嵌套循环、是否可以用哈希表/滑动窗口优化 |
| 本地运行正确,提交全错 | 输入输出格式不符 | 重新阅读题目输入格式,看是否需要多组输入、读入字符串还是整数 |
| 有浮点数比较的题目无法通过 | 精度问题 | 使用math.isclose()或转换为整数进行计算 |
| Python递归深度超限 | 递归层数过大 | 改用迭代或增大递归深度sys.setrecursionlimit() |
| 列表索引越界 | 边界条件未处理 | 在循环之前增加数组长度判断和空值判断 |
| 明明提交了代码但显示未作答 | 点击提交后没有确认 | 牛客网部分试卷需要手动点一次“保存并提交”,注意检查 |
5.5 笔试与面试的衔接:笔试题目如何转化为面试谈资
很多人把笔试和面试割裂看待,笔试通过后就进下一环节,不再回顾。但我的建议是:笔试结束后的两天内,趁记忆还清晰,立刻把所有题目重新整理一遍,尤其是那些当时不确定答案的题,去网上查阅资料、补充原理,把这些内容做成一份“笔试复盘笔记”。这份笔记可以在面试时直接引出技术话题,比如:
- 如果笔试里考了测试用例设计题,面试时可以说“我之前在腾讯音乐笔试中设计过搜索功能的测试用例,当时我按照功能优先级拆分,最关注的是弱网和并发场景,因为音乐类App对播放体验要求很高”
- 如果笔试里考了SQL窗口函数,面试时可以主动说“最近遇到一个查询每个用户最近播放歌曲的需求,我用窗口函数实现,比传统自连接效率高很多”
把笔试题目转化为面试谈资,既能展示你的学习能力和总结能力,又能避免面试时被问到“你做过什么项目”时无话可说。
写在最后,关于这次笔试想分享的心得
从备考到完成笔试,我最大的感触是:测试岗的笔试和开发岗完全是两条线。开发岗看中你能不能写出高性能的算法,测试岗则看中你能不能从需求中拆解出风险、设计出有效验证方案、快速搭建可用的测试工具。这决定了备考方向不能只刷算法题,而要多去思考“这个功能上线后最可能在哪里出问题”“这条数据在异常情况下会不会让整个系统崩掉”。
另外想和大家说的是,大厂笔试虽然有难度,但考点范围其实很固定。只要你把Linux基础、计算机网络、数据库SQL、测试用例设计、Python语法和常见自动化测试框架的知识体系打牢,再把牛客网上历年大厂测试岗真题刷两三套,通过笔试的概率是非常高的。腾讯音乐这批笔试只是测试职业路上的第一道门槛,保持稳定心态、规范答题习惯,后面的面试更看重你解决问题的思路和沟通表达力。准备充分的人,运气不会太差。