B站游戏测试校招笔试题解析：从用例设计到质量Owner思维

先说个挺有意思的现象：很多想进游戏行业的人，第一目标都是策划、程序、美术这些“热门岗”，游戏测试常常被当成“不行就先试试”的备胎。但真到校招笔试的时候，尤其是像哔哩哔哩这种对内容和体验有执念的公司，一张游戏测试笔试卷能直接把不少人打回原形。我见过太多简历挺漂亮、聊起游戏也头头是道的同学，栽在最基础的用例设计题和bug定位分析上。

这份“哔哩哔哩2020校园招聘游戏测试笔试卷（二）”就是很典型的一套题。它考的不是你玩过多少游戏、段位多高，而是你有没有用工程师的脑子去拆解一个游戏功能、有没有系统性地找出问题的能力。这篇文章我就从这套笔试卷出发，把游戏测试岗位校招笔试背后的考察逻辑、常见题型、答题思路，以及我这些年实际做游戏测试踩过的坑，一次性说清楚。不管你是正准备投递游戏测试岗，还是已经在测试圈边缘试探想转正，这篇都值得认真看完。

1. 这道笔试卷到底在筛什么人

先聊一个很多人没想明白的问题：B站这种公司招游戏测试，笔试到底想筛掉什么人？或者说，它想留下什么人？

1.1 游戏测试不是“玩游戏”那么简单

很多同学对游戏测试的理解就四个字：玩游戏找bug。如果你抱着这种心态去答笔试卷，大概率第一轮就被刷。实际上，游戏测试工程师的核心工作是用一套系统化的方法论去验证游戏“是否符合设计预期”，并且在这个过程中发现设计缺陷、逻辑漏洞、性能瓶颈和体验问题。这里面的关键点不是“玩”，而是“验证”和“发现”。

拿笔试卷里最常见的第一类题目来举例：给一段需求描述，让你找出其中不明确的地方，或者让你针对某个功能设计测试用例。这其实是在考察你跟策划、程序沟通时能不能敏锐地发现需求里的坑。游戏开发里有一句老话：“需求文档里每一个模糊的词，最后都会变成线上事故。”比如“玩家点击按钮后，背包里增加一件装备”这句话，看起来没问题，但仔细想：点击按钮后是立即增加还是弹窗确认后增加？网络延迟怎么处理？背包满了怎么办？获得装备时有没有广播通知？如果是绑定装备呢？这些细节，笔试卷不会直接告诉你“请找茬”，但你的用例设计里有没有覆盖到这些场景，就决定了你能不能被看到。

1.2 B站的考题风格：既考基本功，也考游戏理解

B站的游戏测试笔试卷，说实话在业内算是比较有水平的。它不像某些公司那样出一堆八股文式的计算机网络题，也不像另一些公司那样单纯考逻辑智力题。它的特点是：

• 结合具体游戏场景出题，比如针对FPS、MOBA、卡牌等品类设计测试点
• 考察对游戏系统逻辑的理解，比如经济系统、任务链、排行榜
• 注重测试用例设计的完备性和优先级判断
• 偶尔会穿插一些“如果让你去测一个新功能，你会怎么做”的开放题

这套“笔试卷（二）”延续了这些特点。从考生反馈和我看到的题目回忆来看，它考察的能力模型基本可以分成四层：

1.3 岗位画像：他们要的不是“测试员”，是“质量Owner”

我在游戏行业这些年，越来越明显感觉到一个趋势：测试团队在去边缘化。以前测试就是“程序写完丢给测试，测试测完没问题就上线”，现在稍微像样一点的公司，都会让测试尽早介入需求评审，甚至参与玩法设计讨论。所以笔试卷里那些开放题，表面上是在问“你会怎么做”，实际上是在考察你有没有owner意识——愿不愿意主动去理解业务、去推动问题解决，而不是等着别人把东西丢给你。

B站尤其看重这一点。因为B站的核心用户是非常挑剔的年轻玩家群体，他们可能因为一个UI响应慢了0.1秒就在评论区“开团”。所以B站的游戏测试，不仅要能测出功能bug，还要能站在玩家体验角度提出优化建议。这套逻辑，贯穿了整张笔试卷。

2. 题型深挖：那些隐藏在题目背后的真实考点

这一节我们拉开聊。我综合了能找到的题目回忆和考生反馈，把“哔哩哔哩2020校园招聘游戏测试笔试卷（二）”的题型做一个系统梳理，顺便告诉你每一类题到底在考什么，答题的抓手在哪。

2.1 测试基础与理论题：不是背概念，是看你会不会用

笔试卷的选填部分，通常会出现这类问题：一个bug的优先级和严重级别怎么划分？黑盒测试和白盒测试的区别？回归测试的时机和策略？有些人觉得这些题太基础，纯送分，但实际上失分率很高。

举一个真实翻车案例。我看到过一份考生回忆版题目，大概问的是“一个支付成功但未到账的bug，优先级是什么？”很多人选“紧急”，因为涉及钱。但你仔细想：如果支付平台回调正常、只是客户端展示延迟，这属于严重级别高但优先级不一定最高，因为玩家最终会到账；如果回调根本没触发，那才是真的紧急，需要立刻停服排查。这道题考的，其实是你在压力下能不能冷静区分“严重级别”和“优先级”两个维度。

这类题的答题建议是：

• 别只背ISTQB的定义，要学会结合游戏实际场景解释
• 答题时最好体现分类意识：功能类、性能类、UI类、兼容性类，分别怎么处理
• 涉及优先级判断时，主动引入“影响范围”和“发生频率”两个维度

2.2 用例设计题：笔试里的重量级选手

如果一张游戏测试笔试卷算100分，用例设计题至少占30分以上。B站这张卷子的用例设计题，通常会给一个具体功能描述，让你用等价类、边界值、场景法等方法设计用例。

我记得有一个回忆版的题目大概是：一个任务系统，玩家完成任务后可以获得奖励，奖励通过邮件发放。要求设计测试用例覆盖该功能。看起来简单，但里面藏了很多细节坑。

我从实际测试经验出发，给你拆一份这类题的高分答题框架：

第一层：正常流程覆盖

• 完成任务后邮件是否即时发放
• 邮件标题、正文、附件是否正确
• 邮件是否可以正常领取附件
• 领取后背包中是否增加对应物品

第二层：边界与异常场景

• 背包满格时，附件能否领取
• 邮件过期后奖励是否处理正确
• 完成任务瞬间断网/强杀客户端，重连后是否有补偿
• 同时完成多个任务，邮件发放顺序是否正确
• 领取附件时背包格子刚好剩余0个的情况

第三层：性能与兼容

• 大量邮件同时到达时的客户端表现
• 不同手机分辨率下邮件UI是否正常
• 弱网环境下邮件列表加载是否超时

看出区别了吗？普通玩家看到的是一句话：“完成任务发奖励”。测试工程师看到的是一个完整的系统状态机：任务完成状态、邮件生成逻辑、附件领取流程、背包空间判断、网络异常处理、客户端展示一致性。

笔试答题时别怕写得多。用例设计题本质上是在考察你的思维覆盖度，写得多且有条理，比写得少但所谓“精准”更占优势。但要注意，不是让你把想到的都乱写，而是建议用“正常流-异常流-边界流”的结构来组织答案，这样考官一眼就能看出你的逻辑层次。

2.3 游戏系统逻辑分析题：这里刷掉一大半人

还有一类题特别能拉开差距，就是给一个游戏系统的规则描述，让你分析逻辑漏洞或者异常情况。比如背包系统、抽卡保底机制、排行榜奖励结算等等。

这类题的特点是：表面上是让你分析一个具体的游戏系统，实际上考的是你透过现象看本质的能力。我拿抽卡系统举个例子。假设规则描述是“每10次抽卡必出一次SR或以上品质”，让你分析有哪些情况可能导致玩家实际体验与规则不符。

有经验的测试会先拆解这个规则的关键要素：

• “抽卡”怎么定义？单抽和十连是否都计入次数
• “每10次”的计数周期有没有边界问题，跨天是否清零
• “SR或以上”是否包含UR，公告里是否明确
• 如果玩家在第9次抽到SR，第10次还会保底吗，保底计数是否重置
• 网络异常导致客户端显示抽卡成功但服务器未记录，怎么处理

你看，就这么一个简单规则，拆出来就有十几条测试点。这种分析能力，不是靠玩游戏玩出来的，而是靠对游戏底层机制的理解和对异常情况的敏感度练出来的。

在校招阶段，99%的同学没有实际项目经验，所以这类题在笔试里的区分度极大。能把系统规则拆出层次感的人，说明平时就有思考习惯，是真正脑子里装了“测试思维”的人。

2.4 开放设计题：你是个只会执行的人，还是有owner意识的人

B站笔试卷的最后通常有一道开放题，比如“你觉得B站游戏和腾讯游戏在测试上的侧重点有什么不同”或者“如果让你负责一个新游上线前的测试，你会怎么做”，这种没有标准答案但极其暴露水平。

这类题的核心考察点有两个：第一，你有没有结构化的思路；第二，你有没有自己的观点和思考深度。

“如果让你负责新游上线前的测试”，一个低分答案会是：先功能测试，再性能测试，再兼容性测试，没问题就可以上线了。这个答案的问题在于它只罗列了测试类型，没有任何取舍和优先级判断。

高分答案是怎样的？你要先问自己几个问题：这个游戏是MMO还是休闲单机？是iOS首发还是安卓全渠道？服务器架构撑得住多少人同时在线？有没有涉及到支付和账号绑定？这些问题会直接决定测试方案的形态。

拿我实际经历过的项目来举例，一个修仙题材MMO上线前，我们测试团队做的事情是：

• 第一优先级：核心功能链路，包括创角、新手引导、首充支付、第一场战斗
• 第二优先级：服务器压力测试，模拟高峰时段同时在线，观察宕机临界点
• 第三优先级：兼容性测试，覆盖主流机型和中低端机型的帧率和发热
• 第四优先级：体验和表现层的调优，包括UI误触、引导是否清晰、loading时间

这个优先级排序不是拍脑袋定的。因为对MMO来说，服务器崩了或者核心链路断了就是事故级bug，可以毁掉整个公测；但某些UI按钮位置不协调，顶多被玩家吐槽几天，不值得在资源有限的时候优先处理。

开放题里你只要能体现出“先保什么、后保什么”的判断力，就已经赢过大多数人。

3. 从笔试到Offer：游戏测试面试的隐形考点

笔试过了之后还有面试，这里干脆一起讲了。因为对校招生来说，笔试和面试本质上是一条战线，考察的能力模型是连续的。笔试考你的“纸面能力”，面试考你的“现场能力”和“沟通能力”。

3.1 一条数据链路题能看出你懂不懂游戏

游戏测试面试有一个非常高频的题目变体：一个玩家从点击按钮到看到结果，数据是怎么流转的？以“购买道具”为例：

• 玩家点击购买按钮，客户端发送请求到服务器
• 服务器校验玩家账号状态、货币余额、道具合法性
• 服务器扣款、写入数据库、发放道具
• 服务器返回结果给客户端
• 客户端展示购买成功，更新本地数据

这听起来很简单对吧？但面试官紧接着问：如果第3步和第4步之间，玩家断网了会发生什么？如果服务器扣款成功但数据库写入失败怎么办？如果客户端收到结果但展示失败，玩家实际已经拥有道具，他再次购买会怎样？

这些问题背后，考察的是你有没有真正理解游戏架构中，客户端与服务器、数据库与业务逻辑之间的边界。如果完全没概念，会直接暴露出“你只是在黑盒层面看游戏，没有站在系统层面想过问题”。

准备这一类问题时，我的建议是：先画主流程，再逐个环节追加异常假设。哪怕你的技术背景不强，只要你能说出来“这个环节可能出问题，因为客户端和服务器的状态可能不一致”这种话，面试官就会对你另眼相看。

3.2 面试中的“自我介绍”也要体现测试思维

还有一个很典型的点，很多同学面试开场就输了。常规的自我介绍是“我叫XX，来自XX大学，专业是XX，我性格开朗、做事认真、热爱游戏”。这种介绍在面试官耳朵里等于没有信息量。

有测试思维的自我介绍应该怎么讲？你应该用几句话让面试官知道：

• 你玩过哪些游戏，玩到什么深度（不是展示战绩，而是展示观察力）
• 你在游戏过程中有没有发现过bug，并且描述你是怎么发现、怎么复现的
• 你为了想做游戏测试，做过什么针对性准备

比如你可以说：“我玩某款吃鸡游戏的时候，发现当我在快速开镜再取消的瞬间按换弹，有时会触发角色动作卡死。我当时的反应是马上重复测试了几次，大概有70%概率能复现，后来我录了屏给客服反馈，过了两个版本这个bug修掉了。”就是这么一段话，比你说一百遍“我热爱游戏”都有说服力。

这背后其实传达了一个信号：你天生有测试员的警觉性，并且有闭环思维——发现问题、定位问题、复现问题、推动修复。

3.3 对游戏行业的理解：为什么B站需要你

B站面试还有一个很好玩的问题，会问你“平时看不看B站”“喜欢哪些UP主”。有人觉得这是闲聊，实际上这是在考察你对B站用户生态的理解。游戏测试在B站不只是测出一个bug写个jira就完事，你可能要面对的是：这个bug是否会被用户喷、是否会影响内容创作者的创作意愿、是否会在社区内发酵成大节奏。

所以面试中如果你能提到自己对B站社区氛围的理解，提到“游戏测试某种程度上是在为社区体验守门”——这个高度一出来，你跟其他考生的区分度就非常明显了。

4. 常见丢分点与避坑实录

最后聊聊我在辅导过的同学笔面试过程中，看到的那些高发问题。如果你正在备考，这几个坑千万避开。

4.1 把“写得多”当成“答得好”

前面我说用例设计要尽量写全，但有一个前提：要有结构化思维，而不是流水账。我见过一份试卷，针对一个“登录功能”写了50条用例，但问到他“验证码有效期内的重复提交”这类关键边界点时，反而没有覆盖。

这暴露的问题是：他只是在堆数量，没有按照“等价类+边界值+场景法+错误推测法”的思路去组织。面试官一眼就能看出来这个人是“会背题库”还是“真会设计”。

我的建议是：写用例之前，先在草稿纸上列一下你会用到哪些测试方法，再针对每个方法补充用例点。比如等价类对应正常场景，边界值对应边界场景，错误推测对应异常场景。这样出来的用例，才是层次清晰的。

4.2 忽略“可玩性”和“体验”层面的测试

很多校招生写测试用例，关注点永远在功能正确性上——按钮能不能点、任务能不能完成、奖励能不能到账。但游戏测试和普通软件测试最大的不同在于：游戏有一个“体验”的维度。

B站的笔试卷里，也出现过类似“如果你来测试游戏的新手引导，你会关注哪些体验层面的指标”这样的问题。很多人的答案还是“引导是否能正常走完”“点击是否有效”这类功能层面的。但如果你加上“引导步骤是否会让玩家觉得烦躁”“引导的文字是否与当前版本的新手任务匹配”“跳过引导的入口是否明显”这些体验层面的观察点，你的答案水平就完全不同了。

游戏测试不是功能测试的换皮，它需要你多一根“玩家体验”的弦。

4.3 面对不会的题，直接开摆

笔试卷里遇到不会的题很正常。但很多人遇到开放题或者偏冷门的知识点，就直接空着，或者随便写个“不会”。这在任何面试场景下都是大忌。

我遇到过一个同学，被问到“你们说的兼容性测试，一般覆盖哪些厂商的系统”，他不做测试但用过安卓手机，于是他把自己知道的说了一堆：华为、小米有自己定制的系统，分屏、悬浮窗这些功能可能会对游戏产生适配问题。虽然没有标准答案那么完整，但至少证明他有基本的生活观察和推演能力。

就算实在不会，也可以写“我目前的经验还不足以给出好答案，但我的初步思路是……”。这比空白好一万倍。你展现出面对未知问题的推演过程，反而可能让面试官对你判断力加分。

5. 游戏测试校招准备的实操建议

篇幅有限，最后给一些实际的准备建议，按照优先级排下来，照着做就行。

5.1 刷题不是核心，建立思维模型才是

你可以在牛客网、力扣上找到历年的游戏测试笔试题和面经，但我不建议纯粹靠刷题来准备。因为同一道题换个包装，考察的还是那几种能力：系统分析能力、需求理解能力、异常推断能力、逻辑表达能力。

更有价值的做法是：把自己最近深玩的一款游戏，当成“被测产品”，按照测试计划的形式去写一份拆解文档。比如“我要测试某款游戏的公会系统”，你需要写出功能列表、用例覆盖点、风险分析、环境需求。这个过程能真正帮你把知识内化。

5.2 至少掌握一种bug管理工具和用例管理工具

不要等到入职才学。现在就去搜一下Jira、Tapd、禅道这类工具的基本用法，了解bug从提交到关闭的生命周期。如果你能在简历上写“了解Jira的基本使用流程”，你已经比50%的校招生强了。

另外，很多公司面试会问：“你发现了一个bug，但开发说不是bug，你怎么办？”这个问题表面上是沟通题，实际上也在看你有没有把bug管理工具当作证据链的意识。你如果能回答出“我会在Jira里附上录屏、日志和对比视频，说明复现步骤和预期结果”，就已经是职业级回答了。

5.3 学会写“测试日报”和“测试报告”

很多校招生对测试报告完全没有概念。但实际上，测试报告的能力在笔试的开放题里就能体现。一份合格的测试报告至少包含：测试范围、执行情况、缺陷统计、风险评估、版本结论。如果你能在笔试开放题里自然地用测试报告的结构框架来回答“如何负责一个新游上线的测试”，你会给人留下非常职业化的印象。

举个实际的：测试报告的结论部分，不是写“测试通过”，而是写“本次测试共执行用例235条，通过率92%，遗留问题12个，其中轻微问题9个、建议优化3个，无阻塞性严重问题。在上述遗留问题修复并回归通过前，不建议进行全量发布”。你看，这就是职业选手的写法。

5.4 培养对“边界”和“极端”的敏感性

最后一条，也是我觉得最核心的一条：游戏测试工程师的敏感度，本质上是对“边界”和“极端”的敏感度。普通玩家在正常条件下玩游戏，测试人员在各种极端条件下“折磨”游戏。

你在平时的游戏体验中，如果有意识地培养自己思考这些极端情况，比如：

• 如果玩家背包里是满的，会发生什么
• 如果玩家在副本结算瞬间掉线，会发生什么
• 如果一个公会同时有1000人在线发消息，会发生什么
• 如果服务器时间正好跨月跨年，会发生什么

这些思维习惯一旦建立，笔试里的绝大多数案例分析题，你都能够轻松应对。因为你看问题的方式已经是一个合格测试工程师的方式了。

我在这个行业待得越久，越觉得游戏测试是一个非常被低估的岗位。它不仅仅是一个“找bug”的执行角色，而是一个需要系统性思维、产品敏感度、技术理解力和沟通推动力的复合型角色。B站这套笔试卷之所以值得拿出来仔细复盘，正是因为它把这几层能力都揉进了题目里。

如果你正打算投递游戏测试岗，我的建议是：不要只刷题，而是花一个下午，真正坐下来把你最近在玩的游戏当成一个项目，从头到尾拆一遍，想一想你会怎么测、怎么排优先级、怎么向开发提出一个让人心服口服的bug单。等你想明白了这件事，你会发现，笔试、面试都只是顺手的事。