快手测试岗笔试B卷复盘：从用例设计到业务思维的实战解析

2019年春季我在北京参加快手测试岗的校园招聘笔试拿到的正是那份传说中的“测试B试卷”。整张卷子做完第一感受不是难而是“务实”——几乎每一道题都能在快手的业务场景里找到影子。后来和同批笔试的同学复盘大家最认同的一点是这份卷子没问“测试的定义是什么”却一直在问“这个功能你怎么测”。这篇文章就围绕B卷里我印象比较深的几类考点拆一拆解题思路也聊聊从笔试反推出来的快手测试选人逻辑。需要说明的是具体题面只能凭回忆整理个别措辞和数值可能与原卷有偏差但考察的知识点和解题方法是可以复用的。1. 从B卷的题型分布反推快手的招人偏好1.1 卷面结构的大致轮廓B卷整个题量不算小我记得应该是选择、填空、简答、综合设计题四类。选择和填空覆盖得很杂Linux命令、SQL语法、HTTP状态码、测试基本概念都有涉及。简答题主要围绕测试设计比如“你如何测试一个短视频上传功能”。最后一道综合设计题分值最大直接给了一个“用户刷视频时出现卡顿”的定位场景要求写出排查思路并给出测试方案。这个结构本身就很能说明问题。快手这类业务型公司笔试并不追求用偏题怪题难倒你而是想看你在有限时间里能不能把测试基础知识和业务场景结合起来。那些“软件测试的目的是什么”“什么是回归测试”这类送分题当然有但占比不大更多题是给你一个具体功能让你说出测试点。所以如果你只会背概念看到后半张卷子会明显觉得吃力。1.2 基础题里藏着业务影子B卷有几道题表面上是测基础理论实际问的是业务表现。比如有一道填空题是“视频播放时出现花屏可能的原因是____”这比直接问“什么是音视频同步”要难得多。你不仅要懂播放器解码的基本流程还得知道弱网丢包、编码格式不匹配、渲染层异常这些常见根因。再比如HTTP状态码那道题不是简单让你写出200和404的含义而是给出了“用户上传视频成功后客户端收到201 Created但进度条一直停在99%”的场景问你如何定位问题。这种问法把知识点从记忆层面拉升到了应用层面我后来面试时才发现这种“现象→根因→验证”的思路正是实际工作中每天都要做的事。1.3 快手测试岗想要什么样的人做完B卷我能明显感觉到快手测试岗的画像第一基础要扎实Linux和SQL是底线第二思维要业务化不能只会点按钮第三要有排查问题的思路遇到线上故障知道从哪里下手。整张卷子没有考任何编程题但自动化框架和接口的概念都有涉及说明他们默认你有一定的代码基础笔试阶段不需要现场写但面诉环节大概率会追问。所以准备这类笔试不能只看测试理论书更要刻意练习“把功能需求转化成测试点”的能力。比如看到一个功能你能在几分钟内列出功能测试、接口测试、异常测试、性能测试各有什么关注点这比背十个测试原则有用得多。2. 理论题背后的实战陷阱等价类、边界值不能只会背2.1 等价类划分在“视频标题输入”上的完整拆解B卷有一道典型的等价类题目视频发布时需要填写标题要求必填、长度1~30个字符请用等价类划分法设计测试用例。如果只背过“有效等价类、无效等价类”的定义很可能会把答案写成输入1个字符有效输入30个字符有效输入0个字符无效输入31个字符无效。这样写不能算错但拿不到高分。高分答案至少要想到“字符类型”这个维度。标题除了长度限制还可能允许中文、英文、数字、emoji甚至空格。所以有效等价类要覆盖1个中文字符、1个英文字符、1个数字、长度在1-30之间且包含多种字符的混合内容。无效等价类要覆盖空值、超过30个字符、纯空格、首尾带空格、特殊符号比如口算符号、控制字符。我当时在答案里专门写了一行剪贴板粘贴超过30个字符时系统是截断还是拒绝这个点后来面试官说很多人想不到。2.2 边界值分析在评论区字数限制中的具体应用边界值题出现在评论区字数限制上。题干我记得是“评论最多输入200字超出后不能提交请用边界值法设计测试用例”。边界值分析的核心是“边界内最接近边界的值、边界本身、刚过边界的值”。这里要测的点应该是199、200、201同时还要考虑0字和1字这种下边界。但这里面有个业务关键点容易被忽略刚好输入200个字符里面包含emoji怎么办一个emoji在UTF-8中可能占4个字节但在界面显示上通常算作一个“字符”。如果开发用的是数据库varchar(200)实际存储可能被emoji占掉更多长度导致保存时超长报错。这种题考的不只是数学边界而是边界和存储规则之间的冲突属于测试人员必须有的“后端意识”。2.3 判定表和因果图推荐流里的逻辑组合B卷虽然没有直接考因果图但有一道简答题问的是“如何测试快手同城页的推荐排序”如果你只用等价类、边界值去答会觉得无从下手。我当时用了类似判定表的思路先列出输入条件——用户是否开启定位、同城页是否有内容、当前网络是否为弱网、用户是否登录再列出预期结果——展示推荐列表、展示空态、提示开启定位、降级为全国内容。把条件组合成一张表逐项填写预期结果这就是判定表的应用。笔试里不需要画得特别规范但要有“先枚举条件再组合验证”的意识。这道题真正想考察的不是你会不会画因果图而是面对一个多条件耦合的功能你能不能有条理地设计用例矩阵。我在现场只画了一个简化的输入条件列表每个条件打钩再写出对应结果最终得分应该不低。3. 用例设计题的隐藏考点短视频场景的专有缺陷3.1 点赞、评论、关注高频操作的用例设计思路B卷有一道题是“请设计快手视频详情页点赞功能的测试用例”。看起来很简单但如果你的答案停留在“点击赞、点赞数加一、再点取消”这种层面基本上就被淘汰了。这道题背后至少藏着三层逻辑前端交互、接口状态、数据一致性。点击点赞按钮后图标是否立即变成高亮状态弱网下是否有loading反馈重复快速点击会不会导致多次请求。接口层面点赞成功返回什么状态码网络超时时有没有重试机制同一用户重复点赞是幂等的还是要报错。数据层面点赞数增加后服务器、客户端缓存、其他用户看到的数量是否一致评论列表里作者头像旁边的点赞状态在退出重新进入后是否还保持。更细一点还要考虑未登录用户点击点赞时是否弹出登录引导登录后是停留在原页面还是跳转以及取消点赞后再次点赞的计数是否准确。我当时把测试用例分成了“功能正常路径、异常输入、中断场景、数据一致性”四组面试官后来评价说思路完整度比单点罗列好很多。3.2 弱网、断网、弱网切换短视频测试的命门快手这类视频App最关键的场景就是网络切换。笔试有一道场景题用户在4G网络下刷视频进入电梯后网络断开走出电梯后网络恢复请描述这个过程中可能出现的问题及测试方法。这道题回答得好不好基本决定了你能不能进入下一轮。我记得当时写了几个必测场景网络断开时播放中的视频是立即停止还是缓冲一段时间断网后继续滑动列表封面图是否变成占位图网络恢复后是否需要用户手动刷新才能加载新内容弱网环境下切换视频是否会出现声音和画面不同步。对应的测试方法是用Charles或Fiddler做网络限速模拟3G/4G/弱网/无网的切换同时抓取接口日志观察播放器状态和请求重试次数。现在回头看这道题的高分关键不是列功能点而是要有“状态机”的思维播放中、缓冲中、暂停中、网络断开每个状态之间怎么迁移迁移过程是否会出现异常。面试官实际上想看你有没有把网络看作一个可以随时打断业务的变量。3.3 缓存一致性与多端同步容易漏掉的用例B卷有一道填空/简答题问短视频“离线缓存”功能需要测试哪些点。很多人只想到“缓存后可以在无网环境下观看”但忽略了缓存与在线播放之间的数据一致性。比如缓存了一个视频再在线播放同一个视频观看进度是否同步缓存内容被清理后历史记录里的封面图和标题是否还能正常展示。多端同步的考点在另一个问题中出现用户A在手机端点赞了某条视频在iPad端登录同一账号后点赞状态是否同步。这牵扯到客户端本地缓存和服务端的状态校验不是简单看接口返回就行。我当时给了一个具体用例先在手机端点赞然后立刻在iPad端查看该视频判断点赞数是否变化再在iPad端取消点赞回到手机端刷新验证点赞状态是否被正确覆盖。这样的题目说明快手非常关注真实用户场景下的数据流。测试人员不能只测“单机功能”要时刻想着用户会换设备、会断网、会清缓存。这些场景在大学课程里很少被强调但在业务型公司的笔试题里几乎必出。4. Linux与数据库笔试里的“送分题”其实并不送分4.1 日志分析命令行从tail到awk的组合拳B卷的Linux题不算难但考得很实际。有一道题是请使用Linux命令查看某应用日志文件的最后100行并统计包含“error”关键字的行数。最简单的是tail -100 app.log | grep -c error这个大多数人都能写出来。但我觉得高分答案应该进一步考虑日志文件可能很大tail -100是先从尾部截取100行再做筛选这种方式比grep -c error app.log全量扫描快得多因为后者需要读整个文件。还有一道考察awk的题目非常接地气日志中有一列是用户ID如何统计每个用户的请求次数我当时写的是awk {print $1} access.log | sort | uniq -c。这里的考点有两个一是awk能把第一列取出来二是sortuniq -c的组合能完成分组计数。如果对Linux不熟只记得几个零散命令这道题很有可能卡住。我后来在面诉时被追问是否熟悉tail -f定位线上问题这说明快手测试日常大概率会涉及实时日志排查。4.2 一条SQL查每个用户的视频发布量数据库题考察的是统计查询。大致题目是给定用户表和视频表请统计每个用户的视频发布数量并按数量降序排列。标准SQL是SELECT u.user_id, COUNT(v.video_id) AS video_count FROM user u LEFT JOIN video v ON u.user_id v.author_id GROUP BY u.user_id ORDER BY video_count DESC;这道题看似简单但有两个易错点。第一必须用LEFT JOIN而不是INNER JOIN否则没有发布过视频的用户会被过滤掉。笔试里很多人写完觉得没问题却漏掉了没发过视频的用户。第二GROUP BY后面必须包含user_id或各组的唯一键否则在严格模式下会报错在非严格模式下统计结果可能张冠李戴。我还在旁边注释了一句如果视频表非常大可以在临时表里先按作者聚合再关联用户表减少大表JOIN的数据量。4.3 笔试中怎样快速验证SQL正确性当时笔试不允许运行SQL纯靠手写。我的验证方法很简单手动构造三行数据自己当数据库一步步算一遍看结果是否符合预期。比如用户表里有两个用户视频表里有三条视频其中一条作者ID对应不在用户表里一条用户没有发过视频。我用这个最简数据集推演SQL的执行过程很快能发现JOIN类型和GROUP BY列的问题。这个方法听上去笨但在手写SQL时特别管用。很多测试同学写SQL只依赖IDE的自动补全和运行结果到笔试手写阶段就心里没底。平时练习时即使不写代码也要在纸上多构造小数据集做推演。能写好统计SQL等于笔试已经拿下一城。5. 接口和自动化HTTP状态码、Appium和一道框架设计题5.1 手写HTTP请求头需要关注的字段与状态码语义B卷有一道题让写出一个HTTP POST请求的必备字段并且说明各字段的作用。我看到题时先写了URL、Method、Headers、Body四部分Headers里写了Content-Type、Content-Length、User-Agent、Authorization。这道题真正想考察的是你写的请求头能不能被服务端正确识别以及请求头里的校验字段有没有缺失。另一个考点是状态码语义。除了常见的200、404、500我记得判断题里出现了301和302的区分以及304 Not Modified。快手这类内容型产品客户端会大量使用本地缓存304状态码的语义是“客户端有缓存服务端告知未修改”这直接影响播放器是否重新拉取CDN资源。如果测试人员不理解304很容易把正常缓存策略误判成接口异常。5.2 Appium元素定位时最容易踩的坑自动化相关内容没有要求写完整脚本但简答题里有一道在使用Appium测试快手App时如何定位“关注”按钮。我当时最先想到的是resource-id和text组合但快手这类App有大量自定义控件id可能不唯一text可能在多端不一致所以只用一种定位策略是不够的。我给出的思路是先尝试resource-id若找不到用xpath定位父节点text子节点再不行利用uiautomator viewer查看当前页面的控件层级看看是否有动态变化的content-desc。这里有个经验很多新手一上来就用find_element_by_id一旦失败就不知道怎么办。实际笔试题不会真让你跑Appium但会看你有没有“定位失败时的备选方案”这跟日常写自动化脚本是一样的。5.3 如果让你设计一个短视频App的UI自动化框架B卷最后一道设计题我印象里是为快手App设计一套UI自动化测试框架要求考虑用例稳定性、执行速度和持续集成。这道题完全可以写成一篇文章但在笔试半小时内需要挑核心点回答。我当时从三个层面拆解用例层用Page Object模式封装每个页面的元素和操作、执行层使用Appium连接多台设备并行跑提高速度失败用例自动重试两次排除偶发因素、集成层接入Jenkins每次代码合并后触发冒烟测试再全量回归。特别要提到“用例稳定性”这个关键词因为UI自动化最大的痛点就是用例不稳定。我把稳定性方案分成了三类等待策略不使用固定sleep改用WebDriverWait轮询元素、数据隔离每个用例独立注册测试账号避免接口脏数据影响、环境还原用例结束后清理缓存、回到首页保证下一条用例初始状态一致。这样写可能不会让面试官觉得你是框架专家但能看出你确实踩过自动化测试的坑。笔试不是面试不会要求你现场敲代码但需要有完整的框架设计思路。6. 性能与兼容性面向视频流的考题比想象中更细6.1 秒开率、卡顿率、掉帧数据怎么设计测试场景B卷有一道性能相关题如何评估快手App的视频播放性能。这道题如果只写“响应时间小于3秒”就太单薄了。视频产品的性能指标不是单点响应时间而是一组围绕播放体验的数据首次帧渲染时间首帧时长、视频秒开率、播放卡顿率、平均掉帧次数、内存占用等。我当时给出的场景设计是在启动App后点击同城页第一条视频从用户点击到第一帧画面出现的时间记为首帧时长。连续滑动20条视频统计播放过程中卡顿总时长和卡顿次数。网络用Wifi和4G分别测并且要把系统CPU降频、后台运行其他App等干扰因素考虑进去。结果记录不能只记平均值还要看P95/P99因为短视频用户对偶发卡顿的容忍度更低。6.2 弱网模拟和不同机型覆盖的思路弱网模拟题在B卷出现了不只一次我记得有一道填空题让你列出常用的弱网工具。可选的答案有Charles、Fiddler、Network Link Conditioner、Qnet等。这题对应的核心点在于弱网不是一种固定状态而是要模拟丢包、高延迟、低带宽、抖动等多种组合。快手用户分布差异很大从地下室到高铁网络环境千奇百怪测试如果只测“网速慢”这一种情况肯定不够。机型覆盖方面笔试问的是如果你只能选择三台手机做兼容性测试你会怎么选。我当时答的是覆盖Android低端机如骁龙4系、iOS老机型如iPhone 8和一台最新旗舰机。理由很简单低端机内存和CPU有限最容易暴露卡顿和OOM问题老机型系统版本旧容易出现接口兼容和图片显示问题旗舰机用来验证视觉效果和性能上限。这道题背后是“如何用最少的资源覆盖最大风险”的思路测试工作中非常实用。6.3 内存占用题的现场推演有一道题给出了两个内存数据一个是短视频App在滑动列表时内存从180MB涨到350MB另一个是退出播放页面后内存回落到200MB问这两个数据是否正常。很多人看到350MB会觉得内存异常但如果考虑视频解码和图片缓存滑动列表时内存上涨是正常的关键是退出后能不能释放以及400MB是不是超过系统限制。正确的解答思路是先确认测试机型的总内存和系统阈值再看退出页面后的回落曲线如果回收不及时可以用adb命令adb shell dumpsys meminfo 包名观察内存状态变化。笔试题目不会要求你写命令但会看你有没有“内存泄漏和内存峰值是两回事”的判断。我当时在答案里写了只要不会导致低端机被系统杀掉并且退出后能稳定回落到正常区间就算是可以接受的行为但需要做进一步压测确认内存不会无限上涨。这个思路让阅卷人知道我不是简单地拿数字大小做结论。7. 复盘笔试之后才明白的事7.1 时间分配与答题顺序B卷的时间我记得挺紧张选择和填空占据了前面大部分时间。我当时的策略是先花5到8分钟快速扫一遍整卷把有把握的题目序号标出来然后果断先做简答题和综合设计题因为这类题分值高、思路可以写得很充分。等把大题写完了再回来补充选择题细节避免“在单选上纠结太久最后大题来不及展开”。这个策略后来的确帮了我前面有两道Linux命令题我不太确定但我没有一直卡着而是先跳过留到最后再凭印象写。最终大题用例设计写了整整一页纸应该是我能进入后续面试的关键。如果你的目标是笔试通过一定要记住综合设计题的得分上限远高于选择题宁可多写几个有落地的测试点也不要为了一个定义空着。7.2 别在概念题上恋战设计题才是分水岭复盘整张卷子我最大的体会是概念题做得再好最多证明你读过书而设计题能看出你有没有真实测试经验和业务洞察。比如“评论功能测试”这种题目一个没有实操经验的人也能写满但写出来的很可能都是“输入正常内容、输入超长内容、点击发布”这种浅层用例。真正有经验的测试会想到断网发布、草稿保存、评论排序、审核拦截、他人可见性等场景。B卷的分水岭就在这些细节上。如果你在考前只是刷了一堆概念题看到“测试评论功能”可能觉得简单但真正动笔写的时候却发现没有内容。所以准备这类笔试最有效的方法是打开任何一个短视频App挑一个平时不用的功能逼自己列20条用例。练上三五次考场上就不怕设计题了。7.3 给后面人的几点准备建议第一把Linux命令、SQL统计、HTTP状态码这三个基本功刷到肌肉记忆。题目不会直接问“什么是awk”但一定会让你在日志场景里用它。第二准备一个自己熟悉的业务场景比如刷视频、发评论、看同城推荐把测试用例设计、接口验证、弱网异常、数据一致性都串一遍笔试中碰到类似的题就能直接复用框架。第三别忽视“写清楚”这件事。笔试阅卷时间有限你的答案如果只有几个关键词得分不会高用编号、列表、分段把思路写清楚印象分会提升不少。我记得当时考完走出教室和旁边几个同学聊了几句有人一直在懊悔某个选择题选错了我却一直在回想那道点赞功能设计题有没有漏掉“连续点击”的用例。这种心态差异也决定了之后面试准备的节奏。现在回头看快手这套B卷考的不是你有没有背过标准答案而是你有没有真正把自己放到用户的位置上去琢磨一个功能可能出的问题。把这种思维方式练成习惯笔试和面试也就没有想象中那么可怕了。