1. 从这套笔试题说起乐信在找什么样的测试工程师看到“2019乐信校园招聘测试工程师笔试题”这个标题我一下子想起来当年自己参加校招笔试的场景。乐信作为金融科技公司它的校招测试题在当年算是比较有代表性的不考偏题怪题但覆盖面很广逻辑题、技术题、测试设计题都有而且非常看重候选人的工程思维和严谨性。测试工程师这个岗位在校招里其实处于一个很微妙的位置。很多人以为测试就是“点点点”门槛低不需要太多准备但真正到了笔试环节你会发现一套合格的测试笔试题考察的不是你背了多少理论而是你有没有一套完整的、可迁移的测试思维。乐信这套题当年流传度挺广很多准备校招的同学都拿它练手因为它基本代表了金融科技类公司对初级测试工程师的能力预期。这篇文章就带大家从头到尾拆一遍这类笔试题题目背后想考什么、每种题型怎么答、哪些地方容易丢分以及放到今天来看这套考察逻辑又演变成了什么样。不管你是正在准备校招的应届生还是想转行做测试的职场人搞清楚这套题背后的出题逻辑比刷一百道题都有用。2. 题型分布与底层考察逻辑2.1 当年的考试结构先说整体结构。2019年乐信校招测试工程师笔试线上作答时长大概90到120分钟。题型大致分四块逻辑推理与计算题、技术基础题Linux/数据库/编程、测试基础理论题、测试用例设计题。前两块是选择题和填空题为主后两块是大题尤其是测试用例设计题占分比重最高也是拉分的关键。这个结构放到今天依然有参考价值。它其实就对应了测试工程师日常工作的三大能力能理清业务逻辑逻辑题、能看懂技术实现技术题、能设计有效验证方案测试设计题。考试不是在考“你会不会测试”而是在考“你有没有可能被培养成一个合格的测试工程师”。当时乐信的业务重心在消费金融领域所以整套题里其实隐藏着对金融业务场景的理解要求。比如测试用例设计题会给你一个类似“用户注册-授信-借款-还款”的流程让你找出测试点。这种题如果你只是泛泛地写“输入框校验”“页面正常显示”基本就拿不到高分。2.2 阅卷人真正看重的能力模型很多同学备考时喜欢背题、背答案这是最要命的事情。我后来参加过几次面试官培训也帮公司出过笔试题才真正理解出题人的心态笔试题不是用来难倒你的而是用来暴露你的思维过程的。具体来说阅卷人看三点。第一严谨性。测试工程师的核心价值就是发现别人发现不了的问题所以你在笔试中是否考虑到了边界条件、异常情况、并发场景直接反映了你的测试敏感度。比如给你一个“输入手机号获取验证码”的功能普通人写用例就是“输入正确手机号能收到验证码、输入错误手机号有提示”但有经验的测试会继续往下想同一手机号60秒内重复点击会怎样验证码有效期过了再输入会怎样接口被频繁调用会不会触发风控这些延伸点就是得分点。第二技术功底是否扎实。测试工程师不是不用写代码恰恰相反自动化测试、接口测试、性能测试、日志排查样样都需要技术底子。所以笔试题里的SQL、Linux命令、编程逻辑题看着像是在考开发知识其实是在筛选“有技术潜力的测试”而不是“只会点页面的执行者”。第三表达能力。测试用例设计题往往没有标准答案但你的答案组织得清不清楚、分类有没有逻辑一眼就能看出来。用表格、用编号、按功能模块拆分这些习惯在笔试时就能体现出一个人的专业素养。3. 核心题型拆解与答题示范3.1 逻辑推理与计算题不是考数学是考思维严密性这类题通常是整套卷子的开头难度不大但很容易粗心翻车。常见的有几种排列组合、概率、逻辑判断、工程估算。举个例子当年有一道类似的题“一个接口的请求成功率是99.9%某天系统总共收到10000次请求请问大约有多少次请求失败如果每次失败都会产生一条告警日志请问告警日志数量级是多少”这题简单到让人怀疑人生但就是有很多人选错。原因是他们把99.9%直接看成0.1%的失败率却忽略了10000乘以0.001等于10这个基本计算。还有一种更典型的逻辑题是“真假话”问题比如“甲说乙在说谎乙说丙在说谎丙说甲乙都在说谎。请问谁在说实话”这种题考的不是智商而是你能不能有条理地列出所有可能性并逐一排除。我建议在草稿纸上画个简单的真值表别光靠脑子转。这类题的实战意义其实很大。测试过程中经常需要根据日志、报错信息、用户反馈来推断问题根源有时候几条互相矛盾的线索摆在面前你就得像做真假话题一样一条一条假设、验证、排除。3.2 Linux与数据库送分题也是筛选题技术基础题里Linux命令和SQL几乎是必考的。乐信那时候也是这么出的。SQL题常见的有这么几类查重、分组统计、连表查询、子查询。比如给你一张订单表和一张用户表让你“查询消费总金额前10的用户”。这时候一眼就能看出你有没有真正写过SQL而不只是背过语法。SELECT u.user_name, SUM(o.order_amount) AS total_amount FROM user u INNER JOIN orders o ON u.user_id o.user_id GROUP BY u.user_id, u.user_name ORDER BY total_amount DESC LIMIT 10;这里有一个踩坑点很多人忘了在GROUP BY里把u.user_name也带上。在MySQL默认配置下可能不会报错但在严格的SQL模式下直接挂掉。笔试不是让你“能跑就行”而是看你的代码规不规范、能不能在任意环境下都正确执行。Linux题则是偏向实际排查。给你一个日志文件让你找出“访问量最大的IP”考察的就是cat、grep、awk、sort、uniq这套组合拳。cat access.log | awk {print $1} | sort | uniq -c | sort -rn | head -10我当时复习的时候把这套命令背得滚瓜烂熟后来工作中排查线上问题真的天天用。这里多说一句测试工程师会看日志是基本功但很多人栽在“不知道看什么日志、用什么关键字过滤”这就需要在平时积累业务系统的日志规范知道error是什么意思、timeout意味着什么、堆栈里的哪一行才是真正的报错位置。3.3 测试基础理论题别在这些题上丢分测试基础理论题属于整张卷子里的“软柿子”主要有什么是黑盒测试和白盒测试、静态测试和动态测试的区别、回归测试在什么阶段做、缺陷的生命周期有哪些状态、什么是等价类划分和边界值分析。这些题背一背就能拿分但我提醒一句不要只背定义要能举例子。比如问“什么是边界值分析”你如果只回答“在输入边界附近取值”那只是及格水平如果你能补一句“比如一个输入框要求输入1-100的整数我会测试0、1、100、101以及99和2这些正常边界附近的取值”这才是面试官想看到的答案。这类理论题还有个常见变体就是给你一个缺陷描述让你判断它的优先级和严重级别。很多人把这两个概念搞混严重级别是“影响有多大”优先级是“要修多快”。一个按钮颜色不对可能严重级别低但优先级高因为影响用户操作一个只在内网极端条件下出现的崩溃可能严重级别高但优先级低。笔试中遇到这种题先冷静分析再选别凭感觉。3.4 编程基础题测试也要会写代码2019年的乐信笔试题里已经开始出现简单的编程题了难度大概在LeetCode easy级别比如“判断一个字符串是不是回文”“实现一个函数统计数组中每个元素出现的次数”“写一个简单的冒泡排序”。这类题不是让你写出多优雅的算法而是看你的代码基本功。我建议备考时用Python或Java都行但一定要练到能“手写不查文档”的程度。尤其是字符串处理和数组遍历这是最常考的。def is_palindrome(s: str) - bool: s .join(c.lower() for c in s if c.isalnum()) return s s[::-1]如果时间充裕还可以学一下怎么用简单的unittest或pytest给这段代码写测试用例。这在笔试中不是硬性要求但你如果能在卷子上主动补充“这个函数我会用空字符串、大小写混合、含标点符号等场景来验证”那就是明显的加分项说明你已经有“测试自己写的代码”的意识了。4. 测试用例设计大题整套卷子的分水岭4.1 一道典型业务场景题长什么样测试用例设计题通常占20到30分是绝对的重点。乐信当年考过一道类似这样的题“设计一个用户注册功能的测试用例要求覆盖功能、安全、兼容性等方面。注册时用户需要填写手机号、密码、验证码。”我相信很多人看到这道题的第一反应是兴奋“注册功能我熟啊”但真下笔写的时候又觉得脑子一片空白写完的用例翻来覆去就是“输入正确手机号、输入错误手机号、输入正确密码、输入错误密码”这几条干巴巴的毫无亮点。这道题其实是典型的“看着简单写好很难”。它考察的不只是你会不会测一个注册页面而是你有没有完整的测试思路测试范围怎么划分、用例粒度怎么把握、有没有考虑到异常和攻击场景、有没有把后端和前端分开来看。4.2 从0到1推演完整用例集我做这类题有一个固定的框架全部写下来就是一种结构化的表达方式。简单说就是六个字分模块、分层次。先按功能模块拆分手机号输入框、密码输入框、验证码获取与输入、整体提交逻辑、页面交互提示。然后每个模块再按“正常流程、异常流程、边界场景、安全风控”四个层次来展开。以手机号输入框为例正常流程是输入11位有效手机号异常流程是输入10位、12位、包含字母、为空边界场景是输入11位但以0开头、输入“13800138000”这种边界情况安全风控是输入超长字符串、SQL注入语句、脚本代码看系统是否做了输入校验和过滤。密码框就更细致了。要求是“6-16位字母数字组合”那我就要测试6位纯数字是否被拒绝、6位字母加数字是否通过、15位的组合是否通过、16位的组合是否通过、17位是否被拒绝、空格是否被处理、全角字符是否被处理、中文是否能作为密码。验证码这块除了“正确验证码能通过、错误验证码被拒绝”之外一定不要漏掉这些点验证码过期后提交会怎样、点击获取后有60秒倒计时还能不能再点、同一手机号每天获取次数有没有限制、验证码在响应包里能不能直接看到这是很常见的安全问题前后端联调时经常有人把验证码明文返回。我整理一下一个好的“用户注册”用例集大概会出现这样的规模模块用例点预期结果手机号输入11位有效手机号显示成功允许获取验证码手机号输入12位数字提示“手机号格式不正确”不允许提交手机号输入包含字母的手机号提示格式错误键盘或校验拦截手机号输入空值点击提交提示“请输入手机号”密码输入5位密码点击提交提示“密码长度不能少于6位”密码输入17位密码提示“密码长度不能超过16位”密码输入8位纯数字提示“密码必须包含字母和数字”密码输入6位数字字母组合校验通过验证码输入正确的验证码提交注册成功跳转到登录页验证码输入错误验证码提示“验证码错误”验证码等待验证码过期后再提交提示“验证码已过期请重新获取”验证码点击获取后60秒内再次点击按钮置灰不可点击或提示“请勿频繁获取”安全在手机号输入框提交SQL注入字符串系统拦截无异常报错不出现数据库信息安全提交包含“