测试开发高频笔试题全解析：从MySQL优化到LRU手写

上周整理资料的时候翻出一份2023年贝壳找房春招测试开发工程师的笔试卷仔细做了一遍发现这套题出得很有代表性。里面既有数据库、算法、网络这些计算机基础又嵌了不少 Python、Java、Linux 的工程细节问答题更是直指测试开发日常接触最多的几类工作MySQL 优化、接口测试、用例设计、Shell 处理日志、手写 LRU。不管你是正在准备测试开发校招还是想转岗做测开这套题都很值得拿来当一次“体检”看看自己的知识盲区到底在哪。这类笔试题有一个特点表面考的是知识点实际考的是平时写代码、看日志、调接口时有没有真正想过底层原理。很多答案不是靠背八股背出来的而是靠踩坑踩出来的。接下来我就按试卷的模块顺序把每道题背后的考点、解题思路、易错点全部拆开讲一遍最后再聊聊测开岗位的备考路线和实际工作能力模型。整套内容会比较长但看完之后你至少能对测试开发笔试考什么、面试官想看什么有一个非常具体的把握。1. 这份笔试卷的考察思路从题目反推测试开发岗位的能力要求1.1 为什么校招笔试爱考“杂而全”的基础题贝壳这套卷子涉及的科目非常广SQL 聚合查询、完全二叉树、HTTP 状态码、交换机路由器层级、Jmeter 断言、等价类划分、动态规划、LRU、事务隔离级别、Java 多线程、Python 深浅拷贝、JavaScript 作用域、MySQL 优化、Shell 脚本。乍一看像是一份后端开发试卷但它其实精准地画出了测试开发工程师的“能力半径”。测试开发不是纯测试也不是纯开发。日常工作中你要能看懂业务代码才能设计有效用例要能写脚本造数据才能跑自动化要懂数据库才能验证数据一致性要懂网络协议才能定位接口问题要懂 Linux 才能在服务器上排查线上故障。笔试考这些内容本质上是想筛出“具备独立解决问题的技术底座”的人而不是只会点点点的功能测试。另外这类试卷还有一个隐含作用用广度过滤“背题型选手”。如果只盯着某个框架或者某一种自动化工具去准备遇到这种杂食性考卷很容易翻车。反倒是平时自己折腾过一些小项目、写过脚本、遇过线上故障的人看到这些题会觉得“都有点眼熟”答起来更快更稳。1.2 试卷结构概览与时间分配技巧从题目分布看这份卷子应该是单选/多选考基础概念、判断考细节辨析、填空考代码输出和概念默写、问答考工程设计和手写代码。这类结构在校招笔试里非常常见不同模块的得分难度差异很大所以时间分配很关键。我自己的建议是问答题虽然分值高但不要一上来就闷头写。先把选择题、判断题快速过一遍遇到拿不准的做个标记不要在单题上耗超过两分钟。填空题如果是代码输出题建议在草稿纸上模拟执行一遍关键变量变化别只靠“感觉”。问答题通常没有标准答案考察的是思维完整性所以答的时候要分点、给场景、给方案而不是写一两句空话。举个例子如果问“MySQL 查询优化你会怎么做”只写“加索引”三个字得分一定很低。面试官想看到的是“先定位慢查询 → EXPLAIN 分析执行计划 → 根据 type/rows/Extra 判断索引是否生效 → 再考虑改写 SQL 或调整表结构 → 最后验证优化效果”这样一条完整链路。这种答题方式才是从笔试中脱颖而出的关键。2. 选择题与判断题高频考点逐个拆解2.1 数据库Group By 与聚合查询执行的底层顺序这套卷子里考察 SQL 的题含量不低典型的一题是有一张 customer 表包含 id、name、sex、age 字段查询语句为SELECT COUNT(*) FROM customer WHERE age 18 GROUP BY sex HAVING COUNT(*) 1;问这条语句的含义是什么。很多人看到 GROUP BY 和 HAVING 就开始凭印象选答案其实最好的办法是直译先筛出 age 18 的记录再按 sex 分组保留记录数大于 1 的组最后输出每组计数。换句话说它表达的是“统计每个性别中满足年龄大于 18 且数量大于 1 的组数量”而不是单纯统计年龄大于 18 的人数。这个考点背后其实是数据库执行顺序在做题和排查问题时都非常有用。SQL 的逻辑执行顺序是FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。WHERE 在分组之前过滤HAVING 在分组之后过滤。所以 WHERE 里面不能直接用聚合函数HAVING 却可以。我实际工作中就经常遇到这类问题。比如查某个接口的透出效果需要先按用户维度过滤掉测试数据再按城市分组统计很多时候多写一个 WHERE 条件结果和性能完全不一样。另外还要注意 COUNT() 和 COUNT(字段) 的区别COUNT() 统计所有行数COUNT(字段) 不考虑 NULL 值。笔试不会直接考这么细但面试官追问起来就很容易拉开差距。2.2 数据结构与算法完全二叉树叶子数、LRU 淘汰策略选择题里有一道完全二叉树求叶子节点数的题一个完全二叉树共有 1001 个节点问叶子节点有多少个。这类题用两种思路解都很快利用性质完全二叉树中如果节点总数 n 为奇数则叶子节点数为 (n1)/2如果 n 为偶数则叶子节点数为 n/2。1001 是奇数所以叶子节点数为 501。利用层数计算1001 个节点高度约为 10 层2^10 - 1 1023。前 9 层是满二叉树拥有 512 个节点最后一层有 1001 - 512 489 个节点。第 9 层剩余的节点数也可以通过孩子节点倒推最终结果同样是 501。这道题让我想起测试开发为什么要考数据结构做测试平台、写自动化框架时经常需要处理树形结构比如用例树、菜单树、依赖树。如果不熟悉树的性质遍历和计算节点复杂度时真的容易犯迷糊。LRU 那题后面问答题会专门讲选择题这里只要知道 LRULeast Recently Used是“最近最少使用”淘汰策略常用于缓存淘汰、页面置换即可。2.3 网络与系统502 状态码、交换机路由器分层试卷里有一道网络基础题核心是 HTTP 状态码 502。502 Bad Gateway 表示网关或代理服务器从上游服务器收到了无效响应。常见场景是 Nginx 作为反向代理后端服务异常或响应超时Nginx 就会给客户端返回 502。排查 502 时我的套路是这样先看 Nginx 的 error.log确认报错关键字比如 connect() failed 还是 upstream timed out然后确认后端进程是否存活端口是否正常监听再看后端服务负载比如 PHP-FPM 的 max_children 是不是被打满或者 Java 应用线程池是否耗尽最后检查网络链路比如防火墙、安全组、内网 DNS 是否解析正常。很多人一看到 502 就怀疑代码其实有相当比例是服务配置或资源问题。还有一道题考察交换机和路由器在 OSI 模型中的层级。交换机主要工作在数据链路层二层根据 MAC 地址转发数据帧路由器工作在网络层三层根据 IP 地址进行路由选择和分组转发。这个基础概念在做接口测试、链路追踪时也会用到。同一个局域网内的通信走交换机跨网段通信就必须经过路由器理解了这层关系很多网络问题的排查方向立刻清晰。2.4 测试方法等价类划分、自动化边界与断言工具等价类划分属于典型黑盒测试方法。备选项里如果出现“路径覆盖”“语句覆盖”“条件组合”这一类它们都属于白盒测试方法需要看清楚题干问的是“属于黑盒”还是“属于白盒”。等价类划分的核心思想是把输入域划分成若干互不相交的等价类从每个等价类中选取少量代表数据进行测试用最少的用例覆盖最多的有效/无效输入场景。还有一道题关于自动化测试能否完全替代手工测试。正确答案是不能。自动化测试适合回归测试、性能测试、大批量重复执行场景但探索性测试、界面易用性评估、复杂业务逻辑的异常分支仍然高度依赖人工判断。很多团队盲目追求自动化率把一些稳定性极差的 UI 用例全部自动化结果每天光修脚本就耗掉大量人力这就是没想清楚自动化边界。Jmeter 断言也是考点之一。响应断言通常用于检查响应文本是否包含预期关键字断言持续时间用于校验响应时间大小断言校验返回内容字节数JSON 断言可以直接提取 JSON 响应字段做校验。实际做接口压测时我习惯最少加两个断言一个 HTTP 状态码断言一个业务字段断言避免上游返回 200 但业务报错的情况被当成成功请求统计。2.5 语言细节与并发Python 深浅拷贝、Java wait/sleep判断题里有一道是关于 Pythonis与的对比。比较的是值是否相等is比较的是内存地址是否相同。对于小整数和短字符串Python 解释器有可能做了缓存或驻留所以会出现a b和a is b同时为 True 的情况但对可变对象、大规模数据两者结果往往不一致。判断某个对象是不是同一个对象要用is判断内容等不等要用这是写 Python 时最容易忽略的细节。Java 多线程部分重点考wait()和sleep()的区别。wait()是 Object 类方法调用后线程会释放对象锁必须从同步代码块/同步方法中调用sleep()是 Thread 类静态方法调用后线程进入阻塞状态但不会释放锁。所以如果面试官问你“如何让线程等待并释放锁”或者“如何在等待时不占用锁资源”答案就是wait()配合notify()/notifyAll()。而写一个只在当前类内部生效的定时任务用sleep()更简单直接。这套题里还经常出现synchronized关键字的判断题比如“synchronized 可以修饰方法、代码块和静态方法”这类说法。正确答案是都可以。修饰静态方法时锁定的是 Class 对象修饰实例方法时锁定的是当前对象实例修饰代码块时锁定的是括号里指定的对象。这三个锁定粒度搞清楚了后面读并发代码时才不会晕。3. 填空题代码输出题背后的“陷阱逻辑”3.1 Python 闭包与列表扩展变量作用域怎么写才不翻车Python 相关的填空题最常见的是闭包输出题。比如def outer(x): def inner(y): return x y return inner add5 outer(5) print(add5(10))输出结果为 15。这类题的核心是理解闭包会“记住”外层函数的变量 x即使 outer 已经执行完毕inner 仍然可以访问 x。很多新手在这里犯迷糊是因为误以为返回 inner 函数后x 就丢了。闭包在实际测试开发中有一个非常常用的场景给接口请求统一注入公共参数或者给某个函数预先绑定配置项。比如我们写自动化框架时经常用闭包做“配置预填写”避免每个用例都传一堆重复参数。这里要特别注意一个坑如果内部函数修改外层变量需要用nonlocal声明否则 Python 会把它当成内部新变量从而可能引发 UnboundLocalError。list 的extend也是填空题常客。区分下面几个操作a [1, 2] a.append([3, 4]) # a [1, 2, [3, 4]] b [1, 2] b.extend([3, 4]) # b [1, 2, 3, 4]append是把整个参数作为单个元素追加extend是把可迭代对象中的每个元素逐一追加。写测试脚本处理数据时如果混淆了这两个方法经常会导致结果多了一层嵌套肉眼还很难发现。3.2 JavaScript 循环里的 var 与 let异步任务执行的经典坑JS 的填空题几乎必考for循环中var和let的区别典型题目如下for (var i 0; i 3; i) { setTimeout(() console.log(i), 0); }用var声明的 i 是函数作用域循环结束后 i 的值为 3所以三个定时器回调打印的都是 3。如果把var改成leti 每次循环都会创建一个新的绑定打印结果就是 0、1、2。这个坑在做 Web 自动化、接口测试脚本时非常常见。比如你用 JS 在浏览器里批量绑定事件或者写一段 Node 脚本批量发送请求如果循环变量用了var很容易出现“所有请求都用了最后一个参数”的诡异现象。遇到这类问题先检查作用域基本都能找到原因。顺便说一句在 Node.js 里写异步批量任务我后来更倾向于用for...of配合 async/await 串行执行既符合直觉又排查简单。3.3 Set 运算与安全测试基础概念Python 的 set 运算也出现在填空题里。比如s1 {1, 2, 3} s2 {2, 3, 4} print(s1 s2) print(s1 | s2) print(s1 - s2) 是交集结果是 {2, 3}| 是并集结果是 {1, 2, 3, 4}- 是差集结果是 {1}。这组运算符在处理接口返回的数据做去重、对比、找差异时非常高效。比如校验一批用户 ID 的接口返回是否完整只需要把预期集合和实际集合做差集就能立刻看出缺少了哪些数据比循环遍历效率高得多。安全测试的填空题通常要求填“SQL 注入、XSS、CSRF、越权访问”这类常见漏洞类型。这里想提醒一点安全测试不只是“用工具扫一下”。一个合格的测开至少要能理解 SQL 注入的本质拼接恶意 SQL 片段改变查询意图以及在接口测试用例里怎么设计恶意参数。比如登录接口不仅要测正常密码还要测 OR 11这类注入语句是否会被拦截同时检查数据库报错信息是否泄漏给前端。4. 问答题实战测试开发的工程能力才是拉分项4.1 MySQL 慢查询优化从一条 SQL 说到执行计划问答题第一道是 MySQL 查询优化这也是测试开发面试里出现频率最高的问题之一。一个完整答案应该包含以下链路。先定位慢查询开启慢查询日志设置long_query_time 1用mysqldumpslow工具汇总最耗时的 SQL。没有数据支撑的“优化”都是空谈所以第一步永远是“找到那条拖慢系统的 SQL”。再用 EXPLAIN 分析执行计划。重点看四列type访问类型从好到坏一般为 system → const → eq_ref → ref → range → index → ALL。看到 ALL 全表扫描就要警觉。key实际使用的索引为 NULL 则说明没有命中索引。rows预估扫描行数值越大越危险。Extra如果出现 Using filesort 或 Using temporary说明 SQL 需要优化排序或临时表。然后针对问题做优化常用手段包括给 WHERE、JOIN、ORDER BY 涉及的列加索引建立联合索引时遵循最左前缀原则避免在索引列上使用函数或隐式类型转换比如WHERE id 123可能让 int 索引失效避免LIKE %abc这种前置模糊匹配避免SELECT *只取必要字段。除此之外分页深翻页是另一个重灾区。LIMIT 100000, 20前面扫过的十万行都会被丢弃。比较经典的优化方案是“延迟关联”先查询主键或索引覆盖范围内的 ID再回表查询详情或者基于上一页最大 ID 做游标分页。最后别忘了验证优化完把 SQL 再 EXPLAIN 一次对比 rows 和 Extra有条件的话在压测环境看 tps 和响应时间变化。一套完整的答案说下来面试官立刻能确认你有真实性能排查经验而不是只背了几个优化点。4.2 接口测试的完整考虑维度接口测试问答题的套路很固定核心是“从功能到安全再到性能”。我平时设计接口测试方案时习惯从六个维度展开功能维度正常入参能不能返回预期结果必填字段、可选字段、为 NULL 的字段分别怎么处理参数类型传错时是否报错合理边界值比如分页页码为 0、负数、超大数是否被正确拦截。异常维度接口超时、依赖服务不可用、第三方接口返回异常时接口是否会优雅降级返回的错误码和错误信息是否明确。很多团队只测“正常路径”结果线上出现依赖故障时接口直接 500用户看到一堆堆栈这就是异常场景覆盖不足。安全维度是否需要鉴权未携带 token、伪造 token、越权访问其他用户数据时能否被拦截敏感字段手机号、身份证、卡号是否加密传输和脱敏展示SQL 注入、XSS 攻击、CSRF 的常用 payload 是否被过滤。性能维度接口在正常并发下的响应时间、吞吐量、错误率数据库连接池和线程池是否被打满是否存在慢 SQL 导致接口超时。兼容维度协议版本兼容API 版本升级后老版本客户端是否可用不同请求头如 Content-Type、Accept-Encoding下行为是否一致。幂等性维度重复提交同一订单、重复回调等场景接口是否会产生重复数据。这一点在做支付、对账类接口时尤其重要因为生产环境极其依赖网络重试机制幂等性做不好用户会看到两边账不平。这六个维度都想清楚了接口测试方案基本不会有大的遗漏。4.3 手工测试用例设计从“点一点”到“系统化”问答题里面还有一个手工测试用例设计的题。很多人觉得手工测试没什么技术含量但真正能系统化设计用例的人并不多。我自己的设计流程是第一步做需求分析拆解功能点。比如“用户登录”可以拆成输入框合法性校验、账号密码正确性校验、验证码逻辑、记住密码、忘记密码、登录状态保持、异常锁定、日志记录等子功能点。第二步用等价类划分和边界值分析设计主用例。以“密码长度 6-20 位”为例有效等价类随便取一个中间值无效等价类覆盖小于 6 位、大于 20 位、空值、非字符类型。边界值则额外测 5、6、7 和 19、20、21 这几个临界值因为开发往往在边界条件上写错判断。第三步用场景法覆盖业务流程。场景法适合走通主链路比如首次登录、异地登录、登录失效后跳转、连续输错密码锁定等。每个场景都要有明确的前置条件和预期结果。第四步补充异常和兼容场景。比如断网重试、弱网切换、重复点击提交按钮、页面刷新后状态是否一致等。第五步用例评审和执行维护。用例不是写完就结束的后续需求变更时同步更新用例库线上发现的缺陷要反哺补充到用例集中。这套流程和“想测什么就点什么”的野路子相比核心差异在于可追溯、可评估、可复用。面试时你把这套方法论讲清楚比说自己“测过很多项目”有说服力得多。4.4 用 Shell 处理文本统计的几种写法Shell 问答题里出现了一道“统计 Linux 系统某个文本文件中数字出现次数”的题。很多人第一反应是写 Python 脚本但在服务器上现装 Python 依赖并不现实用 Shell 一行命令搞定才是更符合运维场景的做法。最简单的写法是统计所有数字出现的总次数grep -o [0-9] access.log | wc -lgrep -o会把匹配到的每个数字单独列一行wc -l统计行数就得到了数字出现的总个数。为什么不用grep -c因为grep -c统计的是“包含数字的行数”不是数字的出现次数一个行里出现 10 个数字它也只会计 1。如果要统计每个数字出现多少次可以在后面接入排序和去重计数grep -o [0-9] access.log | sort | uniq -csort保证相同数字相邻uniq -c输出每个数字的出现次数。注意uniq只对相邻行去重所以必须先sort再uniq顺序反了统计结果一定不对。如果文本中有多位数字比如需要统计“101”这种完整数字的出现次数-o [0-9]就不合适了应该用grep -oE [0-9]或者用awk遍历匹配。还有一个更稳健的写法是使用 awk 数组awk { for (i1; ilength($0); i) { csubstr($0, i, 1); if (c ~ /[0-9]/) count[c] } } END { for (n in count) print n, count[n] } access.log这个写法稍微复杂一点但不需要依赖额外工具在嵌入式设备或精简系统里更稳妥。实际面试时我会先给最简单的grep -o | wc -l再补充扩展方案并主动说明不同命令的适用场景。这样既证明基础扎实又展示工程判断力。4.5 手写 LRUJAVA 与 Python 的落地实现手写 LRU 是问答题的最后一部分也是最能体现代码功底的一道题。LRU 的核心是当缓存满了优先淘汰最久没被访问的数据。要实现 get 和 put 都是 O(1)必须用“哈希表 双向链表”的组合哈希表保证 O(1) 查找双向链表保证 O(1) 移动和删除。Java 实现可以用 LinkedHashMap也可以手写双向链表。如果让我现场手写更推荐 LinkedHashMap 版本代码简洁且不容易出错import java.util.LinkedHashMap; import java.util.Map; public class LRUCache extends LinkedHashMapInteger, Integer { private final int capacity; public LRUCache(int capacity) { super(capacity, 0.75f, true); this.capacity capacity; } public int get(int key) { return super.getOrDefault(key, -1); } public void put(int key, int value) { super.put(key, value); } Override protected boolean removeEldestEntry(Map.EntryInteger, Integer eldest) { return size() capacity; } }这里的关键是构造器的accessOrder参数必须为 true这样 LinkedHashMap 会按访问顺序排序被访问过的节点会移到链表尾部表头就是最久未使用的节点。removeEldestEntry在插入后判断是否需要淘汰最老元素。如果要你写一个更底层的版本那就用 HashMap 加自定义双向链表节点核心逻辑是get 时把节点搬到链表尾部put 时先检查 key 是否存在存在则更新值并搬到尾部不存在则插入尾部如果容量超限删除链表头部的节点并移除哈希表中对应的 key。Python 用collections.OrderedDict最合适from collections import OrderedDict class LRUCache: def __init__(self, capacity: int): self.capacity capacity self.cache OrderedDict() def get(self, key: int) - int: if key not in self.cache: return -1 self.cache.move_to_end(key) return self.cache[key] def put(self, key: int, value: int) - None: if key in self.cache: self.cache[key] value self.cache.move_to_end(key) else: self.cache[key] value if len(self.cache) self.capacity: self.cache.popitem(lastFalse)move_to_end(key)把 key 移到末尾popitem(lastFalse)移除最左边的元素也就是最久未使用的那个。面试时如果能顺手说出“为什么用 OrderedDict 而不是 dict”因为普通 dict 在 Python 3.7 之后虽然保证插入顺序但不提供“把已有键移到末尾”的 API这个细节会非常加分。5. 备考经验与避坑指南5.1 常见笔试失分点和应对策略结合这套卷子和过往经验我发现测试开发笔试的失分点其实很集中。第一个失分点是“审题不细”。很多选择题问的是“以下哪项不属于黑盒测试方法”有人兴奋地看到熟知的“等价类划分”就选了完全没注意题目问的是“不属于”。我的习惯是把题干里的否定词圈出来比如“不”“错误”“不能”再逐个选项做判断。第二个失分点是“代码题只看不跑”。填空题的代码输出题光靠眼睛看很容易漏掉隐式转换、作用域、闭包这类细节。有条件的情况下在本地 IDE 或在线环境里跑一遍确认输出再落笔。笔试环境通常允许本地 IDE千万不要只凭记忆硬写。第三个失分点是“问答题答得太单薄”。比如问 MySQL 优化只写“加索引”没有过程没有场景分数一定不高。面试官评分时看重的是思维链你需要展示“发现问题 → 分析原因 → 给出方案 → 验证效果”的能力。哪怕是纸上谈兵也要把步骤和理由写清楚。第四个失分点是“时间分配失衡”。有些人前面选择题抠得太细导致问答题没时间写。我的经验是问答题只要框架完整、要点准确得分率比选择题高得多所以整体时间应该倒着分配给问答题预留至少一半的时间。5.2 测试开发学习路线与资料推荐如果你正在准备测开岗位不建议一上来就刷一堆框架 API。我的建议是沿着一条主线走计算机基础 → 测试理论 → 编程语言 → 自动化测试实战 → 性能测试 → 持续集成与 DevOps。计算机基础是地基重点看数据结构、数据库、操作系统、网络四门课。测试理论不需要啃大部头把握住测试计划、用例设计、缺陷管理、测试报告这几个核心环节就好。编程语言建议主攻 Python它语法简单、生态丰富requests、pytest、Selenium、Appium 这些测开常用工具都是 Python 场景的。自动化测试实战是简历和面试的核心素材。可以自己搭一个小型接口自动化项目用 Pytest 管理用例、Requests 发请求、Allure 生成报告、Jenkins 做定时构建再结合 Git 管理代码版本。这个项目不用多大但要求“麻雀虽小五脏俱全”能体现出你对用例分层、数据驱动、断言策略、环境切换等问题的思考。之后可以往性能测试方向延伸Jmeter 和 Locust 二选一掌握场景设计、参数化、断言、监控指标分析这套流程。如果还有余力了解 Docker、Kubernetes、CI/CD Pipeline 的基础用法这些能力在测开岗位中的权重越来越高。5.3 关于 AI 测试开发的一点延伸思考现在网络上关于 AI 测试开发的讨论很多。我的个人观点是短期内 AI 不会取代测试开发但会重构测试开发的工作方式。最明显的变化是AI 已经能自动生成测试用例、自动定位缺陷根因、自动生成接口测试脚本。我试用过一些 AI 辅助工具它们在 80% 的“模板化”工作比如生成数据驱动用例、编写重复性脚本上效率极高但在复杂的业务逻辑推断、探索性测试、以及“理解业务背后的用户价值”这些方面AI 目前还做不到真正的人类判断力。所以对准备入行测试开发的人来说比掌握某个具体工具更重要的是保持对业务的敏感度和对技术原理的深度理解。AI 可以帮你省去写模板代码的时间但如果你不懂 HTTP 状态码的含义、不理解数据库事务的隔离级别、不会分析执行计划AI 给你生成一堆脚本你也不知道它到底对不对、该不该用。这套贝壳的笔试卷放在 2025 年来看知识点依然不过时。那些基础、原理、工程思维恰恰是 AI 时代最不容易被替代的护城河。备考路上不用焦虑“是不是背得不够多”更多地去写、去折腾、去复盘把每道题背后的工程场景想明白你的能力自然会在笔试和面试中体现出来。