快手2019年秋季校园招聘笔试试卷——测试A试卷这份卷子我印象挺深。当时不少目标是测开和测试岗的同学看到“测试A”三个字以为就是纯理论选择题结果一上手才发现两小时里既要写测试用例设计思路又要做编程题、Linux命令题、SQL查询还夹杂着和短视频业务结合的场景分析。说实话这类笔试才是大厂测试岗的真实门槛不是考你会不会背“黑盒白盒”的定义而是看你在限时压力下能不能按测试工程师的思维去拆解问题。这份试卷对2025届甚至更晚的同学依然有很强的参考价值。虽然年份比较早但快手这几年测试岗笔试的核心命题逻辑没有变基础理论打底编程和计算机基础是分水岭业务场景题决定你能不能拿高分。我结合当年参加笔试的候选人多轮复盘以及公开渠道能看到的题目信息把这份试卷涉及的高频考点、答题思路和备战路径完整拆一遍。无论你是第一次参加互联网大厂秋招的应届生还是想转行做测试的社招新人这篇都能直接当备考地图用。1. 快手秋招测试岗笔试全貌时间、题量与考点权重先看整体情况。快手2019年秋季校园招聘的笔试是线上统一作答测试岗分为A卷和B卷A卷面向测试工程师偏业务测试B卷通常偏测试开发。测试A试卷满分100分考试时长120分钟。从题型分布看不是单纯的选择题机考而是主客观混合需要键盘输入答案的题目占比不低。1.1 典型题型与分值结构根据参加过笔试的同学反馈以及社区里的面经汇总快手测试A试卷的题型大致如下题型大致题量分值占比考察重点单项选择题20题左右20%-25%测试基础理论、数据结构、操作系统、网络多选题10题左右10%-15%Linux命令、SQL语法、测试工具使用判断题5-10题5%-8%基础概念的精确理解容易抠字眼简答/设计题3-4题25%-30%测试用例设计、场景分析、缺陷报告写作编程题1-2题20%-25%字符串、数组、基础算法语言不限数据库/Linux操作题2-3题10%-15%多表联查、聚合函数、常用命令实操单看分值占比测试基础理论加上业务场景题能占到一半以上这一点和其他技术岗笔试有明显差异。做这套题的时候不能只按程序员的标准要求自己还要带着质量保障的视角去思考每一道题背后想验证什么能力。1.2 时间分配策略120分钟做这么多题时间其实很紧。不少人的惨痛教训是前面选择题犹豫太久结果编程题只能交白卷。我的建议是这样分配前30分钟完成选择题和判断题。这类题不要反复纠结凭第一直觉快速作答拿不准的先标记跳过。中间40分钟做简答题和测试用例设计题。这部分是拉开差距的关键答案需要组织语言宁可多写也不要空白。后面35分钟编程题和SQL/Linux题。编程题如果一时没有思路先暴力解法拿部分分再优化。最后15分钟检查前面标记的题补漏。这里特别提醒一句测试岗笔试和开发岗笔试不一样不是AC了编程题就能进面试。快手更关注你测试用例设计得有没有层次、边界考虑得全不全、有没有结合业务特点去思考。就算编程题只做出了一半但是场景分析题思路清晰一样能过笔试。1.3 与其他大厂测试笔试的差异点对比腾讯、阿里、字节同期的测试岗笔试卷快手的测试A试卷有两个明显特点一是业务绑定度高。考题里经常出现视频播放、直播互动、弹幕、礼物打赏这类快手核心业务场景不是抽象地让你测一个“登录功能”而是给你一个具体的业务背景比如“用户在弱网环境下上传视频失败请设计测试用例”。这就要求候选人对短视频产品有一定的使用体验和业务理解。二是工具考察偏实用。Linux命令、SQL查询、日志分析这些题目占比不低而且考得很细。不是问你“grep是什么意思”而是给你一段日志让你用命令统计某个接口每天的调用量。这种题光背概念不行真得在命令行里敲过才能快速反应过来。2. 测试基础理论题的高频陷阱与解题思路不管年份怎么变测试基础理论永远是测试岗笔试的基本盘。但这里要提醒的是快手这套A卷里的基础理论题并不是考教科书上的原话而是把理论放到具体场景里看你会不会用。我挑几个反复出现的考点展开讲。2.1 等价类划分与边界值分析不是背公式而是找“度”等价类划分和边界值分析是测试用例设计的两大基础方法笔试中几乎必考。但很多人做题时会犯一个典型错误只考虑有效等价类忘了无效等价类。举个例子一道常见的题某App支持用户设置年龄输入框要求输入1-150之间的整数。请设计测试用例。很多人会这样写输入1通过输入150通过输入50通过输入0不通过输入151不通过输入负数不通过表面上看很完整但只覆盖了等价类和边界值。真正的高分答案会多加几类输入小数如18.5验证是否做了整数限制输入汉字、字母、特殊字符如“abc”“#”验证输入类型校验输入超长字符串验证长度限制输入空格或全角数字验证格式处理输入为空、不输入直接提交验证必填项提示用SQL注入语句、XSS脚本等作为输入验证安全性和转义处理为什么这些是加分项因为快手这类App的注册信息最终会写入后端数据库并展示在个人主页。测试工程师如果只测“能不能存进去”不测“脏数据会不会影响展示”到了线上就会出问题。笔试考的不是你会不会列出等价类而是你有没有形成“正常路径异常路径安全路径”的完整测试思维。我当时在做这类题时给自己定的标准是至少写出8-10条测试点并且每条都要说明“输入什么、预期结果是什么”。如果你能额外写出“该用例覆盖了哪个测试方法”那就更稳了。2.2 黑盒测试与白盒测试的选择题别被定义绕晕选择题里经常出现类似于“以下哪种测试方法属于黑盒测试”的题目选项里有等价类划分、边界值分析、语句覆盖、判定覆盖、因果图、错误推测法、逻辑覆盖。正确答案是等价类划分、边界值分析、因果图、错误推测法而语句覆盖、判定覆盖、逻辑覆盖属于白盒测试。这类题不难但容易因为概念混淆丢分。我有一个比较实用的记忆方法黑盒测试不关心内部代码结构只关心输入输出的对应关系所以凡是“从需求出发设计用例”的方法都是黑盒白盒测试要分析代码逻辑所以凡是“覆盖代码行/语句/分支/路径”的方法都是白盒。不过笔试里更狠的考法是反过来出给你一段简单代码问你如果要做到语句覆盖至少需要几个测试用例。这就变成白盒测试的覆盖计算问题了。这种题建议提前复习一下语句覆盖、分支覆盖、路径覆盖的基本计算方法。比如一个简单的if-else结构语句覆盖通常1-2个用例就够了路径覆盖则需要覆盖所有可能的分支组合。2.3 缺陷生命周期与Bug单写作考察的是专业表述能力测试A试卷的简答题里有一类必考给你一个缺陷描述让你补充完整Bug单或者让你判断Bug的严重程度和优先级。这类题的坑在于很多人分不清“严重程度”和“优先级”的区别。严重程度Severity是缺陷本身对系统的影响程度优先级Priority是修复该缺陷的紧急程度。两者有联系但不是一回事。一个低严重程度但高优先级的典型例子是App的logo显示成了默认图虽然不影响功能但品牌部门会要求立即修复。一个高严重程度但低优先级的例子是某个冷门功能在特定机型上崩溃影响用户数极少可以放到下个版本修复。实际答题时Bug单至少需要包含以下要素缺陷编号所属模块缺陷描述前置条件、操作步骤、实际结果、预期结果严重程度优先级复现概率测试环境操作系统、设备型号、App版本、网络环境附件截图、日志、录屏笔试时如果时间有限可以简写但“前置条件操作步骤实际结果预期结果”这四个维度绝对不能缺。这体现的是专业测试工程师的基本素养大厂尤其看重这一点。3. 编程与Linux操作题不刷后悔的硬核部分测试岗笔试考编程和Linux刷掉了一大批只会手工测试的同学。快手的测试A试卷也延续了这一点——编程题和Linux/SQL题加起来占了30%左右的分值而且这部分是客观题和主观题混合很难蒙。想在笔试中脱颖而出这块必须有扎实的基本功。3.1 编程题的高频类型与实战解法快手测试A试卷的编程题难度大概在LeetCode Easy到Medium之间重点考察字符串处理、数组操作和基础数据结构。和开发岗的编程题相比不会出特别偏的算法题更看重代码的规范性、边界条件的处理能力。以一道出现频率很高的题为例给定两个字符串版本号v1和v2比较两者的大小。版本号由数字和点组成例如1.0.0、2.1.3。如果v1大于v2返回1小于返回-1相等返回0。这道题看起来简单但能测试出候选人是否考虑到位。核心思路是按点号切分逐段比较数字大小缺省位补0。用Python实现def compare_version(v1: str, v2: str) - int: parts1 v1.split(.) parts2 v2.split(.) max_len max(len(parts1), len(parts2)) for i in range(max_len): # 缺省位补0 num1 int(parts1[i]) if i len(parts1) else 0 num2 int(parts2[i]) if i len(parts2) else 0 if num1 num2: return 1 elif num1 num2: return -1 return 0这道题的高频易错点有三个一是忽略“1.0”和“1.0.0”是相等的版本号如果只按切分后的长度比较就会判错所以必须补0处理二是版本号的每个段可能超过int范围但在笔试场景下一般不会那么极端用int即可三是注意输入可能包含前导零比如“01.2”使用int()转换可以自动处理但如果用字符串直接比较就会出错。另一个高频类型是字符串操作题例如“给定一个字符串统计每个字符出现的次数按出现次数降序输出”。这种题在测试岗笔试里很讨巧因为它既考察基础的哈希表使用又隐含了排序和格式化输出的能力而这些恰恰是做测试开发时需要频繁使用的技能。3.2 Linux命令这些命令一定要形成肌肉记忆快手测试岗笔试的Linux题考得很实际基本都是测试工程师日常排查问题时会用到的命令。我把最高频的命令整理成了表功能命令常见用法查看进程ps / topps -ef | grep javatop动态观察CPU和内存查看端口netstat / ssnetstat -tlnp | grep 8080查看日志tail / head / lesstail -f app.logtail -n 100 app.log文本处理grep / awk / sedgrep ERROR app.log | wc -l权限修改chmod / chownchmod 755 script.sh磁盘空间df / dudf -hdu -sh logs/网络请求curlcurl -I http://example.com/api压缩解压tar / ziptar -zcvf backup.tar.gz logs/查找文件find / locatefind /home -name *.log笔试题目经常这样出线上接口报错了给你一段日志文件在打印题里模拟让你排查问题。如果熟悉组合命令回答起来会很占优势。举个例子假设接口响应时间突然变慢需要排查哪类请求耗时最长可以通过下面的命令组合快速定位awk -F, {print $4, $5} request.log | sort | uniq -c | sort -k1 -nr | head -20这道题考察的本质是能否从非结构化日志中提取关键字段、排序、去重、统计。这些都是测试工程师的日常基本功。如果笔试里出现了这类操作题可以直接把命令写出来并简述执行结果的判断依据。即使没有真实环境考官也能看出你的实战能力。3.3 SQL题多表联查和聚合函数是重点SQL操作题在测试A试卷里属于“性价比最高”的部分——只要练过就能拿分没练过就只能凭感觉猜。高频考点集中在多表联查INNER JOIN、LEFT JOIN、聚合函数COUNT、SUM、GROUP BY、子查询和排序。一道典型的题目是有三张表用户表usersid, name、视频表videosid, user_id, duration、播放记录表play_recordsid, video_id, play_time。请查询每个用户发布的视频被播放的总次数按播放次数降序排列输出用户名和播放次数。标准答案SELECT u.name, COUNT(p.id) AS play_count FROM users u LEFT JOIN videos v ON u.id v.user_id LEFT JOIN play_records p ON v.id p.video_id GROUP BY u.id, u.name ORDER BY play_count DESC;这道题考察的点很全面JOIN方向的选择LEFT JOIN保证没有发布视频的用户也能显示、GROUP BY的字段匹配MySQL中GROUP BY主键即可但SQL标准的严格模式下需要把所有非聚合列都加进去、COUNT计数的对象COUNT(p.id)而不是COUNT(*)避免统计到用户没有视频时产生错误计数。SQL题在笔试里想拿满分建议按以下步骤检查先确认要查询的字段属于哪几张表明确JOIN关系。判断用INNER JOIN还是LEFT JOIN看题目是否需要保留无匹配记录的表。聚合后是否需要对结果过滤如果需要用HAVING而不是WHERE。排序字段和排序方向是否正确。4. 移动端与短视频业务场景题拉开差距的地方要说快手测试A试卷里最有辨识度的部分一定是移动端与短视频业务场景结合的题目。这套卷子想要的人是“懂测试、也懂业务”的测试工程师所以卷二里的场景分析题特别多也更贴近快手实际的产品形态视频拍摄、上传、转码、播放、直播、互动、评论、私信、推荐流。4.1 视频上传与转码链路测试一道典型的场景设计题笔试中出现频率很高的一道题是“用户上传一个2GB的4K视频可能遇到哪些问题请设计测试用例覆盖全流程。”这道题考核的其实是两条链路客户端上传链路和服务端转码链路。先看客户端侧视频过大时上传是否支持断点续传断网恢复后能否从断点继续上传弱网环境下3G、地铁、电梯上传是否超时超时后的重试策略是什么上传过程中App切到后台或被杀掉重新打开后状态是否一致上传过程中手机存储空间不足是否有明确提示视频格式不支持如拍摄过程中损坏是否有错误提示并引导用户重新录制上传的同时用户退出登录任务是否终止重新登录后能否恢复再看服务端侧2GB视频的转码耗时是否需要用户等待是否采用异步任务并反馈进度转码失败后是否有重试机制失败原因如何反馈到客户端不同分辨率720P、1080P、4K的转码输出是否符合预期转码中间文件是否及时清理避免占用服务端存储空间。高并发上传场景下服务端是否会拒绝请求限流策略是否合理这道题想拿高分不能只答“测功能”还要体现你的链路思维从用户操作入口到服务端处理再到用户端的结果反馈每一个环节都要有对应的测试点。我当时备考时养成了一个习惯拿到任何业务场景先画一条链路图把UI层、业务逻辑层、服务端、数据库、第三方依赖全部列出来再针对每个节点补测试点。这个习惯在笔试里帮了大忙。4.2 播放器与网络测试弱势网覆盖的完整方案短视频App最核心的体验是播放所以播放器相关的测试题也是这套A卷的重头戏。结合相关热搜词里大家关心的“网速测试”“rtmp测试地址”“内存测试”基本可以推断出快手笔试的侧重点弱网测试、播放卡顿、首帧时间、内存占用。播放器类场景题通常这样出用户在弱网环境下刷视频经常出现卡顿和加载失败请设计测试方案。回答时需要覆盖以下几个维度功能维度首帧加载时间从点击视频到画面出现耗时多久是可接受的播放进度条拖动拖动后是否能快速seek到指定位置清晰度切换不同网络状态下是否自动切换清晰度1080P切到480P播放失败重试失败后是否自动重试重试几次前后台切换切后台再回前台播放状态是否正确保留弱网专项模拟不同网络类型2G、3G、4G、5G、Wi-Fi下的播放行为模拟丢包、高延迟、抖动场景验证播放器的容错能力网络恢复后播放器是否自适应恢复清晰度性能专项播放过程中的CPU占用率是否稳定会不会出现持续走高内存是否会随着播放时长增长而不断膨胀切换多个视频后发现内存无回收基本可以判定有内存泄漏。长时间播放的耗电情况后台播放是否被系统限制播放类问题的排查思路也值得了解。比如上报“播放卡顿”问题时不能只反馈一句“卡顿”要能说明是用例的复现步骤、设备型号、App版本、网络环境最好再附上播放器日志和抓包信息。测试工程师如果能通过Charles或Fiddler抓包对比下发的视频流地址和CDN节点往往能帮开发快速定位问题出在调度策略还是网络链路。4.3 直播与互动场景高并发下的测试设计快手除了短视频直播也是核心业务。测试A试卷里有一类和直播相关的题目比如“直播聊天室同时在线人数突破百万如何设计压测方案”这种题对没有接触过服务端性能测试的同学来说会比较陌生但核心考点很一致高并发、消息实时性、数据一致性。直播场景的测试设计可以从这几层展开客户端层万人直播间内弹幕和礼物的实时渲染是否存在卡顿网络抖动时消息是否出现乱序和丢失不同机型渲染弹幕的性能表现低端机是否出现UI线程阻塞服务端层百万用户在同一个直播间消息通道是否支持水平扩展弹幕消息的推拉模式选择全量推送还是按房间维度推送热点房间是否触发限流规则限流后的降级策略是什么数据一致性用户赠送礼物后金币扣减与礼物特效是否一致直播结束后回放视频与聊天记录是否完整归档排行榜数据能否做到秒级更新答这类题时最好加上具体的压测方案使用JMeter模拟千级、万级、十万级并发逐步加压观察TPS、响应时间、错误率、CPU和内存使用率。如果能写出一套完整的压测流程在笔试中会显著加分。4.4 兼容性与性能测试简历上一定要有的亮点移动端App测试中兼容性和性能测试几乎是每个岗位的必问项。快手这种拥有海量安卓机型用户的App兼容性测试要求尤其高。兼容性测试的核心关注点操作系统版本最低支持到哪个版本不同版本的系统权限管理差异Android 6.0运行时权限、iOS 14的隐私权限是否被正确处理屏幕分辨率刘海屏、水滴屏、折叠屏、全面屏的适配情况。硬件差异不同厂商定制ROM对App存活策略的影响如华为、小米、OPPO、vivo后台清理策略不同可能导致推送接收失败。网络制式5G、4G、双卡切换时网络是否存在闪断。性能测试的核心关注点启动时间冷启动、热启动是否有明显差异内存占用持续使用30分钟、1小时后内存是否稳定在合理范围内存泄漏使用LeakCanary等工具检测Activity泄漏、Fragment泄漏。卡顿监控通过BlockCanary监控主线程耗时任务。流量消耗播放视频时每五分钟流量消耗是否正常这里提醒一下兼容性和性能测试这部分特别适合作为笔试后的面试谈资。笔试只是一个门槛面试官更关注你实际做没做过。建议在校期间用一台旧手机装一个开源App跑一遍内存监控和启动时间测试把过程写成博客或者整理成文档面试时直接展示效果比背一百道理论题都强。5. 从笔试反推备战路径工具链与面试准备要点快手测试A试卷的考点分布其实已经把测试工程师这个岗位的核心技能树画得明明白白测试理论打底、代码能力加分、Linux和SQL是日常排查问题的左膀右臂、业务理解决定你能走多深。下面这份备战路径是根据历年笔试题目倒推出来的照着准备基本不会跑偏。5.1 工具链清单现在就可以动手搭的环境不管已经投了简历还是还在准备阶段工具链越早搭建越好。笔试只是初步筛选面试和实习才是真正动手的环节。我整理了一套自测用的工具链学完就能覆盖笔试里的大部分工具类考点。方向工具用途学习建议接口测试Postman接口调试与自动化至少能完成一个GET和POST请求的断言接口自动化Python requests批量接口回归结合pytest写一个数据驱动的测试脚本UI自动化Appium pytest移动端UI自动化能启动App并完成一个简单的点击流程持续集成Jenkins自动化任务调度能创建一个定时执行测试脚本的Job抓包工具Charles / Fiddler网络请求分析、弱网模拟会设置断点、断网、弱网模拟性能测试JMeter接口压测会配置线程组、聚合报告和断言缺陷管理Jira / 禅道Bug生命周期管理熟悉缺陷流转流程即可这里面最关键的是Python requests pytest这套组合因为笔试编程题和面试手写用例都能用到。建议用一周时间写一个针对任意网站接口的自动化用例重点练习接口关联和断言。5.2 实战项目怎么做工具链光看不练等于零。如果想在笔试和面试中体现项目经验最好的办法是自己做一个“麻雀虽小五脏俱全”的测试项目。不需要多复杂但要有完整的测试流程。一个可以复用的项目路径找一个开源项目比如一个简易的待办事项管理Web应用本地启动服务。用Postman调试接口整理出核心接口清单增删改查。用Python requests pytest编写接口自动化测试用例。引入pytest-html插件生成可视化测试报告。在Jenkins上创建一个任务配置构建触发器实现每天凌晨自动执行测试并发送结果邮件。这个项目做完之后笔试里和自动化、持续集成相关的题目基本都能答上面试时也拿得出手。关键是过程中一定要用版本管理工具比如Git/GitLab把代码提交记录整理清楚这也是大厂测试开发岗面试常问的点。5.3 业务理解从“点工”到测试工程师的分水岭最后一个想重点说的是业务理解。笔试里的场景题比如“短视频App的发布功能测试”“直播间礼物特效测试”考察的其实不是你会不会写用例而是你有没有完全理解这个业务是怎么运转的。拿短视频发布功能来举例。一个只停留在功能层的测试会关注能不能拍摄、能不能上传、有没有滤镜、能不能剪辑、发布成功后能不能在主页看到。而一个有业务思维的测试会多思考几层用户发布视频的核心动机是什么是记录生活还是获取关注还是参与平台话题活动发布效率对用户留存的影响有多大如果上传失败率超过5%用户流失会有多严重推荐算法会给新发布的视频分配初始流量吗这个流量池和发布功能有没有联动自己做的App有哪些特殊业务指标比如日均发布量、审核通过率、举报率这些思考不是笔试现场能憋出来的需要平时就对自己常刷的产品做刻意练习。我自己的方法是每用一款新App就强制自己写一份“功能测试业务分析”文档先拆功能模块再思考每个模块的产品目标和核心指标最后写测试要点。坚持几个月做场景分析题时思路会明显不一样。从快手这份2019年秋季校招测试A试卷往回看这几年大厂测试岗的笔试命题风格虽然一直在变但底层逻辑始终如一既要懂测试方法也要会写代码更要理解业务。把本文提到的几块内容踏踏实实过一遍笔试大概率不会拖你后腿。最后再分享一个我踩过的坑笔试时千万别在一道选择题上卡超过两分钟测试岗的卷子题量大、维度杂留时间给后面的场景题和编程题才是最优策略。祝各位都能拿到心仪的offer。