先说明一下：这张试卷是2023年春招的，网上流传的版本信息比较零散。但作为经历过完整校招、也参与过社招面试的测开老兵，试卷拿到手，我看的其实不是某道题的答案，而是整个考察逻辑和出题人想要的人。这篇就顺着试卷的考察维度逐块拆，把每一类题背后的考点和备考思路说透。
1. 试卷整体结构与考察逻辑拆解
1.1 这又不是刷题，是测开的“行为面试”
先把大框架摆出来。2023年贝壳找房春招测试开发工程师笔试卷，整体时间120分钟，常见配置是：单选20题左右、编程题2到3道、测试设计题1到2道、简答题若干。乍一看好像和普通后端开发的笔试卷没什么区别，但仔细做下来会发现，出题人一直在围绕一个核心问：你有没有用测试思维去写代码、去分析系统。
举个很典型的例子。编程题里给了一个字符串处理需求，描述本身很常规，但输入说明里藏了边界条件：空字符串、超长字符串、包含特殊字符、重复字符等。很多候选人把它当普通算法题写，写完核心逻辑就提交，结果用例挂了一大半。而真正的测开候选人会下意识地先列边界，再写实现，甚至会在注释里写“这里需要处理空串返回null”。
这就是我常说的，测开笔试卷其实是一场“带编码行为测试”。考官不是要看你能AC多少题，而是看你在面对不确定输入时有没有防御意识。所以这份试卷的每一类题，本质上都在问同一件事：你有没有在代码里预判未来可能出错的路径。
1.2 考察维度拆解：算法只是入场券
试卷的具体题型分布大致是：
| 题型 | 数量 | 考察目标 |
|---|---|---|
| 单选题 | 15-20 | 计算机网络、操作系统、数据结构、数据库、Linux基础 |
| 编程题 | 2-3 | 代码实现能力、边界处理、算法基础 |
| 测试设计题 | 1-2 | 测试用例设计能力、业务理解 |
| 简答题 | 2-3 | 接口测试、自动化框架、性能测试、质量保障思路 |
从这张表能看出来，算法题占比其实不高，但它是硬门槛。贝壳这类互联网公司不会要求你手撕红黑树，但二分、双指针、哈希表、字符串处理、基础动态规划、排序这些高频考点一定要熟练。
更重要的一点，它把“测试设计题”单独拿出来考，这跟纯后端岗位区别非常明显。因为测开工程师日常工作中有一半时间在写用例、设计场景、考虑异常链路，所以题目里专门有一个场景让你去拆，而且会故意留一些业务上的坑。我接下来会详细拆一道有代表性的测试设计题，告诉你该怎么往深了写。
1.3 贝壳找房的业务底色决定出题方向
再往深处说一句。贝壳的业务核心是房产交易，包含房源信息、经纪人作业、线上签约、资金存管、售后流程等一系列环节。所以在它的笔试卷里，编程题和测试设计题往往不是抽象的数学题，而是带业务背景的场景题。比如房源信息去重、按小区聚合统计、优惠券状态机流转、用户搜索排序、看房预约时间冲突检测等。
你提前了解这个背景，答题时就能更敏锐地捕捉业务约束。比如设计房源搜索测试用例时，有候选人只会写“输入关键词返回结果”，但贝壳的考官想看到的是：你还得考虑城市维度、房源状态（在售/已成交/下架）、经纪人是否在职、价格区间边界、排序策略是否合理、并发下数据是否一致。这些考虑不是凭空来的，而是对这个行业业务有了解才会想到。
2. 编程题精讲：从AC到有测试思维的编码
2.1 典型题目：房源关键词匹配统计
编程题里比较有代表性的一道，大概描述是这样：给定一批房源标题和一系列关键词，统计每个关键词在所有房源标题中出现的次数，按次数降序输出，次数相同按关键词字典序升序。输入规模数量级在10万级。
这道题表面上是“字符串匹配+排序”，很多候选人第一反应是暴力枚举，每个关键词遍历所有房源标题，调用string.find或者indexOf去匹配。如果关键词数量是1万，房源标题是10万条，那最坏就是10亿字符级别的匹配操作，时间上基本会超时。
更合理的思路是用哈希表预处理，然后逐一匹配。但这里有个关键考点：匹配方式。题目里没有说清楚是不是“精确匹配子串”，如果是包含关系，一个简单的indexOf其实就够了；如果要求分词匹配（比如按空格切分），那就得先做分词再统计。这个题目如果出题人故意不写清楚，考察的就是你有没有反问和澄清需求的意识。笔试卷面上没法问，那你就要在代码注释里写明假设，这也是一种得分点。
2.2 一题多解：倒排索引是加分项
既然业务背景是房源，如果你对搜索引擎有了解，这题的最佳解其实是倒排索引：把每个房源标题分词，建立词到房源ID列表的映射，然后对关键词直接查表，统计命中次数。时间复杂度从O(N*M)降到了近似O(N+查询次数)，单次查询基本是常数级。
我当时跟学弟复盘这道题时说，倒排索引你写不写得出来不是关键，关键是能不能在代码里体现出“当数据量大时，我有索引意识”。哪怕你不写完整实现，在注释里写一句“数据量大时可采用倒排索引优化，先将标题分词建索引，再查询关键词”，面试官都会对你高看一眼。
另外还有个细节：统计完次数后要排序，这里建议直接用语言内置的sort，别自己写快排，容易在边界和稳定性上出问题。但你要注意排序的稳定性，关键字是“次数降序，字典序升序”，所以比较器要写成：
if (a.count != b.count) { return a.count > b.count; } return a.word.compareTo(b.word) < 0;这里用Java写就是Comparator里两个条件，用Python就是sorted的关键字传tuple。考察的是API熟练度和细节敏感度，很多人挂在忘记第二个排序条件上。
2.3 题目二：看房预约时间冲突检测
第二道编程题也很有贝壳特色：给定多个经纪人的带看预约时间段，格式是“2023-03-01 10:00~11:30”，判断是否存在时间重叠，输出重叠的预约编号。这道题看着像区间重叠检测，但业务上的坑在地点、房源、经纪人多维度。
核心解法是把预约按开始时间排序，然后依次比较前一个预约的结束时间和当前预约的开始时间，如果结束时间大于当前开始时间，就说明有重叠。这个思路很简单，O(n log n)来自排序，一次遍历就能完成。
但这里面至少有三个容易踩的坑：一是时间解析，字符串要转成datetime，处理格式不一致的情况；二是边界条件，比如一个预约的结束时间正好等于另一个预约的开始时间，算不算重叠？这取决于业务定义，如果没有明确说，我会把“等于”视为不重叠，并在注释里说明这个假设；三是多维度判断，如果题目的“重叠”要求同一房源、同一经纪人、且时间段相交，那么排序就要在“房源ID+经纪人ID+开始时间”这样的复合键上做。
我的建议是写代码前先花两分钟把时间区间重叠的数学条件写出来：给定区间[a, b]和[c, d]，重叠条件是a < d且c < b。把这个公式写清楚，再落到代码，基本不会错。
2.4 代码规范：考官会看你的注释和变量命名
编程题部分，我最想强调的点是：笔试系统里，考官真的会看代码，不是只看结果。我自己参与过校招简历筛选和笔面试评审，一份代码如果有清晰命名、必要注释、边界处理、异常考虑，哪怕AC率不是百分之百，评分也往往高于一份AC全对但写得像“一坨拼出来的逻辑”的代码。
具体来说，命名别用a、b、c，至少用keyword、count、title这样的业务词。注释写三类就够了：数据规模说明、边界条件说明、业务假设说明。异常处理上，空输入返回空结果，非法时间格式单独catch并记录，不要整个程序崩溃。
如果你还有余力，在代码最后写一个简短的测试用例列表，比如“输入空列表、输入完全重叠、输入首尾相接”等，这在笔试中会非常加分。因为这就是测开和纯后端的差异点：后端可能写完逻辑就觉得结束了，你写出测试列表的那一刻，就是在告诉考官，你适合做测试开发。
3. 测试设计题精讲：用场景法拆解业务逻辑
3.1 拿到场景题，先别急着写用例
测试设计题是整套试卷里区分度最高的一题。题目通常会给一个功能描述，比如“设计房源搜索功能的测试用例”，并要求覆盖功能、接口、兼容性、异常等角度。很多候选人上来就洋洋洒洒写几十条用例，看着很努力，但得分却不高，原因是缺少结构。
我拿到这类题，会先在草稿纸上画三个维度，再动笔。
第一个维度是测试金字塔：单元层面、接口层面、UI/E2E层面各测什么。第二个维度是功能拆解：正常流程、异常流程、边界条件、业务规则。第三个维度是质量属性：功能、性能、兼容性、安全、易用性。
用这三个维度去套任何场景题，都能把思路撑开。拿房源搜索来说，正常流程是输入小区名/地铁站/商圈，返回在售房源列表；异常流程是输入不存在的小区、输入空格、断网、服务端返回500；边界条件是最长关键词长度、搜索结果为空、翻页到最后一页、价格筛选为0或负数；业务规则是仅展示“在售”状态的房源、已下架房源不出现在列表（但详情页可能可以通过链接进入）、经纪人离职不影响已发布房源展示等。
3.2 等价类划分与边界值分析实操
写用例时，等价类划分是最基础也是最重要的方法。以“房源面积筛选”为例：假设需求是“房源面积筛选范围为0-1000平方米，支持整数输入”，那有效等价类就是0-1000之间的整数，无效等价类就是负数、大于1000的数、小数、字符串、空值。每个等价类抽一条代表用例就行，但边界值要额外测：0、1、999、1000、-1、1001、0.5、“abc”、空字符串。
这不是什么高深理论，但笔试时能把边界写全的人真的不多。为什么会这样？因为很多人脑子里的“测试”是“输入正常值看输出”，而不是“系统哪个点最容易崩”。边界就是最容易崩的地方，写用例时下意识把边界列出来，这是测开的基本功。
我建议笔试时用表格来呈现用例，比如：
| 用例编号 | 测试项 | 输入/操作 | 预期结果 | 优先级 |
|---|---|---|---|---|
| TC01 | 正常筛选 | 面积输入50 | 返回面积50㎡的房源 | P1 |
| TC02 | 下边界 | 面积输入0 | 返回全部房源或按需求处理 | P1 |
| TC03 | 上边界 | 面积输入1000 | 返回面积1000㎡的房源 | P1 |
| TC04 | 越界 | 面积输入1001 | 提示输入合法范围，不查询 | P2 |
| TC05 | 非法字符 | 面积输入“abc” | 前端拦截，不允许提交 | P2 |
表格最大的好处是阅卷人一眼能看到你考虑过哪些点，而不是在文字段落里大海捞针。而且表格形式天然体现结构和条理，符合大厂对文档表达能力的要求。
3.3 场景法：把用户行为串成故事线
除了等价类和边界值，场景法也是必考重点。场景法不是孤立地测一个输入框，而是把用户操作串成一条故事线。比如“用户从首页进入搜索页→输入小区名→点击搜索→查看结果列表→点击查看详情→收藏房源→预约看房”，这就是一条主场景流。
主场景之外还要考虑备选流：搜索结果为空时，提示“没有找到相关房源”并提供附近推荐；网络异常时，展示错误页和重试按钮；用户连续快速点击搜索两次，是否会重复请求；详情页下架时，返回列表页是否仍然可用；收藏操作在未登录状态下，是否跳转登录页。
这里有个技巧：写场景法用例时，把自己当成第一次用这个产品的用户，一个功能一个功能地往后推，每一步都问“如果我是用户，点了这里会怎样？如果网络不好会怎样？如果信息不存在会怎样？”这样就能自然地串出几十个场景。比硬背模板要有效得多。
3.4 系统性地补充非功能测试角度
很多候选人写测试用例只写功能，忽略了非功能维度，这在测试设计题里会丢分。贝壳的房源搜索，至少要补上这么几个维度。
性能：搜索接口在并发200用户下的响应时间P95小于800ms；热门城市关键词的搜索QPS预估；分页深度很大时（比如第100页）查询会不会变慢；缓存策略是Redis缓存还是本地缓存。兼容性：微信内置浏览器、iOS Safari、Android Chrome、各版本App（iOS 14+、Android 8.0+）、不同屏幕尺寸下的搜索结果展示。安全：搜索关键词是否有SQL注入风险、接口返回数据是否包含敏感字段（如业主手机号是否脱敏）、登录态失效时接口返回什么。
这些维度不需要全部写进笔试卷，但至少每个维度补一两条，能让阅卷人看出你有系统性的质量意识。我当时带过的一个实习生，笔试时在兼容性维度写了“不同手机品牌自带的浏览器内核不同，可能导致页面渲染差异”，这一句话就给面试官留下了深刻印象。
4. 数据库与Linux实操题：测开的“手边工具”
4.1 SQL题：连表、聚合、排序是标配
贝壳笔试卷的SQL题一般会结合房源和经纪人数据来出。比如“统计每个城市在售房源数量，按数量降序排序，只输出数量大于100的城市”这类。这里考的其实是三个知识点：GROUP BY分组、HAVING过滤聚合结果、ORDER BY排序。
我见过很多候选人在这道题上翻车，翻车原因不是不会写GROUP BY，而是忘了加HAVING，或者用WHERE去过滤数量，导致直接报错。WHERE和HAVING的区别是：WHERE在分组前过滤行，HAVING在分组后过滤聚合结果。数量大于100是对聚合结果做的判断，所以必须用HAVING。
再进阶一点的题目会考子查询或窗口函数。比如“找出每个城市在售房源价格最高的前三套房源”，这就需要用窗口函数ROW_NUMBER() OVER(PARTITION BY city ORDER BY price DESC)，再在外面套一层查询取rn小于等于3的数据。窗口函数在互联网公司笔试里出现频率越来越高，建议提前练熟。
我的建议是，SQL题的复习重点是：GROUP BY、HAVING、JOIN（特别是LEFT JOIN和INNER JOIN的区别）、子查询、窗口函数、去重。这六块覆盖了贝壳这类公司笔试SQL题的绝大多数考点。每类都找两三道题练到手熟，考试时基本不会卡壳。
4.2 Linux题：日志分析能力直接对应工作场景
Linux在测开笔试里很少考冷门命令，更多是“给定一个线上应用日志文件，统计报错次数”这类贴近生产场景的问题。常见命令是grep、awk、sort、uniq、tail、sed。
一道典型的题是：统计access.log中每个接口的访问次数，按次数降序输出前10个接口。完整命令是：
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10这个命令拆开看，awk取第七列（通常是请求路径），sort让相同路径相邻，uniq -c统计次数，sort -rn按数值降序排序，head -10取前十条。每一环都对应一个Linux基础知识。如果你能顺手解释每个管道的作用，这在笔试简答题里就是加分项。
还有一类题是“日志中出现了大量超时报错，给出排查命令”，这时候除了grep定位关键字，还要会用tail -f实时查看、用wc -l统计行数、用less翻页查看大文件、用top和free查服务器负载和内存使用。
为什么Linux在测开笔试里如此重要？因为测试开发工程师日常就要去Linux环境部署测试环境、查看服务日志、分析接口报错、定位问题归属。这些能力不是纸面知识，而是日常干活的基本功。笔试考它，就是提前筛选掉不了解线上环境的人。
4.3 网络与操作系统基础题：不深但广
单选题部分里，计算机网络和操作系统往往是重头戏。网络题常考的有：TCP三次握手和四次挥手、HTTP状态码含义（特别是301/302/304/401/403/404/500/502/503）、HTTP和HTTPS的区别、Cookie和Session的区别、DNS解析流程、TCP和UDP的区别。
操作系统题常考的有：进程和线程的区别、死锁产生的四个必要条件、虚拟内存和物理内存、进程间通信方式、IO多路复用。数据库题常考索引失效场景、事务的ACID、隔离级别、乐观锁和悲观锁。
这些题看起来是“八股”，但测开岗位考它们是有道理的。设计接口测试用例时，你要知道HTTP状态码和常见错误；排查线上问题时，你要会看进程状态和日志定位死锁；设计性能测试方案时，你要理解并发和IO模型。所以复习时不要死记硬背，每道题都想想“这个知识点在我日常测试工作中什么时候会用到”，这样记得更牢，答题时也能写出自己的理解。
5. 简答题：接口测试与自动化框架的底层原理
5.1 接口测试的核心关注点
简答题里必有一道接口测试相关的问题，常见的问法是“设计一个商品详情接口的测试方案”或者“接口自动化测试中，你如何设计断言”。
接口测试的核心不只是“调通接口、看返回200”，而是要在三个层面验证。
协议层面：请求方法是否正确、请求头是否完整、状态码是否符合预期、响应时间是否达标。数据层面：响应体的JSON结构是否符合文档、字段类型是否正确、关键字段值是否准确、数据是否落库。逻辑层面：相同参数重复请求结果是否一致、不同参数的组合是否返回不同但合理的结果、异常参数是否能被正确处理。
以房源详情接口为例，正常用例要验证：传合法的房源ID，返回的JSON里有title、price、area、address、status等字段，且status为1（在售）。异常用例要验证：传不存在的房源ID返回404还是自定义错误码；传负数ID返回什么；不传ID返回什么；传非数字ID返回什么。还要考虑并发场景：同一个房源ID被恶意刷接口，服务端是否有频率限制。
写这道简答题时，建议用“入参校验→正常流程校验→业务规则校验→异常流程校验→数据一致性校验”的层次来组织答案。这样逻辑清晰，阅卷人不用费力找你的得分点。
5.2 自动化框架题：从使用到原理
自动化相关简答题常问“你用过哪些自动化测试框架，它们的工作原理是什么”，或者“设计一个可维护的UI自动化测试框架，你会怎么设计”。
很多候选人的答案是“我用过Selenium”就没了。这种答案在笔试里几乎不得分。正确的答法应该是：说明Selenium通过WebDriver协议与浏览器驱动通信，驱动控制浏览器执行操作，底层使用JSON Wire Protocol传输命令；元素定位方式有id、name、xpath、cssSelector等，推荐优先使用data-*属性定位，因为更稳定；等待策略有强制等待、隐式等待、显式等待，推荐显式等待，因为它能精确等待某个元素出现。
进一步，设计框架时要说分层。至少要分四层：测试用例层（描述业务场景）、页面对象层（Page Object，封装每个页面的元素和操作）、公共方法层（封装点击、输入、滚动等通用动作）、配置文件层（环境地址、账号信息、浏览器类型等）。分层的目的只有一个：降低维护成本。当页面元素变更时，只需要改页面对象层的定位器，不用动用例层逻辑。
这个题的本质是考察你有没有做过真实项目、有没有踩过维护成本高的坑。如果你能写出“上次项目用Selenium写脚本，结果页面重构后脚本大量失效，后来引入Page Object模式后维护成本降低了60%”，这种实战经验的描述会比任何理论都更有说服力。
5.3 性能测试题：思路比工具重要
性能测试的简答题通常会给一个场景，比如“上线前发现接口响应变慢，你如何定位和分析”。
答题框架我认为应该分四步。第一步，采集数据：通过慢日志、调用链、监控平台定位慢接口，确认是接口整体变慢还是某个操作变慢。第二步，分层排查：数据库层面看慢SQL、索引是否失效；缓存层面看Redis命中率；服务层面看CPU、内存、GC情况；外部依赖层面看第三方接口耗时。第三步，复现与验证：用压测工具（如JMeter、wrk、locust）模拟并发请求，确定瓶颈在哪个环节。第四步，优化验证：修改后重新压测，对比优化前后的响应时间、吞吐量、错误率。
这个答题思路在笔试卷上写出来，再结合你自己的真实案例，基本就是满分答案。如果没有真做过性能测试，可以写一个模拟的推演过程，但要符合逻辑。因为面试官后续大概率会追问细节，所以不要编造没做过的数据，诚实反而更让人信服。
6. 备考策略与实战心得
6.1 按优先级分配复习时间
如果你正在准备测开岗位的春招秋招，我给的建议是复习时间按“4:3:2:1”分配。四成时间刷编程题和写测试用例，三成时间过计算机网络、操作系统、数据库八股，两成时间做接口测试、自动化框架的项目积累，一成时间了解目标公司业务和行业特点。
这个比例不是随便拍的。编程题和测试设计题是笔试的主体，也是拉开差距的地方；八股是地基，决定你的下限；项目和业务了解是你在面试中展示差异化的关键。贝壳这种公司，你如果能在笔试题里写出“考虑经纪人状态、房源上下架状态”，那就比纯背八股的候选人高出一截。
刷编程题时，建议按专题刷：数组、字符串、哈希表、链表、栈与队列、二叉树、排序、二分、双指针、动态规划。每个专题刷10到15道经典题就够，不需要题海战术，但每道题必须做到能讲清楚思路、能分析时间空间复杂度、能说出边界条件。
6.2 笔试实战的答题节奏
120分钟的试卷，我的建议是：选择题控制在25到30分钟，编程题每道20到30分钟，测试设计题20分钟，简答题15到20分钟，最后留5到10分钟检查。
这个节奏的关键点在于：别在选择题上恋战。遇到不确定的题，先标记跳过，把后面的大题做完再回来看。因为选择题猜对概率还有25%，而大题空着就是零分。编程题如果第一道20分钟没AC，先写一个暴力解法保底，把用例能过多少算多少，再优化局部。这样至少有一部分分。
我见过太多人在第一道编程题上死磕40分钟，结果后面测试设计题没时间写，整个过程是非常亏的。记住，笔试不是“单题赛跑”，而是“总分游戏”。
6.3 复盘错题比刷新题重要
笔试结束后，无论结果如何都建议做复盘。把每道错题归类，问自己三个问题：是知识点没掌握，还是思路没想到，还是粗心看漏条件？知识点没掌握就要补，思路没想到就要总结套路（比如看到TopK就想到堆或快排），粗心就要提醒自己下次审题时把输入输出说明划出来。
我还建议把每道编程题写成博客或笔记，包括题目描述、思路分析、代码实现、测试用例、复杂度分析。写下来的过程比做十道题更有价值，因为你要组织语言，逼自己把模糊的理解变成清晰的表达。这个表达能力在面试环节同样重要。
7. 常见问题速查与避坑指南
7.1 高频问题排查表
把笔试中容易踩的坑整理成一张速查表，考前翻一遍非常管用：
| 问题类型 | 典型场景 | 避坑建议 |
|---|---|---|
| 输入处理 | 未处理空字符串/空列表 | 写代码前先判断输入是否为空 |
| 类型溢出 | 金额/数量用int导致溢出 | 大数场景用long或BigDecimal |
| 排序条件 | 只写了主排序忘了次排序 | 逐字读题，把排序条件写全 |
| SQL过滤 | 用WHERE过滤聚合结果 | 分组后的条件用HAVING |
| 接口断言 | 只断言状态码不断言数据 | 至少加字段级断言 |
| 用例设计 | 只写正常用例 | 强制自己写边界、异常、兼容性用例 |
这个表里的每一项，都是我实际批改简历和面试时看到的高频失误。考前对照着自查一遍，至少能避免40%的粗心扣分。
7.2 如何把“不会”变成“会”
笔试时遇到完全没思路的题怎么办？我的经验是：先把题目的输入输出示例读懂，尝试用最笨的方法写一个能跑的版本，再用测试用例去驱动优化。不管再难的问题，暴力解法总能拿一部分分。
如果简答题遇到没准备过的概念，不要留白。把自己的理解写出来，哪怕不完全准确，也能让阅卷人看到你的分析过程。比如问“如何设计一个高可用的测试环境”，你可以从环境隔离、数据准备、部署自动化、监控告警、回滚机制这几个方向去推理，不需要说出标准答案，但能体现你的系统性思考。
最重要的一点：笔试结束后，把不会的题目记下来，查资料搞懂。我当年面试时被追问过“你上次笔试最后一道题是怎么解决的”，这就是考察你的学习闭环能力。你能把不会的题吃透并讲出来，反而比全都会的人更有亮点。
7.3 岗位定位：测开不是“点点点”
最后想多说一句关于岗位认知。测试开发工程师对很多人来说是“门槛低、天花板低”的岗位，这个认知大错特错。好的测开工程师，既要会写代码、做自动化框架，又要懂业务、做质量策略，还要能推动流程改进。贝壳这种业务复杂度高的公司，测开的职责非常宽：房源数据质量保障、经纪人作业工具的自动化测试、核心交易链路接口测试、性能压测与调优、测试平台开发。
所以笔试卷里考算法、考数据库、考Linux、考设计用例，并不是要难为你，而是在选一个真正能干活、能扛事的人。你备考时如果把每个知识点都和“这个能力在测试工作中有什么用”联系起来，而不是死记硬背，那你就已经在用测开的思维思考问题了。
按这套思路去准备，我相信你拿到的不是一份试卷的答案，而是进入这个行业的底层能力。
