“测试开发”这四个字在校招简历上出现频率越来越高但真正明白这个岗位在笔试阶段考察什么的人其实不多。我先说个真实感受很多人以为测试开发就是“比开发简单一点的岗位”结果一看笔试题就傻眼——算法题照样出代码题占比不低还夹杂着大量需要结合业务场景来答的测试设计题。滴滴出行2018校园招聘网申笔试-测试开发工程师第一批就是这类笔试里很有代表性的一个。把这份笔试卷拆明白基本等于把互联网公司校招测试开发岗的备考逻辑过了一遍。这篇内容适合谁两类人。一类是正在准备校招测试开发岗位的同学尤其是瞄准滴滴、美团、字节这类业务复杂度高的互联网公司另一类是已经在做功能测试、想转岗测试开发想系统补笔试基础的从业者。我会从题型逻辑、算法题应对、测试用例设计、计算机网络与数据库考点、模拟实战、考前冲刺六个维度展开全部是能直接落地的经验。1. 校招测试开发笔试到底在考什么先看题型的底层逻辑1.1 测试开发不是“点点点”笔试要求的能力画像我见过太多简历上写着“熟悉软件测试流程”的同学一到笔试就暴露了真实水平。测试开发这个岗位本质上是“会用代码做测试的人”不是“会点页面的人”。所以笔试的题型设计几乎都围绕着一个核心原则考察你在代码能力和测试思维之间的交叉地带能够处理多深的问题。具体拆开来看能力画像大致分五块编程基础语言语法、数据结构、算法、测试理论用例设计方法、缺陷生命周期、测试流程、计算机基础网络、数据库、操作系统、Linux、业务理解能力能不能把一个实际产品功能拆成可验证的测试点、逻辑表达思路是否清晰能不能用文字让别人看懂你的方案。这五块在校招笔试里的比重不同公司差异很大但滴滴这种体量的公司算法题和测试设计题基本是五五开剩下的零散考点分布在网络、数据库和Linux上。所以只刷LeetCode不够只背测试理论也不够两边都得硬。1.2 从滴滴的业务场景反推笔试重点我每次准备面试前都会先看公司的业务形态因为笔试题目一定会往业务上靠。滴滴的核心业务是什么出行。出行牵扯到哪些链路定位、地图、路线规划、订单分配、费用计算、支付、评价加上司乘两端App、小程序、Web管理后台随便拎出来一个环节都是复杂的测试场景。这就决定了它的笔试不会只考“登录怎么测”这种通用题目而是会偏重几个方向状态机流转订单状态从“待接单”到“已支付”的每一步变化、金额计算与并发费用预估、优惠券叠加、并发下单、LBS与地图相关逻辑定位偏差、路线规划结果校验、异常场景乘客取消、司机断网、支付超时。这跟纯电商公司考“购物车和库存”是完全不同的出题风格。所以你在准备滴滴这类测试开发笔试的时候要刻意训练一个能力拿到任何题目先想“这个功能在真实业务里会怎么跑一遍完整流程”再从流程里找测试点。这个思维习惯比多背二十个测试理论名词管用得多。2. 算法与编程题笔试的重头戏如何高效拿分2.1 常考的算法题类型与难度定位先给个定心丸校招测试开发岗的算法题普遍比开发岗难度低半档到一档大概在LeetCode中等题以下的水平。但“低一档”不代表你可以裸考经典题型必须熟练掌握。滴滴这类公司常考的算法题型我按出现频率排个序字符串与数组的处理找第一个不重复字符、字符串反转、数组去重、合并两个有序数组、旋转数组找目标值。这些题不考奇技淫巧考的是你把基础API用对、把循环边界写清楚的能力。哈希表与计数问题两数之和、判断字符异位词、数组中出现次数超过一半的数字。哈希表的空间换时间思路在测试开发笔试里是高频考察点。链表操作反转链表、找链表中间节点、判断链表是否有环、两个链表是否相交。链表题考验的是指针操作的严谨性跟测试里的“边界条件”思维天然契合。排序与查找的变体手写快排/归并、二分查找找左右边界、TopK问题。简单动态规划爬楼梯、最大子序和、零钱兑换最基础的一档。动态规划在校招测试开发笔试里不会考太深但“状态转移方程”这种思路会间接融入测试路径设计题。二叉树的遍历前中后序、层序、最大深度。树的基础操作偶尔会出现。难度定位上笔试前把LeetCode的“Top 100 高频题”里前50道刷透再把这六类题型各挑两三道练熟应试基本够用。不需要去啃难题压轴题性价比不高。2.2 代码题作答的几个实操技巧代码题不是“写出了就是满分”线上笔试环境有很多隐性扣分点我踩过、也见过别人踩给你提个醒。第一输入输出必须提前熟悉。很多同学平时在IDE里写惯了函数一上笔试系统要求自己处理标准输入输出就慌了。牛客网和赛码网是两个最常见的校招笔试平台题目给的输入可能是多组测试用例、可能一行多个整数、可能字符串里有空格。我的习惯是每次笔试前先把这两个平台的输入输出模板背下来用Python的话就是sys.stdin.read()配合split用C就是cin 和getline的边界处理。省得考场上花十分钟试错。第二边界条件比算法本身更值分。判题系统判的是“对不对”不是“优不优”。一个干净利落的快排方案如果没处理空数组和单元素数组照样挂一个看起来很笨的暴力解法只要把所有边界都考虑到了能拿的分一分不少。我的建议是代码写完别急着交自己在注释里列出三个边界用例——空输入、单元素、极端大数逐个在心里跑一遍。第三不会AC也要写注释和关键步骤。校招笔试的判卷虽然以线上自动判题为主但有些公司的系统会允许人工审阅代码尤其是主观题部分。哪怕你的代码有问题也要用注释把“思路”写出来。比如“这里用双指针是因为数组已排序目标是将时间复杂度降到O(n)”。让阅卷人看到你有分析能力这比交一个空白编辑器强太多。注意笔试时如果发现某道题卡了二十分钟果断跳过。算法题分值通常不是均匀分布的后面可能还有一道你秒会的字符串题。先拿稳定分再回来啃硬骨头。3. 测试用例设计题面试官想看的不是“多”而是“全”3.1 等价类与边界值两道题吃透基础方法测试用例设计题在校招笔试里几乎必出而且经常以“请设计XX功能的测试用例”这种开放式问题出现。很多人遇到这类题就疯狂罗列“输入什么、输出什么”写了几十条但分数依然不高。原因很简单用例设计考的不是数量是方法论。我最推荐先把两个基础方法掌握到条件反射级别等价类划分和边界值分析。这两个方法不是面试官随口说的理论名词而是实战中最高频、最实用的用例设计工具。拿一个最简单的例子说清楚比如“登录页面的用户名输入框要求6~20位字符”用等价类划分先把输入域分成有效等价类和无效等价类。有效等价类就是6到20位的合法用户名无效等价类有三类少于6位、多于20位、包含非法字符比如中文、空格、特殊符号。你只需要在每一类里选一个代表值来测不用每个字符长度都测一遍。然后上边界值分析既然边界是6和20那就要测5、6、7、19、20、21这六个值。为什么6和20要测两遍因为边界值里“刚好等于边界”和“刚好越过边界”是两个不同场景一个应该通过一个应该被拦截。这个思路把一条用例设计的颗粒度瞬间拉高阅卷人一眼就能看出你真的干过测试。3.2 场景法把业务链路变成测试用例等价类和边界值解决的是“单个输入框怎么测”但真实业务往往是多个模块串在一起的这时候就要用场景法。场景法的核心是把用户从开始到结束的完整操作路径拆成一个个步骤再针对每个步骤设计正常流和异常流的用例。以滴滴为例“用户从发单到上车”的主流程大概是打开App → 定位 → 输入目的地 → 确认呼叫 → 司机接单 → 司机到达上车点 → 乘客上车 → 行程开始 → 到达目的地 → 支付。这就是一条主场景。主场景跑通了再逐一拆分支场景乘客中途修改目的地、司机取消订单、乘客取消订单、司机找不到乘客、行程中网络中断、支付时余额不足。这种思维在笔试里答题时特别有用因为你能把一个模糊的“请测试叫车功能”变成清晰的流程拆解。我当时准备时的一个技巧是画不出流程图没关系只要在答题里按“步骤-操作-预期结果”的格式写成表格面试官就会认为你有场景思维。关键是让每一步都形成“操作了什么系统应该怎么反应”的闭环。3.3 一个完整的用例设计答卷模板笔试时间有限用例设计题不需要完整地写几十条用例但你必须让阅卷人看到你的结构。我建议按下面这个模板答题既省时间又容易拿分用例编号规则TC_功能模块_序号比如TC_Login_001。这个细节非常加分证明你有团队协作意识知道用例是要进用例库的。前置条件一条用例的执行前提。举个例“用户已注册账号且网络正常。”没有前置条件的用例别人没法复现。测试步骤用1、2、3列出操作动作动词开头。比如“1.打开App登录页2.输入已注册手机号3.输入正确密码4.点击登录按钮。”预期结果具体到可验证的观察点。不要写“登录成功”这种笼统的话要写“页面跳转到首页右上角显示用户头像和手机号数据库用户表记录本次登录时间。”预期结果越可验证说明你的测试功底越扎实。优先级标明P0/P1/P2P0是核心流程不通过就不能上线。这个维度展示的是你的风险判断能力。用这个模板组织答案哪怕你只写了8条用例也比别人罗列30条没结构、没优先级的用例得分高。4. 计算机网络与数据库看似简单却最容易被扣分的部分4.1 网络协议的必背知识点计算机网络在测试开发笔试里占的比重不算大但几乎每次都会出现一两道而且一旦考到就是送分题不去拿就显得可惜。最常考的知识点我梳理成一个清单TCP三次握手和四次挥手能画出状态图能说清为什么要三次、不能两次。四次挥手里TIME_WAIT的意义和时长2MSL也常考。HTTP状态码2xx200、201、204、3xx301、302、304、4xx400、401、403、404、429、5xx500、502、503、504。不要只背数字每个状态码要能对应一个测试场景。比如弱网环境下请求超时前端看到的是504还是自己定义的超时提示这就是一个测试点。GET和POST的区别从语义上、请求参数位置、幂等性、缓存机制几个角度对比。这个知识点几乎年年考别只答“GET有长度限制”这种模糊表述。HTTPS的握手过程对称加密和非对称加密是怎么配合的、证书的作用是什么。DNS解析过程从输入URL到拿到IP地址期间发生了什么。这个考的是完整链路思维跟测试里的全链路分析很像。这些知识点不用背到八股文的程度但要做到“看到术语能讲清楚它解决什么问题”。比如TCP握手是为了让双方确认收发能力都正常这个“为什么”理解了比死记状态名有用得多。4.2 数据库查询与数据校验数据库的考点分为两类一类是写SQL一类是测试数据校验意识。SQL题通常是给两张表让你写出查询结果。常考的就是GROUP BY 聚合函数、JOININNER、LEFT、子查询、DISTINCT去重、ORDER BY排序、LIMIT分页。没有特别偏的题只要你能熟练写“查询每个部门的平均工资按平均工资降序排序”这种程度就够。数据校验意识是测试开发笔试的隐藏考点。很多功能测试的同学容易忽略这点但笔试和面试官很看重。举例测试一个“叫车后发送短信通知”的功能除了验证用户手机上有没有收到短信内容还要验证数据库里有没有写入一条短信发送记录发送状态是成功还是失败失败后的重试机制是什么。这就是“数据落库校验”的思路体现的是你从黑盒看到了白盒。我的经验是SQL语法不会就练但“测完功能要查库”的意识没建立的话笔试里很难临时补上。从现在起你每测一个功能就把“数据库哪里会变化”这个问题问一遍时间长了就内化了。5. 真题风格的实战演练模拟一套“第一批”笔试卷5.1 模拟题1找出字符串中第一个不重复字符题目描述给定一个只包含小写字母的字符串找出其中第一个不重复的字符并返回它的下标。如果不存在返回-1。例如sddtravel第一个不重复字符是t返回下标5。这道题是哈希表计数类的典型代表。思路是遍历两次第一次统计每个字符出现的次数第二次找第一个出现次数为1的字符。这里“第一个”指的是下标最小所以不能只用哈希表存次数要保留原始顺序。Python参考解法def first_unique_char(s: str) - int: count {} for ch in s: count[ch] count.get(ch, 0) 1 for i, ch in enumerate(s): if count[ch] 1: return i return -1时间复杂度O(n)空间复杂度O(1)因为字符集固定为26个小写字母。笔试里写到这里再补一个边界说明“当字符串为空时直接返回-1”这道题就稳了。为什么选这道题当模拟因为它把“哈希表”“字符串”“边界条件”三个测试开发笔试高频考点全占了。类似的题目还有“字符串中第一个只出现一次的字符”“数组中出现次数超过一半的数字”建议配套练掉。5.2 模拟题2设计一个“滴滴App登录页”的测试方案题目描述请设计滴滴出行App登录页面的测试用例包含手机号、验证码、登录按钮三个元素。要求覆盖正常流程和异常流程。这道题我在笔试经验分享里反复提到因为它完美考察了测试开发的核心素养。我从三层来拆解。第一层是UI层面检查页面布局是否正常手机号输入框和验证码输入框的间距、字号、颜色在主流机型上是否一致键盘弹起会不会遮挡输入框iOS和Android的placeholder提示文字显示是否相同。这些细节说明你有适配意识。第二层是功能逻辑层面这里要分层设计手机号输入框不输入直接点登录、输入1位数、输入10位、输入11位但非手机号、输入11位有效手机号、输入带86前缀的号码、输入超长号码。验证码输入框不输入、输入3位、输入4位正确、输入4位错误、输入已过期的验证码、重复点击“获取验证码”、60秒倒计时内再次获取。登录按钮正常流程登录成功后跳转到首页弱网环境下点击登录出现了loading动画重复点击登录按钮是否会出现重复提交。第三层是安全和异常层面验证码接口被频繁调用时有没有限制防刷机制手机号输入国际字符会不会报错登录接口返回超时时前端有没有toast提示杀掉App进程重新进入登录状态是否保持。这样答下来阅卷人能看到你的思路是有层次的不是想到哪写到哪。这种层次感平时练题就要刻意去建立。5.3 模拟题3判断两个单链表是否相交题目描述给定两个无环单链表判断它们是否相交。这里的“相交”指的是两个链表存在同一个节点而不是值相等。这道题属于链表题里的经典变体需要一点逻辑推导。核心思路如果两个链表相交那么从相交节点开始到末尾的节点是完全重合的所以它们末尾节点一定相同。可以分别遍历两个链表记录各自长度然后让长链表的指针先走差值步数再同步遍历比较节点是否相等。Python参考解法class ListNode: def __init__(self, val0, nextNone): self.val val self.next next def get_intersection_node(headA: ListNode, headB: ListNode) - ListNode | None: lenA, lenB 0, 0 pA, pB headA, headB while pA: lenA 1 pA pA.next while pB: lenB 1 pB pB.next pA, pB headA, headB if lenA lenB: for _ in range(lenA - lenB): pA pA.next else: for _ in range(lenB - lenA): pB pB.next while pA and pB: if pA is pB: return pA pA pA.next pB pB.next return None注意这里比较的是is而不是因为链表相交是节点引用相同。这道题考察的就是你对“引用”这个概念的理解测试开发日常验证数据时也有非常类似的对象一致性判断场景。6. 笔试前的冲刺清单与踩坑复盘6.1 最后四周冲刺计划笔试准备最忌讳“什么都想看什么都没看透”。我建议把冲刺期按周拆开分配方式可以参考这个节奏。第一周集中刷算法基础。目标是把数组、字符串、哈希表、链表四类题型刷到条件反射。每天3道题不用贪多但每道题都按“独立写出来、分析复杂度、说清思路”三个步骤完成比一天刷十道只过眼瘾强得多。第二周集中补测试理论和方法论。等价类、边界值、场景法、正交实验法、错误推测法每种方法找一个业务案例做练手把用例设计模板跑熟。同时把网络协议、数据库SQL、Linux常用命令的清单过一遍。第三周开始做整套模拟卷。找牛客网或赛码网上的校招真题按真实笔试的时间限制和输入输出方式来练。这一周是最容易发现问题的阶段比如某类算法题超时、用例设计题写太慢、SQL语法不熟该补哪里趁早补。第四周复盘针对性突击。把前几周的错题和没吃透的知识点重新过一遍整理一份自己的“高频考点速查表”。考前一天只看速查表不做新题保持状态但不高强度学习。6.2 我在笔试中最常看到的三个翻车场景作为过来人我复盘过自己和其他同学在笔试中的真实表现有几个翻车场景特别普遍提前提醒你避坑。第一个翻车场景是“代码写对了输入输出格式错了”。线上判题系统的输出容错很低多一个空格、少一个换行都可能判错。解决办法是考前花二十分钟专门练输入输出模板别把时间浪费在考场上试错。第二个翻车场景是“测试用例设计只顾着写正常路径”。我记得有次模拟练习“搜索目的地”功能大部分人写的是“输入正确地点名、点搜索、出现结果”只有少数人写到“搜索结果为空时页面如何展示”“搜索到多个同名地点时如何排序”“输入emoji表情会怎样”。异常路径和边界场景才是拉开差距的分水岭。第三个翻车场景是“时间分配失控”。有人在一道算法题上死磕四十分钟导致后面测试设计题只写了三行。我的建议是笔试开始先花两分钟浏览全部题目给每道题定一个预算时间并严格执行比如算法题每道最多25分钟用例设计题每道20分钟超了就做下一题。稳稳地把所有题都答完比“一道题完美、其他题空白”拿到的总分更高。注意校招笔试不只是知识考核也是策略游戏。先完成再完美先把能拿的分都拿到再回头优化细节。我个人在这个岗位摸爬滚打之后最大的感受是测试开发笔试其实是在筛选一种“既能钻到代码细节里又能跳出来看全局”的人。算法题考的是你能不能钻进去用例设计题考的是你能不能跳出来。准备的时候不要偏废同样重要的还有一件事——把每一次练习都当成真实的笔试题来对待限时、手写、模拟判题环境。备考没有捷径但方向对了你的每一份努力都会体现在分数上。最后再分享一个小技巧笔试前一天把过去一周整理的高频考点速查表拿出来念一遍尤其是容易混淆的HTTP状态码和SQL聚合函数。这些零散知识点不念一遍考场上经常会有“明明会但就是想不起来”的感觉。睡个好觉比熬夜多刷一套题更重要。