9月初我投完贝壳找房的测试开发工程师岗位系统几乎是当天就弹出了笔试邀请2024届秋招第一批笔试距离考试时间不到三天。说实话测开岗的笔试在秋招里一直是个有点尴尬的存在——你按纯算法岗去准备够不着只背测试理论又怕编程题直接翻车。但贝壳这场笔试给我的整体感受是它考的不是某一块特别深的东西而是你在有一定代码能力、懂测试方法、能解决实际质量问题这条线上是否足够全面。这篇文章我就把这次笔试的实际经历、题型结构、考点复盘和答题策略完整整理出来重点说说测试开发笔试到底考什么、怎么准备给接下来要踏上秋招战场的同学一个可参考的坐标。1. 秋招笔试前我是怎么定位测试开发这个岗位的1.1 为什么选测开而不是纯开发说实话我身边不少同学对测开岗有误区觉得后端卷不动了才去投测试。我选测开倒不是因为退缩而是我认真对比过自己的工作偏好纯业务开发更多沉浸在功能实现里而测试开发需要从整体质量视角去看一个产品从需求评审、用例设计、自动化脚本到上线后的监控预警参与的链路其实更长技术广度的要求也更高。测开在笔试环节就能感受到这种广度压力。一场笔试往往同时包含计算机基础选择题、算法编程题、测试理论题甚至还有结合业务场景的用例设计题。这和纯后端笔试那种算法定生死的风格完全不同更考验知识面的完整度。如果你代码能力中等偏上又愿意花时间和产品细节死磕测开其实是一个非常合适的岗位。1.2 我给自己列的复习知识清单确定方向后我结合牛客上能找到的往年笔经和贝壳的岗位JD给自己列了一张复习清单。核心逻辑是不追求每个方向都达到竞赛级深度但每个方向的核心考点都要能快速给出准确答案。数据结构与算法数组、链表、栈、队列、哈希表、二叉树、图排序与复杂度分析二分查找常见动态规划模型。按剑指offer和LeetCode Hot 100刷题。计算机网络TCP/UDP、三次握手、四次挥手、HTTP/HTTPS、DNS解析过程、Cookie和Session的区别。操作系统进程与线程、死锁的四个必要条件、内存分页分段、常用Linux命令。数据库SQL增删改查、索引原理与失效场景、事务四大特性、隔离级别与脏读幻读。测试理论基础测试流程、用例设计方法等价类、边界值、场景法、判定表、bug生命周期、接口测试、自动化测试框架原理。编程语言我用的Java所以重点复习了集合框架、字符串处理、异常机制这些是笔试编程题的常用工具。这份清单看起来科目很多但真正过一遍也就两周时间。我当时的策略是先做一次摸底把不会的知识点圈出来重点背已经掌握的随手过。后面几场笔试证明这种广覆盖、不深挖的准备方式和测开岗笔试的出题风格高度匹配。2. 贝壳2024届秋招测开笔试题型分布和我的第一感受2.1 考试平台与整体节奏贝壳这次笔试用的是牛客网笔试系统邮件里会写明考试时间段登录后进入在线答题页面。我参加的批次数是120分钟系统支持本地IDE调试编程题也可以直接在网页里写代码。这里提醒一下不同批次的时长和题型可能有差异一切以邮件通知为准但整体框架大概率是一致的。考试页面分三个区域左侧是题目列表中间是题干和选项右侧是代码编辑器。选择题和编程题混在一起你可以自由切换顺序作答。我个人不太建议按顺序死磕而是先把整张卷子扫一遍对题量和难度的分布心里有数再决定做题策略。2.2 题型结构一览我这场笔试的题型大致如下这里说大致是因为贝壳不同批次的题目会轮换但类型基本稳定。按照我的记忆和同批次同学在群里的反馈可以整理成这样一个表格题型数量分值占比估我的答题时间单选20题左右约35%30分钟多选5题左右约15%15分钟编程题2题约35%55分钟测试设计题1题约15%15分钟总计—100%约115分钟注意多选是少选得部分分、错选不得分这种规则所以拿不准的选项我宁可少选绝不乱选。编程题两道都是核心必拿分项测试设计题看起来分数占比不高但它是测开岗的特色菜答得好很容易在后续面试中被面试官追问所以绝对不能空着。这个分数配比其实透露了一个信号贝壳的测开笔试不是纯比拼算法而是考察基础能力代码能力测试思维的三角结构。后面我会把每一块的核心内容展开细讲。3. 选择题里高频出现的计算机基础考点3.1 计算机网络和操作系统老面孔但坑很多选择题中计算机网络和操作系统加起来大概能占到三分之一题目本身并不偏但有两个特点一是考得很细二是喜欢在看起来正确的干扰项上做文章。以TCP四次挥手为例题目不是问你挥手过程用了几个报文而是问TIME_WAIT状态存在的两个主要原因是什么。这个点要是只背了结论很容易选漏一个原因第一是保证最后一个ACK报文能够到达对端如果丢失可以重发第二是让旧连接中的所有报文在网络中自然消失避免影响新连接。这两个原因都得选上才算对。再比如HTTPS的握手过程很多人只记得对称加密非对称加密但题目会具体到客户端收到服务器证书后用的是什么密钥验证签名。答案是CA的公钥不是服务器公钥。这要求你对一次完整握手过程中每一步使用的密钥类型有清晰的认知而不是停留在概念层面。操作系统部分同样如此。进程和线程的私有资源是一个经典考点进程之间是相互独立的一个进程崩溃不会直接导致其他进程崩溃而线程共享进程的堆和方法区但每个线程有自己的虚拟机栈、程序计数器和本地方法栈。多选题经常把共享堆和共享栈混在一起用来试探你是否真的理解。死锁的必要条件也是高频多选互斥、占有并等待、不可剥夺、循环等待四个条件缺一不可。特别容易漏的是循环等待因为它其实是前三个条件的推论但因为够直观很多人反而会忽略它。3.2 数据库与Linux测开岗的差异化考点数据库在测开笔试里的地位比纯后端笔试更突出因为测试过程中你需要造数据、查数据、核对脏数据SQL是基本功。我印象里考了这样几个点联合索引在什么情况下会失效。最左前缀原则是必考的比如建了一个(a, b, c)联合索引查询条件直接写b和c那就走不了索引。还有在索引列上做函数运算、隐式类型转换也会导致索引失效。这类题背熟了就是送分但没系统总结过就是连环坑。事务隔离级别和脏读、不可重复读、幻读的对应关系也要能脱口而出读未提交可能发生所有三种问题读已提交解决了脏读可重复读解决了脏读和不可重复读但仍可能幻读在MySQL默认引擎InnoDB下通过间隙锁基本解决了幻读串行化全部解决。这里如果题目提到MySQL默认隔离级别答案不是解决了所有问题而是可重复读不要被惯性带偏。Linux命令考察得比较务实比如查看某个端口被哪个进程占用答案是netstat -tlnp | grep 端口号或者lsof -i:端口号比如统计日志文件中每个IP的出现次数答案是awk {print $1} access.log | sort | uniq -c | sort -nr。这些命令你平时用得越多越觉得简单但笔试是纸上谈兵建议在考前专门花半小时把高频命令敲一遍。3.3 数据结构与算法基础概念题也不白送数据结构的选择题通常会结合程序执行结果来考。比如给出一棵二叉树的前序遍历序列和中序遍历序列要求推断后序遍历序列。这类题没有捷径就是在草稿纸上老老实实把树还原出来。我当时的做法是先看前序确定根节点再在中序里找到根节点位置把左右子树切分出来递归进行画完树再写后序。还有一个让我印象深刻的题是哈夫曼编码给出一组字符和出现频率问编码后总长度是多少。这个题如果不熟悉哈夫曼树的构造过程很容易算错。正确做法是每次取频率最小的两个节点合并直到只剩一个根节点然后把所有叶子节点的频率×深度累加起来。我当时在草稿纸上完整的画了一遍哈夫曼树才敢填答案。哈希冲突的解决方式也考了一道多选开放定址法、再哈希法、链地址法很多人容易漏掉建立一个公共溢出区这个方案。这种题目没有难度纯粹考记忆完整性就看复习的时候有没有覆盖到位。所以如果你正在准备测开笔试选择题部分千万不要只看高频考点就完事那些边边角角的概念反而是拉开差距的地方。我的建议是把大学四门核心课计算机网络、操作系统、数据库、数据结构的期末复习提纲过一遍把每个概念都当成可能出多选题来背。4. 编程题复盘两道题从读题到AC的思路变化编程题是测开笔试里最容易让人焦虑的部分但贝壳这两道题整体难度控制得比较合理属于认真刷过题就能做出来的档次。我复盘一下自己的思路过程。4.1 第一题模拟类的送分题怎么做到不丢分第一题是典型的字符串模拟题。类似这样给定一个字符串统计连续相同字符的个数并按照字符出现次数的格式输出要求去掉出现次数小于3的连续片段。题目本身不复杂但题干里藏了不少边界条件空字符串、全部是非法字符、连续片段正好等于3个字符。我读题后第一时间确定用一次遍历解决维护当前字符和计数器遇到不同字符时判断计数器是否大于等于3再决定是否拼接到结果里。这个思路很直白时间复杂度O(n)空间复杂度O(1)。写代码的过程也顺利但我还是花了额外几分钟检查了字符串末尾的处理因为最后一个连续片段如果没有触发遇到不同字符的边界很容易被漏掉。这类模拟题拿满分的关键不是思路多惊艳而是把边界条件写全。我当时专门列了三个测试用例空字符串、长度为1的字符串、末尾刚好是连续片段结尾的字符串。自己写完用例再跑一遍确认无误后才提交。这也是我刷题阶段养成的习惯——笔试题目跑通用例比追求代码简洁更重要。4.2 第二题靠数据范围逼你优化的经典题第二题就明显有区分度了。题目大意是给定一个有序数组和一个目标值要求找出数组中两个数的下标使它们的和等于目标值并返回所有不重复的下标组合。乍一看很简单但看数据范围才发现数组长度可以达到10的5次方暴力双循环肯定超时。我的第一反应是用哈希表记录每个数最后出现的位置一边遍历一边查target - nums[i]是否存在。这是经典的O(n)解法代码量也很少。但题目要求返回所有不重复下标组合这就涉及到重复元素和去重的问题。我需要保证每个组合只输出一次避免类似(0, 3)和(3, 0)都输出。我当时处理的方式是先把数组排序然后用双指针从两端向中间移动。左指针指向当前最小值右指针指向当前最大值如果两数之和小于目标值左指针右移如果大于目标值右指针左移如果相等记录下标组合然后同时移动两个指针并跳过重复元素。排序后数组下标会变化所以还要用Map记录排序前每个元素原下标这一步稍微繁琐但逻辑上很清晰。这道题给我的教训是看到有序数组两数之和第一反应就应该是双指针而不是哈希表。哈希表虽然也能做但在处理所有不重复组合和输出原下标时代码写起来会复杂不少。考场时间紧张能用更简单的数据结构解决问题就尽量不要炫技。关于编程题还有两个特别实在的建议。第一掌握好输入输出的读写模板。Java用BufferedReader搭配StringTokenizerPython用sys.stdin.read再split这样既能保证速度又能避免输入解析的格式问题。第二如果一道题十分钟内没有完整思路果断先写暴力解。暴力解可能只过一半用例但那一半分数是实打实的总比卡死在最优解思路上最后交白卷强。5. 测试设计场景题贝壳业务背景下的用例设计5.1 一道房源搜索的测试用例设计题贝壳的笔试果然没有回避业务测试设计题给了一个非常贴近实际业务的场景在贝壳App的搜索框中输入关键词比如小区名、商圈名、地铁站名系统返回匹配的房源列表要求设计完整的测试用例。看到这个题的时候我第一反应不是高兴而是有点慌因为它不像选择题和编程题那么有边界。但冷静下来之后我决定用一套固定的维度框架来组织答案保证不遗漏。这套框架就是功能、异常、性能、安全、兼容性、易用性。功能测试方面我列了这些用例输入完整小区名验证返回的是该小区所有在售/在租房源排序是否符合预期。输入模糊关键词比如朝青这种商圈名验证返回结果包含该商圈下所有房源。输入不存在的关键词验证是否有友好的空结果提示以及是否有引导推荐。输入纯空格、特殊字符、超长字符串比如几百个字符验证输入框限制和系统处理。点击搜索历史记录验证是否能正确填充关键词并触发搜索。搜索结果列表的加载方式分页加载还是全部返回下划加载更多是否会出现重复数据。点击具体房源卡片跳转详情页后返回搜索条件和搜索结果是否被保留。异常测试方面我补充了断网状态下点击搜索是否有统一的错误提示不做无效请求。弱网比如3G网络环境下是否有加载中的状态展示超时后如何处理。搜索请求发出后服务器返回500或超时前端是否有重试机制。多个用户同时搜索同一热门小区系统是否能正常响应不崩溃。性能、安全和兼容性维度我用了通用思路搜索响应时间是否在可接受范围比如3秒内、搜索接口的QPS要求、SQL注入输入框拼接恶意SQL语句、XSS脚本注入、不同手机型号和操作系统的适配、不同屏幕分辨率的显示。但我在回答时特意加了一个业务相关的点房源数据的实时性。贝壳的房源信息变化很快一套房子可能今天在售明天就下架了所以搜索结果的缓存策略必须考虑数据一致性不能把已下架房源长时间展示给用户。5.2 测试设计题的答题框架这道题我在考后复盘时专门总结了一套答题框架。核心原则是不要想到一个写一个要有层次感。我推荐的答题顺序是先功能从正常到异常从输入到输出从列表到详情。再异常包括网络异常、服务端异常、数据异常。再性能包括响应时间、并发量、资源占用。再安全包括注入、越权、敏感信息泄露。再兼容性包括设备、系统、分辨率、浏览器如果是Web端。最后易用性包括交互提示、加载状态、空状态、容错引导。这套框架的好处是即使你对业务理解不深也能保证覆盖度。但想要拿高分必须加业务细节。比如搜索引擎还有个关键点搜索关键词的匹配范围是只匹配小区名还是也匹配房源描述、户型、朝向、附近地铁站这直接影响用例设计的完整性。另外很多同学在写用例时会忽略预期结果。我在笔试里每条用例都写了操作步骤、输入数据和预期结果。比如输入关键词回龙观点击搜索预期结果为展示回龙观区域所有在售房源列表按默认综合排序展示每条房源卡片展示价格、面积、户型、朝向等关键信息。这样写不仅让答案更完整也让阅卷人觉得你真的有测试思维。考后复盘时我还想明白一个问题贝壳为什么在测开笔试里放这么一道场景题因为测开这个岗位不是写一堆自动化脚本就完了你首先要能想到一个功能上线前有哪些环节可能出问题然后才知道该用什么样的手段去验证。测试设计题本质上考的就是这个问题嗅觉。6. 笔试中的时间分配和答题策略6.1 我的时间安排120分钟的笔试我给自己定的时间计划是选择题40分钟以内结束编程题55分钟测试设计题15分钟最后留10分钟检查。实际执行下来基本符合但我发现很多同学最容易犯的错是前紧后松——选择题做爽了一路磨叽等到了编程题只剩30分钟心态直接崩。我当时是先花5分钟扫了一遍全卷确认了编程题的大致难度第一题简单第二题中等偏上。心里有底之后我先做了选择题因为这时候头脑最清醒概念题不容易出错。做完选择题大概用了32分钟。然后立刻切到第一道编程题15分钟写完并跑了自测用例。第二道编程题花了35分钟主要是在双指针去重那一步多考虑了一会儿。最后15分钟写测试设计题用框架快速列了20多条用例。建议大家都按自己的节奏做一个类似的时间表并且提前想好哪部分可以压缩时间。对我来说选择题的计算机网络部分是最熟的所以我遇到不会的题先标记不做过多纠结整张卷子写完再回来思考。6.2 遇到不会的题怎么办这里单独说一下遇到不会的题这个每个人都会经历的场景。我这次笔试也遇到了一道多选题目问的是以下哪些HTTP状态码表示客户端错误选项里混了301永久重定向、400Bad Request、403Forbidden、500Internal Server Error。我心里很清楚500是服务端错误但对400和403这两个状态码的区别有点模棱两可最后只选了非常有把握的403放弃了400。考后查资料确认400也是客户端错误我虽然少拿了一半分但至少没因错选扣完。这是一个很重要的策略多选拿不准的选项不放进去宁少勿错。因为错选可能整题零分少选还能保留部分分数。这个规则在牛客笔试系统里通常会有说明大家一定要在开考前看清。编程题遇到不会的题更要懂得止损。我给自己定过一个原则二十分钟没有完整AC思路就写一个暴力解拿部分分然后立刻转去做其他题目。笔试考的是总分不是单题英雄主义。一道题你卡了一个小时最后还没AC损失的不仅是这道题的分数还有后面本该稳稳拿下的简单分。还有一点很实在调试信息一定要会处理。很多人编程题代码逻辑没问题但输出格式不对也会被判错。比如题目要求输出结果以空格分隔你却换行输出哪怕结果全部正确也是零分。提交前检查输入输出的格式这个习惯至少能帮你挽回5%的分数。7. 笔试结束后的复盘与后续衔接7.1 考后复盘我对照答案收集的考点清单笔试结束后我最重要的一件事不是等结果而是趁记忆还热乎立刻做了一份复盘。我把整场笔试的考点汇总成了一个清单逐个对照自己是否掌握TCP四次挥手TIME_WAIT的原因差一点选漏HTTPS证书校验流程回答正确线程私有资源回答正确联合索引失效条件回答正确哈夫曼编码总长度计算现场画树耗时较长双指针求解两数之和AC测试用例设计框架覆盖较全但业务细节不足这个清单的价值在于它让你清楚知道自己的弱点在哪里。我复盘后发现自己对HTTP状态码的边界记忆是模糊的于是专门花了一个晚上把所有状态码分类整理成表包括1xx信息响应、2xx成功、3xx重定向、4xx客户端错误、5xx服务端错误并标注了每个指令的实际场景。后来我在另一家公司的笔试里又遇到了类似题目很轻松就答对了。这就是复盘的复利效应。7.2 笔试与面试的衔接点贝壳的面试节奏比较紧凑笔试通过后大概一周内就会收到面试邀请。笔试中出现的测试设计题面试时往往会被继续深挖。比如面试官可能会问你在搜索功能的用例设计中你是如何考虑数据一致性的或者追问如果房源数据在搜索过程中被下架了你会选择什么自动化测试方案来覆盖这个问题所以我的建议是笔试结束后不要只盯着有没有过而是把笔试里那些你回答得不够好的题目当成面试的模拟题来准备。测开面试极少问特别偏的八股文更多是围绕你做过什么、怎么发现问题、怎么保证质量来展开。笔试里的编程题解法、测试用例设计思路都是很好的面试素材把它们整理成自己的项目总结比临阵磨枪背面经有效得多。另外如果你有志于贝壳这种带有明显业务属性的公司建议面试前也了解一下它的核心业务逻辑房产交易链条长、频次低、金额大这种情况下产品质量出问题的代价极高。所以测开岗位的价值在于通过自动化手段和测试策略尽可能早地发现风险而不是单纯执行功能测试。想明白这一点你在面试时回答问题的高度会完全不同。这场笔试之后我又陆续参加了其他几家公司的测开笔试每次都会用贝壳这场笔试的复盘思路去检查自己的盲区。说实话能在秋招前经历一场类型全面、难度适中的笔试比盲目刷十套模拟题都有用。如果你也准备投测开岗建议不要把精力全部耗在算法竞赛题上多花点时间把测试设计题和计算机基础补齐那才是拉开差距的关键。我个人还有个很实用的小习惯每场笔试后都把自己写过的测试用例模板存在一个文档里遇到类似的场景题直接套用上一次的框架再迭代优化越用越顺手。这个方法分享给大家希望秋招路上的你也能少踩几个坑。