2019年那阵子乐信的测试工程师校招笔试在求职群里传得挺广。前前后后我帮不少学弟学妹过过这套题发现它和很多大厂笔试最大的区别是不跟你玩纯智力题轰炸而是把一个消费金融业务场景拆开揉碎考你是不是真能当一个测试工程师。这不是游戏测试那类偏操作体验的笔试而是一整套贴合消费金融业务的测试能力考察。整套卷子做下来涉及的考点其实很集中——用例设计、金融规则理解、接口和数据库验证、自动化基础再加一两道开放题。这篇就按这套考察逻辑把典型题型和破题思路完整拆一遍。不管你是准备校招还是刚转行想入测试这份拆解都能当一份不错的复习提纲。1. 金融业务背景决定了这套笔试的题目风格很多人拿到这套题的第一反应是为什么考这么多业务题要回答这个问题得先搞清楚乐信当时在做什么。1.1 分期乐这类产品到底在测什么乐信的核心产品是分期乐一个消费金融平台。用户在里面走完的行为链路大致是注册登录、实名认证、授信评估、在商城购物或者申请借款、生成借款订单、风控审核、放款、按期还款中间还可能出现逾期、催收、提前还款这些分支。这个链路有一个非常鲜明的特点每一步都涉及资金和契约关系。普通电商平台订单金额错了最多引起客诉借贷平台还款金额错了那就是资损和合规事件。所以这套笔试题的底色就是围绕“钱不能错”这三个字展开的。出题人想筛的不是那种背了几套测试理论就能答题的学生而是能理解业务、能识别资金风险的准测试工程师。所以你会看到同样的登录功能题普通公司考“用户名密码的等价类划分”乐信会把它放到真实用户路径里加实名认证、加绑卡、加验证码安全策略难度一下子就不一样了。1.2 整张试卷的考点分布和时间分配根据这套题在考生群体里的反馈我大致还原了一下结构分布考察模块大致占比典型题型用例设计约30%登录注册、借款流程、还款金额验证接口与数据库约25%接口用例设计、SQL查询、数据一致性自动化与性能约20%概念选择、工具使用流程开放题与逻辑题约15%如何测试某功能、智力题计算机基础约10%网络协议、Linux命令、数据结构假设笔试时间是120分钟我的建议分配是用例设计题控制在40分钟内接口和数据库题30到40分钟自动化与性能题15分钟开放题和逻辑题20分钟最后留10分钟检查。这个节奏很关键后面我会单独展开讲。2. 用例设计题登录、借款、还款各有各的考法用例设计是整套卷子的重头戏也是最容易看出考生功底的模块。它不是让你默写测试用例模板而是给你一个具体功能看你能不能快速找到测试点。2.1 登录注册用例别把边界值和安全验证写漏了登录注册是几乎所有测试笔试都会考的基础题但大部分人答得千篇一律正确账号密码、错误密码、账号不存在写个十几条就停了。放到乐信这个业务背景里这样的答案只能拿个基础分。更好的思路是分层展开。第一层是正常路径正确手机号和密码登录、验证码登录、第三方授权登录。第二层是边界与异常密码长度边界值比如6位和20位是上下限5位和21位必须拦截验证码倒计时、验证码过期、验证码错误、连续输错N次后账号锁定账号被风控标记后的登录拦截手机号未注册时给出明确提示。第三层才是真正拉开差距的安全策略。密码是否明文传输、登录接口有没有防暴力破解机制、验证码能不能重放、用户输入SQL注入语句时系统是否做了转义、多端登录时旧token是否失效。这种安全细节笔试题里特别愿意考。我记得当时有学弟答题时只写了功能用例安全、兼容、弱网这些点完全没提。出题人一眼就能看出来这个考生对测试的理解还停留在“点按钮、看结果”的层面没有风险意识。2.2 借款流程场景法加状态机主流考生容易栽的地方如果说登录题是送分题那借款流程的用例设计就是分水岭。典型出法是这样的用户提交借款申请后要经过系统额度校验、风控自动审核、人工复核、放款、生成还款计划、到账通知这些环节请你设计测试用例。这题背后的核心是状态机。借款订单从创建开始会经历申请中、审核中、审核通过、审核拒绝、放款中、已放款、还款中、已结清、逾期、坏账等一系列状态。用例设计的本质就是验证这些状态之间的流转是否符合预期。优先要覆盖的用例包括主流程提交申请自动审核通过放款成功还款计划生成。分支流程风控自动拒绝、人工复核拒绝、用户主动取消、放款失败后重试。状态互斥审核中的订单不能重复放款已拒绝的订单不能再次进入放款中已结清的订单不能再发起还款。额度边界借款金额等于授信额度、大于授信额度、低于最小借款金额、金额不是100的整数倍。并发场景同一订单同时提交两次放款请求系统只能成功一次。这个题特别容易踩的坑是只写到了“审核通过后放款”没有继续往后推。很多考生把流程止步于放款成功忘了后面还有还款计划生成、到账通知、账单展示这些节点。出题人就是要看你能不能覆盖完整业务闭环。2.3 还款金额验证等额本息的数学基本功金额计算是金融业务测试最核心的硬功夫。笔试里如果考“借款10000元年利率12%分12期等额本息还款如何验证每期应还金额”很多人就卡住了因为他们只会点页面不会算账。等额本息的公式是M P × [ r(1r)^n ] / [ (1r)^n - 1 ]其中P是本金r是月利率n是期数。套进题目P10000年利率12%月利率1%n12。(10.01)^12 ≈ 1.126825M 10000 × [0.01×1.126825] / [1.126825-1] ≈ 888.49所以每期应还约888.49元。验证的时候光算出一个总金额还不够还要拆到每一期的本金和利息。第一期利息10000×1%100元应还本金888.49-100788.49元剩余本金9211.51元。第二期利息9211.51×1%92.12元应还本金888.49-92.12796.37元。按这个逻辑一直滚到最后剩余本金应该正好清零。笔试中如果给了具体的还款计划表你要检查的就是本金合计是否等于借款金额、利息合计是否合理、每一期的剩余本金是否递减、最后一期是否出现尾差。实际项目里金额字段一般用decimal(10,2)页面展示到分不能拿浮点数直接比较否则会有精度问题。这样的题一写出来你和其他考生的差距就拉开了。因为它既考了数学又考了测试设计还考了金融常识。3. 接口与数据库笔试里最能拉开差距的硬核部分用例设计题是基本功接口和数据库题是硬功夫。金融业务里功能看得见摸得着但数据对不对、接口稳不稳才是决定系统能不能上线的关键。3.1 还款接口用例设计参数、越权、幂等一个都不能少接口测试题在笔试题里通常是这么出的有一个还款接口入参包含userId、orderId、amount请你设计测试用例。基础选手会写正常还款成功、金额为0、金额过大。但真正能拿高分的答案要覆盖下面这几个维度。参数维度必填项缺失比如不传orderId类型错误amount传字符串边界值amount为0、负数、超过应还金额金额精度传100.001、100.005这种带三位小数的值。业务维度orderId不存在、orderId已关闭、orderId已还清当前用户不是该订单的借款人同一订单重复发起两笔还款还款金额小于最低还款额系统是否拦截。安全维度用户A传入用户B的userId和orderId试图替别人还款接口必须做越权校验。这个点太容易漏了但金融系统里是最严重的漏洞之一。一致性维度第三方支付渠道超时后接口返回失败还是返回处理中支付回调重复到达时系统能否保证只扣一次款下游服务异常时订单状态是否卡在中间态。接口用例的断言也不能只写“返回成功”。要写清楚HTTP状态码、业务码、响应消息体、数据库订单状态、账务流水变化。比如正常还款后响应里的订单状态从REPAYING变成CLOSED数据库流水表新增一条还款记录用户账户余额减少888.49元。只有把接口和数据库联动起来验证才叫完整的接口测试。3.2 订单状态流转的数据库验证先查库再信页面笔试里经常给出一张订单表结构让你写SQL或者设计数据验证方案。比如订单表loan_order有字段order_id、user_id、amount、status、update_time还款计划表repay_plan有期数、应还本金、应还利息、应还日期、实还日期。验证思路应该是这样的第一步造数。准备一个待还款的订单明确知道它的订单号、金额、期数。 第二步执行操作。调用还款接口或者模拟还款行为。 第三步查库。确认loan_order的status从REPAYING变为CLOSEDupdate_time被更新。 第四步查子表。确认repay_plan里每一期的状态同步更新实还金额、实还日期正确。 第五步查流水。确认账户流水表新增一条类型为还款的记录流水号唯一金额和接口入参一致。这个“先查库再信页面”的顺序是我在项目里反复强调的原则。页面上显示已还清不代表数据库里真的还清了有可能是前端展示问题。测试必须要求数据链路完整否则上线后对账就会出问题。3.3 数据一致性金融系统测试的隐形门槛2019年的笔试题里已经有公司开始问分布式事务、数据一致性这类偏架构的问题了。乐信这套题里数据一致性更多是结合场景来考。最典型的是跨系统调用场景用户发起还款订单系统要更新订单状态支付系统要扣款账务系统要记账。三个系统之间通常靠消息队列异步通知。如果消息丢了怎么办如果支付成功但订单状态没有更新怎么办答案是必须有对账机制。测试时要设计这样的场景模拟支付成功但未收到回调观察定时对账任务能否发现差异并触发补偿模拟同一消息重复投递观察消费方是否做了幂等处理。应届生不需要把分布式事务方案写到多深但至少要理解“不能只测单一系统”这个理念。能把这条写进答案说明你对金融级系统的复杂度有概念这一点非常加分。4. 自动化与性能测试基础概念的踩分点自动化在2019年的校招笔试里考得不算深但一定会有。它考察的是你对测试工具链的整体认知。4.1 自动化选型为什么笔试总爱考UI和接口自动化的边界笔试里常见的选择题或简答题是UI自动化和接口自动化各自的优缺点以及适用场景。UI自动化贴近用户操作能覆盖真实路径但代价是页面改动频繁导致脚本维护成本高运行也不稳定。接口自动化执行快、稳定性高、能直接验证业务逻辑但不覆盖前端展示和交互。性能测试则是在上线前验证系统承压能力不适合日常回归。类型优点缺点适用场景UI自动化贴近用户真实操作维护成本高、稳定性差核心冒烟回归接口自动化稳定、快速、成本低不覆盖UICI流水线、全量回归性能测试发现容量瓶颈场景设计难度大大促、发薪日高峰期压测这个表几乎是标准答案。答题时如果能再补一句“实际项目里通常按接口为主、UI为辅的层级来搭自动化体系”出题人会知道你真有项目思维。4.2 接口自动化小Demorequests加pytest的简洁写法有些笔试会要求写一段简单的接口自动化脚本或者让你描述接口自动化的实现思路。一个简洁的requests加pytest示例就能说明问题import requests def test_repay_success(): payload { userId: 1001, orderId: 20230001, amount: 888.49 } resp requests.post(https://api.example.com/repay, jsonpayload) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][status] CLOSED这个示例虽然简单但包含了接口测试最核心的几件事构造入参、发起请求、校验状态码、校验业务码、校验关键业务字段。笔试里不要求你写出完整工程有这个雏形再说明可以用pytest管理用例、用Jenkins做定时触发、用Allure出报告就非常完整了。放到现在的语境里这也是全栈测试工程师技术栈的基本盘。4.3 性能估算题一个简单QPS计算思路性能测试的选择题经常考QPS、TPS、响应时间、并发用户数这些概念。真正有意思的是估算题日活100万用户核心还款接口高峰期QPS大概是多少。估算逻辑是这样的100万用户里假设当天有20万用户产生操作每人平均操作2次全天请求总量约40万操作集中在2小时高峰内也就是7200秒平均QPS约40万除以7200约等于55再按3到5倍的峰值系数高峰期QPS大概在165到275之间。这种估算不要求精确关键是会拆解日活到操作量到时间窗口到峰值系数。性能压测里的场景设计本质上也是这个思路。知道要测多少并发、要压多长时间、关注哪些指标比背几个工具命令有用得多。5. 开放题和逻辑题没有标准答案但有高分思路这套卷子末尾通常会有几道开放题和智力题用来考察思维方式和应变能力。很多学生觉得这part随便写写就行其实恰恰错了。5.1 “如何测试一个借款功能”这类开放题怎么答才不跑偏开放题最忌讳一上来就埋头写测试点。高分思路是先澄清边界再分维度展开。我先问你几个问题借款功能是Web还是App面向哪些用户借款额度范围多少支持哪几种还款方式有哪些第三方依赖这些需求不明确测试范围就没法定。把边界写清楚出题人会认为你有需求分析意识。然后按维度展开功能维度借款申请、审批、放款、还款、提前还款、逾期全流程接口维度入参校验、幂等、并发数据库维度状态流转、金额一致性安全维度越权、加密、防重放性能维度集中放款高峰的并发处理兼容维度不同机型、浏览器、操作系统易用性维度借款金额输入是否有提示、校验失败文案是否清晰。这个框架能把你脑子里零散的测试点串成体系答案看起来既有全局观又有优先级。哪怕某个维度写得不深也比那种想到哪写到哪的答案高出一个段位。5.2 智力题背后的通用套路分组、编码与状态压缩智力题是笔试里争议最大的一部分很多人觉得没意义但出题人就是用它看思维习惯。这类题其实是有一套通用套路的。最常见的一类是“1000瓶药里有一瓶有毒1小时后会发作最少用多少只小白鼠能在1小时内找出毒药”。答案是10只因为1只老鼠有死和活两种状态10只可以表示2的10次方共1024种编码。把药瓶编号转成10位二进制第几位是1就给第几只老鼠吃。1小时后看哪些老鼠死亡反推出毒药的二进制编号。这个题背后的思想是编码和状态压缩和接口测试里的笛卡尔积覆盖、性能测试里的场景采样本质是相通的。答题时哪怕忘了具体答案只要讲清楚“要用二进制编码减少实验次数”也能拿一部分分。天平找次品也是经典思路通过三分法把问题规模每次缩小三分之一。倒水问题则是差值法的应用。这些题不要求你在考场秒解但通过你列的推导过程出题人能看出你的逻辑是否清晰。6. 试卷怎么答才能拿到高分节奏和表达同样重要最后聊一个很多人忽略的问题同样的能力怎么表达才能拿更高分。我帮人改过不少模拟卷发现很多挂掉的同学不是不会而是答得乱七八糟。6.1 用例题的标准表达结构用例设计题一定要用“编号、前置条件、操作步骤、预期结果”的结构来写。比如借款流程编号前置条件操作步骤预期结果TC001用户已注册并完成授信申请借款10000元选12期提交借款申请进入审核中展示预计利率和还款计划TC002用户授信额度5000元申请借款10000元系统拦截提示超出授信额度TC003借款订单处于审核中再次提交相同借款申请系统提示已有在途订单不能重复申请这个格式最大的好处是复用性强、可执行性高出题人扫一眼就知道你会不会干活。同时要注意排列顺序先主流程再分支再异常再安全性能。不要东写一条西写一条。还有个小技巧每条用例只写一个核心验证点。出现过很多次的情况是考生一条用例里塞了三四个步骤和好几个预期结果最后出问题根本定位不到是哪一步出的问题。测试用例的基本原子性在笔试里就应该体现出来。6.2 时间分配与检查策略拿到试卷先别急着做题用3分钟把所有题目扫一遍标记出简单题、中档题、难题。我的策略是先做会做的把基础知识选择题快速拿分再做用例设计题最后回头啃开放题和智力题。笔试最怕的就是在智力题上死磕20分钟最后用例设计题草草收尾白白丢了最值钱的分数。开放题如果一时没思路先写框架把一个一个维度列出来哪怕每个维度只写一句话也比空白或瞎编强。阅卷人最看重的是你的思路在不在正确的方向。最后检查时要重点看有没有漏写安全测试点、有没有漏掉数据库状态校验、金额计算题的数字有没有算错。很多考生会把等额本息的月利率算成年利率这种粗心错误在真实测试工作里也是一样致命的。这套2019年的笔试题放到现在其实没有过时。AI测试、全栈测试这些词被反复提起但底层的业务理解、用例设计、数据校验能力依然是测试工程师的立身之本。我自己带新人的时候也习惯先让他们把一道借款流程题完整写一遍写得好不好基本能看出这个人能不能在测试这条路上走远。希望这份拆解能帮你看清楚题目背后的考察逻辑而不是背几道答案就上场。