我当年刷这份小红书2020校招测试开发后端笔试题卷三的时候第一感受是这卷子不像网上流传的很多“背八股”型笔试题它明显在筛选两类人——一类是“用过工具但没想清楚原理”的人另一类是“能把零散知识点串成系统”的人。作为过来人我把这份卷子从考点猜测、解题思路到踩坑经验完整复盘一遍顺便聊聊测试开发和后端两条线在校招笔试里到底怎么准备才不白费功夫。1. 这份卷子值得复盘的原因2020年校招笔试题的题型分布与考察逻辑先说结论小红书2020年的校招笔试题卷三考察内容基本覆盖了测试开发和后端开发两个方向最核心的基础能力而且出题风格偏向“结合业务场景考基础原理”不是单纯的概念默写。这一点和当时很多互联网公司的校招笔试有本质区别——有的公司喜欢出很偏的八股文小红书这套卷子更看重你“能不能用学过的知识解决实际问题”。我当时拿到卷子先扫了一遍大致能看出题型的分布逻辑。虽然没有官方题目全文但从同类岗位历年校招题的考察范围来看这套卷子通常可以分成四大块题型模块大致分值占比考察目标软件测试基础与用例设计25%-30%测试思维、边界值/等价类等经典方法后端技术基础语言数据库网络30%-35%编程语言掌握程度、数据库与网络原理算法与数据结构编程题20%-25%代码实现能力、复杂度分析、边界处理综合场景设计题15%-20%系统设计思维、测试策略、排查思路这个分布背后有一个很明显的信号**测试开发岗和纯后端岗在笔试阶段用的是同一套卷子说明公司默认这两类岗位的基础能力栈是重合的。**你如果想投测试开发至少得会写代码、懂后端常用技术栈你如果想投后端也得对测试的基本方法有概念因为开发同样需要自测、设计可测试的接口。这在当年的校招里算是一个“提前规划”的信号——不要只盯着单一方向准备。整套卷子的难度梯度也比较清晰。前面的选择题和填空题相对基础考察的是“知不知道”中间的大题开始上强度考察“会不会用”最后的设计题则考察“能不能想全面”。这种梯度设置对候选人来说是一个很好的“锚点”——如果在基础题上花费太多时间后面的设计题基本就废了所以时间分配本身就是这道试卷的第一道隐性考题。还有一个值得注意的点是这套卷子虽然没有直接考“测试开发工具链”的具体操作但很多题目都隐含着对工具原理的理解要求。比如问到接口测试就绕不开HTTP协议的状态码、请求头、幂等性这些概念问到性能测试就离不开并发模型、线程池参数这些后端基础。所以准备笔试题的时候千万不要死记工具的功能列表而是要把工具放到技术原理的上下文里去理解。2. 测试开发部分的出题风格与得分点拆解2.1 测试用例设计题核心是在边界条件和业务规则上做文章测试开发方向的题目最典型的就是“给一个功能模块设计测试用例”。这类题在笔试卷子里基本不会缺席而且最容易拉开分差。很多人拿到这种题就是凭感觉写五六条但评分标准里其实有固定的踩分维度。以常见的“用户登录功能”为例一份拿高分的测试用例设计至少应该覆盖以下维度功能测试正确账号密码登录、错误密码、不存在的用户名、空账号/空密码、密码大小写敏感、前后有空格的处理。边界值测试密码长度的上下限假设是6-20位则5位、6位、20位、21位要各测一遍、账号重复提交、连续登录失败的锁定策略。异常与中断网络超时、服务器返回5xx、重复点击登录按钮、断网恢复后的表现。兼容性不同浏览器、不同操作系统、不同屏幕尺寸。安全性SQL注入、密码是否明文传输、登录态token是否有效期过短、验证码是否能复用。我当时在笔试里看到同类题目时踩过一个坑只写了功能测试和边界值忘了“安全性”和“兼容性”两个维度。后来复盘才发现测试用例设计题最关键的得分点其实是“维度覆盖是否全面”而不是单个用例写得多么详细。建议答题时先列出测试维度再在每个维度下展开具体用例这样阅卷人一眼就能看到你的测试思维结构。另外业务规则是很容易被忽略的隐藏考点。小红书的业务里有很多内容相关的规则比如文章发布、评论审核、粉丝关注这类功能在出题时往往会有一个“业务限定条件”。例如“同一个用户对同一篇文章只能点赞一次再次点赞则取消点赞”这种规则必须体现在用例里。如果你只是泛泛地测“点赞成功”和“点赞失败”而没有考虑到“重复点赞取反”“并发点赞时只能有一个成功”这道题基本就拿不到好分数了。2.2 测试工具与自动化不考操作步骤考原理理解2020年这套卷子里的测试工具题基本不会要求你写出具体的命令行或脚本代码更多是考察工具背后的原理和适用场景。我当时整理了一份常考对照表后来发现对笔试和面试都很管用工具/框架常考原理点常见误区SeleniumWebDriver如何驱动浏览器、定位策略优先级以为Selenium能处理验证码和弹窗JUnit/TestNG注解生命周期、断言机制把JUnit当成功能测试工具JMeter线程组、采样器、聚合报告的含义把JMeter当成接口测试的万能工具Postman环境变量、集合运行、断言脚本以为Postman只能做手动测试Charles/Fiddler抓包原理、HTTPS证书信任、断点改包以为抓包工具只用来“看包”以Selenium为例它本身是一个Web自动化测试框架原理是通过WebDriver协议和浏览器之间建立一个通信通道把测试代码中的指令转换成浏览器能执行的自动化操作。笔试如果问“Selenium定位不到元素怎么排查”答题思路不能只停留在“换一个定位方式”而要从几个层面展开元素是否在iframe里、是否在shadow DOM中、是否有动态ID、页面是否异步加载还没渲染完成、是否被其他元素遮挡、是否是隐藏元素。这个排查思路通常比写法本身更值钱。JMeter的高频考点是“线程组参数的含义”和“聚合报告里各项指标怎么看”。很多人能说出线程数、循环次数但问“吞吐量为什么比期望值低”就蒙了。笔试中遇到这种题至少要从“服务端性能瓶颈、网络带宽、客户端资源瓶颈、参数化数据是否充足、是否有定时器引入思考时间”几个方向去回答。我当时把JMeter当性能测试工具用忽略了它做接口自动化回归时的参数化优势后来在实际项目中才发现它处理CSV数据集的灵活度非常适合做批量的数据驱动测试。自动化测试的另一个考察点是框架的分层思想。2020年的时候很多公司已经在用PO模式Page Object来组织UI自动化测试但笔试题里考察的不是“PO模式怎么写”而是“为什么要分层”。答题时要说出关键理由页面元素和测试逻辑分离之后页面变动只需要修改对应的Page层测试用例层不用动维护成本大幅降低同时测试脚本的复用率提高公共操作可以收敛到独立的模块。如果能在答案里附带一个相对简单的分层示例——把元素定位、页面操作、业务断言放到不同类里——得分会明显更高。2.3 缺陷管理与测试流程别把“流程题”答成“背流程”测试开发方向还有一个常考题型是“描述一个Bug从发现到关闭的完整流程”。很多人上来就写“提交、分配、修复、验证、关闭”这五个词这样答基本只能拿保底分。更好的答法是分角色、分状态、分边界缺陷生命周期各状态New新提交、Open已确认、Rejected拒绝、Fixed已修复、Reopen重开、Closed关闭。各角色的职责测试人员提交缺陷并跟踪开发人员确认并修复测试经理负责分配和仲裁产品经理在某些更新后需要确认需求变更。重要边界开发拒绝修复时测试怎么处理、缺陷在验证不通过时如何Reopen、低优先级的缺陷在版本发布前如何处理。这个小点看起来简单但它是“测试思维”的直观体现。因为流程背后反映的是团队协作的规范性和严谨性而校招生往往缺乏实际的项目协作经验只能靠背流程所以我们这些做过一点真实项目或者看过开源社区Issue管理的人反而能在这种题上写出更接地气的答案。我当时还特意加了“线上紧急Bug不走完整流程需要先紧急修复再补单”这类现实处理方式结果这道题的反馈比死记流程好得多。3. 后端基础题高频考点与易错点清单3.1 语言基础从语法题到内存模型的跨越后端方向的题目语言部分通常以Java为主偶尔会掺一些Python或Go的题。语法层面的考点包括equals和的区别、HashMap的底层实现、String不可变性、异常处理机制、泛型擦除等这些是高频选择题填空。但真正拉分的往往是“内存模型”和“并发”相关的内容。以“Java内存模型”为例笔试常见的考察点不是让你背堆和栈的区别而是给出代码片段让你分析该对象创建之后各个部分分别存储在哪个区域。比如一个典型的例子public void method() { User user new User(xiaohongshu); String name user.getName(); }在这个代码片段中user引用和name引用存放在Java虚拟机栈的栈帧中new User(xiaohongshu)创建的对象和内部的name字符串如果是字面量赋值则指向常量池存放在堆区。如果答“user和name都存在堆里”说明你只记得概念没理解引用和对象的区别。这道题在笔试里反复出现但错误率一直非常高。并发编程的考点则集中在synchronized和volatile、synchronized和ReentrantLock的对比、线程池参数设置、按顺序并发执行的方式。这里有一个常被忽视的细节**volatile不保证原子性只保证可见性和有序性。**如果你在代码题里用volatile来保证计数器的线程安全那基本就掉坑了应该说清楚它适合开关状态这样的标志位场景并不适合做计数器。相比之下synchronized、ReentrantLock、AtomicInteger各自适用的场景要能配合讲出来。回答线程池参数时我一直推荐用一个具体的案例一个IO密集型任务和一个CPU密集型任务分别怎么设置核心线程数和最大线程数。这两个场景下参数完全不一样——CPU密集型任务线程数可以设置为CPU核数1IO密集型任务则通常需要更大的线程数来掩盖等待时间。这类题考察的不仅是背参数更是你是否理解线程池的调度机制和任务执行的阻塞点在哪里。3.2 MySQL索引失效与SQL优化是底层逻辑数据库是后端笔试的大头MySQL相关题目几乎每年都有。常考的点覆盖事务隔离级别、索引失效场景、SQL执行顺序、SQL优化、MVCC机制。其中“索引失效”是选择题的高频考点也是很多人容易混淆的部分。一份常考索引失效场景清单大致如下对索引列使用函数比如WHERE DATE(create_time) 2020-01-01会让索引失效。隐式类型转换比如索引列是varchar查询条件传入数字会导致索引失效MySQL隐式转换后无法命中索引。前导模糊匹配比如LIKE %keyword会失效但LIKE keyword%通常可以走索引。条件中使用OR连接非索引列索引通常会失效。NOT IN、、!在某些情况下无法使用索引。联合索引不满足最左前缀原则比如索引是(a, b, c)查询条件是b和c索引失效。真题如果给一个慢查询SQL让你分析优化思路答题节奏应该是这样的先看执行计划explain分析type类型和key字段是否使用了索引再看查询条件里有没有索引失效的操作然后看是否涉及回表和覆盖索引的问题最后才考虑是否需要改写SQL或增加冗余字段。这个顺序本身就是得分点。3.3 Redis从缓存穿透到数据一致性再到持久化Redis在后端笔试中的出现率极高。最基础的是常用数据类型及应用场景比如String用于缓存计数Hash用于存储对象属性List用于消息队列Set用于去重与交集并集计算ZSet用于排行榜。然后是高级考点缓存穿透、缓存击穿、缓存雪崩的区别和解决方案。这里的思路是缓存穿透查询一个不存在的数据导致请求直接打到数据库。解决方式包括缓存空值、使用布隆过滤器、接口层做基础校验。缓存击穿某个热点key过期的瞬间大量请求打到数据库。解决方式包括互斥锁、逻辑过期、热点key不过期。缓存雪崩大量key同时过期或者Redis宕机导致数据库压力骤增。解决方式包括过期时间加随机值、永不过期、多级缓存、Redis主从或集群架构。常考的数据一致性问题主要围绕“先删缓存再更新数据库”还是“先更新数据库再删缓存”。在笔试里比较稳妥的答题思路是优先采用先更新数据库再删除缓存的方式并说明如果删除缓存失败如何处理——可以通过消息队列异步重试或者订阅数据库的binlog变更来触发缓存清除。这种方案虽然不是零延迟一致但在绝大多数业务场景下已经足够。Redis持久化也是笔试常客。RDB和AOF的区别、各自优缺点、如何选择这些问题几乎每年都有公司考。答题时可以给一个清晰的对比框架RDB是快照式的全量持久化恢复快但对数据完整性保障较差AOF是追加式的日志持久化可以做到秒级甚至更细粒度的数据恢复但性能开销更大。比较推荐的组合是RDB做主备全量数据加载、AOF做数据增量保护具体配置要看业务对数据丢失的容忍度。3.4 计算机网络不只是背状态码而是理解三次握手后端笔试必考计算机网络。TCP三次握手和四次挥手的过程、为什么需要三次握手、TCP和UDP的区别、HTTP和HTTPS的区别、状态码含义、GET和POST的区别这些都是高频题。但真正加分的答案不是在背过程而是能解释设计原因。比如三次握手的意义就包括确认双方的收发能力都正常、同步初始序列号、避免历史重复连接导致的资源浪费。笔试中如果只写“第一次客户端发SYN第二次服务端回SYNACK...”只能得基本分补充“为什么不是两次或者四次”才能显示出深度。HTTP状态码也常考这里有几个容易混淆的状态码需要特别注意301永久重定向浏览器会缓存重定向结果。302临时重定向每次都要重新请求原地址。304Not Modified协商缓存命中服务端返回该状态码但不会返回响应体。400Bad Request客户端请求错误通常代表参数格式非法。401Unauthorized未认证通常需要登录。403Forbidden服务器拒绝执行虽然身份认证可能已经通过。另一个高频考点是HTTP和HTTPS的区别。HTTPS的核心不仅仅是加密而是通过SSL/TLS协议实现对通信内容的机密性、完整性和服务器身份认证。回答时按“对称加密效率高、非对称加密安全性高HTTPS用非对称加密协商出对称密钥之后数据用对称加密传输”来展开再补充证书的作用是验证服务器身份防止中间人攻击这样就能把整条链路说清楚。4. 算法与编程题不只是AC还看代码习惯4.1 常见出题方向字符串、数组、链表、动态规划从同类型暑期实习和校招的整体出题风格来看小红书笔试题卷三的算法题难度大概率处在LeetCode中等题的层次不会出特别偏的题目但会考查对基础算法和数据结构的掌握程度。重点方向包括字符串处理、数组操作、链表逆置、二叉树遍历、动态规划。一个高频题型是“字符串中的字符去重并保持相对顺序”或“判断两个字符串是否互为变形词”。这类题本身不难但笔试考察的往往不是你能不能做出来而是你处理边界条件的能力空字符串、全重复字符、字符串长度很大时是否有O(n)时间复杂度的方案。数组和链表相关的题容易出“给定一个数组找出和为目标值的两个数”这类经典题目。暴力解法两重循环也能过但如果想拿更高分就要写成利用哈希表将时间复杂度降为O(n)的版本。代码量不大但非常体现基本功。4.2 一个典型的代码题答题框架与细节看卷子时间分配的话通常编程题是压轴的大题。答这类题有一个通用的框架按这个顺序写基本不会漏分先写解题思路说明时间复杂度和空间复杂度。写主逻辑代码保持变量命名清晰。显式处理边界条件空数组、长度为一、值越界、重复值。给出测试用例举例不是在笔试里完整跑测试而是在代码注释中列出几个关键用例来验证逻辑。以“求二叉树最大深度”为例标准的递归解法很短空节点返回0非空节点返回左右子树最大深度1。但如果只写这段代码说明你只回答了“会不会”如果补充说明“递归深度受系统栈限制二叉树严重倾斜时可能栈溢出可以用迭代层序遍历方式实现同样的功能”这个追加的说明才是真正的加分项。笔试卷子如果有空间强烈建议把这种对比思考写上去阅卷人能看到你的边界意识。4.3 处理“没见过的题”时最稳妥的思路笔试中一定会遇到没见过的题。有些人不假思索就开写结果越写越偏。我的经验是先花两到三分钟把题目理解准确抽象成一个已知的模型。很多题本质是“排序二分”“遍历哈希表”“递归回溯”三种模型的组合把题目映射到已知模型之后解题就清晰多了。如果一道题想了十分钟还是没有思路不要死磕。先把基础的暴力解写出来保证拿一部分分数有些笔试题是按测试用例通过比例给分的再逐步优化。校招笔试最怕的不是不会做而是因为一道难题导致后面简单的题都没时间做。5. 综合场景题从笔试题到系统思维的跨度5.1 测试开发方向的场景题如何测试一个“搜索框”场景题是卷子里最能区分经验深浅的部分。测试开发方向的常见场景题是“如何测试一个搜索框”或者“如何测试一个推荐流”。很多人觉得这种题很虚但只要掌握答题框架它其实是整张卷子中最能展示系统思维的部分。以“搜索框”为例答题思路可以分五层展开功能层面正常搜索、关键字联想、空搜索、搜索结果排序、搜索历史记录、清空历史、热门搜索展示。性能层面搜索接口响应时间、搜索请求并发量、搜索结果图片懒加载性能。兼容性层面不同浏览器、不同移动端系统、不同网络环境弱网/无网。安全层面搜索词注入、XSS脚本注入、用户搜索隐私保护。异常场景输入特殊字符、超长字符串、输入emoji表情、连续快速输入导致请求顺序错乱。这道题的评分关键不在于你列出了多少条用例而在于你是否有一个“从功能到性能到安全”的测试框架。如果你的答案只有功能点即使写出了五十条用例分数也不会特别高。反过来如果你能展示出分层的测试思维哪怕每条只写一句话也会给人留下清晰的印象。类似地“如何测试一个购物车功能”往往包含加购、改数量、删除、结算、优惠券计算、库存扣减、并发下的超卖问题。尤其值得关注的是超卖问题因为它从测试自然地延伸到后端设计数据库行锁、乐观锁版本号、Redis预扣库存这些方案都可以作为验证点来考察。5.2 后端方向的场景题接口设计和数据一致性后端方向的场景题通常围绕“设计一个短链接系统”“设计一个点赞接口”“设计一个关注关系”或“设计一个订单超时关闭方案”来出题。这类题看起来是设计题实际上考察的是你对数据模型、接口语义、一致性和容错性的理解。以“点赞接口”为例答题不能只说“有一个点赞表点一下插入一条记录”。一个完整的方案应该拆成几个层次接口层面POST/like和DELETE /like是语义更清晰的RESTful设计而不是用一个POST /toggleLike通过开关控制后者在并发场景下容易产生状态不确定性。数据模型点赞记录表user_id, target_id, target_type, create_time同时需要在target表维护点赞数字段。一致性方案什么时候更新计数、mq异步更新的可靠性怎么保障、数据库和缓存双写失败怎么处理、热点内容被大量点赞时怎么扛住。幂等设计重复请求、客户端重试时保证同一个用户对同一个目标只能有一条点赞记录通常用唯一索引或者token机制。订单超时关闭则是另一个高频设计题。常见的方案有定时轮询扫表、延迟队列、Redis过期key监听以及时间轮。每种方案各有优劣定时扫表实现简单但对数据库压力大延迟队列精确度高但需要额外维护组件Redis过期key监听存在过期到达时间精度的问题。回答时如果能比较几种方案的优缺点再结合业务量级给出选型建议会更加出彩。5.3 从笔试场景题中提炼出的通用思维模型把各种场景题放在一起看互联网大厂的笔试场景题几乎都围绕几个通用的思维模型展开缓存模型数据一致性、缓存穿透/击穿/雪崩。异步模型消息队列削峰、最终一致性、重试机制。并发模型锁的粒度、幂等设计、超卖与重复提交。安全模型用户鉴权、接口防刷、数据越权访问。这套模型不仅笔试用得上后来实际做项目和面试复盘时都反复用到。我当时建议准备笔试的人用一个专门的文档把每套模型下的经典问题、解决方案、常见坑整理成自己的记忆结构笔试前过一遍比盲目刷题高效得多。6. 复盘式备考路线当时踩过的坑和后续验证6.1 我在复习阶段踩过的三个具体的坑第一个坑是只刷题不总结。笔试前我每天在在线评测平台上刷算法题刷了几十道但很少对同一类题做归纳。结果考试时遇到一道“删除链表的倒数第N个节点”虽然和刷过的题很接近但因为当时没有总结“快慢指针”的通用场景现场反应还是慢了很多。后来我调整了刷题方法每做完一道题把这个题解法抽象成一句话归类到对应的算法模式下面比如“快慢指针”“双指针滑动窗口”“前缀和”“单调栈”。这样面试或者笔试时看到题目能迅速映射到模式而不是靠刷题数量去碰运气。第二个坑是重知识点轻系统理解。准备后端基础的时候我花了很多时间背Redis数据结构的命令和MySQL索引底层原理但忽略了这些技术在一个具体业务场景里如何配合使用。应付选择题还行一旦场景题的题干里带了一段业务背景就不知道怎么把知识用进去。后来我把复习方式改成了“按场景打包复习”——比如“用户登录”场景会涉及JWT、Redis缓存、数据库索引、接口幂等、黑名单机制再比如“商品详情页”会涉及缓存预热、缓存降级、接口限流、数据一致性。这样每一个知识点都不是孤立存在的而是长在业务结构里的。第三个坑是忽视了测试思维的训练。我始终觉得投测试开发岗算法和代码能力练好了就差不多了结果在模拟场景题时发现写测试用例的思路非常单一只会列正常流程和异常流程完全不会从安全性、兼容性、性能、用户体验这些维度去补充。后来我强迫自己拿到一个功能模块先写出测试维度再在维度下面填充用例经过一段时间的练习测试思维才逐渐成型。6.2 这套卷子对后续面试的持续影响力笔试只是校招的第一关但它的知识和能力框架会延续到后面的每一轮面试。比如笔试中测试开发部分的用例设计题面试时很可能会变成“请你现场设计一个测试方案”考察的能力完全一致后端部分的Redis和MySQL问题面试时大概率会追问“你实际项目中遇到过缓存击穿吗”这类深挖型问题。复盘这套卷子时我梳理出了一条比较清晰的备考主线如果你也准备测试开发或者后端岗可以参考基础能力层面Java/Python语法、数据结构与算法、计算机网络、操作系统、数据库。岗位专项层面测试开发需要补充测试理论、用例设计、自动化测试框架、缺陷管理流程后端需要补充Linux命令、常用框架原理、系统设计方法论。综合能力层面场景题、项目复盘、沟通表达和逻辑梳理。这三个层面其实还可以映射成一份“能力自检清单”基础能力能不能闭卷写出关键答案岗位专项是不是能结合案例讲出来综合能力能否在时间压力下输出结构化的表达。我在实际笔试中感受最深的就是“结构化表达”这一项答题条理越清晰得分就越稳。6.3 给后来者的几条“性价比最高”的备考建议结合这套卷子的出题逻辑和刷题经验我给准备测试开发和后端校招的同学几条实操建议**语言基础优先选Java面试覆盖面更广。**即使你更熟悉Python或Go简历上的主语言只要有一条清晰的技术栈路线笔试基本不会吃亏。Java在并发、JVM、框架生态方面的资料最多复习效率更高。**多刷近期真题但更重要的是整理分类。**不要只看数量把每道题归类到考点模块下考前集中过一遍自己的错题本。**场景题一定要动笔写不能只在脑子里想。**笔试题里时间紧张如果不提前练习结构化输出现场容易想到什么写什么。提前把“功能、性能、安全、兼容、异常”这五个维度练成肌肉记忆任何场景题都能快速列出一个框架。**软技能也要提前准备。**笔试虽然不直接考表达但逻辑是否清晰会体现在答案结构上面试时就更重要了表达顺畅的人天然有优势。最后说点个人体会复盘完这套卷子我最深的感受是校招笔试考察的核心并不是你到底背了多少知识点而是你在有限时间内能不能把学过的知识“组织”成一套有结构的答案。真正拉开差距的不是会不会而是稳不稳、全不全、有没有边界意识。测试开发和后端岗位的笔试准备前期可以分开学后期一定要合并练——因为这两个方向在真实工作里本来就是互相咬合的后端工程师写出来的接口质量直接决定测试人员怎么设计验证方案测试人员反馈出来的问题也常常反过来推动后端设计改进。后来我在实际项目里体会得越来越深也建议你准备笔试的时候把这份“互相理解”的视角提前建立起来。