1. 从贝壳这份卷子反推测试开发岗的筛选逻辑1.1 贝壳找房为什么值得拿来做复盘样本春招季节网上流传的笔试题五花八门但贝壳找房这套2023春招测试开发笔试卷1我觉得是很有参考价值的一套。原因不复杂贝壳的业务形态决定了它的技术栈和测试场景都相当有代表性。贝壳的核心业务是真房源、二手房交易、新房营销、租赁以及围绕房产交易的VR看房、估价、金融辅助等。这类业务对数据的准确性、接口的稳定性、权限控制的严谨性要求都极高。一套房源信息错了轻则用户投诉重则可能引发交易纠纷。所以贝壳的技术团队在质量保障上的投入一直很大对测试开发工程师的要求也就相应更高。网上搜“测试开发”相关热词会看到大量关于学习路线、面试八股文、项目实战的内容。这侧面说明一个事实这个岗位的笔试面试已经相当成熟和体系化不是随便刷两道题就能过的。而贝壳这套卷子恰恰是这种成熟体系的一个典型切片。我用这套卷子做深度复盘不光是带着大家过一遍“可能考了什么”更重要的是想通过卷子反推贝壳这类大厂在春招时到底想通过笔试筛选出什么样的人。搞清楚这个底层逻辑比背一百道题都管用。1.2 笔试卷1这种卷子通常长什么样虽然我没法拿到这份试卷的原始题目全文但结合贝壳往年的出题风格以及大厂测试开发笔试的通行套路这类卷子的结构其实是可以高度还原的。一般来说测试开发工程师的笔试卷会包含以下四个模块模块考查内容常见题型大致占比计算机基础数据结构、算法、计算机网络、操作系统选择题、编程题30%-40%测试理论测试用例设计、测试流程、缺陷管理简答题、场景题20%-30%数据库与LinuxSQL编写、索引优化、常用命令选择题、手写SQL10%-20%综合设计测试方案设计、自动化框架理解大题的形式出现10%-20%为什么这么分配因为测试开发这个岗位本质上是“懂开发的测试”和“懂测试的开发”的复合体。你要能看懂代码、能写自动化脚本这是开发能力的一面你也要能设计测试用例、能评估风险、能推动质量体系建设这是测试思维的一面。笔试就是要在一张卷子里同时试探这两面。我特别想强调的是很多人拿到这种卷子第一反应是“算法题好难”然后疯狂刷LeetCode。但实际上测试开发的笔试和纯后端开发的笔试有个显著区别它更看重你用测试思维去解问题的能力。同样一道编程题测试开发岗位的评分标准里往往包含了对边界条件的考虑是否周全、对异常输入的处理是否健壮这类维度。这一点很多人容易忽略。1.3 对照“测试开发学习路线”看考点覆盖现在的网络上“测试开发学习路线”的内容特别多有的让你从Python基础学起有的让你直接撸Selenium还有的推荐学JavaTestNG一套组合拳。我看过不少说实话质量参差不齐。反过来看贝壳这套试卷能给我们一个非常清晰的信号公司考察的不是你会不会某个具体工具而是你的基础功底和思维体系。很多学习路线把自动化测试工具放在很靠前的位置Jmeter、Postman、Selenium、Appium列了一堆。但笔试的时候这些工具顶多出现在选择题里考一两个概念比如“Selenium中等待的两种方式是什么”真正的大头永远是数据结构、算法、SQL、测试用例设计这些“硬功夫”。这也是为什么我建议准备春招的同学如果时间有限宁愿少学两个工具也要把数据结构和SQL的基础打牢。工具可以入职后再学基础不行简历那一关都过不了。2. 测试理论题不是背八股是把测试思维摊开给人看2.1 黑盒用例设计是必考大题关键在覆盖度在测试开发的笔试卷里黑盒测试用例设计几乎是必考的模块。贝壳这类业务型公司尤其爱考因为它们的业务功能逻辑复杂随便拉一个功能出来都能出成一道用例设计题。我结合贝壳业务场景给你演示一下这类题的完整答题思路。假设题目是“为一个房源搜索功能设计测试用例支持按区域、价格区间、户型、朝向筛选房源。”拿到这种题第一反应千万不要直接开写。先在草稿纸上把测试维度列出来然后逐层展开。功能维度区域筛选选择单个区域、多个区域、不选区域默认全部价格区间低价段、中间段、高价段、跨区间边界值户型筛选一居、两居、三居、全部户型朝向筛选南、北、东西、全部朝向组合筛选多个条件同时生效界面交互维度筛选条件是直接展示还是折叠展示选完条件后是立即刷新结果还是需要一个“确定”按钮结果列表是否显示已选条件的标签能否一键清除数据展示维度搜索结果的排序规则默认排序、价格排序、面积排序无结果时的空态页面提示结果数量过大时的分页加载是否正常异常与边界维度价格区间的最小值大于最大值如最低价500万、最高价100万价格区间填入极大数据如999999999网络请求超时或断网时的提示信息房源信息在浏览过程中被下架数据状态一致性这么写下来一套用例基本就覆盖了。阅卷人看的是你有没有这个分层思考的能力而不是你写了多少条。2.2 “如何测试一个登录接口”这类送命题的满分答法很多笔试和面试都会问给你一个登录接口你怎么测这题看着简单但恰恰是拉开差距的地方。初级答法输入正确的用户名密码能登录再试试错误的密码。稍微好一点的答法补充参数校验、密码加密、验证码等维度。真正能拿高分的答法是从接口测试的完整思维链出发第一层功能正确性正确的账号密码返回成功错误的密码返回明确的错误提示不存在的用户名返回什么体验上是否合理密码错误五次后锁定锁定时间是否合理第二层参数边界与异常用户名为空、密码为空、参数缺失用户名超长、密码超长特殊字符、SQL注入字符、XSS脚本注入请求方式错误比如应该POST却用GET第三层业务规则与状态流转同一个账号在不同设备同时登录是互踢还是允许登录成功后token的有效期、刷新逻辑登出后token是否立即失效重置密码后原token是否失效第四层并发与安全并发登录时是否有竞态问题接口是否有限流策略响应中是否不应该暴露敏感信息密码传输是否加密你看同样一道题答出四个层次和只答第一层差距天上地下。这套框架换到任何一个接口上都能用建议你在笔试前就用自己熟悉的系统把所有常见接口过一遍。2.3 兼容性和稳定性测试的答题视角贝壳这类公司有大量的移动端用户所以兼容性测试在笔试题里出现的频率也相当高。问法通常是“你怎么做兼容性测试”或者“手机上某功能在部分机型上崩溃怎么排查”兼容性测试千万不要一开始就报设备型号那是最低效的做法。成熟的思路是先分层先做用户画像分析通过埋点数据看看主流用户用什么系统版本、什么机型、什么分辨率。比如你的App用户里iOS占比70%那测试资源就应该向iOS倾斜而不是安卓iOS平均用力。再做核心链路优先把登录、房源浏览、搜索、下单这类高优链路提取出来在真机或云真机上做全量覆盖。非核心链路可以降级为模拟器覆盖。最后做数据兜底在测试阶段记录所有兼容性问题的复现路径、系统版本、机型、内存占用等关键信息形成兼容性测试报告为后续开发提供定位依据。关于稳定性测试一个重要考点是本地日志要提前打开崩溃时能抓到完整堆栈。很多测试同学遇到崩溃就直接截图丢给开发开发回一句“日志呢”然后两边开始扯皮。成熟的测试人员会主动抓取日志、分析堆栈、把问题定位到具体的方法级别再提Bug。笔试如果考到稳定性测试把这些动作写进去绝对比只写“用Monkey跑半小时”高一个段位。3. 代码题与算法题贝壳这类卷子的高频题型和解法思路3.1 字符串与哈希最容易被低估的考点如果你翻过各大厂的测试开发笔试回忆版会发现字符串和哈希的出场率高得惊人。为什么因为测试开发日常要写大量的断言、做大量的数据比对字符串处理和哈希结构是最趁手的工具。我举个例子一道典型的笔试算法题是这样给定一个字符串找出其中不含有重复字符的最长子串的长度。这道题在LeetCode上是中等难度但放在测试开发笔试卷里它一点都不超纲。因为它考察的是滑动窗口思想而滑动窗口在测试开发的实际工作中非常常用——比如做日志分析时要在一个时间窗口内统计某类异常出现的次数。核心解法用Python写出来是这样的def length_of_longest_substring(s: str) - int: char_map {} left 0 max_len 0 for right, ch in enumerate(s): if ch in char_map and char_map[ch] left: left char_map[ch] 1 char_map[ch] right max_len max(max_len, right - left 1) return max_len注意这里的关键点在于当遇到重复字符时left指针要跳到上一次出现位置的下一个位置同时要判断这个重复字符的上一次出现位置是否在当前窗口内。这个细节写不对代码跑用例就会出问题。笔试真正考你的不是“会不会背这个解法”而是遇到变体题能不能灵活应对。比如题目改成“返回最长无重复子串本身”而不是长度或者在字符串中允许最多两个重复字符你该怎么改这些都是在基础解法上的延伸平时练习时就要有意识地做这种变形训练。3.2 链表与数组的边界陷阱链表题是另一个高频考点而且字符串题最大的不同在于链表题对边界条件的考察极其严苛。测试开发这个岗位尤其看重这一点因为你日常写自动化脚本、做测试数据构造大量的Bug都出在索引越界、空指针、边界条件没覆盖这些地方。举一个经典题合并两个有序链表。class ListNode: def __init__(self, val0, nextNone): self.val val self.next next def merge_two_lists(l1: ListNode, l2: ListNode) - ListNode: dummy ListNode(0) cur dummy while l1 and l2: if l1.val l2.val: cur.next l1 l1 l1.next else: cur.next l2 l2 l2.next cur cur.next cur.next l1 if l1 else l2 return dummy.next这道题里用到了一个非常关键的技巧dummy哨兵节点。为什么要引入dummy因为合并后的头节点不确定是l1还是l2如果不加dummy就得单独处理头节点为空的情况代码会繁琐很多。笔试时如果你能写出用dummy节点的版本再解释一句“这样可以避免单独处理头节点为空的分支”这个细节就能让阅卷人对你的代码功底多一分认可。链表的边界条件总结起来就那几类链表为空的情况只有一个节点的情况头节点需要被删除或替换的情况两个链表长度不相等的情况把这四类情况在写代码前先在脑子里过一遍再动手敲出错概率会大幅下降。3.3 一道典型的“测试开发友好型”算法题怎么拆解还有一类算法题在测试开发笔试卷里非常典型就是“找重复元素”。这类题在业务测试中太常见了——比如验证一批导入的房源数据里有没有重复的房源编号。我们说一道经典的变体题给定一个整数数组和一个整数k判断数组中是否存在两个不同的索引i和j使得 nums[i] nums[j]并且 |i - j| k。这道题是LeetCode第219题但在测试开发的场景里它可以被包装成“如何检测短时间内重复提交的订单”。最直接的解法当然是暴力双重循环但时间复杂度是O(n²)在笔试中可以被接受但在实际工作中数据量一大就完蛋。优化解法是用哈希表记录每个值最近一次出现的索引def contains_nearby_duplicate(nums: list[int], k: int) - bool: last_seen {} for i, num in enumerate(nums): if num in last_seen and i - last_seen[num] k: return True last_seen[num] i return False这个解法的时间复杂度是O(n)空间复杂度也是O(n)。笔试如果只要求通过用例暴力解也能过但你要主动告诉阅卷人“我还能优化到O(n)”这就是区分度。4. 数据库与Linux容易被忽略的送分题和丢分题4.1 SQL题里的经典陷阱聚合、分组与NULL数据库题在测试开发笔试卷里通常不算难但丢分率却意外地高。原因很简单大家觉得“SQL嘛写了三年了还能不会”——然后一写就翻车。贝壳这种业务笔试很爱出跟业务贴合的表结构题。比如给一张房源表house和一张带看记录表visit让你统计每个区域的带看次数。题目大概是这个意思表结构house(id, title, district, price)visit(id, house_id, visit_time, visitor_phone)请统计每个区域的总带看次数小于10次的区域不展示按带看次数降序排列。正确写法SELECT h.district, COUNT(v.id) AS visit_cnt FROM house h LEFT JOIN visit v ON h.id v.house_id GROUP BY h.district HAVING COUNT(v.id) 10 ORDER BY visit_cnt DESC;这里有一个很大的坑为什么用LEFT JOIN而不是INNER JOIN因为INNER JOIN会漏掉那些没有被带看过的房源导致区域统计缺失。而LEFT JOIN能保证每个区域的房源都在结果集里即使它的带看次数是0。第二个坑是为什么HAVING里面用COUNT(v.id)而不是COUNT(*)?因为LEFT JOIN后没有带看记录的房源对应的v_id是NULLCOUNT(v.id)只统计非NULL值而COUNT(*)会把NULL也数进去。这个细节很多人不知道。这两个细节能看出一个人是真写过复杂的统计SQL还是只背过语法。4.2 Linux命令题怎么答才算完整Linux命令在笔试题里一般不会太难通常是查日志、查进程、查端口这三件套。但答题时要注意完整性不能只写命令本身要写清楚“这条命令在这种场景下为什么够用、如果不够用时下一步怎么查”。举个例子题目是“线上服务日志文件路径为/data/logs/app.log如何实时查看最新日志”标准回答tail -f /data/logs/app.log但如果你能补充这些就明显高出平均水平如果想要带行号tail -n 100 -f /data/logs/app.log如果要在日志中过滤关键词比如ERRORtail -f /data/logs/app.log | grep ERROR如果日志量极大、只想看最后500行并搜索关键字tail -n 500 /data/logs/app.log | grep --colorauto Exception如果服务挂了要看进程还在不在ps -ef | grep app或者pgrep -fa app如果要看端口占用netstat -tlnp | grep 8080或lsof -i:8080笔试如果考到这种题把场景化的延伸命令写上去比只写一条tail -f要稳得多。因为阅卷人能从你的答案里看出你处理过真实故障。4.3 笔试中的时间分配不纠结、不恋战关于数据库和Linux这部分想多说一句时间分配的问题。Shell和SQL题是整套试卷中性价比最高的部分知识点固定、题型固定、答案标准拿分相对容易。建议答题时按顺序做遇到这类题不要跳过先拿到确定性分数。而算法题如果卡了超过15分钟还没有思路果断跳过把后面的测试设计题和SQL题做完再回来补。笔试是一个全局最优问题不是单题最优问题。这个思路本质上就是一种测试思维你要管理的是整体的“用例覆盖率”而不是单个用例的“执行时间”。5. 测试设计与综合题完整测试方案怎么写得让阅卷人眼前一亮5.1 测试设计题的答题框架从需求到验收的闭环综合题是测试开发笔试卷中区分度最大的部分。它通常就是一个大场景题让你给出完整的测试方案。贝壳这类公司尤其喜欢出这种题因为它能看出一个人是不是只懂点工具操作。我总结了一套百试不爽的答题框架叫“五层递进法”需求层先复述你对需求的理解包括业务背景、用户角色、核心流程、预期效果。这一层的作用是让阅卷人知道你看懂了需求。功能层按照用户操作路径把功能点拆细像第2节讲的那样列出功能维度、异常维度、边界维度。注意要体现优先级P0级核心链路、P1级普通功能、P2级边缘场景。数据层列出关键数据字段和它们之间的业务约束关系。比如下单时库存扣减和价格计算的数据一致性支付成功后订单状态流转是否可靠。自动化层说明你如何把核心回归用例自动化选择什么工具链脚本如何组织断言如何设计持续集成如何接入。风险层列出你预估的风险点和对策比如第三方支付接口不稳定怎么办、大促流量激增时系统能否扛住、数据迁移时历史数据兼容性如何保障。如果这是道笔试题你只需要在每一层写3到5个要点就够了不求全求层次和逻辑。5.2 一个接口自动化测试方案的核心代码骨架综合题里有时候会让你写一个接口自动化的核心代码或者在代码题里让你实现一个小的测试工具。这个过程最能体现你是不是真的“会写代码”而不是只在简历上写了“熟悉Python”。我给出一个用Python requests实现接口测试的骨架你能看懂它笔试基本不会慌import requests import pytest BASE_URL https://api.example.com class TestHouseSearch: def setup_method(self): # 每个用例执行前准备测试数据 self.session requests.Session() self.session.headers.update({ Content-Type: application/json, Authorization: Bearer fake-token }) def test_search_with_valid_params(self): url f{BASE_URL}/v1/house/search payload { district: 西湖区, price_min: 100, price_max: 500, page: 1, page_size: 10 } resp self.session.post(url, jsonpayload) assert resp.status_code 200, f状态码异常: {resp.status_code} data resp.json() assert data[code] 0, f业务码异常: {data[code]} assert len(data[data][list]) 10, 返回条数超过分页大小 def test_search_with_price_min_greater_than_max(self): # 边界异常用例最小价格大于最大价格 url f{BASE_URL}/v1/house/search payload { district: 西湖区, price_min: 500, price_max: 100, page: 1, page_size: 10 } resp self.session.post(url, jsonpayload) # 期望接口返回参数错误而不是把结果全部查出 data resp.json() assert data[code] ! 0, 参数校验未生效 assert price in data.get(message, ).lower()这段代码里有两个细节值得注意一是setup_method的使用它是pytest框架的测试前置钩子每个用例执行前都会重新创建会话避免用例之间的数据污染。很多初学者喜欢在模块顶层创建一个全局session结果用例之间互相干扰一个用例改了headers另一个用例跟着变。二是断言的有效性。第一个用例里断言了返回条数不超过分页大小这是对业务规则的有效验证第二个用例断言了错误提示中包含price字段这说明你关注参数校验的精确性。有经验的测试人员写的断言一定是“对业务有意义”的断言而不是简单的resp.status_code 200。5.3 笔试中设计题答题时间分配的建议综合题的解答一定要控制住篇幅。笔试不是写论文阅卷人批改一份卷子的时间非常有限。如果一个设计题你写了三页纸核心重点反而会被淹没。我的建议是每个层次用3到5个要点概括全文控制在八百字以内。像写测试用例那样把最核心的P0场景写清楚P2场景列出名称就可以。另外答案中如果涉及技术选型一定简单一句说明“为什么选这个”这能体现你的判断力而不仅仅是知识面。6. 一路备考过来关于学习路线和踩坑复盘6.1 从八股文到项目实战我建议按这个节奏走现在搜索“测试开发学习路线”内容铺天盖地但没有一条路线是公认的标准答案。结合我对贝壳这类公司笔试题的复盘我建议你按这样的阶段推进阶段一计算机基础夯实两到三周数据结构数组、链表、栈、队列、哈希表、二叉树常见算法二分、双指针、滑动窗口、递归、DFS/BFS计算机基础进程线程区别、TCP三次握手、HTTP常见状态码这个阶段的目标不是刷难题而是把最核心的数据结构和算法题刷到闭眼能写的程度。阶段二测试理论体系一到两周黑盒用例设计方法等价类、边界值、因果图、场景法测试流程需求评审、测试计划、用例评审、执行、回归、上线评估缺陷管理Bug生命周期、严重级别定义、定位方法这个阶段建议配合真实例子去理解比如拿你最常用的App没事就拆解一个功能在脑子里过一遍完整的测试设计。阶段三自动化入门两到三周Python基础语法和常用库requests、json、pytest接口自动化测试从手动调用接口到用脚本断言UI自动化可选学Selenium先了解原理和定位知道坑在哪这个阶段的核心是“动手”。哪怕你只写了20个接口用例也比你刷十节视频课有用。阶段四项目复盘和简历包装一周把你大学或工作中做过的项目用测试的视角重新审视一遍补上你当时遗漏的测试设计部分思考“如果让我重新测一遍我会怎么做”把项目中的测试难点、数据构造方法、Bug定位过程写进简历6.2 我踩过的坑希望你避开我在准备测试开发笔试时踩过几个明显的坑在这里分享一下第一个坑死磕难题偏题。有一段时间我沉迷于LeetCode困难级别的题目觉得能做出来就有面子。结果笔试时发现出的题基本都是中低档难度那些偏题难题根本没机会上场。更尴尬的是因为花了太多时间在难题上基础题反而手生了。后来我调整策略把中低档题做透保证代码在边界条件下的正确性效果立竿见影。第二个坑忽视手写代码的规范性。笔试不是在IDE里写代码没有自动补全也没有即时编译器帮你查错。很多人在纸上或在线编辑器里写的代码缩进混乱、变量名随意、没有注释阅卷人一看就头疼。后来我每次练习都要求自己写出可以直接扔进IDE运行的完整代码而不是只写核心逻辑片段。第三个坑只在看中学不在做中学。看十篇接口测试教程不如自己找到一个开放API写一套完整的用例执行脚本并跑通。真正的能力是在动手过程中形成的看只能给你“我懂了”的错觉。6.3 用opencode这类工具做项目实战的尝试最近圈子里很多人讨论“用opencode开发一个项目从需求到设计到开发到测试”这种玩法。确实是一个很高效的实践方式。你可以让AI辅助你完成一些基础代码的生成然后你从测试视角去审查它生成的代码找出问题、补充测试用例、验证功能正确性。这个过程对测试开发思维的训练非常有帮助。我当时做的一个小练习是让AI帮你生成一个简易的待办事项管理后端API然后你设计出一套完整的接口测试用例并尝试找出它代码里的逻辑漏洞和边界问题。你会发现AI生成的代码虽然能跑通主流程但在异常输入处理、并发安全、接口提示信息合理性等方面往往存在不少盲区。找出这些问题并给出改进建议这本身就是测试开发的核心能力。如果你能在笔试的综合设计题里体现出这层思维比单纯回答“用什么工具”更能打动阅卷人。6.4 笔试前最后一周的冲刺清单最后把一个我在笔试前一周都会过的冲刺清单分享出来照着逐项自查[ ] 排序算法能手写冒泡、快排、归并并说出各自的时间复杂度[ ] 字符串匹配能写滑动窗口和双指针解法[ ] 链表操作能处理头节点边界情况[ ] SQL能写出带GROUP BY、HAVING、多表JOIN的统计查询[ ] 能说出至少三种HTTP状态码及其含义400、401、403、404、500、502、503等[ ] 能完整设计一个用户登录功能的测试用例[ ] 能完整设计一个查询接口的接口测试方案[ ] Linux常用命令能熟练写出查看进程、端口、日志每一次复盘这套清单我都能找到自己遗漏的点。准备笔试这种事没有捷径就是把基础功磨到不留死角。从我自己的备考经历来看测试开发笔试的核心并不复杂它考的是你用工程化思维解决质量问题的潜力。工具会过时框架会迭代但数据结构、SQL、测试设计思维这些东西是十年后依然管用的底子。把底子打牢无论贝壳还是别的公司都能从从容容地上场。
从贝壳春招测试开发笔试卷，反推大厂筛选逻辑与备考路线
1. 从贝壳这份卷子反推测试开发岗的筛选逻辑1.1 贝壳找房为什么值得拿来做复盘样本春招季节网上流传的笔试题五花八门但贝壳找房这套2023春招测试开发笔试卷1我觉得是很有参考价值的一套。原因不复杂贝壳的业务形态决定了它的技术栈和测试场景都相当有代表性。贝壳的核心业务是真房源、二手房交易、新房营销、租赁以及围绕房产交易的VR看房、估价、金融辅助等。这类业务对数据的准确性、接口的稳定性、权限控制的严谨性要求都极高。一套房源信息错了轻则用户投诉重则可能引发交易纠纷。所以贝壳的技术团队在质量保障上的投入一直很大对测试开发工程师的要求也就相应更高。网上搜“测试开发”相关热词会看到大量关于学习路线、面试八股文、项目实战的内容。这侧面说明一个事实这个岗位的笔试面试已经相当成熟和体系化不是随便刷两道题就能过的。而贝壳这套卷子恰恰是这种成熟体系的一个典型切片。我用这套卷子做深度复盘不光是带着大家过一遍“可能考了什么”更重要的是想通过卷子反推贝壳这类大厂在春招时到底想通过笔试筛选出什么样的人。搞清楚这个底层逻辑比背一百道题都管用。1.2 笔试卷1这种卷子通常长什么样虽然我没法拿到这份试卷的原始题目全文但结合贝壳往年的出题风格以及大厂测试开发笔试的通行套路这类卷子的结构其实是可以高度还原的。一般来说测试开发工程师的笔试卷会包含以下四个模块模块考查内容常见题型大致占比计算机基础数据结构、算法、计算机网络、操作系统选择题、编程题30%-40%测试理论测试用例设计、测试流程、缺陷管理简答题、场景题20%-30%数据库与LinuxSQL编写、索引优化、常用命令选择题、手写SQL10%-20%综合设计测试方案设计、自动化框架理解大题的形式出现10%-20%为什么这么分配因为测试开发这个岗位本质上是“懂开发的测试”和“懂测试的开发”的复合体。你要能看懂代码、能写自动化脚本这是开发能力的一面你也要能设计测试用例、能评估风险、能推动质量体系建设这是测试思维的一面。笔试就是要在一张卷子里同时试探这两面。我特别想强调的是很多人拿到这种卷子第一反应是“算法题好难”然后疯狂刷LeetCode。但实际上测试开发的笔试和纯后端开发的笔试有个显著区别它更看重你用测试思维去解问题的能力。同样一道编程题测试开发岗位的评分标准里往往包含了对边界条件的考虑是否周全、对异常输入的处理是否健壮这类维度。这一点很多人容易忽略。1.3 对照“测试开发学习路线”看考点覆盖现在的网络上“测试开发学习路线”的内容特别多有的让你从Python基础学起有的让你直接撸Selenium还有的推荐学JavaTestNG一套组合拳。我看过不少说实话质量参差不齐。反过来看贝壳这套试卷能给我们一个非常清晰的信号公司考察的不是你会不会某个具体工具而是你的基础功底和思维体系。很多学习路线把自动化测试工具放在很靠前的位置Jmeter、Postman、Selenium、Appium列了一堆。但笔试的时候这些工具顶多出现在选择题里考一两个概念比如“Selenium中等待的两种方式是什么”真正的大头永远是数据结构、算法、SQL、测试用例设计这些“硬功夫”。这也是为什么我建议准备春招的同学如果时间有限宁愿少学两个工具也要把数据结构和SQL的基础打牢。工具可以入职后再学基础不行简历那一关都过不了。2. 测试理论题不是背八股是把测试思维摊开给人看2.1 黑盒用例设计是必考大题关键在覆盖度在测试开发的笔试卷里黑盒测试用例设计几乎是必考的模块。贝壳这类业务型公司尤其爱考因为它们的业务功能逻辑复杂随便拉一个功能出来都能出成一道用例设计题。我结合贝壳业务场景给你演示一下这类题的完整答题思路。假设题目是“为一个房源搜索功能设计测试用例支持按区域、价格区间、户型、朝向筛选房源。”拿到这种题第一反应千万不要直接开写。先在草稿纸上把测试维度列出来然后逐层展开。功能维度区域筛选选择单个区域、多个区域、不选区域默认全部价格区间低价段、中间段、高价段、跨区间边界值户型筛选一居、两居、三居、全部户型朝向筛选南、北、东西、全部朝向组合筛选多个条件同时生效界面交互维度筛选条件是直接展示还是折叠展示选完条件后是立即刷新结果还是需要一个“确定”按钮结果列表是否显示已选条件的标签能否一键清除数据展示维度搜索结果的排序规则默认排序、价格排序、面积排序无结果时的空态页面提示结果数量过大时的分页加载是否正常异常与边界维度价格区间的最小值大于最大值如最低价500万、最高价100万价格区间填入极大数据如999999999网络请求超时或断网时的提示信息房源信息在浏览过程中被下架数据状态一致性这么写下来一套用例基本就覆盖了。阅卷人看的是你有没有这个分层思考的能力而不是你写了多少条。2.2 “如何测试一个登录接口”这类送命题的满分答法很多笔试和面试都会问给你一个登录接口你怎么测这题看着简单但恰恰是拉开差距的地方。初级答法输入正确的用户名密码能登录再试试错误的密码。稍微好一点的答法补充参数校验、密码加密、验证码等维度。真正能拿高分的答法是从接口测试的完整思维链出发第一层功能正确性正确的账号密码返回成功错误的密码返回明确的错误提示不存在的用户名返回什么体验上是否合理密码错误五次后锁定锁定时间是否合理第二层参数边界与异常用户名为空、密码为空、参数缺失用户名超长、密码超长特殊字符、SQL注入字符、XSS脚本注入请求方式错误比如应该POST却用GET第三层业务规则与状态流转同一个账号在不同设备同时登录是互踢还是允许登录成功后token的有效期、刷新逻辑登出后token是否立即失效重置密码后原token是否失效第四层并发与安全并发登录时是否有竞态问题接口是否有限流策略响应中是否不应该暴露敏感信息密码传输是否加密你看同样一道题答出四个层次和只答第一层差距天上地下。这套框架换到任何一个接口上都能用建议你在笔试前就用自己熟悉的系统把所有常见接口过一遍。2.3 兼容性和稳定性测试的答题视角贝壳这类公司有大量的移动端用户所以兼容性测试在笔试题里出现的频率也相当高。问法通常是“你怎么做兼容性测试”或者“手机上某功能在部分机型上崩溃怎么排查”兼容性测试千万不要一开始就报设备型号那是最低效的做法。成熟的思路是先分层先做用户画像分析通过埋点数据看看主流用户用什么系统版本、什么机型、什么分辨率。比如你的App用户里iOS占比70%那测试资源就应该向iOS倾斜而不是安卓iOS平均用力。再做核心链路优先把登录、房源浏览、搜索、下单这类高优链路提取出来在真机或云真机上做全量覆盖。非核心链路可以降级为模拟器覆盖。最后做数据兜底在测试阶段记录所有兼容性问题的复现路径、系统版本、机型、内存占用等关键信息形成兼容性测试报告为后续开发提供定位依据。关于稳定性测试一个重要考点是本地日志要提前打开崩溃时能抓到完整堆栈。很多测试同学遇到崩溃就直接截图丢给开发开发回一句“日志呢”然后两边开始扯皮。成熟的测试人员会主动抓取日志、分析堆栈、把问题定位到具体的方法级别再提Bug。笔试如果考到稳定性测试把这些动作写进去绝对比只写“用Monkey跑半小时”高一个段位。3. 代码题与算法题贝壳这类卷子的高频题型和解法思路3.1 字符串与哈希最容易被低估的考点如果你翻过各大厂的测试开发笔试回忆版会发现字符串和哈希的出场率高得惊人。为什么因为测试开发日常要写大量的断言、做大量的数据比对字符串处理和哈希结构是最趁手的工具。我举个例子一道典型的笔试算法题是这样给定一个字符串找出其中不含有重复字符的最长子串的长度。这道题在LeetCode上是中等难度但放在测试开发笔试卷里它一点都不超纲。因为它考察的是滑动窗口思想而滑动窗口在测试开发的实际工作中非常常用——比如做日志分析时要在一个时间窗口内统计某类异常出现的次数。核心解法用Python写出来是这样的def length_of_longest_substring(s: str) - int: char_map {} left 0 max_len 0 for right, ch in enumerate(s): if ch in char_map and char_map[ch] left: left char_map[ch] 1 char_map[ch] right max_len max(max_len, right - left 1) return max_len注意这里的关键点在于当遇到重复字符时left指针要跳到上一次出现位置的下一个位置同时要判断这个重复字符的上一次出现位置是否在当前窗口内。这个细节写不对代码跑用例就会出问题。笔试真正考你的不是“会不会背这个解法”而是遇到变体题能不能灵活应对。比如题目改成“返回最长无重复子串本身”而不是长度或者在字符串中允许最多两个重复字符你该怎么改这些都是在基础解法上的延伸平时练习时就要有意识地做这种变形训练。3.2 链表与数组的边界陷阱链表题是另一个高频考点而且字符串题最大的不同在于链表题对边界条件的考察极其严苛。测试开发这个岗位尤其看重这一点因为你日常写自动化脚本、做测试数据构造大量的Bug都出在索引越界、空指针、边界条件没覆盖这些地方。举一个经典题合并两个有序链表。class ListNode: def __init__(self, val0, nextNone): self.val val self.next next def merge_two_lists(l1: ListNode, l2: ListNode) - ListNode: dummy ListNode(0) cur dummy while l1 and l2: if l1.val l2.val: cur.next l1 l1 l1.next else: cur.next l2 l2 l2.next cur cur.next cur.next l1 if l1 else l2 return dummy.next这道题里用到了一个非常关键的技巧dummy哨兵节点。为什么要引入dummy因为合并后的头节点不确定是l1还是l2如果不加dummy就得单独处理头节点为空的情况代码会繁琐很多。笔试时如果你能写出用dummy节点的版本再解释一句“这样可以避免单独处理头节点为空的分支”这个细节就能让阅卷人对你的代码功底多一分认可。链表的边界条件总结起来就那几类链表为空的情况只有一个节点的情况头节点需要被删除或替换的情况两个链表长度不相等的情况把这四类情况在写代码前先在脑子里过一遍再动手敲出错概率会大幅下降。3.3 一道典型的“测试开发友好型”算法题怎么拆解还有一类算法题在测试开发笔试卷里非常典型就是“找重复元素”。这类题在业务测试中太常见了——比如验证一批导入的房源数据里有没有重复的房源编号。我们说一道经典的变体题给定一个整数数组和一个整数k判断数组中是否存在两个不同的索引i和j使得 nums[i] nums[j]并且 |i - j| k。这道题是LeetCode第219题但在测试开发的场景里它可以被包装成“如何检测短时间内重复提交的订单”。最直接的解法当然是暴力双重循环但时间复杂度是O(n²)在笔试中可以被接受但在实际工作中数据量一大就完蛋。优化解法是用哈希表记录每个值最近一次出现的索引def contains_nearby_duplicate(nums: list[int], k: int) - bool: last_seen {} for i, num in enumerate(nums): if num in last_seen and i - last_seen[num] k: return True last_seen[num] i return False这个解法的时间复杂度是O(n)空间复杂度也是O(n)。笔试如果只要求通过用例暴力解也能过但你要主动告诉阅卷人“我还能优化到O(n)”这就是区分度。4. 数据库与Linux容易被忽略的送分题和丢分题4.1 SQL题里的经典陷阱聚合、分组与NULL数据库题在测试开发笔试卷里通常不算难但丢分率却意外地高。原因很简单大家觉得“SQL嘛写了三年了还能不会”——然后一写就翻车。贝壳这种业务笔试很爱出跟业务贴合的表结构题。比如给一张房源表house和一张带看记录表visit让你统计每个区域的带看次数。题目大概是这个意思表结构house(id, title, district, price)visit(id, house_id, visit_time, visitor_phone)请统计每个区域的总带看次数小于10次的区域不展示按带看次数降序排列。正确写法SELECT h.district, COUNT(v.id) AS visit_cnt FROM house h LEFT JOIN visit v ON h.id v.house_id GROUP BY h.district HAVING COUNT(v.id) 10 ORDER BY visit_cnt DESC;这里有一个很大的坑为什么用LEFT JOIN而不是INNER JOIN因为INNER JOIN会漏掉那些没有被带看过的房源导致区域统计缺失。而LEFT JOIN能保证每个区域的房源都在结果集里即使它的带看次数是0。第二个坑是为什么HAVING里面用COUNT(v.id)而不是COUNT(*)?因为LEFT JOIN后没有带看记录的房源对应的v_id是NULLCOUNT(v.id)只统计非NULL值而COUNT(*)会把NULL也数进去。这个细节很多人不知道。这两个细节能看出一个人是真写过复杂的统计SQL还是只背过语法。4.2 Linux命令题怎么答才算完整Linux命令在笔试题里一般不会太难通常是查日志、查进程、查端口这三件套。但答题时要注意完整性不能只写命令本身要写清楚“这条命令在这种场景下为什么够用、如果不够用时下一步怎么查”。举个例子题目是“线上服务日志文件路径为/data/logs/app.log如何实时查看最新日志”标准回答tail -f /data/logs/app.log但如果你能补充这些就明显高出平均水平如果想要带行号tail -n 100 -f /data/logs/app.log如果要在日志中过滤关键词比如ERRORtail -f /data/logs/app.log | grep ERROR如果日志量极大、只想看最后500行并搜索关键字tail -n 500 /data/logs/app.log | grep --colorauto Exception如果服务挂了要看进程还在不在ps -ef | grep app或者pgrep -fa app如果要看端口占用netstat -tlnp | grep 8080或lsof -i:8080笔试如果考到这种题把场景化的延伸命令写上去比只写一条tail -f要稳得多。因为阅卷人能从你的答案里看出你处理过真实故障。4.3 笔试中的时间分配不纠结、不恋战关于数据库和Linux这部分想多说一句时间分配的问题。Shell和SQL题是整套试卷中性价比最高的部分知识点固定、题型固定、答案标准拿分相对容易。建议答题时按顺序做遇到这类题不要跳过先拿到确定性分数。而算法题如果卡了超过15分钟还没有思路果断跳过把后面的测试设计题和SQL题做完再回来补。笔试是一个全局最优问题不是单题最优问题。这个思路本质上就是一种测试思维你要管理的是整体的“用例覆盖率”而不是单个用例的“执行时间”。5. 测试设计与综合题完整测试方案怎么写得让阅卷人眼前一亮5.1 测试设计题的答题框架从需求到验收的闭环综合题是测试开发笔试卷中区分度最大的部分。它通常就是一个大场景题让你给出完整的测试方案。贝壳这类公司尤其喜欢出这种题因为它能看出一个人是不是只懂点工具操作。我总结了一套百试不爽的答题框架叫“五层递进法”需求层先复述你对需求的理解包括业务背景、用户角色、核心流程、预期效果。这一层的作用是让阅卷人知道你看懂了需求。功能层按照用户操作路径把功能点拆细像第2节讲的那样列出功能维度、异常维度、边界维度。注意要体现优先级P0级核心链路、P1级普通功能、P2级边缘场景。数据层列出关键数据字段和它们之间的业务约束关系。比如下单时库存扣减和价格计算的数据一致性支付成功后订单状态流转是否可靠。自动化层说明你如何把核心回归用例自动化选择什么工具链脚本如何组织断言如何设计持续集成如何接入。风险层列出你预估的风险点和对策比如第三方支付接口不稳定怎么办、大促流量激增时系统能否扛住、数据迁移时历史数据兼容性如何保障。如果这是道笔试题你只需要在每一层写3到5个要点就够了不求全求层次和逻辑。5.2 一个接口自动化测试方案的核心代码骨架综合题里有时候会让你写一个接口自动化的核心代码或者在代码题里让你实现一个小的测试工具。这个过程最能体现你是不是真的“会写代码”而不是只在简历上写了“熟悉Python”。我给出一个用Python requests实现接口测试的骨架你能看懂它笔试基本不会慌import requests import pytest BASE_URL https://api.example.com class TestHouseSearch: def setup_method(self): # 每个用例执行前准备测试数据 self.session requests.Session() self.session.headers.update({ Content-Type: application/json, Authorization: Bearer fake-token }) def test_search_with_valid_params(self): url f{BASE_URL}/v1/house/search payload { district: 西湖区, price_min: 100, price_max: 500, page: 1, page_size: 10 } resp self.session.post(url, jsonpayload) assert resp.status_code 200, f状态码异常: {resp.status_code} data resp.json() assert data[code] 0, f业务码异常: {data[code]} assert len(data[data][list]) 10, 返回条数超过分页大小 def test_search_with_price_min_greater_than_max(self): # 边界异常用例最小价格大于最大价格 url f{BASE_URL}/v1/house/search payload { district: 西湖区, price_min: 500, price_max: 100, page: 1, page_size: 10 } resp self.session.post(url, jsonpayload) # 期望接口返回参数错误而不是把结果全部查出 data resp.json() assert data[code] ! 0, 参数校验未生效 assert price in data.get(message, ).lower()这段代码里有两个细节值得注意一是setup_method的使用它是pytest框架的测试前置钩子每个用例执行前都会重新创建会话避免用例之间的数据污染。很多初学者喜欢在模块顶层创建一个全局session结果用例之间互相干扰一个用例改了headers另一个用例跟着变。二是断言的有效性。第一个用例里断言了返回条数不超过分页大小这是对业务规则的有效验证第二个用例断言了错误提示中包含price字段这说明你关注参数校验的精确性。有经验的测试人员写的断言一定是“对业务有意义”的断言而不是简单的resp.status_code 200。5.3 笔试中设计题答题时间分配的建议综合题的解答一定要控制住篇幅。笔试不是写论文阅卷人批改一份卷子的时间非常有限。如果一个设计题你写了三页纸核心重点反而会被淹没。我的建议是每个层次用3到5个要点概括全文控制在八百字以内。像写测试用例那样把最核心的P0场景写清楚P2场景列出名称就可以。另外答案中如果涉及技术选型一定简单一句说明“为什么选这个”这能体现你的判断力而不仅仅是知识面。6. 一路备考过来关于学习路线和踩坑复盘6.1 从八股文到项目实战我建议按这个节奏走现在搜索“测试开发学习路线”内容铺天盖地但没有一条路线是公认的标准答案。结合我对贝壳这类公司笔试题的复盘我建议你按这样的阶段推进阶段一计算机基础夯实两到三周数据结构数组、链表、栈、队列、哈希表、二叉树常见算法二分、双指针、滑动窗口、递归、DFS/BFS计算机基础进程线程区别、TCP三次握手、HTTP常见状态码这个阶段的目标不是刷难题而是把最核心的数据结构和算法题刷到闭眼能写的程度。阶段二测试理论体系一到两周黑盒用例设计方法等价类、边界值、因果图、场景法测试流程需求评审、测试计划、用例评审、执行、回归、上线评估缺陷管理Bug生命周期、严重级别定义、定位方法这个阶段建议配合真实例子去理解比如拿你最常用的App没事就拆解一个功能在脑子里过一遍完整的测试设计。阶段三自动化入门两到三周Python基础语法和常用库requests、json、pytest接口自动化测试从手动调用接口到用脚本断言UI自动化可选学Selenium先了解原理和定位知道坑在哪这个阶段的核心是“动手”。哪怕你只写了20个接口用例也比你刷十节视频课有用。阶段四项目复盘和简历包装一周把你大学或工作中做过的项目用测试的视角重新审视一遍补上你当时遗漏的测试设计部分思考“如果让我重新测一遍我会怎么做”把项目中的测试难点、数据构造方法、Bug定位过程写进简历6.2 我踩过的坑希望你避开我在准备测试开发笔试时踩过几个明显的坑在这里分享一下第一个坑死磕难题偏题。有一段时间我沉迷于LeetCode困难级别的题目觉得能做出来就有面子。结果笔试时发现出的题基本都是中低档难度那些偏题难题根本没机会上场。更尴尬的是因为花了太多时间在难题上基础题反而手生了。后来我调整策略把中低档题做透保证代码在边界条件下的正确性效果立竿见影。第二个坑忽视手写代码的规范性。笔试不是在IDE里写代码没有自动补全也没有即时编译器帮你查错。很多人在纸上或在线编辑器里写的代码缩进混乱、变量名随意、没有注释阅卷人一看就头疼。后来我每次练习都要求自己写出可以直接扔进IDE运行的完整代码而不是只写核心逻辑片段。第三个坑只在看中学不在做中学。看十篇接口测试教程不如自己找到一个开放API写一套完整的用例执行脚本并跑通。真正的能力是在动手过程中形成的看只能给你“我懂了”的错觉。6.3 用opencode这类工具做项目实战的尝试最近圈子里很多人讨论“用opencode开发一个项目从需求到设计到开发到测试”这种玩法。确实是一个很高效的实践方式。你可以让AI辅助你完成一些基础代码的生成然后你从测试视角去审查它生成的代码找出问题、补充测试用例、验证功能正确性。这个过程对测试开发思维的训练非常有帮助。我当时做的一个小练习是让AI帮你生成一个简易的待办事项管理后端API然后你设计出一套完整的接口测试用例并尝试找出它代码里的逻辑漏洞和边界问题。你会发现AI生成的代码虽然能跑通主流程但在异常输入处理、并发安全、接口提示信息合理性等方面往往存在不少盲区。找出这些问题并给出改进建议这本身就是测试开发的核心能力。如果你能在笔试的综合设计题里体现出这层思维比单纯回答“用什么工具”更能打动阅卷人。6.4 笔试前最后一周的冲刺清单最后把一个我在笔试前一周都会过的冲刺清单分享出来照着逐项自查[ ] 排序算法能手写冒泡、快排、归并并说出各自的时间复杂度[ ] 字符串匹配能写滑动窗口和双指针解法[ ] 链表操作能处理头节点边界情况[ ] SQL能写出带GROUP BY、HAVING、多表JOIN的统计查询[ ] 能说出至少三种HTTP状态码及其含义400、401、403、404、500、502、503等[ ] 能完整设计一个用户登录功能的测试用例[ ] 能完整设计一个查询接口的接口测试方案[ ] Linux常用命令能熟练写出查看进程、端口、日志每一次复盘这套清单我都能找到自己遗漏的点。准备笔试这种事没有捷径就是把基础功磨到不留死角。从我自己的备考经历来看测试开发笔试的核心并不复杂它考的是你用工程化思维解决质量问题的潜力。工具会过时框架会迭代但数据结构、SQL、测试设计思维这些东西是十年后依然管用的底子。把底子打牢无论贝壳还是别的公司都能从从容容地上场。