2019年春招的时候快手校招的节奏很快测试岗笔试直接就是线上统一笔试。那套“快手2019年春季校园招聘笔试试题——测试B试卷”我前后复盘过很多遍。如果你也准备走测试方向这份卷子很值得拿来当样板题目不偏不难但覆盖面广非常考验你在有压力的情况下能不能用测试的思维方式去答题。今天我不想把笔试答案贴一遍而是拆开卷子把试卷结构、每个模块到底在考什么、答题节奏怎么安排、哪些地方最容易丢分一次讲清楚。不管是应届准备测试岗还是已经工作想转岗测试这篇都可以当成一份系统的复习地图。1. 试卷印象这份B卷在筛什么样的人快手2019年春季校招的测试岗笔试采用的是在线笔试系统限时作答全程录像这种情况下想靠“场外求助”几乎不可能能依赖的只有平时的积累。也正因为是这样整张B卷呈现出非常鲜明的筛选逻辑不是看你会不会背某一本教材而是看你在三个维度上是否合格——逻辑推理能力、计算机基础扎实程度、测试设计意识。1.1 为什么分A/B卷B卷到底难不难校招笔试分A/B卷本质上是防止作弊的一种常规操作。提交答案时间相近的情况下如果两张卷子题目完全一样很容易出现雷同答案分卷之后题目顺序、选项顺序甚至部分题干数字都会不同能极大降低抄袭的发生率。所以A卷和B卷并不是“一个简单一个难”而是平行卷难度取齐。有些同学拿到B卷后先慌了一下觉得是不是自己抽到了加难版真不用把它当成普通一套题把节奏稳住就好。顺带说一句有的公司还会在笔试系统里搞乱序组卷每个考生看到的题目顺序都不一样这种卷子本质上比固定A/B卷更“个性化”。快手那几年在校招笔试上采用的是比较稳妥的A/B卷策略重点考核内容一致只在小细节上做区分。所以复盘B卷约等于把整场笔试的出题套路复盘了一遍不需要过于纠结为什么自己拿到的是B而不是A。1.2 试卷结构和推荐时间分配线上笔试一般不会告诉你每个模块具体占多少分但题目类型基本就在这几类里打转逻辑推理选择题、计算机基础选择题含多选、测试设计与场景简答题、编程题。我根据复盘时各模块题量和常见分值整理了一张时间分配建议表试卷模块常见题量建议用时做题策略逻辑推理题10—15道25—30分钟先做有把握的图形题和数字题不要死磕计算机基础题15—20道35—40分钟单选题提速多选题宁可少选不乱选测试设计题2—3道35—40分钟先列框架再补细节覆盖正向和异常编程题1—2道25—30分钟先写暴力解保底再优化复杂度和边界这个时间分配是我自己复盘后得出的经验不一定适合所有人但总原则是通用的选择题不能恋战简答题不能糊弄编程题一定要留时间。很多考生失败的根本原因不是不会而是被前面的选择题卡住导致后面分值很高的测试设计题草草收场。这一点请格外注意。2. 核心考点拆解与解题思路要拿捏这份卷子先看它考的模块。测试岗不是开发岗笔试不太可能只考算法考的是工程基础和测试敏感度。下面我把几个主要模块逐个拆开帮你理解每个模块到底在考什么深层能力。2.1 逻辑推理题考的是“快速建模”能力逻辑推理题是几乎所有互联网公司校招笔试的第一道“开胃菜”快手B卷也不例外。这类题常见的有数字规律、图形规律、逻辑判断、资料分析四类。数字规律和图形规律的核心不在计算而在快速建立模型。比如给一串数字先看差值变化再看差值本身是不是等差、等比或者平方关系图形题则是看边数、位置、颜色、旋转对称这四个维度。逻辑判断里“只有A才B”“如果A那么B”这类条件推导尤其需要警惕不要凭直觉选一画真值表就清晰了。对于测试岗来说逻辑题不只是刷人用的它和实际工作直接挂钩。测试用例设计本质上就是逻辑建模把所有输入条件当成变量把所有可能结果当成输出然后理清条件之间的关系。所以这部分的训练价值不止在笔试得高分更在于建立“测试脑”。有个朋友当年一起参加笔试他逻辑题做得并不快但准确率很高原因就是他把每道题都当成一个黑盒系统去分析输入和输出这个习惯后来在工作中帮了他不少。2.2 数据结构与算法测试岗也要懂复杂度这部分有一些选择题和一道编程题。选择题常考的点包括常见排序算法的时间复杂度和稳定性、链表和数组的优劣、栈和队列的典型应用、二叉树的遍历方式、哈希表的冲突处理。比如有一类很经典的题就是让你判断“哪些排序算法是稳定的”。记住结论还不够最好能理解快排为什么不稳定归并排序为什么能保持稳定这样换一个问法也不会懵。那几年笔试选择题里还喜欢把时间复杂度的概念和实际操作结合比如“在有序数组中查找某个值用二分查找时间复杂度是多少”这类题属于基础分但往往有人因为没看清“有序”二字而选错。测试岗为什么要考算法因为测试工程师要是连代码的时间复杂度都看不明白就没办法评估性能风险也没法给开发提有价值的优化建议。更现实的是很多测试开发岗日常工作要写自动化脚本脚本本身如果写成了嵌套循环跑上百万条数据时直接卡死这就是明显的设计问题。所以笔试考算法不是在难为测试而是在筛掉没有代码基础的候选人。2.3 计算机网络与操作系统实测基础中的基础计算机基础题通常占据整个计算机选择题的半壁江山。网络部分TCP三次握手和四次挥手是高频中的高频而且喜欢换着花样考。比如“第三次握手如果丢了客户端会怎么样”“服务端在TIME_WAIT状态等待多久”这类问题如果只看过教材答单选题还行遇到改错或者“以下哪种说法是正确的”就会露馅。除了TCPHTTP状态码也是常客要能准确区分2xx、3xx、4xx、5xx各自的含义尤其是302重定向和304缓存这两个容易混的状态码笔试选择题里经常把它们放在同一个选项里当干扰项。操作系统部分进程和线程的区别、死锁产生的四个必要条件、内存分页和虚拟内存的概念常见于选择题。有一个高频坑是考“死锁必要条件是哪些”时经常设置多选很多同学只选了互斥、请求保持等前两项漏掉了循环等待又或者把“剥夺条件”记错成“不可剥夺”结果直接整道题扣分。这块没有捷径只能靠多刷题把基础概念打牢。我在实际复盘时发现真正拉开差距的不是那些偏题怪题而是基础题里的多选陷阱一错就是两三分比一道简答题损失还大。2.4 数据库与SQL最接地气却最容易翻车数据库题也是测试笔试题里的常客通常以SQL查询的形式出现。快手这种短视频App业务数据天然和用户、视频、评论、点赞强相关所以SQL题很接地气。比如会给你两张表一张是视频表一张是评论表让你统计评论数排在前十的视频或者统计活跃度最高的用户。典型的写法是左连接加聚合再按数量倒序limit一下。这种题目说难不难但踩坑率很高常见坑是join的方向写反导致没有评论的视频直接被过滤掉或者group by之后忘记条件应该用having而不是where结果过滤时机不对数据就不对。我建议做这类题的时候先不要急着写SQL花十秒钟画出两张表的主外键关系再想清楚要保留哪些行。只要保留逻辑对了写出来的SQL基本就八九不离十。数据库索引和事务的特性也会以选择题出现比如ACID是哪些单词的缩写什么情况适合建索引这些属于必须拿分的送分题如果这里丢分就太可惜了。另外快手这类业务场景里评论表通常会有软删除字段统计评论数时要不要过滤已删除的评论、要不要剔除被举报下架的评论这些“隐藏业务条件”恰恰是测试岗SQL题爱挖的坑出题人想看的不是你会不会select而是你会不会结合业务去理解数据口径。3. 测试设计与场景题——真正拉开差距的部分选择题做得再好也只是一个基础达标线真正拉开考生差距的是测试设计和场景题。这部分的字面分值可能只占三成左右但在阅卷人眼里它的权重可能比选择题更高因为它直接展现你具不具备测试思维。很多同学以为测试设计题就是“把功能点列出来”这么答只能拿到基础分拿不到高分。3.1 先吃透四种基础用例设计方法快手测试笔试题里考到的测试用例设计核心方法绕不开等价类划分、边界值分析、场景法、错误猜测法。等价类划分是把输入条件分成有效和无效的类每类取一个代表性数据目的是用尽量少的用例覆盖尽可能多的场景。边界值分析是等价类的补充因为大量bug都出在边界比如登录密码要求6到20位那5位、6位、20位、21位这四组边界必测空值和大写状态也要考虑。场景法常用于从用户操作路径的角度来设计用例比如注册→登录→浏览→下单→支付→售后一条完整的业务链路要能从始到终跑通。错误猜测法则更多依赖经验和直觉比如输入超长字符串、连续快速点击、弱网断连、权限被拒绝等等。笔试答题时如果能把四种方法混合使用而不只是“照着功能正常点一遍”得分会明显不一样。一个很实用的技巧是拿到题目后先画一个简单的Xmind结构把功能测试、异常测试、兼容性测试、性能测试、安全测试五个分支列出来再往每个分支里填具体测试点。这样做的好处是哪怕某个分支只填了一两个点阅卷人也能看出你有结构化思维而不是东一榔头西一棒子。3.2 场景题示例给“视频评论”设计测试用例举个例子快手App里最核心的互动功能之一就是视频评论。笔试中出现类似的题你该怎么答才显得专业我的建议是分层次展开。先从功能测试入手能不能正常发评论、评论字数上限和下限、是否只允许登录用户评论、评论后能否删除、重复点击发送会不会产生重复评论。再从异常场景入手发送评论时断网、快速滑动导致评论加载失败、发出去的评论中包含表情或特殊字符、被拉黑的用户评论是否被拦截。然后是兼容性不同操作系统、不同分辨率、不同版本下的表现。最后是性能大量评论同时刷出来的时候页面是否卡顿滚动是否流畅弱网环境下是否需要很久才能展示评论。为了更直观我把一个相对完整的用例设计框架整理成了表格。测试维度测试点举例功能测试正常发送、删除、举报评论字数边界检查回复评论和楼中楼逻辑异常场景断网重发、重复提交、特殊字符、被拉黑用户、评论后立刻删视频兼容性iOS/Android不同机型、分辨率、系统版本、App版本性能测试大V视频下万条评论滚动卡顿、内存占用、首屏加载耗时安全测试评论内容注入、越权删除他人评论、恶意刷屏、评论审核绕过用户体验键盘遮挡输入框、评论时间显示、下拉加载、红点提醒如果你能把一个功能拆出上面这六个维度并且每个维度下至少写三四个点那么阅卷人一眼就知道你有实际测试经验这和临时背模板的答案完全不一样。评论功能看起来简单实际上涉及数据一致性、权限控制、内容安全、弱网容错、性能优化这些点都踩到了才叫真正的测试思维。3.3 场景题背后的“测试脑”这些题目背后的核心不是让你背功能点而是看你能不能形成一套自己的测试分析框架。我经常用一句话总结测试设计要想得比产品多一步。产品经理说“评论要支持删除”你立刻要想到谁可以删、能不能删除别人的评论、删除后要不要提示、删除后数据是物理删除还是逻辑删除、删除之后评论数怎么更新、被删除的评论是否还要进审核流。每多想一步测试用例就更完善一层。快手业务里还有一类常考场景是直播。直播间画质清晰度切换、弹幕渲染、礼物特效、主播连麦延迟这些都需要测试设计。笔试可能只让你测某个小功能但考察逻辑是一样的把用户从进入直播间到离开直播间的完整路径走一遍在每一步找可能的异常点。这里有一个经验分享别把测试场景题当成“证明自己懂业务”而是当成“证明自己懂风险”风险点找得越准分数越高。4. 编程题分值不高但别被零封编程题在测试笔试题里的占比不像开发岗那么大一般一到两题但绝对不建议直接放弃。有些同学看到编程题就默认“测试岗应该不考代码”结果到了考场上傻眼。实际上测试开发岗、自动化测试岗、性能测试岗对代码能力的要求越来越高快手这类头部公司对测试候选人的工程能力也盯得很紧。4.1 编程题常见考查范围和语言选择常见考查范围是字符串处理、数组操作、二分查找、链表反转、简单动态规划很少会出特别复杂的算法题。这些题考察的是最基本的编程能力。语言选择上建议选自己最熟的不要因为“别人都用C更高效”就临时换语言。笔试平台上C、Java、Python一般都会支持但编译环境、输入输出方式会有差异提前熟悉平台比临场发挥更重要。还有个很容易被忽略的点测试岗编程题有时候会以“写一个函数”的形式出现而不是完整读入读出的ACM模式。所以备考时一定要两种形式都练既能写独立函数也能处理标准输入输出。平台如果支持本地IDE验证就先用本地把逻辑跑通再粘贴上去如果不支持也要在脑子里手动走一遍样例避免低级错误。4.2 一个示例字符串压缩比如一道很典型的题是字符串压缩输入一串由字母和数字组成的字符串要求把连续相同的字符压缩成“字符次数”的形式输出。很多人一眼就看出来解法但失分点往往在细节输入为空字符串怎么办压缩后的长度比原串还长时是返回压缩串还是原串连续次数超过10时怎么输出这些边界如果不处理就算主流程写对了测试用例一跑立刻扣分。这道题的套路就是先把框架写出来再回头补边界最后检查复杂度是否做到O(n)。很多测试岗同学做这类题时容易陷入“开发思维”只想着上线一个抽象的好实现忽略了测试视角。如果切换成测试视角你会自然地问这个函数的输入范围是什么会不会有非法字符如果输入有大小写怎么办这种换位思考反而能帮你把边界条件考虑得更全写出更稳健的代码。4.3 编程题保分策略暴力解优先更重要的经验是考试的时候不要一上来就追求最优解。先把能跑出正确结果的暴力解写出来确保这道题至少有点分然后再优化。有的同学非得在脑子里憋一个最优解憋到最后时间耗尽代码还没写上去保底分都丢了。测试岗的编程题通常对时间复杂度的要求不会像开发岗那么苛刻只要做法合理、代码可读、能过样例分都不会太低。如果编程题一共有两题建议先做有把握的那道把分数先拿到手再回头啃难题。这里也想多说一句平时练习时要刻意训练自己“写完代码后检查边界条件”的习惯尤其是数组越界、字符串为空、整数溢出这三类边界是校招笔试最常见的扣分原因。笔试现场的样例通常给得很友好真正阴险的用例都在后台藏着你只有主动补边界才能躲过一劫。5. 高频失分点与备赛建议复盘这份B卷我把考生最容易丢分的点归纳成了一张速查表同时给出对应的应对建议希望能直接帮你在备考阶段避坑。这张表不一定只适用于快手其他互联网公司的测试岗笔试题也基本通用。5.1 高频失分点速查表失分点具体表现应对策略多选题漏选只选了两个确定项漏掉第三个多选不确定时宁少勿多因为少选可能给部分分错选直接0分用例题写单一路径只写了正常流程没有任何异常分支按“正向反向异常边界性能安全”六层展开时间分配失衡选择题死磕测试设计题来不及写提前定好每个模块的Deadline到点立刻切下一模块编程题不跑样例写完直接提交边界样例全挂写完后至少花2分钟自测空值、最大、最小三种样例平台不熟悉在线IDE和本地IDE行为不一致输出格式错误笔试前做一次平台模拟题熟悉输入输出和编译按钮SQL表关系不清join方向写反group by条件用错where和having动手画表关系先想保留哪些行再写SQL用例设计没优先级把所有用例平铺看不出重点用“P0/P1/P2”标出用例优先级体现风险管理意识这张表里的“用例设计没优先级”这一点很多人会忽略但阅卷人非常看重。能写出P0/P1/P2分级说明你清楚上线前哪些问题会挡住发布哪些问题可以带病上线再优化这种判断力是测试岗的核心竞争力之一。5.2 备赛三阶段建议准备时间充裕的情况下我建议按三个阶段来备考。第一阶段用两周把测试理论基础补齐重点看等价类、边界值、场景法、因果图配合测试用例设计例题练习目标是拿到一个功能能立刻写出结构化用例。第二阶段用两周刷计算机基础题覆盖数据结构、计算机网络、操作系统、数据库四门课的高频考点多选和单选都要练。第三阶段用一周做模拟笔试严格掐时间把逻辑题、基础题、测试设计、编程题完整过一遍重点找自己的时间短板。有些同学只刷计算机基础不练测试用例这是本末倒置。笔试选择题靠短期冲刺或许能提分但用例设计题如果没有形成结构化思维一旦碰到陌生的业务场景很容易写成一团浆糊。我觉得测试岗笔试备考和会计考证有点像快速拿分的关键不是你记得多少细节而是你遇到任何一道题都知道该套用哪套分析框架。5.3 考前最后一天做什么考前最后一天不建议再刷大量新题越刷越慌。更好的做法是把自己整理的错题和用例框架翻一遍尤其是那些经常看错的SQL条件、TCP状态、多选漏项。然后把笔试平台的登录信息、编译环境、截屏规则确认清楚第二天才能把精力集中在题目上而不是处理各种意外。还有一个小细节网络差的千万别拖到最后几秒交卷在线笔试系统最怕自动提交失败。考前专门测试一下网络、确认浏览器适配、关掉无用的弹窗插件这些操作看起来琐碎但每年都有考生因为这些原因导致整场考试失败。把这件小事当成正式用例去对待也算是一种测试思维的应用。如果问我这份B卷给人最大的启示是什么我会说它并不追求你是一个“什么都会的人”而是追求你是一个“遇到问题能有条理地分析并解决的人”。测试岗校招笔试考的基础是看得见的考的能力是看不见的。那些能在用例设计题里写出六层维度、在编程题里还留着时间补边界条件的同学往往不是刷题最多的那批而是真正用测试思维思考过的那批。把这份复盘记在心里后面无论遇到哪家的测试岗笔试都能稳住节奏。