2018年秋天我坐电脑前打开滴滴出行2018校园招聘网申笔试的链接岗位是测试开发工程师批次是第三批。那场笔试的体感很特别它不是那种“算法好就能稳过”的考试也不是“背背测试理论就能应付”的考试而是同时要求你会写代码、懂测试、能围绕具体业务场景把问题拆开。几年后再看这些考核点依然是大厂测开岗的通用标尺。这篇文章不打算复刻“原题”而是把我整理出的能力模型、答题顺序和准备方式分享出来给正在准备测试开发校招的同学一个可参考的坐标。你可能查不到同一套卷子但只要把底层的知识结构和答题思路理顺换哪一年、换哪个厂心里都不慌。1. 为什么2018年的滴滴测开笔试放在今天仍然有参考价值1.1 从测开岗位的日常职责反推笔试考点我后来面试过不少测试开发候选人发现一个普遍现象不少人对这个岗位的理解还停留在“写测试用例、点点点、提Bug”。但滴滴的测试开发工程师日常要做的事情其实更接近三件事第一保障核心业务链路的质量比如从用户打开App、输入起终点、呼叫车辆、司机接单、行程计费到支付完成这条主链路任何一个环节出问题都会直接影响用户体验第二把重复性的验证工作自动化自己写框架、写脚本、搭平台而不是靠手工一遍遍回归第三做线上问题排查、性能分析和稳定性治理很多时候要直接干开发的活。因为职责跨度大笔试就不可能只考单一维度。我打开试卷后明显感受到它是按“准测开工程师的能力体检表”来设计的先给一堆基础题看知识底子再来几道编程题看动手能力最后来一道测试设计题看你能不能像测开一样思考。这种结构今天依然很常见。1.2 第三批次的招聘节奏决定了你不能只拼运气滴滴2018校招分了多个批次第三批意味着整个招聘战线已经拉到中后段。前两批可能已经发了不少offer坑位变少但机会依然存在。到这个阶段做笔试心态和技术同等重要。有些同学因为之前投的其他公司没回音整个人已经焦虑到不行笔试时连题目都读不进去也有同学是刻意避开第一波高峰等自己刷题充分了才报名反而答得更从容。从题目本身看不同批次的题目难度不完全一致。但据参加过前两批的同学反馈知识范围大差不差第三批并没有离谱到超出常规。所以我的建议是别把精力花在揣测“哪一批更容易”上而是把算法、测试理论、计算机基础、业务场景分析这四块能力老老实实补齐。哪怕批次不同只要你的底层能力是够的筛选只是时间问题。2. 测开笔试的四块硬功夫算法、网络、操作系统、数据库2.1 算法不要只盯着LeetCode高频题测开岗的算法题通常不会达到纯算法岗的难度但依然是笔试里最筛人的一关。我当时刷题的时候优先看的是数组、字符串、链表、栈、队列、二叉树和基础的动态规划。排序和查找必须能手写复杂度也必须张口就来。很多题目喜欢披着业务场景的外衣考最基础的算法比如“给定一组打车订单的时间区间判断是否有重叠”本质就是区间的合并与排序。一个容易被忽略的点是测开笔试的编程题有时候并不要求你写出最优解但要保证代码风格干净、逻辑完整、能处理边界输入。我见过不少同学能快速想到O(n^2)的暴力解却因为忘记处理空数组和极端值导致多个测试点过不去。记住在笔试环境里先保证“能跑通”再考虑“够优化”这才是拿分策略。2.2 网络基础从TCP三次握手到HTTP状态码测试开发在排查线上问题时经常要面对网络相关的故障。所以笔试里出现TCP/UDP的区别、三次握手为什么是三次、HTTP和HTTPS的差异、GET和POST的区别这类题一点不奇怪。这些知识点看起来基础但问法往往很实际。比如给你一个App页面加载慢的场景让你判断是网络问题、服务端问题还是客户端渲染问题这时候你对HTTP状态码、DNS解析、连接复用这些概念的理解就直接影响答题深度。操作系统也同理。进程和线程的区别、死锁产生的四个条件、虚拟内存的作用、Linux下常用命令top、ps、netstat、grep、awk都可能被放进选择题或简答题。测开日常要在Linux服务器上看日志、查性能这些不是纯理论是实打实的工具。2.3 SQL和数据库手写SQL是常规操作数据库相关的题几乎必考。要么是给两张表让你写查询要么是问你索引为什么会失效要么是给你一个“订单表数据量大查询变慢”的场景让你给出优化思路。我当时花了不少时间在牛客网刷SQL题尤其是多表关联、聚合函数、子查询、分组统计这几种。笔试里的SQL一般不会太复杂但要求你写出来的语句逻辑正确、可执行别在最后忘了分号或者用错聚合字段。如果你是零基础建议先建一张表自己往里面插入几十条模拟数据然后反复练习“查某个城市订单量”“查每个司机的平均评分”这类题目。手写SQL真的没有捷径多练几次语法自然就熟了。3. 测试理论与测试设计题从“会写代码”到“会设计测试”3.1 等价类、边界值、场景法不能只会名字很多同学以为测试理论就是背几个名词结果笔试一考就露馅。等价类划分是最基础的黑盒测试方法它的核心是把输入数据分成若干“有代表性的”类别然后用少量用例覆盖尽量多的输入空间。边界值分析则是专门去测那些最容易出错的边界情况比如年龄的18岁、金额的0.01元、每页条数的上限。但笔试真正想看的是你能不能在实际问题里用上这些方法。比如让你测试一个“优惠券满100减20”的功能你光说“等价类划分”没有用你得能回答出金额小于100、等于100、大于100、金额为0、金额为负数、金额带小数怎么办优惠券过期怎么办同一订单能否叠加多张优惠券。这些话一说出来面试官就知道你是真的做过测试设计而不是背了本理论书。3.2 现场写测试用例怎么做到条理清晰测试设计题往往是最后一道大题分值不低。见过不少同学一上来就洋洋洒洒写了几十条用例乍一看很多其实重复、混乱、没有优先级。我自己的答题框架通常是三句话先写主流程用例再写异常流用例最后写非功能用例。主流程就是用户正常操作时最核心的路径比如“输入正确目的地-点击呼叫-司机接单-到达-支付成功”异常流是各种失败场景比如“网络断开”“定位失败”“司机取消订单”“余额不足”非功能用例则包括性能、兼容性、安全、易用性。这样分类写面试官一眼就能看到你的思路。哪怕用例数量不多也比写一百条没有分类的用例更能打动人。3.3 从测试设计反推产品思考好的测试工程师不只是照着需求文档写用例而是能反过来质疑需求本身。笔试如果给一个“司机端APP的接单按钮”让你测试除了验证按钮能不能点、点了有没有反应你还应该想到如果司机正在开车这个按钮点击后会不会干扰驾驶接单后倒计时多久倒计时内被其他乘客取消怎么办同一时刻有多个订单推送过来按钮的状态怎么变化这些问题的背后是对用户场景、异常容忍度、业务规则的理解。测开笔试里这一部分往往是拉开差距的关键。很多同学能写代码却写不出这种有业务深度的测试用例。4. 把“滴滴打车”当作考题业务场景题的拆解套路4.1 拿到一个具体业务功能先画出主干流程我印象里这类笔试特别爱出和自身业务相关的场景题。比如“请设计一个测试方案来验证‘乘客发单后能够匹配到附近的司机’”。这种题看起来开放其实有固定解法。第一步不要急着写测试点先把主干流程画出来乘客发起订单、系统获取地理位置、筛选符合条件的司机、向司机推送订单、司机响应、乘客收到匹配结果。这一步画完后续的测试用例就有了骨架。4.2 功能之外别忘了兼容性、性能、异常针对“发单匹配司机”这种核心链路功能测试只是及格线。容易拉开分的是非功能部分。性能上要考虑到高峰期大量用户同时叫车系统能不能扛住匹配算法响应时间是否在可接受范围内。兼容性上要覆盖Android和iOS的不同版本、不同屏幕尺寸、弱网环境。数据一致性上要验证乘客端显示的司机位置和司机端是否一致订单状态在前后端是否同步。我当时答题的时候习惯把测试类型列成一张表格功能测试、接口测试、性能测试、兼容性测试、安全测试、异常测试。每类下面写两三个具体例子。这样做的好处是阅卷人或者面试官能一眼看到你的测试粒度而不是在一堆零散的操作步骤里自己找重点。4.3 稳定性测试和线上监控也是测开的日常除了功能上线前的验证测开还要负责上线后的稳定性。所以业务场景题里偶尔也会出现“线上出现了某个问题你如何排查”的问法。这时候不要一上来就查代码而是先定位影响范围、复现步骤、看日志、查监控、确认是客户端还是服务端问题。我当时在准备阶段刻意练习过“全链路排查”的思维从前端到网关到后端服务到数据库每一层可能抛出的问题是什么。这种思维在笔试里非常吃香。5. 编程题不是全部但“部分通过”和“AC”之间差了很多面试机会5.1 先写暴力解再渐进优化第三批笔试里的编程题我记得当时是可以在一个在线编辑器里写系统会自动跑测试用例。很多题的第一眼都能想出暴力解。比如“找出数组中两个数之和等于目标值”最直接的双重循环就是O(n^2)。如果你只能写暴力解也不要心慌先把它稳稳写出来确保能通过部分测试点。然后在暴力解的基础上用哈希表、双指针、前缀和等手段去优化。测开岗位不会像算法岗那样要求你所有题都秒出最优解但如果你连暴力解都没跑通那后面连面试机会都很难拿到。5.2 边界条件、空输入、大数值这些细节决定了通过率我在实际刷题时发现最可惜的丢分不是题目不会而是边边角角的细节没处理好。题目说输入的字符串长度可能为0你在代码里却没有处理数组元素可能是负数你却默认了非负数值可能超过int范围你却用了int存储。这些“小坑”在笔试环境下特别容易踩因为时间紧人容易只盯着主逻辑。后来我养成了一个习惯写完代码后强迫自己花30秒检查四件事——空输入、单元素输入、最大值最小值、重复元素。这个习惯帮我保住了很多不该丢的分数。5.3 常见编程题类型字符串、模拟、树和基础动态规划测开笔试的编程题通常不会出太偏的题型。字符串处理反转、去重、子串判断、数组操作排序、去重、查找、简单的链表操作、二叉树的遍历、基础的动态规划爬楼梯、最大子序和、背包雏形这些属于高频范围。另外有些题目会伪装成“业务模拟”比如“实现一个简单的订单状态机”“判断司机和乘客匹配的规则”本质还是在考你写代码的准确度和逻辑严谨性。我建议准备时间有限的同学优先把剑指Offer里简单和中等难度的题刷两遍再配合LeetCode的热门100题做练习。不要追求题海战术而是每做完一道题都问自己这个解法的时间复杂度是多少空间复杂度是多少如果数据量放大十倍还能跑吗6. 笔试后的准备窗口以及现场面试的高频追问方向6.1 考完立刻复盘把错题变成自己的题库笔试结束不代表这件事就结束了。我当时考完不是马上放松而是趁记忆还热把自己没做出来的题、模棱两可的选择题、写得不流畅的SQL全部记下来。这些复盘内容后来直接变成了面试前的高效复习资料。尤其是那些你“好像会但没答好”的知识点往往就是之后面试官喜欢追问的点。比如笔试里有一道关于HTTP状态码的选择题你可能当时犹豫了。如果不复盘面试时被问到“402和403有什么区别”你还是会卡住。但如果笔试后就主动查一遍再结合几个实际场景去理解这个知识就真正变成你的了。6.2 现场面试中项目经历是怎么被深挖的笔试通过后面试环节最常被问到的是简历上的项目。很多同学写在简历上的测开项目是“基于Selenium的UI自动化测试框架”但一问细节就露馅。面试官会问为什么选Selenium而不是别的你的框架是怎么处理用例依赖的跑一批用例要多久元素定位失败怎么处理失败了会不会自动重试CI/CD是怎么集成的这些问题的答案都必须来自你实际动手的体验而不是网上抄一段项目描述。我的建议是哪怕你在学校做的项目规模很小只要是你自己一行行代码写出来的把“为什么这样做”讲清楚也比堆一堆华丽但经不起追问的“高并发”“微服务”词好得多。6.3 反问环节怎么聊才显得你懂测开面试最后通常会让你反问。这时候不要提“加班多不多”“年终奖多少”这类问题至少不要作为第一个问题。你可以问“团队目前用的自动化测试框架是什么”“线上质量指标主要看哪几个”“测试开发在项目里的角色是偏工具开发还是偏业务测试”。这些问题既得体又能让你判断这个岗位是否适合自己。我自己在面试别人时如果候选人能问出这种问题通常会在心里给他加分因为说明他真的思考过这个岗位。7. 关于那场笔试的碎碎念和几条实操建议7.1 建议的答题顺序先做测试设计题再做编程题这是我和好几个上岸的同学交流后得出的共同经验。笔试时间有限如果一开始就死磕编程题很容易卡住并产生焦虑导致后面的测试设计题草草了事。测试设计题不需要精确的语法只要你思路清晰、格式工整拿分相对容易。先把这些稳定拿到的分攥在手里再回头啃编程题心态会完全不一样。当然这个顺序也看个人习惯。如果你编程能力强先做编程题也没问题。关键是不要在中间某道题上恋战。一道题想了十五分钟还没有头绪果断先跳过去把会做的题做完再回来补。7.2 审题比做题更重要尤其是“字少”的题有一类题题干特别短比如“设计一个测试方案覆盖拼车功能”。越短的题越容易审偏。有人看到“拼车”就开始写功能测试点完全忘了还要考虑拼车成功率的算法逻辑、拼友取消订单、费用分摊异常、上下车点变更、司机多订单并发等场景。越短的题干往往隐含的考察面越宽。答题前先在草稿纸上写几个关键词把题干里每个词都过一遍再动笔这个习惯能让你的答案准确率提高不少。7.3 现在回看最值得提前做的一件事如果让我穿越回2018年那次笔试前我会告诉自己别急着背所谓的“大厂题库”先把你简历上写过的每一句话都想清楚。笔试考的是知识边界但面试考的是你对自己做过事情的认知深度。这两者的交集才是你能真正拿到Offer的关键。多做几个能讲清楚“我为什么这么做”的小项目比刷十套题更有用。每次我回想那场笔试记忆最深的反而不是某道算法题而是它让我想明白了一个道理测试开发工程师不是“开发的备选项”它需要你兼具工程实现能力和质量敏感度这份职业本身就值得被认真对待。如果你也想走这条路希望这篇复盘能帮你少踩几个坑把力气花在真正重要的地方。