快手测试B卷解析：从用例设计到校招笔试核心考点

又是一年校招季，看到这个标题我都觉得有点亲切。快手2019年春季校园招聘的测试B试卷，当年我也算是在好几个同学的收藏夹里见过它，如今回头来看，这套题放在今天依然很有参考价值。测试岗的笔试不像开发岗那样硬核到玩命刷题，但它考察的面特别宽：计算机网络、操作系统、数据结构、数据库、测试用例设计、逻辑思维，甚至还有一些业务场景的理解。目标就是筛出那些基础扎实、思维缜密、对测试有热情的人。

快手2019春招测试B卷，测试岗笔试题到底考什么

这篇文章我想以过来人的视角，把这套测试试卷的考察逻辑拆开揉碎了讲一遍。内容不光是简单回忆题型，更重要的是分析每类题目背后的考察点、答题思路，以及每道题在真实面试里可能会被怎样追问。不管你是正在准备校招的应届生，还是想跳槽到短视频赛道的测试工程师，这份分析都值得耐心看完。

1. 快手测试B卷的整体盘点与考核逻辑

1.1 这批题目的定位和测试岗筛选逻辑

很多人以为测试岗笔试只是走个过场，开发岗的笔试才是硬骨头。实际上当年快手测试岗的笔试筛选率并不低，因为投放给测试岗位的试卷有自己的筛选逻辑，它不看你会不会写多高级的算法，而是看你具不具备“测试思维”和“计算机体系基础”这两项底层能力。

快手测试B卷在设计上有一个明显的特点：覆盖广、深度不夸张、业务贴近率高。常规题目像计算机网络、操作系统、数据结构，基本控制在大学专业课范围；算法题不会让你手写红黑树，也不会让你去推AC自动机，最多考到哈希表、栈、队列、字符串处理这个量级。但业务场景题会结合快手App的真实功能来出，比如短视频上传、评论刷新、直播连麦、推荐流加载这些，这个思路在当时并不算普遍，也恰恰是这套题最有含金量的地方。

我当时和一个一起准备秋招的同学聊过，他说别人家测开笔试考一堆虚头巴脑的逻辑题，快手这套题倒好，直接上来就是“请为划屏切换视频功能设计测试用例”，而且一占可能就是二三十分。这其实传递了一个信号：这家公司想要的是能直接上手App测试的人，不是只会背八股文的答题机器。

1.2 试卷结构与题目类型分布

从整体看，这套试卷可以大致分成几个模块：计算机基础、数据结构与算法、测试基础理论、场景用例设计题，以及逻辑推理题。占比上，测试用例设计和场景分析类题目最重，计算机基础其次，算法和逻辑推理相对浮动。

这里要提醒一句，不要觉得“占比参考”是固定的，每年的试卷都会有微调。但你至少要能从这种结构里看出一个重点：凡是和业务挂钩的题目，分值权重就是对岸的。所以准备快手这类短视频公司的测试笔试，重点一定要放在业务场景分析上。

1.3 这套题对今天校招生的参考价值

虽然标题是2019年的真题，但测试岗的底层能力模型几乎没有变化，甚至因为业务复杂度提升，快手现在对测试工程师的要求更高了。你能在这套试卷里提前感知到几个很重要的信号：

• 测试不再是点点点，笔试就开始考你代码能力和逻辑拆解能力；
• 业务理解比工具使用更重要，会写自动化脚本的候选人很多，能说清楚业务逻辑和风险点的候选人稀缺；
• 边界和异常处理是测试的灵魂，试卷里大量题目其实都在反复验证你有没有这个敏感度。

所以我建议正在看这篇文章的你，不要抱着“这是老题随便看看”的心态，而是把它当作一次摸底测验，逐题过一遍，看看自己的基础能力到底在哪个水位线上。

2. 计算机基础与编程题的核心考点拆解

2.1 计算机网络：重点考察TCP和HTTP的掌握深度

快手测试B卷里，计算机网络几乎是必考的模块。考核重点基本集中在TCP三次握手和四次挥手、TCP与UDP的区别、HTTP状态码语义、HTTPS的握手过程、DNS解析流程这些经典知识点上。

乍一看这些题目很普通，但它的提问方式往往会在细节上做文章。比如不是简单问“TCP和UDP区别”，而是给你一个具体的业务场景——“快手App里的评论消息发送，应该用TCP还是UDP？为什么？”。这就是典型的让理论和实践结合的出题思路。

回答这类题要有结构。先说结论，再展开机制，最后结合场景落回到业务。以TCP和UDP的选择题为例：

• TCP提供可靠的、面向连接的传输，有确认重传、拥塞控制机制，适合对完整性要求高的场景；
• UDP面向无连接，传输效率高、延迟低，但丢失不重传，适合音视频流、实时互动类场景；
• 短视频App的评论发送必须保证消息不丢不乱序，肯定选TCP；而直播过程中的音视频数据包通常走UDP或基于UDP的私有协议，因为丢一帧画面可以接受，但延迟不可接受。

答题的时候如果能补充一句“实际开发中很多直播场景不会裸用UDP，而是会基于UDP做一层数据补偿和抖动缓冲”，那这道题你就答出了超出预期的水平，会在阅卷人那里拿到额外的印象分。

2.2 操作系统：进程线程与死锁条件是老面孔

操作系统在测试岗笔试里，题目方向非常固定：进程和线程的区别、死锁产生的四个必要条件、进程间通信方式、内存管理的基本概念。快手这套试卷基本也是这个套路。

举一个高频选择题的变体：“多线程环境下，哪个选项不会导致数据不一致？”选项一般围绕volatile、synchronized、原子类、普通变量来出。很多人在这道题上会翻车，把“原子类”和“普通变量”混为一谈。我建议各位把一个简单的判断原则记住：只有原子操作或者通过锁保护的操作，在多线程环境下才能保证数据一致性。

问答题里“死锁产生的四个必要条件”也几乎是送分题：互斥条件、请求与保持条件、不可剥夺条件、循环等待条件。但送分不代表能拿满分，因为考官经常会加一个追问：“如何避免死锁？”这时候你要能对应地说出破坏四个条件中任意一个的具体方案，比如一次性分配所有资源来破坏请求与保持条件、强行剥夺资源来破坏不可剥夺条件、资源有序分配来破坏循环等待条件。

2.3 数据结构与简单算法：字符串和哈希是高频考点

测试岗的算法题整体难度低于开发岗，但依然要考。快手这套试卷里，我印象比较深的题目集中在字符串处理、数组遍历、哈希表应用这几个方向。

我记得当年好像有一道经典的字符串题目，大概是“给定一个字符串，找出第一个只出现一次的字符”，要求手写实现。这道题目简单，但能一次性写对也不容易。最优解法是遍历两次：第一次用哈希表记录每个字符的出现次数，第二次按原顺序找到第一个计数为1的字符。

def first_unique_char(s: str) -> int: from collections import Counter count = Counter(s) for i, ch in enumerate(s): if count[ch] == 1: return i return -1

这里我要多说一句：写算法题，哪怕是在笔试里，也要注意边界条件。空字符串、全重复字符、只有一种字符的输入，这三类情况容易出错。很多人在线笔试时自己想得好好的，一运行就报错，90%是没考虑空输入。考场上时间紧，这种细节更是要命。

2.4 数据库与SQL基础：测试人必须具备的查数能力

数据库的题目在测试笔试里不会出得太深，但会考察你基本的SQL编写能力和数据一致性理解。常见的有“查出每个用户的最近一条登录记录”、“统计某时间段内视频发布数量”这类题目。

这类SQL题的本质是考察分组排序和表连接。以“每个用户的最近一条登录记录”为例，思路是基于user_id分组，取login_time最大值的记录。有两种常见写法，窗口函数在MySQL 8.0里简单好用：

SELECT user_id, login_time FROM ( SELECT user_id, login_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC) AS rn FROM user_login_log ) t WHERE rn = 1;

老版本MySQL不支持窗口函数的，也可以写成关联子查询或者先分组再join。我建议笔试时优先选择自己最有把握的写法，因为阅卷系统很可能不会真正执行SQL，而是人工审核逻辑，简洁正确比炫技更划算。

3. 测试基础与用例设计题，这套卷子的重头戏

3.1 测试基础理论：等价类、边界值、场景法都要熟

只要你做测试岗位的笔试，测试基础理论就是绕不开的。等价类划分、边界值分析、因果图、判定表、场景法、错误推测法，这几种用例设计方法一定得烂熟于心。

快手这套卷子很少直接让你默写“什么是等价类”，而是给你一个具体输入框，让你设计测试用例。比如一个“视频标题”输入框，限制长度是2-30个字符，要求覆盖正常和异常场景。这种题看起来简单，但特别能看出一个人的测试素养。

标准答案一般要覆盖这么几类：

• 合法输入：2个字符、30个字符、中英文混合、数字符号组合；
• 边界情况：1个字符、31个字符、空字符串；
• 特殊输入：全空格、纯标点、emoji、前后带空格、SQL注入字符串；
• 业务约束：重复标题是否允许、是否过滤敏感词、是否支持换行。

如果你只是写“输入正常字符可以提交，输入超长字符会提示错误”，那这道题大概率只能拿一半分。因为考官希望看到的是系统的、有层次的用例设计思维，而不是零散的几条测试点。

3.2 短视频场景用例设计：从功能到异常的全链路覆盖

快手这套测试B卷里，有一类题目决定你能不能进下一轮，就是关于App核心功能的测试用例设计。比如“请为双击点赞功能设计测试用例”、“请为短视频拍摄上传功能设计测试用例”、“请为直播间礼物赠送功能设计测试用例”。

以“双击视频点赞”为例，很多人的第一反应就是“点赞后心形图标变红”。这没错，但这是最浅的一层。真正的测试用例设计要从功能、交互、网络、异常、兼容性、弱网这几个维度去拆：

这类题作答的核心原则是：不要只在正常功能里打转，要把异常流、边界流、数据一致性、前端展示和后端接口串联考虑。每一条用例最好写成“前置条件 + 操作步骤 + 预期结果”三段式结构，哪怕时间紧无法完全展开，也要保证框架清晰。

3.3 测试用例设计经典题：登录、上传、评论的通用套路

除了业务特色题，经典的功能用例设计题也是必出现的位置，比如登录功能、文件上传、评论发送。这类题好在通用性强，不管你去面哪家公司都适用。这里我给出登录功能的一个答题框架，你以后遇到类似题目可以直接套用：

• 正常流程：正确用户名和密码登录成功，跳转首页；
• 参数校验：空用户名、空密码、错误密码、用户名不存在、大小写不敏感验证；
• 安全测试：密码是否加密传输、验证码是否失效、错误密码多次尝试是否锁定；
• 网络异常：超时、断网、弱网条件下登录是否有明确提示；
• 兼容性：多端登录、同账号多设备登录、退出登录后token清理。

我见过太多人在写用例设计题时只写正常路径，然后草草收场。其实你只要把边界值、异常值、安全、多端协同这几个维度展开来答，哪怕你逻辑不是特别严谨，分也不会低。阅卷人看的是你的测试思考习惯，而不是你写出了多少条用例。

3.4 缺陷管理相关题目：考察你对测试流程的理解

有一部分笔试也会结合场景来考察缺陷生命周期和bug管理流程。常见考法是给你一道场景描述，比如“测试时发现了一个偶现的闪退问题，你会怎么处理”，然后让你谈一谈定位思路。

这类题没有标准答案，但有一个较好的回答框架：

• 记录环境信息：设备型号、系统版本、App版本、操作路径、出现频率；
• 尝试复现：尽量稳定复现，复现是定位的前提；
• 收集日志：抓取logcat或相关崩溃日志，定位到错误堆栈；
• 排除干扰：检查是否为低内存、网络切换、后台进程被杀导致；
• 提单跟进：提交bug单并附上复现步骤、日志和视频录屏，设置合理的优先级。

如果在笔试中遇到这种开放题，就尽可能把“信息收集 → 复现 → 定位 → 跟进”这条链路写全。这一套思路在任何测试岗位都通用，也是对一个测试工程师基本素养的考察。

4. 行测逻辑题与智力题，看似无用实则筛人

4.1 逻辑推理题：题干变长了，考察你抓住主要矛盾的能力

笔试中穿插一些逻辑推理题，是很多互联网公司的惯例。快手这套测试B卷里也有一定比例，比如条件排序、真假话推理、图表数据分析等。

我当时印象比较深的一道类型是条件排序题，就是给了甲乙丙丁四个人各自的说法，有人真有人假，最后让你判断谁在说谎。这种题目其实并不难，但特别耗时间，如果死磕就容易挤占后面用例设计题的答题时间。

我的建议是，逻辑题快速判断自己能否在2分钟内解出；解不出就先蒙一个并做好标记，把时间留给后面的场景设计题。因为后者才是真正影响你是否进入面试的关键。

4.2 数字规律和图形推理：没必要刻意准备

数字规律题和图形推理题，本质上考察的是你在有限时间内找到pattern的能力。坦白说，这类题刷多了意义不大，因为考场上的题你基本没见过，拼的是现场反应。如果平时看到这类题就头疼，我建议不要投入大量时间专门准备，保证“能做出来两三道”就够用了。

有个小技巧可以分享：看到一组数字，先看相邻差、再看比值、再看奇偶位拆分、最后看多项式。图形推理则重点看旋转、对称、笔画数、部分数这几个维度。大部分笔试题的规律都不超过这个范围。

5. 考场实战策略，如何在有限时间内拿下最高分

5.1 时间分配：先拿必得分，再啃硬骨头

快手这套测试B卷整体题量不算小，再加上部分场景设计题需要大篇幅书写，时间分配非常重要。我当时给自己定的策略是：

• 前15分钟：快速浏览全部题目，标注会的、不确定的、完全不会的；
• 前40分钟：做计算机基础、数据库、测试理论等客观题和简单题；
• 中间40分钟：主攻场景用例设计题和SQL题，把框架写全；
• 最后25分钟：回来处理逻辑题和不确定的选择题，检查有没有漏答、错别字。

这个策略的核心思路是先拿确定性高的分，再追求扩展分。测试岗笔试不是看你最难题能答多深，而是看你该拿的分有没有全部拿到。

5.2 多快好省地写出高分用例设计题答案

针对用例设计题，如果题目要求设计“短视频评论”功能的测试用例，建议你按照下面这个维度去写：

• 基础功能：正常发送评论、评论显示、删除评论、举报评论；
• 边界与异常：评论内容为空、超长评论、纯表情、含敏感词、含链接；
• 交互体验：评论后列表是否置顶、评论数是否实时更新、发送按钮的置灰逻辑；
• 权限场景：未登录用户能否评论、被拉黑用户能否评论、作者删除评论后对方端是否同步；
• 性能与兼容性：大V视频下万条评论的滑动加载是否卡顿；不同机型显示是否正常；
• 网络等特殊情况：弱网下评论发送失败后的提示、断网重连后的状态恢复、前后台切换后草稿是否保留。

每条用例都要以“可执行”为标准，不要写“验证评论功能是否正常”这种废话。你这张卷子能得多少分，很大程度上取决于用例的可执行性和覆盖的全面度。

5.3 开放题：想办法展示你的测试思维和业务理解

快手笔试里偶尔还会出一道关于改进建议的开放题，比如“你觉得快手App的某个功能有什么可优化之处，你会怎么测？”。这类题想拿高分，不能只站在测试角度说，还要代入用户角度、数据角度、竞品角度。

举个例子，如果题目问“如何优化视频播放卡顿的体验并验证效果”，你可以这么答：从端上做预加载、根据网络情况动态切换清晰度、调整播放缓冲策略，然后通过卡顿率、首帧时长、用户反馈率等指标来验证。这样一答，既体现了你对业务的理解，又展示了测试思维向测试开发的延伸，非常加分。

6. 常见问题与备考踩坑实录

6.1 备考时最容易踩的四个坑

• 只刷题不总结。很多人把牛客网上题库刷了几百道，但错过的题立马就忘，第二次还能再错。正确姿态是每做完一套题，把错题按知识点归类，定期复盘，这样才能把一套题吃透。
• 忽视业务理解。测试岗笔试如果只准备通用八股，不关注目标公司的产品形态，场景设计题很容易答得泛泛而谈。建议在笔试前至少把快手的核心功能都体验一遍，心里有数。
• 时间分配失衡。有些人在逻辑题上较劲，最后用例设计题草草两行，这种丢分最可惜。我一直强调，测试岗笔试的大头永远是测试设计题。
• 不写前置条件和预期结果。用例设计题如果只写操作步骤，不写预期结果，会被认为没有完整的测试思维。这属于低级的规范性错误，一定要避免。

6.2 现场笔试的几个实用技巧

在线笔试环境一般会有监控，很多同学容易紧张，我分享几个能直接用的技巧：先把编译器或编辑器调好，做好模板准备；写SQL前先理清表结构，避免来回修改；打字速度慢的，用例设计题可以先用短句快速列点，再回头补充修饰。

还有一点很重要，笔试前一定要确认设备的浏览器兼容性和网络稳定性。我见过不止一个人因为浏览器弹窗拦截导致代码保存失败，或者因为网络断线让答题页面直接卡死，这种场外因素丢分才真叫冤枉。

6.3 真实答题范例：从低分答案到高分答案

我来举个具体例子，让大家直观感受一下低分和高分答案的差距。题目是“请为短视频上传功能设计测试用例”。

低分答案往往这样写：

• 选择一个视频上传；
• 上传成功后显示在作品列表里。

这只能说明你理解了题目表面的意思，完全没体现测试深度。稍微好一点的答案会写：

• 选择不同格式和清晰度的视频上传，验证上传进度条、上传成功后的跳转；
• 弱网状态下上传，查看是否提示失败，是否有重试机制；
• 上传过程中切到后台，检查任务是否中断或继续。

高分答案则会按维度系统地输出：功能维度覆盖正常上传、上传进度、上传结果；异常维度覆盖格式不支持、体积超限、存储空间不足；网络维度覆盖弱网、断网、网络切换；交互维度覆盖取消上传、重新上传、上传中退出App；数据维度覆盖上传完成后的列表同步和服务端存储校验。同时还会写明每个用例的前置条件和预期结果。把这个结构写出来，考官的印象分自然就不一样了。

7. 从笔试到面试，这套题暴露的能力要求

7.1 面试官会围绕笔试题怎么追问

笔试之后如果你收到了面试通知，千万不要以为笔试已经结束了。面试官往往会在面试前翻看你的笔试答卷，然后挑几道题来追问。最常见的就是用例设计题，比如你写了“测试登录功能”，面试官可能会追问：

• 你说要验证密码加密，具体怎么验证？
• 你说要测试验证码，验证码过期和错误分别是什么表现？
• 如果登录接口返回500，你怎么判断是前端问题还是后端问题？

这些追问考察的都是你是否真的理解自己写下的答案，还是背了一堆模板上去。我给你的建议是：笔试时写的每一条用例，都尽量在脑海里过一遍“如果面试官问为什么这么写，我怎么解释”。准备到位了，面试反而是你展示能力的好机会。

7.2 测试岗面试还需要准备哪些额外能力

笔试只是第一关，通常快手测试岗的面试会更看重沟通表达、逻辑思维和实际项目经验。无论你是在校生还是转行人员，我建议在简历里准备一个你自己真正做过或者深入研究过的测试项目，不一定非得是大项目，哪怕一个简单的秒杀系统或者小程序的测试，只要你能说清楚需求分析、用例设计、执行流程和bug跟踪闭环，就是很好的加分项。

语言方面，Python是测试岗使用率最高的语言，至少要能熟练读写。Linux常用命令要熟悉，SQL基础查询要熟练，再加上一些抓包工具的使用经验，基本上就能覆盖大部分公司测试岗位的要求。

7.3 从这份试卷延展出去，测试工程师的核心竞争力

其实把整张卷子看下来，你会发现它考察的不是某个知识点的记忆，而是测试工程师最核心的三个能力：

第一，基础知识的广度，需要对常见技术栈有认知，因为只有理解了技术实现，才能设计更全面的测试场景。第二，业务思维和用户思维，要能站在用户使用的角度出发，去覆盖真实场景，而不只是执行文档里的步骤。第三，逻辑拆解的深度，面对复杂业务，能把它拆解成不同维度、优先级和风险等级的测试点。

这三个能力，恰恰就是测试岗位从初级到高级的分水岭。初级测试能做执行，把case跑完；中级测试能做设计，把场景覆盖全面；高级测试能做策略和体系，能通过工程化手段来提升测试的效率和可信度。

从这份试卷来看，快手的测试团队在筛选人才时，已经走在行业前面了。所以如果你现在正在准备投递测试岗位，不妨以这套题为基础，把自己的知识体系和测试思维认真梳理一遍。我个人一直觉得，刷完一套笔试题，真正值钱的部分不是你会做了多少道题，而是你借着这些题目，补上了哪些以前忽略掉的认知盲区。如果你准备校招，最好现在就开始动手，给自己做一次模拟测试，掐着时间把整套卷子写一遍，写完再回头看这份分析，你一定会对自己该往哪个方向努力心里有数。