企业官网建设流程全解析

2019年那阵子，乐信的测试工程师校招笔试在求职群里传得挺广。前前后后我帮不少学弟学妹过过这套题，发现它和很多大厂笔试最大的区别是：不跟你玩纯智力题轰炸，而是把一个消费金融业务场景拆开揉碎，考你是不是真能当一个测试工程师。这不是游戏测试那类偏操作体验的笔试，而是一整套贴合消费金融业务的测试能力考察。

整套卷子做下来，涉及的考点其实很集中——用例设计、金融规则理解、接口和数据库验证、自动化基础，再加一两道开放题。这篇就按这套考察逻辑，把典型题型和破题思路完整拆一遍。不管你是准备校招，还是刚转行想入测试，这份拆解都能当一份不错的复习提纲。

1. 金融业务背景决定了这套笔试的题目风格

很多人拿到这套题的第一反应是：为什么考这么多业务题？要回答这个问题，得先搞清楚乐信当时在做什么。

1.1 分期乐这类产品到底在测什么

乐信的核心产品是分期乐，一个消费金融平台。用户在里面走完的行为链路大致是：注册登录、实名认证、授信评估、在商城购物或者申请借款、生成借款订单、风控审核、放款、按期还款，中间还可能出现逾期、催收、提前还款这些分支。

这个链路有一个非常鲜明的特点：每一步都涉及资金和契约关系。普通电商平台订单金额错了，最多引起客诉；借贷平台还款金额错了，那就是资损和合规事件。所以这套笔试题的底色，就是围绕“钱不能错”这三个字展开的。

出题人想筛的，不是那种背了几套测试理论就能答题的学生，而是能理解业务、能识别资金风险的准测试工程师。所以你会看到，同样的登录功能题，普通公司考“用户名密码的等价类划分”，乐信会把它放到真实用户路径里，加实名认证、加绑卡、加验证码安全策略，难度一下子就不一样了。

1.2 整张试卷的考点分布和时间分配

根据这套题在考生群体里的反馈，我大致还原了一下结构分布：

假设笔试时间是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(1+r)^n ] / [ (1+r)^n - 1 ]

其中P是本金，r是月利率，n是期数。套进题目：P=10000，年利率12%，月利率1%，n=12。

(1+0.01)^12 ≈ 1.126825

M = 10000 × [0.01×1.126825] / [1.126825-1] ≈ 888.49

所以每期应还约888.49元。验证的时候，光算出一个总金额还不够，还要拆到每一期的本金和利息。

第一期利息=10000×1%=100元，应还本金=888.49-100=788.49元，剩余本金=9211.51元。第二期利息=9211.51×1%=92.12元，应还本金=888.49-92.12=796.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变为CLOSED，update_time被更新。 第四步，查子表。确认repay_plan里每一期的状态同步更新，实还金额、实还日期正确。 第五步，查流水。确认账户流水表新增一条类型为还款的记录，流水号唯一，金额和接口入参一致。

这个“先查库再信页面”的顺序，是我在项目里反复强调的原则。页面上显示已还清，不代表数据库里真的还清了，有可能是前端展示问题。测试必须要求数据链路完整，否则上线后对账就会出问题。

3.3 数据一致性：金融系统测试的隐形门槛

2019年的笔试题里，已经有公司开始问分布式事务、数据一致性这类偏架构的问题了。乐信这套题里，数据一致性更多是结合场景来考。

最典型的是跨系统调用场景：用户发起还款，订单系统要更新订单状态，支付系统要扣款，账务系统要记账。三个系统之间通常靠消息队列异步通知。如果消息丢了怎么办？如果支付成功但订单状态没有更新怎么办？

答案是必须有对账机制。测试时要设计这样的场景：模拟支付成功但未收到回调，观察定时对账任务能否发现差异并触发补偿；模拟同一消息重复投递，观察消费方是否做了幂等处理。

应届生不需要把分布式事务方案写到多深，但至少要理解“不能只测单一系统”这个理念。能把这条写进答案，说明你对金融级系统的复杂度有概念，这一点非常加分。

4. 自动化与性能测试：基础概念的踩分点

自动化在2019年的校招笔试里，考得不算深，但一定会有。它考察的是你对测试工具链的整体认知。

4.1 自动化选型：为什么笔试总爱考UI和接口自动化的边界

笔试里常见的选择题或简答题是：UI自动化和接口自动化各自的优缺点，以及适用场景。

UI自动化贴近用户操作，能覆盖真实路径，但代价是页面改动频繁导致脚本维护成本高，运行也不稳定。接口自动化执行快、稳定性高、能直接验证业务逻辑，但不覆盖前端展示和交互。性能测试则是在上线前验证系统承压能力，不适合日常回归。

这个表几乎是标准答案。答题时如果能再补一句“实际项目里通常按接口为主、UI为辅的层级来搭自动化体系”，出题人会知道你真有项目思维。

4.2 接口自动化小Demo：requests加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", json=payload) 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 用例题的标准表达结构

用例设计题，一定要用“编号、前置条件、操作步骤、预期结果”的结构来写。比如借款流程：

这个格式最大的好处是复用性强、可执行性高，出题人扫一眼就知道你会不会干活。同时要注意排列顺序：先主流程，再分支，再异常，再安全性能。不要东写一条西写一条。

还有个小技巧：每条用例只写一个核心验证点。出现过很多次的情况是，考生一条用例里塞了三四个步骤和好几个预期结果，最后出问题根本定位不到是哪一步出的问题。测试用例的基本原子性，在笔试里就应该体现出来。

6.2 时间分配与检查策略

拿到试卷先别急着做题，用3分钟把所有题目扫一遍，标记出简单题、中档题、难题。我的策略是先做会做的，把基础知识选择题快速拿分，再做用例设计题，最后回头啃开放题和智力题。笔试最怕的就是在智力题上死磕20分钟，最后用例设计题草草收尾，白白丢了最值钱的分数。

开放题如果一时没思路，先写框架，把一个一个维度列出来，哪怕每个维度只写一句话，也比空白或瞎编强。阅卷人最看重的是你的思路在不在正确的方向。

最后检查时要重点看：有没有漏写安全测试点、有没有漏掉数据库状态校验、金额计算题的数字有没有算错。很多考生会把等额本息的月利率算成年利率，这种粗心错误在真实测试工作里也是一样致命的。

这套2019年的笔试题，放到现在其实没有过时。AI测试、全栈测试这些词被反复提起，但底层的业务理解、用例设计、数据校验能力，依然是测试工程师的立身之本。我自己带新人的时候，也习惯先让他们把一道借款流程题完整写一遍，写得好不好，基本能看出这个人能不能在测试这条路上走远。希望这份拆解能帮你看清楚题目背后的考察逻辑，而不是背几道答案就上场。