每年校招季测试开发岗位的简历投递量都在涨而笔试就是第一道硬门槛。我翻了下手上这套哔哩哔哩2023校园招聘测试开发方向笔试卷B发现它非常能代表主流互联网公司测开笔试的命题思路代码题、测试思维题、业务场景题混着出表面上考技术实际上考的是“你会不会像测试工程师一样思考”。不管你是正在准备校招的应届生还是想从功能测试转测开的在职同学这套卷子的拆解思路都值得认真看一遍。我这两年帮人改简历、做模拟面试见过太多在笔试环节翻车的案例。最可惜的不是不会写代码而是明明技术栈都会却因为不懂测开笔试的答题逻辑把用例设计题答成功能测试点把开放题答成八股文背诵现场最后分数和预期差一大截。这篇文章就从这套B卷出发把题型、答题套路、避坑经验一次性讲透你可以直接拿着去模拟练习。1. 试卷结构与命题逻辑先看懂出题人想考什么1.1 题型分布与分值权重这套笔试卷B的整体结构大体上分成五个模块选择题涵盖计算机网络、操作系统、数据库、Python/Java基础、编程题2道左右、测试用例设计题1道大题、自动化/测试框架相关简答题以及一道业务场景开放题。每个模块的分值权重不是平均的从往年笔试情况看编程题和用例设计题往往是大头合计能占到一半以上。这块有一个很多同学容易忽视的点选择题虽然分值不高但覆盖的知识面非常广而且往往埋着“一票否决”性质的细节题。比如TCP三次握手的状态迁移、HTTP状态码含义、Python可变对象与不可变对象的区别、SQL中where和having的执行顺序这些题单独看都不难但组合在一起就是用来筛掉基础不扎实的人。所以我的建议是选择题虽然叫“小分”但绝对不能战略性放弃它决定了你能不能进入下一轮面试。分值结构的另一层含义是出题人默认你具备基本的计算机通识笔试不是为了考倒你而是为了判断你在真实工作场景里能不能独立解决问题。B站业务的特点是视频、弹幕、直播、UP主内容生态所以笔试题里凡是涉及业务场景的几乎都长在UGC内容链路附近。这一点在后面几个模块里体现得特别明显。1.2 B站业务特点如何渗透进笔试题很多同学做这套卷子的时候会有一个很直观的感受题目描述里动不动就出现“用户上传视频”“弹幕去重”“直播低延迟”“评论区排序”这些词。这不是出题人为了贴业务而贴业务而是测开岗位天然要求你理解业务。一个不懂弹幕实时流转逻辑的测试开发是做不好弹幕功能测试和性能测试的。比如说编程题里出现“设计一个数据结构支持高频写入和按时间范围读取”如果不结合业务你可能就当成普通算法题硬做但如果联想到B站的弹幕池、评论流、直播聊天室你就能自然地想到用“队列哈希索引”或者“环形缓冲区”来解代码写出来更有说服力也更容易命中出题人藏在题目里的隐含条件。再比如用例设计题常见考法是“请为视频播放页设计测试用例”。这种题如果你只写“点开能播放、能暂停、能拖动进度条”那基本只能拿辛苦分。出题人真正想看的是你有没有考虑到弱网环境下的播放策略、不同清晰度之间的切换、双语字幕的显示、弹幕开关与透明度设置、播放器在前后台切换时的状态保持以及视频上报埋点是否触发。这些点背后都是真实的B站业务场景考官一看就知道你是真的看过、用过这个产品还是只在背模板。所以备考逻辑要反过来不是先刷题再了解业务而是先理解业务再带着业务视角去刷题。这套B卷的命题方向其实就是给所有测开候选人提了个醒技术是底座业务理解才是你和其他候选人拉开差距的地方。2. 编程题实战弹幕去重与缓存设计的完整拆解2.1 基于业务场景的算法题怎么下手编程题是这套卷子里最硬核的部分也是大部分人最紧张的部分。我做了一个小范围统计身边参加过同批次笔试的朋友反馈常考的编程题方向集中在字符串处理、哈希表应用、Top K问题、LRU缓存、简单动态规划。这些题本身不超纲但题面会穿一层业务外衣。举个例子有一道很典型的题给定一条视频下的所有弹幕内容要求过滤掉完全相同的重复弹幕同时保留第一次出现的那条最后按出现顺序输出。这题看起来简单实际上考了两点一是你能不能识别出“完全去重且保持顺序”这个需求二是你会不会用合适的数据结构。很多人第一反应是set但set会丢顺序正确做法是用有序字典Python里的dict天然维护插入顺序或者“setlist”的组合。def dedup_barrage(barrage_list): seen set() result [] for item in barrage_list: if item not in seen: seen.add(item) result.append(item) return result如果题目再加一个限制比如“内存不能装下全量弹幕”那就需要引入外部排序或者分片哈希的思路。这时候你要能写出“分片归并”的大致流程把单机内存压力分摊掉。笔试不要求你一次性写出工业级实现但至少要让阅卷人看到你有海量数据的意识。另一类高频题是“设计一个支持get和put的LRU缓存”。这个题在业务里的映射非常直接B站首页推荐流、视频元信息缓存、评论区热榜全是缓存场景。手写LRU的时候关键点不是用现成的OrderedDict而是要能讲清楚底层为什么是“哈希表双向链表”为什么get和put的时间复杂度都是O(1)。我在笔试模拟里经常看到有人直接调库但被追问原理时就卡壳这种代码即使过了笔试面试也容易露馅。2.2 笔试判题系统的隐形规则编程题除了算法本身还有一堆跟“判题系统”打交道的隐性规则这些规则不会写在题目里但决定了你能AC还是挂零。首先是输入输出格式有些平台用标准输入输出有些平台要求你实现一个类的方法比如Solution类里的某个函数。如果没看清要求你辛辛苦苦写的main函数可能在某些平台直接被判编译错误。其次是边界条件。我在给候选人做辅导时经常强调一个习惯写代码前先花30秒想清楚边界。字符串为空怎么办数组长度为1怎么办数值溢出了怎么办。测开笔试的编程题判题时用例往往会在边界值附近设陷阱比如空字符串、全重复输入、超长字符串。很多人算法主体写对了但就是边界没处理导致最后只过了一半用例非常可惜。还有一个隐形规则是复杂度意识。笔试平台对超时是零容忍的你写一个O(n^2)的解法如果数据量到10^5基本会卡在运行超时上。但如果你在代码注释里写明“当前解法时间复杂度O(n)空间复杂度O(n)满足数据量要求”即使代码有小瑕疵阅卷人如果是人工阅卷也会认为你有复杂度分析能力。这个习惯在面试手撕代码时同样加分。最后提醒一句代码风格真的会被看。变量命名用a、b、c还是user_list、dedup_set函数是拆成小函数还是全堆在main里这些细节直接影响阅卷人对你工程素养的判断。测开岗位以后要写自动化框架、维护测试平台代码可读性差是会坑队友的考官自然会额外在意这一点。3. 测试用例设计题拉开分差的硬骨头3.1 从“登录功能”看用例设计的完整套路测试用例设计题是测开笔试和纯开发笔试最大的区别也是最能体现“测试思维”的题型。B站这套B卷比较有代表性的是一道“请为登录功能设计测试用例”的题目看起来人畜无害但想拿高分一点都不简单。低分答案长这样输入正确的用户名和密码能登录输入错误的不能登录。高分答案会按维度拆开覆盖比如功能维度要覆盖正常登录、错误密码、用户不存在、账号被锁定、密码连续错误多次的提示接口维度要覆盖登录接口的入参校验、异常返回、token有效期安全维度要覆盖SQL注入、暴力破解、密码传输是否加密兼容性维度要覆盖不同浏览器、不同移动端系统版本体验维度要覆盖弱网、断网重试、输入框长度限制。这样一套写下来用例设计的广度和深度就拉开了。我建议你养成一个习惯凡是设计用例先画一个简单的分层框架功能、接口、兼容、安全、性能、体验六个维度先列出来再往里面填具体场景。这样做的好处是你不容易漏项而且阅卷人扫一眼就知道你有体系化思维。测试用例的表单一般建议写成“用例编号 前置条件 操作步骤 预期结果”的格式这个格式本身就是职业习惯的体现。登录功能还有一个隐藏考点验证码。很多同学只会写“输入正确验证码能通过”但进阶的测开会思考验证码是否有时效性是否区分大小写连续刷新验证码是否会导致旧验证码失效验证码接口是否有频率限制防刷。这些细节全部都是真实线上会出现的问题写进用例里你的答案就不再是“学生腔”了。3.2 等价类、边界值与场景法的组合应用用例设计不止是“列点”背后是一套成熟的测试设计方法。校招笔试里最常用的三个方法是等价类划分、边界值分析和场景法。等价类划分的核心思想是把输入域分成若干个子集每个子集里的数据对测试结果来说是等价的从每个子集里取一个代表值就能覆盖这一类情况。比如登录账号长度限制是6到20位那6位、20位、5位、21位就是边界而中间随便取一个“abcdef”就属于有效等价类。边界值分析的道理更简单大量线上bug都出在边界的临界点上。写用例时刚好等于边界值、稍微小于边界值、稍微大于边界值这三类情况必须全部覆盖。比如视频标题限制50个字符你就得测49、50、51三个长度别觉得这很死板实际执行起来能拦下无数“差一个字符就崩了”的bug。场景法则是从用户实际操作路径出发把功能放到完整业务流程里去测。比如测B站的投稿功能不只是测上传视频这一个点而是从用户点击投稿、选择文件、填写标题简介、设置分区、选择封面、等待审核、审核通过后前台展示这一整条链路都要覆盖。场景法的价值在于它能发现单点测试发现不了的交互问题比如某个字段在上一步输入非法值后下一步按钮置灰了这种跨步骤的状态流转只有场景法能覆盖到。我在辅导时经常跟候选人说用例设计题的答案不是越多越好而是越结构化越好。与其写20条没有分类的碎片用例不如写15条分好类的、有层级的用例。因为阅卷人看的是你的思维模型而不是你的“工作量”。4. 自动化与测试框架笔试中的工程素养考察4.1 接口自动化分层的标准答案自动化测试是测开岗位的核心职责之一所以笔试里必然会涉及。最常见的是“接口自动化”方向的题比如让你设计一个接口自动化测试方案的架构或者问你pytest框架里fixture和conftest.py的用法。接口自动化的标准答案不在于你背了多少框架API而在于你有没有分层思维。成熟的接口自动化方案一般分三层用例层负责编写和维护测试用例API层负责封装接口的请求地址、请求头、参数和断言配置层负责管理环境地址、数据库连接、账号数据等公共配置。这样分层的好处是当接口地址变更时只需要修改API层当测试数据变化时只需要调整配置层用例层不用大改。# conftest.py 中定义一个全局token fixture import pytest import requests pytest.fixture(scopesession) def auth_token(): resp requests.post( https://api.example.com/login, json{username: test_user, password: test_pass} ) assert resp.status_code 200 return resp.json()[token]这段代码虽然简单但涵盖了一个高频考点fixture的scope。session级别的fixture在整场测试中只执行一次适合登录这种一次性操作function级别则会每个用例都执行一次适合需要隔离数据的场景。很多人笔试时知道fixture怎么用但说不清scope的差异这就是八股文背得不深的表现。接口自动化的另一个考点是数据驱动。常见的做法是使用pytest的parametrize装饰器把测试数据放在测试函数外的参数列表里或者从YAML/Excel里读取。数据驱动的优势是测试数据和测试逻辑分离新增一条用例只需要加数据不需要改代码。笔试中如果让你写出读Excel的用例数据解析代码核心就是用openpyxl读取行再通过parametrize注入。4.2 UI自动化定位、等待与异常处理的答题要点UI自动化在部分公司校招笔试里出现频率略低于接口自动化但B站这种重前端交互的产品UI自动化依然是测开的重要技能。笔试常考的点有两个元素定位和等待策略。元素定位的核心不是背八大定位方式而是知道优先级。实际项目里id和name经常动态变化完全依赖id定位往往导致脚本频繁失效。我一般建议优先使用稳定的业务属性比如data-testid其次是相对路径和文本定位最后才考虑绝对路径xpath。还有一点值得写进答案定位不到元素时不要只检查定位表达式还要检查元素是否在iframe里是否在shadow DOM里是否因为页面懒加载还没出现在DOM树中。等待策略就是一个典型的“看着简单实则常错”的考点。强制等待就是time.sleep写起来最省事但效率最低。隐式等待是轮询DOM判断元素是否存在但它的致命问题是一旦设置成全局整个session内所有查找元素的操作都会被拖慢。显式等待则是针对指定元素轮询直到满足某个条件。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC wait WebDriverWait(driver, 10) element wait.until( EC.element_to_be_clickable((By.ID, submit-btn)) )笔试里如果要求你“解决元素点击无效的问题”你至少要能答出三步先检查是否被遮挡、是否在iframe中、是否处于不可点击状态然后考虑用显式等待等待可点击状态最后才是用JavaScript去执行点击。一上来就写element.click()不判断状态是典型的测试新人写法。UI自动化题里还常出现“如何处理alert弹窗”和“如何切换多个窗口”这些都属于基础操作关键是别只写一两个字的术语要能写清楚处理流程。比如alert要先switch_to.alert再调用accept()或dismiss()多窗口要先获取window_handles列表再切换switch_to.window。这些小步骤看起来零碎但恰恰是笔试机考里最容易白屏的题。5. 数据库、Linux与网络测开绕不开的地基5.1 SQL统计题的常见套路测试开发日常工作中验证数据、造测试数据、核对线上问题都离不开SQL。所以笔试题里大概率会有一道SQL题。B站这套B卷里的SQL题方向通常是用户行为统计类的比如“统计每部视频的播放次数”“统计近7天活跃UP主数”“查询被举报最多的弹幕内容”这些场景都很B站。SQL题的答题套路核心是先看清楚是“分组统计”还是“关联查询”是“一张表”还是“多张表”。常见的坑有统计时需要去重用DISTINCT分组后用HAVING而不是WHERE做条件过滤关联查询要注意INNER JOIN和LEFT JOIN的区别。我刷到过一道比较经典的题查询播放量排名前10的视频但要求输出视频标题和UP主昵称。这就涉及三张表关联要先求出排名再关联用户表和视频表。SELECT v.title, u.nickname, v.play_count FROM video v JOIN user u ON v.uploader_id u.id ORDER BY v.play_count DESC LIMIT 10;这里有一个容易被忽略的点如果播放量的统计口径是“去重后的用户播放数”那就不能直接用video表里的play_count字段而要先对播放记录表按video_id分组用COUNT(DISTINCT user_id)算出播放量再排序。出题人非常喜欢在这种“口径”上设坑你写SQL之前一定要先确认统计维度。另外SQL写的规范程度也会被阅卷人注意到。关键字大小写一致、聚合函数和分组字段写法清晰、每行缩进整洁这些细节是职业习惯的体现。很多候选人写出的SQL语法没错但缩进乱成一团阅卷感受会差很多。你是在给一个团队写代码不是在给自己写草稿。5.2 Linux排障与网络分析的实用命令测开工作中有一个高频场景线上出了bug开发说是环境问题测试说要先定位最后谁拿Linux命令和日志说话。所以笔试里关于Linux的题目通常不是让你背命令选项而是给你一个真实场景考你怎么排障。最经典的是“服务接口响应缓慢如何定位”。一个完整的回答链路是先用top看系统负载和CPU占用再用free -h看内存是否吃紧然后df -h看磁盘空间是否被打满接着用tail -f或grep去日志里搜错误关键字最后用curl -w看接口耗时或者用tcpdump看网络包是否异常。这个链路里面每一步都有明确的排查目的而不是随机敲命令碰运气。日志分析也是测开笔试的高频考点。比如给你一段nginx访问日志让你统计访问量最高的IP或者统计某个接口在最近一小时的错误请求数。这种题其实就是“Linux命令 文本处理”的组合核心工具是grep、awk、sort、uniq的组合使用。awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这行命令的逻辑是先用awk取出IP列排序后让相同IP相邻再用uniq -c统计次数最后按次数倒序取前10。这是测开必须刻在脑子里的命令管道笔试出现了直接套用就能拿分。网络基础题通常围绕HTTP协议比如状态码的含义、GET和POST的区别、Cookie和Session的关系、HTTPS的握手过程。这里要注意别只会背定义要能结合测开场景说。比如定位一个“前端页面能打开但接口返回401”的问题你得能推断出是token失效或未携带然后去抓包确认请求头而不是傻乎乎地清缓存重启。6. 开放题、时间分配与备考复盘6.1 开放题的回答框架试卷最后通常有一道开放题比如“如何看待测试开发这个岗位”“如果让你测试一个推荐系统你会怎么设计”“假设B站上线了直播带货功能测试方案怎么设计”。这类题没有标准答案但得分差距往往非常大。低分回答是喊口号比如“我会认真测试保证产品质量”。高分回答一定是有框架、有策略的。拿“测试推荐系统”来说你至少应该拆成四个层面数据层测试样本数据是否准确、特征计算是否正确、策略层测试推荐结果是否符合预期策略、冷启动是否有兜底、接口层测试推荐接口的入参出参、性能、限流、体验层测试推荐位展示是否正常、刷新后是否有重复内容、用户反馈是否进入下一轮迭代。开放题的回答框架推荐用“总分总 分层拆解”的方式。第一段先表明你理解这个问题的核心挑战比如推荐系统最大的挑战是“测试数据量大、预期结果多解、线上效果无法用单一断言判断”。中间部分按测试层次一个个拆每个层次说明测什么、怎么测、用什么工具。最后简单收一下线上质效保障不能只靠功能测试需要建立监控和回放机制。这套框架不用背用多了自然熟练。还有一个容易被忽略的点开放题往往没有严格字数限制但写得越少越容易显得没想法。我建议至少写300字以上最好能画出一个简单的测试方案结构。内容质量固然重要写的内容量本身也反映了你的思考投入度。6.2 笔试后的复盘与知识体系搭建笔试结束不等于这件事就完了。我见过太多人考完就对答案、看分数然后就把试卷扔到一边这其实是最大的浪费。一套有代表性的笔试卷是你校准复习方向的绝佳素材。建议考完当天趁记忆还在列一张表把每道题对应的知识点、你的掌握程度、错误原因都记下来。这样做两到三套卷子之后你的薄弱项会非常清晰地浮出来。测开的知识体系我建议按四根柱子去搭编程与算法、测试理论与用例设计、自动化与持续集成、计算机基础网络、数据库、操作系统、Linux。每一根柱子下面再细分小的知识点然后每天抽固定时间刷知识点周末集中做一套完整的模拟卷。这个节奏坚持下去比考前突击一个月有效得多。另外八股文不能只背得能讲出来。笔试只是第一关后面面试一定会深挖你的答案。比如笔试里你写了pytest的fixture面试官就会追问fixture的优缺点以及和setup/teardown的区别。所以备考的时候建议把每个答案都当成“要讲给别人听”来准备自己一个人对着镜子或者用录音软件练一遍效果会好很多。7. 写在后面测开笔试真正考的是什么回到这套哔哩哔哩2023校园招聘测试开发方向笔试卷B你会发现它本质上不是在考“你会不会做题”而是在考“你有没有测试开发的职业思维”。代码题考察的是你的逻辑和实现能力用例设计题考察的是你的细心和产品理解自动化题考察的是你的工程化意识开放题考察的是你对岗位本身的认知深度。这四件事恰恰是测开日常工作中每天都在做的事。我自己当年准备笔试时最大的教训是花了太多时间在刷算法题上忽略了测试用例设计和业务理解。结果算法题答得不错但用例设计题写得又散又浅被面试官反问得有点尴尬。现在回过头看一套合格的测开笔试准备应该是算法、测试理论、自动化框架、计算机基础四线并行再拿业务场景题做串联练习。这套卷子里的题型和方向放到今天依然有很强的参考价值。你完全可以把它当作一份模拟题清单逐个知识点去突破。准备笔试的过程本身就是在为真正的测试开发工作做预演。