2023年秋招那阵子测试开发方向的热度一下子被拉起来了。身边不少同学把B站校招测试开发方向的笔试卷当成普通的技术题海来刷LeetCode刷了小三百道结果在测试用例设计题上栽了跟头。我花了一周时间把B站2023校园招聘测试开发方向笔试卷A的各个模块完整复盘了一遍最大的感受是这套卷子真正想筛选的不是“会写代码的人”而是“有质量保障思维的人”。测试开发岗位和纯后端、纯算法岗的笔试题不太一样。它既要求你有扎实的编码能力又要求你懂测试理论、会设计用例、能处理数据、还能理解业务。B站作为视频社区头部产品动手题里有弹幕、投稿、直播这些业务场景的影子。这篇文章我就按试卷A的题型结构从计算机基础、算法题、测试用例设计、SQL实战到临场策略完整拆一遍每个模块都附上拿分思路和容易踩的坑给接下来要投测试开发岗的同学做个参考。1. 这套笔试卷的真实画像到底考什么、想筛什么人拿到试卷先别急着做题。我复盘完之后第一件事就是反推它的出题逻辑。B站这套卷子的题型结构结合近几年校招同学的反馈来看大致分四个模块模块题量与形式分值占比参考考察重点计算机基础15-20道选择题20%-30%网络、操作系统、数据结构、数据库理论算法与编程2-3道代码题30%-40%字符串、数组、动态规划、边界处理测试理论基础与用例设计1-2道简答/设计题20%-30%等价类、边界值、场景法、业务理解SQL与手写代码1-2道题10%-20%多表查询、聚合、窗口函数、优化思路时间一般给90到120分钟。要注意的是算法题通常是平台自动判题用例过了就有分简答题和测试设计题是人工判分逻辑完整性比字数重要。为什么B站会这样设计题量因为测试开发岗位的日常是既要做手工和自动化测试也要自己搭测试平台、写测试工具、做性能压测、跟进线上质量。这决定了你既要能和研发同学在一个技术层面上对话也要有用户视角去发现别人忽略的边界情况。这套卷子里的很多选择题并不难但坑很细。比如TCP和UDP的适用场景、HTTP状态码含义、进程和线程的区别这些在开发岗笔试里可能只是一笔带过但在测试开发岗笔试里会结合具体业务场景反复出现。原因是测试人员在实际工作中经常要判断一个线上问题是网络层、应用层还是配置导致的基础不牢定位问题就像没带地图走迷宫。另外千万别把测试开发卷当成纯开发卷来答。我记得有一年笔试简答题是“设计一个视频投稿功能的测试用例”有同学把整个后端接口逻辑都写了一遍但一条用例都没列这种答案在判卷人眼里是跑题的。测试开发岗的笔试从选择题到编程题都藏着“测试视角”的暗线这个后面详细展开。2. 计算机网络与操作系统送分题里最容易丢分的三个细节点2.1 TCP和UDP的高频问法别只背区别要学会场景迁移选择题和简答题里TCP和UDP的区别几乎是必考的。但B站这套卷子里的问法不会那么直白它倾向于给你一个业务场景让你判断该用哪个协议。举个例子弹幕系统应该用TCP还是UDP我第一次看到这类题时下意识选了UDP理由是弹幕实时性强、允许丢失。但仔细想想B站的弹幕要保证顺序、要可回看、需要精准记录发送人和时间这些要求其实更偏向TCP的可靠性。如果问的是实时直播间的超高并发弹幕流转允许部分弹幕在极端情况下丢弃以换取低延迟那UDP加应用层补偿机制才是合理选择。答案不唯一关键是你要写出分析路径而不是直接给结论。我建议复习时把TCP和UDP的对比表背到反射级别但更重要的是记住一句话TCP牺牲一点速度换可靠性UDP牺牲可靠性换速度和实时性。答题时先给出结论再把业务对可靠性、实时性、顺序性的需求列出来最后落在协议选择上这样逻辑链才是完整的。2.2 HTTP状态码要能说出这个错误背后的排查路径HTTP状态码在测试开发笔试里属于明面送分、实则暗藏杀机的一类题。正常只能写出200、404、500还不够。把301、302、304、400、401、403、502、503、504这几个高频状态码的含义和典型场景背熟。B站业务里最常出现的场景是CDN回源失败。题目可能会问用户播放视频时页面报502 Bad Gateway可能的原因有哪些答题时要写出链路排查思路比如DNS解析是否正常、源站是否宕机、CDN节点有没有超时、回源鉴权是否失败。测试开发日常要写线上问题的排查报告这种题考的就是链路思维。304这个状态码也要搞明白。视频站点的很多静态资源都走浏览器缓存服务器返回304表示“资源未修改继续用缓存”这能大幅降低带宽成本。笔试里可能会问“如何通过响应头判断缓存是否生效”这时候Cache-Control、ETag、Last-Modified这几个字段就要能写出来。2.3 操作系统题进程线程是表面资源竞争才是内核操作系统模块大概率会考进程和线程的区别、死锁的条件、线程同步方式。这些内容如果你只背概念遇到具体场景还是会错。B站视频转码任务属于CPU密集型还是IO密集型这道题的坑在于转码确实要读大量视频文件、写输出文件看起来像IO密集型但真正消耗时间的是编码计算所以更加偏向CPU密集型。答题时最好说一下为什么不要只给一个标签。死锁的四个必要条件——互斥、持有并等待、不可剥夺、循环等待是简答题的高频考点而且要会举例子。笔试里如果让“如何避免死锁”至少能从破坏这四个条件的角度各写一条方案。比如破坏循环等待就是给资源排序破坏持有并等待就是一次性申请所有资源等。3. 算法题AC不是终点边界和复杂度才是分水岭3.1 这套卷子算法题的出题规律B站测试开发方向笔试卷的算法题没有大厂后端岗那么卷但也不是随便写写就能过。复盘下来出题频率最高的是字符串处理、数组操作、双指针、简单动态规划和二叉树遍历。题目有个特点会尽量包装成业务场景读题时别被故事绕晕抽离出核心数据结构就是解题关键。举个典型例子题目可能会这样描述B站收到一批UP主上传的视频切片时间区间请将重叠区间合并返回最终的不重叠区间列表。剥掉外壳这道题就是经典的合并区间。3.2 合并区间从题目到代码的完整推导我给自己定的答题步骤是先明确输入输出再想暴力解法再优化最后补测试用例。暴力解法的时间复杂度是O(n^2)两层循环判断两两区间是否重叠然后把结果合并但这样实现起来容易漏区间。更优的做法是先排序再贪心合并核心思路是把所有区间按起点排序然后顺序遍历如果当前区间的起点小于等于已合并区间的终点说明重叠更新终点为两者最大值否则直接追加到结果列表。def merge_intervals(intervals): if not intervals: return [] intervals.sort(keylambda x: x[0]) merged [intervals[0]] for start, end in intervals[1:]: prev_start, prev_end merged[-1] if start prev_end: merged[-1][1] max(prev_end, end) else: merged.append([start, end]) return merged笔试环境里很多人一上来就写中间逻辑忽略了空列表判断和排序。排序是必须的第一步不排序的话后面所有判断都是错的。还有一点容易被忽略区间是左闭右开还是左右都闭合如果切片区间表示的是持续时间那[1, 2]和[3, 4]就不重叠如果是两个点坐标[1, 2]和[2, 3]在端点处重合是否要合并要看题意。3.3 一个容易丢分的地方测试思维在算法题里的体现这部分是我刷题复盘时最有感触的。B站这套卷子在编程题上给的是标准输入输出自动判题只看用例通过率。很多同学代码逻辑没问题但边界测试用例没想全导致通过率卡在80%上不去。所以我的习惯是写完代码后在草稿纸上把这几个用例过一遍——空输入、单元素输入、完全重叠、部分重叠、完全不相交、逆序输入。这一点和测试开发岗位平时写单测的工作习惯完全是相通的。笔试虽然不要求你写完整的测试代码但你在注释里主动写出“考虑空列表和逆序输入”这样的话人工阅卷时印象分会差很多。3.4 动态规划题别慌先定义状态再写转移方程动态规划在测试开发笔试中出现的概率比后端岗低一些但一旦出现通常是“最长上升子序列”“最大子数组和”“爬楼梯”的变形。我复习时的方法是把常见的DP题型都过一遍但不需要做到能默写重要的是能看懂题、定义出dp数组含义、写出状态转移方程。打个比方很多人觉得DP难其实它就是“把大问题拆成一层层小问题并记住小问题的答案避免重复计算”。笔试里一个小时做三道题遇到DP题如果5分钟内没有状态定义思路我建议直接做下一题不要死磕。这类题分值再高也不值得影响整张卷子的节奏。4. 测试用例设计题这套卷子的隐形重头戏4.1 为什么B站笔试里一定有测试用例设计题说实话测试开发岗位的笔试如果只考代码那和普通开发岗就没什么区别了。测试用例设计题才是真正拉开差距的地方也是B站这种重视业务体验的产品一定会考的部分。这类题的本质是考察你有没有完整的质量保障思维。要能识别一个功能里的正常路径、异常路径、边界状态、安全风险和性能约束还要能分优先级。这不是背几道题就能应付的而是考察你是否习惯性地用用户的视角去想问题。4.2 登录功能测试用例为什么这道题“烂大街”还要考很多同学觉得登录用例都写烂了不会考了结果B站这套卷子里还真有。但它的要求没那么简单不是列功能验证就完了它会问“结合移动端和Web端的不同场景设计测试用例”。所以我复盘时把登录用例整理成一套标准化答案模板按照功能、界面、安全、性能、兼容性、异常恢复六个维度来写功能账号密码正确能登录账号或密码错误有明确提示密码为空、账号为空时不提交边界值密码长度为1个字符、恰好等于规定最大长度、超过最大长度安全性密码传输过程是否加密连续输错5次是否触发验证码或锁定是否支持防SQL注入兼容性主流浏览器Chrome、Safari、FirefoxiOS和Android不同版本性能1000人同时登录时响应时间是否达标异常恢复登录过程中断网恢复网络后是否正确提示重试4.3 B站业务场景题视频投稿功能的测试用例怎么设计比登录更能体现你懂不懂B站的是业务场景题。复盘中我见到的高频题是“设计视频投稿功能的测试用例”和“设计直播开播功能的测试用例”。视频投稿功能我会这样拆基础功能选择文件、拖拽上传、填写标题标签简介、投稿成功进入审核状态文件格式mp4、flv、mov、avi等主流格式是否支持不支持格式是否有明确提示文件大小超过4GB上限时是否有前置提醒未达到最小时长的是否禁止投稿断点续传网络中断后重新上传是重头传还是从断点继续审核流程审核中、审核通过、审核不通过三种状态展示是否正确不通过时是否有原因可查看分P上传多P视频之间能否调整顺序某一P上传失败是否影响其他P保存这类题的加分思路是给测试项加优先级。P0级别的用例是投稿主流程和审核状态流转P1是格式与大小限制P2是兼容性和弱网场景P3是体验优化项。标注优先级会让阅卷人觉得你有测试计划思维而不仅仅是罗列点。4.4 用例设计题的答题技巧把测试方法名字写在前面这点是我复盘后最想强调的。以前我答题时只写具体用例内容后来发现把测试方法名写出来专业性会立刻提升一个档次。比如写“用等价类划分方法将所有输入划分为有效等价类、无效等价类和边界等价类”比直接写“账号填123456”要加分。等价类划分、边界值分析、错误推测法、场景法、判定表这五个测试方法的名称和使用场景必须熟练。B站这套卷子还喜欢在用例设计题最后加一个开放性问题“你会用自动化方式验证哪些用例”这时候不要急着说用什么框架先回答自动化最适合的两种用例形态重复性回归用例和需要大量数据构造的接口用例。再提一句Selenium或pytest也可以但重点是表达你理解自动化的适用边界而不是盲目宣称全部自动化。5. SQL与数据库会写SELECT不等于能过笔试5.1 B站SQL题的问法表结构先设对否则一切白搭SQL题在测试开发笔试里稳占一道偶尔两道。分值不算高但丢了很可惜。B站这套卷子的SQL题一般不会考特别复杂的算法型SQL更多是基础查询、多表关联、聚合统计和窗口函数。有一个坑是题目偶尔不显式给表结构需要你自己根据业务描述推断。比如题目说“请统计近7天每个UP主上传视频的总数”你要先默认有一张upload_record表字段至少包括uploader_id、video_id、upload_time再写SQL。如果直接把表名写错这是硬伤。5.2 一道“用户观看记录统计”SQL题的实战推演假设有表play_log字段为user_id、video_id、play_date、play_duration_sec。请统计每个用户近7天内的总观看时长秒按观看时长倒序输出。基础版SQL可以这样写SELECT user_id, SUM(play_duration_sec) AS total_seconds FROM play_log WHERE play_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY user_id ORDER BY total_seconds DESC;这个写法测试开发岗位笔试中能拿到大部分分数。但有几个细节要注意第一CURDATE()取的是当天0点如果业务口径是“最近7天包含小时分钟”就得用NOW()加INTERVAL 7 DAY。第二如果同一天内一个用户看了多个视频GROUP BY user_id是没问题的因为我们要的是每人总量。第三如果要求人均每日观看时长那还要按user_id, play_date分组后再取平均值这时候子查询反而更清晰。高级一点配套问法可能是“请找出连续3天都有观看记录的用户”。这种题用窗口函数最简单思路是给每个用户按日期排序把日期与行号做差如果差值是同一个值说明这些日期是连续的。WITH play_dates AS ( SELECT DISTINCT user_id, play_date FROM play_log ), numbered AS ( SELECT user_id, play_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY play_date) AS rn FROM play_dates ), groups AS ( SELECT user_id, play_date, DATE_SUB(play_date, INTERVAL rn DAY) AS grp FROM numbered ) SELECT user_id FROM groups GROUP BY user_id, grp HAVING COUNT(*) 3;这道题如果在笔试现场写不出来不丢人但至少要往窗口函数的方向想。阅卷时看到你用ROW_NUMBER()而不是三层子查询去暴力关联印象分是会有区别的。5.3 慢查询优化题三个层面回答覆盖80%的得分点SQL问答题最常见的是“某条慢查询如何优化”。不要只答“加索引”。我把标准答案拆成三个层面索引层面确认where、join、order by涉及字段是否建立合适索引避免在索引列上使用函数导致索引失效避免隐式类型转换SQL语句层面避免select *改写子查询为join大表分页使用延迟关联物理设计层面数据量过大考虑分区表热点数据引入缓存定期归档冷数据最后补一句用EXPLAIN分析执行计划重点看type、key、rows三个字段。这句话可以让阅卷者知道你不只是背方案而是真的排查过慢查询。5.4 SQL题里常见的三个翻车点第一个是NULL处理。统计时长时如果某个用户没有播放记录或者某条记录时长为NULL直接SUM出来的值可能是NULL而不是0要习惯用IFNULL或COALESCE处理。第二个是日期格式。笔试环境里日期可能是字符串比如2023-09-01写条件时不能漏引号。第三个是隐式JOIN。老派写法FROM a, b WHERE a.id b.uid虽然能跑但可读性不如显式JOIN在需要展示专业度的地方尽量用LEFT JOIN或INNER JOIN。6. 临场发挥的实战策略把会的题全部变成有效分6.1 建议的时间分配方案复盘B站这套卷子90分钟和120分钟两种时长都要考虑到。我给自己定的时间分配是这样计算机基础选择题控制在25到30分钟不要在一道题上反复纠结算法题留出35到45分钟三道题里如果有一道10分钟没有思路果断先做下一道测试设计题20到25分钟必须写够维度SQL题15分钟最后留5分钟检查有没有漏题。选择题有个技巧拿不准的题先标记回头再看。因为后面的简答题可能会给你一点联想线索有时候做到测试设计题再回来看网络选择题反而能把之前没想起来的协议细节想起来。6.2 不会做的算法题如何“骗”步骤分代码题没做出来不代表零分。平台判题虽然只看用例但有些试卷会有人工二次查看。哪怕是伪代码把你理解的解题思路写成注释也是有价值的。比如你识别出这是一道动态规划题但状态转移方程没推导出来那就把dp数组定义先写出来。这个动作至少能证明你的思路不是完全跑偏。还有一种情况题目要求输出结果你实在不会最优解那就写一个暴力解法。暴力解虽然用例通过率可能只有一半但这半部分分数是实在的。我见过太多同学因为觉得暴力解不体面干脆空着不写结果白白丢分。在考场上能得分的方式就是好方式。6.3 一个容易被忽略的加分细节答案里的“测试开发岗位感”这是我复盘完整张卷子后最想提醒的一点。同样是写代码题普通开发岗考生的答案往往止步于AC而测试开发岗的候选人如果能在代码下方多写一段“测试用例”备注整个答案的观感会完全不同。比如合并区间那道题代码写完之后补一句“测试用例包括空列表、单个区间、全部重叠、部分重叠、完全不相邻等情况确保边界均被覆盖”这句话看起来轻描淡写但在人工阅卷时传递的信号是这个人写代码时会习惯性考虑边界条件这正是测试开发岗位最需要的素质。SQL题也是一样写完查询后简单解释一句为什么用DISTINCT或GROUP BY而不是只丢一段代码。其实整个笔试卷的答题逻辑是相通的就是把思考过程显性化让阅卷人看见你解决问题的能力路径这比标点符号都标准但思路全藏起来的答案更值钱。我个人的体会是准备B站这类视频平台公司的测试开发笔试与其刷完一本习题集不如把时间花在反复练习“一边写代码一边想测试用例”这个习惯上。如果你平时没有这个习惯刷题时容易陷入LeetCode式的“AC万岁”思维那到了测试用例设计题和SQL业务题上还是会露馅。这套笔试卷看着是四五个模块其实主线就一条你有没有系统性的质量保障意识。我复盘这套卷子最值的地方不是记住了多少道题而是搞明白了这个岗位的筛选标尺。接下来准备笔面试你可以围绕这把标尺去准备效率会高很多。