又是一年校招季看到这个标题我都觉得有点亲切。快手2019年春季校园招聘的测试B试卷当年我也算是在好几个同学的收藏夹里见过它如今回头来看这套题放在今天依然很有参考价值。测试岗的笔试不像开发岗那样硬核到玩命刷题但它考察的面特别宽计算机网络、操作系统、数据结构、数据库、测试用例设计、逻辑思维甚至还有一些业务场景的理解。目标就是筛出那些基础扎实、思维缜密、对测试有热情的人。快手2019春招测试B卷测试岗笔试题到底考什么这篇文章我想以过来人的视角把这套测试试卷的考察逻辑拆开揉碎了讲一遍。内容不光是简单回忆题型更重要的是分析每类题目背后的考察点、答题思路以及每道题在真实面试里可能会被怎样追问。不管你是正在准备校招的应届生还是想跳槽到短视频赛道的测试工程师这份分析都值得耐心看完。1. 快手测试B卷的整体盘点与考核逻辑1.1 这批题目的定位和测试岗筛选逻辑很多人以为测试岗笔试只是走个过场开发岗的笔试才是硬骨头。实际上当年快手测试岗的笔试筛选率并不低因为投放给测试岗位的试卷有自己的筛选逻辑它不看你会不会写多高级的算法而是看你具不具备“测试思维”和“计算机体系基础”这两项底层能力。快手测试B卷在设计上有一个明显的特点覆盖广、深度不夸张、业务贴近率高。常规题目像计算机网络、操作系统、数据结构基本控制在大学专业课范围算法题不会让你手写红黑树也不会让你去推AC自动机最多考到哈希表、栈、队列、字符串处理这个量级。但业务场景题会结合快手App的真实功能来出比如短视频上传、评论刷新、直播连麦、推荐流加载这些这个思路在当时并不算普遍也恰恰是这套题最有含金量的地方。我当时和一个一起准备秋招的同学聊过他说别人家测开笔试考一堆虚头巴脑的逻辑题快手这套题倒好直接上来就是“请为划屏切换视频功能设计测试用例”而且一占可能就是二三十分。这其实传递了一个信号这家公司想要的是能直接上手App测试的人不是只会背八股文的答题机器。1.2 试卷结构与题目类型分布从整体看这套试卷可以大致分成几个模块计算机基础、数据结构与算法、测试基础理论、场景用例设计题以及逻辑推理题。占比上测试用例设计和场景分析类题目最重计算机基础其次算法和逻辑推理相对浮动。题型模块常见考察点占比参考难度感受计算机基础TCP/UDP、进程线程、HTTP状态码、Linux命令25% - 30%中等偏基础数据结构与算法数组、链表、栈、队列、字符串、查找排序20% - 25%简单到中等测试基础理论黑盒白盒、用例设计方法、缺陷生命周期15% - 20%中等容易失分场景用例设计短视频、直播、评论、上传下载、登录等20% - 30%核心拉分项逻辑与智力题找规律、条件推理、概率估算10%左右不稳定看状态这里要提醒一句不要觉得“占比参考”是固定的每年的试卷都会有微调。但你至少要能从这种结构里看出一个重点凡是和业务挂钩的题目分值权重就是对岸的。所以准备快手这类短视频公司的测试笔试重点一定要放在业务场景分析上。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核心功能的测试用例设计。比如“请为双击点赞功能设计测试用例”、“请为短视频拍摄上传功能设计测试用例”、“请为直播间礼物赠送功能设计测试用例”。以“双击视频点赞”为例很多人的第一反应就是“点赞后心形图标变红”。这没错但这是最浅的一层。真正的测试用例设计要从功能、交互、网络、异常、兼容性、弱网这几个维度去拆测试维度用例举例功能正常双击视频红心出现点赞数加1交互细节连续双击多次点赞数只加一次松手后动画完整播放网络切换飞行模式下双击提示网络异常但不崩溃恢复网络后状态正确异常场景视频加载失败时双击是否有响应点赞接口超时是否有重试机制数据一致性点赞前后数据在列表页、详情页、个人主页是否保持一致兼容性Android/iOS不同版本不同分辨率全面屏和异形屏适配这类题作答的核心原则是不要只在正常功能里打转要把异常流、边界流、数据一致性、前端展示和后端接口串联考虑。每一条用例最好写成“前置条件 操作步骤 预期结果”三段式结构哪怕时间紧无法完全展开也要保证框架清晰。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跑完中级测试能做设计把场景覆盖全面高级测试能做策略和体系能通过工程化手段来提升测试的效率和可信度。从这份试卷来看快手的测试团队在筛选人才时已经走在行业前面了。所以如果你现在正在准备投递测试岗位不妨以这套题为基础把自己的知识体系和测试思维认真梳理一遍。我个人一直觉得刷完一套笔试题真正值钱的部分不是你会做了多少道题而是你借着这些题目补上了哪些以前忽略掉的认知盲区。如果你准备校招最好现在就开始动手给自己做一次模拟测试掐着时间把整套卷子写一遍写完再回头看这份分析你一定会对自己该往哪个方向努力心里有数。