又到一年秋招季手边正好翻到一份快手2019年秋季校园招聘笔试试卷—测试B试卷。很多准备投测试开发、测试工程师岗位的同学一看到“笔试试卷”四个字就开始紧张总觉得笔试要考很高深的算法、很偏的底层原理其实测试岗的笔试更像一张“能力体检表”考察的是你平时有没有真正动手做过测试、有没有把基础理论吃透。这篇文章我就结合这份试卷的考核方向以及我在测试行业干了这么多年带新人、参与招聘的经验把测试岗笔试里最常考的几块内容、做题思路和失分点全部拆开讲清楚给准备秋招的你一份可以直接照着复习的清单。不管你是科班出身还是半路转测试只要按这个思路去准备至少能避开80%的坑。和很多同学聊完我发现大家真正焦虑的不是“会不会做题”而是“不知道测试笔试到底考什么”。所以这篇我尽量写得具体一点从考试题型拆到考点底层逻辑再给到能落地的复习动作希望能帮你在笔试现场心态稳一点、答题思路顺一点。1. 笔试题型与整体设计思路拆解1.1 从“测试B试卷”看测试岗笔试的底层逻辑快手2019年秋季校园招聘笔试试卷—测试B试卷这份试卷最核心的定位就是“校招测开/测试工程师”岗位。很多人以为笔试只考代码题实际上测试岗笔试的题目设计遵循一个非常明确的逻辑能不能用工程化的方式发现和解决质量问题。它不追求你写一个多牛的系统而是考察你在一个项目周期里能不能把测试计划、用例设计、缺陷分析、质量评估这些事做明白。“B卷”一般是和“A卷”对应的概念通常A卷和B卷的难度相当但考察侧重点会换一批考点目的是防止前后考场的考生互相传答案。所以你在考场上遇到“B卷”不需要慌它和网上流传的“A卷”只是题目顺序或局部内容不同核心知识范围是一致的。真正要关注的是试卷里反复出现的那些能力标签测试理论基础、用例设计能力、Linux和数据库操作、自动化脚本思路、性能与兼容性意识。1.2 题型分布与时间分配从我看到的历年测试笔试题型和多个大厂的校招真题来分析这类试卷一般由三到四大块组成。第一块是客观题包括单选题、多选题、判断题主要覆盖测试理论、软件开发流程、网络基础、操作系统基础第二块是主观题通常是给出一个功能模块让你写出测试用例或者给定一个bug描述让你补充分析第三块是编程/脚本题可能要求你用Python或Shell写一个小工具做接口测试或日志分析有些试卷还会加一道场景设计题比如“如何测试一个视频App的播放功能”、“如何测试一个推荐系统”。时间上一份100分钟到120分钟的试卷我建议客观题控制在25分钟左右不要纠结太久。主观用例设计题是拿分重点至少要留40分钟。最后的编程题哪怕写不完整也一定要写思路、写伪代码把关键步骤和注释写清楚阅卷人能看到你的工程思维。1.3 判断自己属于哪一类测试方向在准备笔试前先想清楚自己要投的是“测试工程师”还是“测试开发工程师”。这两个方向在笔试中的权重有明显区别。基础测试岗更偏向用例设计、手工测试流程、缺陷管理代码题难度会低一些测开岗则更强调自动化框架、CI/CD、性能工具、代码能力。快手秋招的测试B试卷从岗位属性看通常是面向测开和测试工程共同招聘所以代码题一定会有但不至于像算法岗那样变态。我见过很多同学栽在这一步简历上写着“熟悉自动化测试”结果笔试里遇到一道pytest入门题都写不出来。所以在笔试前先诚实地评估自己的水平。如果自动化只是用过录制回放工具那就把功夫花在补Python基础和接口测试框架上不要硬往测开方向冲。2. 测试理论基础与用例设计笔试的重头戏2.1 黑盒、白盒、灰盒概念题不是靠背的测试理论是客观题的绝对主力而黑盒、白盒、灰盒又是最基础的概念。很多同学背得很熟黑盒不看内部实现白盒看内部逻辑灰盒介于两者之间。但笔试真正拉开差距的地方是给你一个具体场景让你判断用了哪类测试方法。举个例子题目问“针对一个登录接口根据数据库中的用户状态来设计不同返回结果的验证属于什么测试”。这时候很多人会犹豫因为它既涉及了外部输入输出又涉及了数据库内部数据。其实回归到定义白盒测试是基于内部结构和逻辑的测试如果你能看到代码分支、数据库表结构并且基于这些内部信息设计用例那就是白盒或灰盒。所以这道题更准确的答案是白盒测试因为你已经参考了内部数据状态。我给大家一个非常实用的判断口诀只看界面和外部功能的是黑盒要去看代码、看流程图、看数据库的是白盒既要看外部功能又要确认内部数据流转的是灰盒。有了这个标准客观题基本不会错。2.2 用例设计方法等价类、边界值、场景法的组合拳主观题的用例设计阅卷人最喜欢看到的不是罗列一堆操作步骤而是体现方法论的用例。比如“测试一个输入框要求0-100的整数”如果你只写了“输入50输入101”逻辑上没错但显得很单薄。好的回答会长这样等价类划分有效等价类0到100之间的整数、无效等价类小于0、大于100、非数字、小数、空值、特殊字符边界值分析0、100是上点-1、101是离点1、99是内点还有0-100之间的一个正常值异常场景输入超长字符串、复制粘贴带空格、输入负数、输入小数点、输入null等这套组合拳用下来10分的用例设计题至少能拿8分以上。特别要注意边界值不只是测边界本身还要测边界外的第一个值。曾经有一个同学把所有边界都写对了但漏了“空字符串”这个用例结果在面试复盘时被追问“为什么空值不属于有效等价类”一下子不知道怎么答。空值不是0它是“没有输入”属于无效等价类这一点很多人会忽略。2.3 一道边界值题目的完整推演为了让大家更直观地理解我给你完整推演一道经典题目。题目是测试一个“商品折扣计算”功能规则是购买数量在10到50件之间打95折数量超过50件打9折数量低于10件没有折扣。请设计测试用例。如果是我来答题我会这样组织先明确输入域购买数量是一个整数理论上可以为0、正整数也可能存在负数、小数等异常输入。等价类划分有效等价类11到9件无折扣有效等价类210到50件95折有效等价类351件及以上9折无效等价类0、负数、小数、非数字、空值边界值分析上点1、10、50、51离点0、9、11、49、52内点5、30、80正常用例购买5件验证无折扣购买30件验证95折购买80件验证9折。异常用例购买0件、-5件、10.5件、abc、不输入直接提交。这道题的坑点在于很多人会把“10件”误认为是“折扣起始值”忘了检查“50件”到底是95折还是9折。题干只要写“数量超过50件打9折”那50件就应该仍然属于95折区间这是边界上的语义陷阱。所以用例设计时一定要把边界上的两个值分别验证清楚。3. Linux、数据库与Shell测试工程师的硬功夫3.1 目录定位、日志排查、进程管理三大高频场景测试岗笔试里Linux操作题几乎每年都会出现。做测试日常要部署环境、查日志、看服务状态所以Linux是基本功。最常考的场景有三个定位目录和文件、查看日志、管理进程。定位文件常见的是给一个路径要你写命令查找指定文件。比如“在/home/log下查找所有包含error关键字的日志文件”标准答案是grep -rn error /home/log/或者用find /home/log -name *.log | xargs grep error。你要想清楚grep -r是递归搜索-n是显示行号这两个参数缺一不可。日志查看是重头戏。笔试常问“怎么实时查看日志文件新增内容”答案是tail -f app.log要查看某段日志用sed -n 100,200p app.log要统计某个关键字出现次数用grep -c 关键字 app.log。这些命令一定要练到不用想就能写出来的程度因为笔试时间很宝贵。进程管理则集中在ps和kill这两个命令上。比如“查看进程号为8080的Java进程”ps -ef | grep 8080如果端口被占用需要杀掉进程kill -9很多时候是无奈之举但笔试卷上最好写完整的kill -9 进程号并说明这是强制杀掉正常情况应该先用kill发TERM信号让进程优雅退出。能写出这层考虑说明你不是背命令而是真做过线上问题排查。3.2 数据库校验与SQL基础测试工作里验证数据是最日常的任务所以SQL必考。笔试常见的有三种题型简单查询、多表关联、聚合统计。我建议大家重点掌握where、group by、having、order by、join的配合使用。举个例子题目是“统计每个用户的订单总金额只展示总金额大于1000的用户并按金额降序排序”。正确答案是SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id HAVING SUM(amount) 1000 ORDER BY total_amount DESC;这里有一个高频易错点where和having的区别。很多人会写成WHERE SUM(amount) 1000这是错的因为where在分组之前过滤不能使用聚合函数。必须用having在分组后过滤。这类题不仅考SQL写法还考逻辑的严密性。另外检查给定的SQL语句是否存在问题也是常见考法。比如字段名大小写、子查询别名引用、空值处理不当等。建议你平时多写多练最好用MySQL或者SQLite搭一个测试库自己造点数据跑一跑比单纯背SQL书高效得多。3.3 用Shell把重复工作自动化有些笔试试卷会有一道“脚本题”让你写一段Shell或Python脚本。比如“每日定时清理超过7天的日志文件”这就非常贴近实际测试工作。一个比较简洁的Shell写法是find /var/log/app/ -type f -name *.log -mtime 7 -exec rm -f {} \;这道题考察的是find的-mtime 7参数表示修改时间超过7天。-exec rm -f {} \;则是把找到的文件删除。如果你对-exec不熟悉也可以配合xargsfind /var/log/app/ -type f -name *.log -mtime 7 | xargs rm -f我在笔试辅导中反复强调脚本题不要求一定写出最优解但要把思路和注释写清楚。阅卷人看到你写“按修改时间查找、删除”但忘了加-mtime 7至少知道方向对了。如果完全不写直接丢分太可惜。4. 自动化测试与接口测试拉开差距的进阶题4.1 为什么笔试会加考自动化随着质量保障体系逐渐向“自动化优先”转型测试岗笔试里自动化相关内容越来越重。快手这类互联网公司的业务迭代速度非常快如果纯靠手工回归上线节奏根本跟不上所以测开和测试工程师都需要具备一定的自动化能力。笔试加考自动化本质上是想确认你有没有“用代码解决重复劳动”的思维。这种思维比会某个工具更重要。比如题目问“你如何对一个登录功能做自动化回归”你要是只回答“用Selenium录制脚本”这道题基本拿不到高分。更好的回答是先分析登录场景的稳定性再选择接口层做校验配合UI层做冒烟用例最后把脚本接入CI/CD在每次代码合并后自动跑一遍。4.2 接口测试的完整答题模板接口测试是自动化里性价比最高的一类因为接口比UI稳定、执行快、容易定位问题。笔试里出现接口测试题时我建议按这个模板来组织答案明确接口协议和传参方式是HTTP还是RPC是GET还是POST参数放在URL、Header还是Body。设计正常场景用例正确参数、必填参数、参数边界值、参数组合。设计异常场景用例缺少参数、参数类型错误、参数值为空、非法字符、鉴权失败、并发请求。明确断言点状态码、响应体字段值、数据库数据变化、响应时间是否在预期范围内。举个典型例子测试一个“获取用户信息”的接口地址是/api/user/info需要传入user_id和token。我会这样写用例正常传参返回200响应体包含用户名、头像、等级等字段且字段类型正确。不传user_id返回参数错误提示状态码不能是200。传一个不存在的user_id返回用户不存在数据库无对应记录。传一个负数user_id返回参数校验错误。传非法token返回401未鉴权。连续请求200次验证是否有频率限制和接口是否正常响应。这套用例不仅覆盖了功能还覆盖了安全和稳定性在笔试里会非常加分。如果你能在答案里补充一句“接口测试的断言不能只看状态码要校验业务字段”那说明你真有实战经验。4.3 Appium与Web UI自动化考点速览UI自动化的笔试通常不会让你现场写完整代码但会考关键概念和流程。比如Appium的工作原理、WebDriver协议、定位元素的方式id、xpath、class name等、等待机制显式等待和隐式等待的区别。高频逻辑题是“页面加载慢自动化用例不稳定怎么排查”。标准回答思路是先确认是不是网络原因再检查定位方式是否稳定优先使用id和accessibility id而非xpath然后看等待时间设置是否合理尽量避免固定sleep使用显式等待等待元素出现最后排查是否存在多端适配差异在模拟器和真机上分别验证。我自己带项目时踩过最大的坑就是“脚本在自己电脑上能跑到了CI环境就挂”。后来发现是等待策略的问题。所以你在笔试里如果能主动提到“环境差异”和“稳定性设计”就能体现出真实项目经验这比背十个API函数都管用。5. 性能、安全与专项测试容易被忽略的加分项5.1 性能测试到底在测什么性能测试是笔试里“看似考概念、实则考理解”的部分。最常见的问题是“请解释TPS、QPS、响应时间、并发用户数之间的关系”。如果只回答“TPS是每秒事务数”得分很低。更好的回答是把它们串成一个故事性能测试关注的是系统在特定并发压力下每秒能处理多少事务TPS每个事务要多久返回响应时间以及这个过程中系统资源CPU、内存、IO是否稳定。进一步拉开差距的做法是能说出性能测试的分类。比如负载测试、压力测试、稳定性测试、容量测试的区别。负载测试看系统在不同负载下的表现压力测试看系统的崩溃边界稳定性测试看长时间运行是否有内存泄漏容量测试看当前架构能支撑多少用户量。笔试时如果能画一个简单的性能指标对比表文字列出会显得思路非常清晰。我特别建议准备一道“线上接口变慢如何排查”的题。完整的排查思路是先看监控确认是单机问题还是全局限流如果是单机登录机器看CPU、内存、磁盘IO再查慢日志和数据库慢查询最后用压测工具复现对比优化前后的TPS和响应时间。这套思路能串起性能、Linux、数据库多块内容是综合性最强的答题框架之一。5.2 安全测试的基本思路虽然安全测试不是所有测试岗笔试的必考项但“测试B试卷”这类大厂试卷里经常会出现一两个安全相关题目比如SQL注入、XSS、越权访问。这些概念不要求你成为渗透专家但你要能说清基本原理和测试思路。以SQL注入为例题目给一个登录框问你怎么测试它是否存在SQL注入风险。最基础的思路是输入单引号观察是否报错再尝试 OR 11这类经典注入语句看是否能绕过校验。如果你能进一步说明“后端应该使用参数化查询而不是拼接SQL并对输入做白名单校验”这道题的分数就拿到了。越权访问则是测试里很容易被忽视的环节。笔试可能会问“测试一个订单详情接口怎么判断是否存在越权风险”。标准思路是用自己的账号A创建一个订单然后用账号B的token去访问A的订单详情如果返回了订单数据就说明存在水平越权。这类题考察的是测试思维的完整性而不是安全技术本身。5.3 专项测试兼容性、弱网、耗电互联网产品越来越复杂专项测试也成了笔试的加分考点。兼容性测试最常见的问题是“如何设计一款App的兼容性测试方案”。我想看到的关键点是设备选型要有依据不能把所有手机都测一遍而是根据用户设备TOP榜选择前10款机型覆盖不同系统版本、屏幕分辨率、芯片架构同时要结合核心功能做冒烟不需要把所有用例都在所有设备上执行。弱网测试在移动端笔试中也很常见。你要能说出弱网工具如Charles、Network Link Conditioner以及常见的模拟场景3G、4G、弱WiFi、高延迟、丢包率大于10%。核心思路是验证App在网络抖动时会不会崩溃、卡死、数据错乱以及恢复网络后能否自动重试或提示用户。能把这个场景说清楚说明你考虑到了真实用户使用环境。耗电测试和内存测试属于底层专项笔试提得相对少。但一旦出现你只需要记住核心逻辑耗电测试关注前台和后台不同场景下的电量消耗内存测试关注App在长时间操作后是否出现内存持续上涨、最终被杀进程的问题。Android上常用的命令是adb shell dumpsys meminfo 包名和systrace能写出这两个工具也是加分项。6. 常见问题与备考实战建议6.1 笔试过程中的失分重灾区结合我参与校招面试和批改笔试题的经验测试岗笔试的失分点非常集中先给大家提个醒。第一类是“用例设计过于粗糙”。很多人写测试用例只写“输入正确信息系统正常返回”这种废话。阅卷人想看到的是具体数据、具体前置条件、具体预期结果。一个合格的用例应该包含编号、测试标题、前置条件、测试步骤、测试数据、预期结果、优先级这几个要素。如果你能按这个格式来答哪怕场景覆盖不是特别全逻辑分也不会低。第二类是“不区分功能和性能的断言”。比如“测试一个搜索功能”大部分人都能写出“输入关键词点击搜索展示结果列表”但很少有人补充“搜索响应时间应小于2秒搜索结果应按相关度排序翻页和筛选功能应联动生效”。后者才是测试思维的完整体现。第三类是“代码题留白”。我知道很多同学看到一道不熟悉的编程题就直接放弃这是最可惜的。实际上测试岗的代码题难度远低于算法岗考察的多是字符串处理、文件读写、简单循环和异常处理。就算写不出完整代码也要把思路分步写出来多少能拿一点过程分。6.2 从笔试到面试的衔接准备笔试不只是为了过筛它还会直接影响后面的面试。很多面试官会直接拿你笔试里的用例设计题来追问比如“你这个登录用例为什么只考虑了5个场景”“如果用户被锁定了怎么办”“如果传输过程被截获了怎么办”。所以笔试完之后一定要把题目记下来尤其是主观题回去认真复盘。我建议你准备一个“复盘文档”把每一道自己写过的用例设计题重新写一遍并补充面试追问中提到的场景。这个过程比刷十套题都有效。因为笔试考核的是“会不会”面试追问考核的是“有没有深度”两者是递进关系。你能在两轮之间完成这个升级面试通过率会明显提升。另外一个容易被忽视的点是时间管理。笔试时先做会做的题再啃难题不要在一道选择题上死磕。我自己当年笔试的时候有一道SQL题卡了15分钟结果最后压轴用例设计题没来得及写完整回头想想非常亏。正确策略是先把所有题目扫一遍把最有把握的分先拿到手。6.3 我的备考经验与避坑建议最后分享一些我自己的经验希望你能少走弯路。第一不要只看不练。测试理论和Linux命令光靠眼睛看是记不住的一定要在本地搭一个虚拟机或者用云主机把常用命令敲一遍把SQL多跑几遍。第二多用“如果…怎么办”来扩展用例这是测试思维训练的捷径。每写一个功能用例就追问自己“如果用户断网”“如果数据库超时”“如果返回数据为空”这些追问本身就是新增用例的来源。第三一定不要忽略“缺陷报告”的书写。虽然有些笔试试卷没有明说考缺陷报告但主观题里很可能让你描述一个bug。一个完整的bug描述应该包含问题标题、复现步骤、实际结果、预期结果、环境信息系统版本、设备型号、App版本、严重程度、优先级。我在面试中见过太多同学把一个偶现bug描述成“有时候会闪退”没有任何复现路径这样的描述在工作中会产生大量沟通成本。根据我的体感测试岗笔试真正想筛掉的不是基础知识不够的人而是“没有工程意识”的人。你不需要在笔试中表现得多完美但要让阅卷人看到你有逻辑、有方法、有闭环。写用例时给出边界值和异常值写代码时考虑到异常处理写方案时提到落地的工具和指标这三件事做到了你的笔试成绩一定不会差。如果准备时间有限我的优先级建议是用例设计方法 接口测试思路 Linux命令 数据库SQL 自动化框架原理。把这五块吃透无论你碰上的是A卷、B卷还是别的什么卷心里都会踏实很多。希望这份拆解能帮你在接下来的秋招里少一点慌乱多一点底气。