滴滴校招测试开发笔试解析：从测试思维到编程题备考指南

滴滴出行2018校园招聘网申笔试-测试开发工程师(第二批）

每年秋招季，总有学弟学妹来问我：“测试开发工程师的笔试到底考什么？跟后台开发考的一样吗？”我一般都会直接甩一句：测试开发岗的笔试题，表面上看是考代码、考基础，实际上考的是你有没有“测试思维”。什么是测试思维？就是同样一道题摆在你面前，别人看到的是“怎么把功能做出来”，你要看到的是“怎么把功能搞挂”。滴滴2018年校招这一批测试开发工程师的笔试题，就是非常典型的一套“看起来在考开发、实际上在考测试素养”的卷子。我自己当年也参加过类似的笔试，后来也帮部门出过校招笔试题，所以对这类题型的考察逻辑还算有点发言权。

这篇文章会把这份笔试题的考察逻辑、典型题目、解题思路和准备方法完整拆一遍。不管你是正在准备校招的应届生，还是打算从功能测试转测试开发的在职同学，只要把这里面的套路摸透了，再遇到类似的测试开发笔试题，心里会踏实很多。文章里的题目是我根据当年的题目风格和考察点整理还原的，重点在于讲清楚“为什么这么考、应该怎么答”。

1. 这份笔试题到底在考什么——测试开发岗位的能力画像

1.1 测试开发岗并不是“点点点”

先说一个很多人对测试开发的误解。在很多没接触过这个岗位的人眼里，测试就是“软件上线前点一点界面，看看有没有bug”，测试开发就是“会写点自动化脚本的测试”。这理解不能说全错，但至少落后了五到八年。稍微正规一点的互联网公司，测试开发工程师干的活早就不是单纯找bug了，而是围绕“质量保障”做一整套体系：自动化测试框架搭建、CI流水线里的质量门禁、线上故障演练、性能压测、测试数据平台建设，甚至还要参与代码review和架构评审。

滴滴这家公司的业务属性比较特殊，出行场景对系统的实时性、并发能力、地理位置计算的准确性要求特别高。你在App上发一个行程请求，后端要在一两百毫秒内完成派单、计价、路径规划、司机匹配、风控校验这一连串操作。这个链路上任何一个环节出问题，用户感知都是直接的。所以滴滴的测试开发，不能只会写用例，还得能理解分布式系统、消息队列、缓存、数据库这些后端组件的运行机制，甚至要能自己写工具去模拟极端场景。

校招笔试就是基于这个定位来设计的。它不指望你什么都会，但要通过有限的题目，快速判断你有没有“质量保障思维”的底子，以及你的编程基础能不能支撑你后续在测试工具开发、自动化框架搭建这些方向上成长。

1.2 滴滴笔试的筛选逻辑：三层能力过滤

我后来参与出题时，发现一套好的测试开发笔试题，通常是在做三层过滤。

第一层过滤的是“基础是否扎实”。计算机网络、操作系统、数据库、数据结构，这些计算机核心基础课的知识点会用选择题和简答题的形式出现。你以为这是在考八股？不完全是。它考的是你有没有形成完整的计算机知识体系。测试开发在工作里要接触的链路太长了：客户端发起请求、网络传输、网关转发、服务端处理、数据库读写、结果返回，每一层都可能出问题。如果你对基础协议和系统原理没有完整认知，出了问题根本不知道从哪一层开始排查。

第二层过滤的是“编程能力是否达标”。这一层用编程题来实现。但注意，测试开发的编程题，难度通常比同场次的后台开发岗位要低半个档次。它的重点不是让你写出多复杂的算法，而是考察你的代码风格是否规范、逻辑是否严谨、有没有考虑边界条件。因为测试开发日常写代码，大多数是写测试脚本和测试工具，核心要求不是算法复杂度极优，而是正确、稳定、可维护。

第三层过滤的是“有没有测试思维”。这一层是最隐蔽也最关键的。它可能隐藏在一道“给你一个场景，请设计测试用例”的题目里，也可能藏在编程题里——“让你实现一个函数，并说明你打算怎么测试它”。很多开发基本功不错的同学，就是栽在这一层。代码写得挺漂亮，但一说到怎么测，就只会说“跑一下看看结果对不对”，这离测试开发的要求就差远了。

2. 笔试整体结构与时间分配策略

2.1 题型分布与分值权重

滴滴这份测试开发笔试题（第二批），整体结构比较典型，和大多数互联网公司校招测试岗的笔试卷子大差不差。整张卷子大概由四部分组成：第一部分是单选题，大概10到15道，覆盖计算机网络、操作系统、数据库、数据结构、测试基础理论；第二部分是简答题或问答题，一般有两到三道，主要考测试设计思路和场景分析；第三部分是编程题，两道左右，不限定语言，可以用C/C++、Java、Python等主流语言作答；第四部分有时候会有一道“开放设计题”，给你一个功能场景，让你设计一套完整的测试方案。

分值权重上，编程题和测试设计题占了大头，加起来超过一半。单项选择题每题分值不高，但因为数量多，整体占比也在三成左右。这里有一个很多人没意识到的点：选择题拿分比编程题容易得多。编程题写不出来就是零分，但选择题至少可以排除法，而且考察的知识点相对固定，复习起来性价比很高。我见过不少同学花大量时间刷LeetCode中等难度的题，结果基础选择题反而丢了一堆分，非常可惜。

2.2 时间分配：先抢分，再攻坚

我当时给学弟学妹的建议是“先抢分、再攻坚”。整场笔试的时间一般是90到120分钟。我的建议分配方式是：

选择题控制在20到25分钟内完成。不要在一道选择题上死磕超过两分钟。拿不准的先标记，后面有时间再回头想。简答题控制在25到30分钟。这类题比较开放，只要思路清晰、条理完整，踩到得分点不难，但前提是你得把答案写结构化，不能让阅卷人在你潦草的文字里找得分点。编程题要预留至少40分钟。两道题，先审题、再构思、再写码、最后自测边界情况。如果编程题卡住了超过15分钟，果断换思路或者保一道题。

还有一个容易被忽略的点：展示思考过程。尤其是简答题和测试设计题，阅卷人希望看到你的推导路径，而不是只看到结论。举个例子，问“如何测试一个下单功能”，你的答案不能只是列七八条测试用例，而是要先说明需求分析、测试范围、用例设计思路、优先级划分、风险点，这样才能让阅卷人感觉到你脑子里有一套完整的方法论。

3. 客观题高频考点复盘与解析

3.1 计算机网络：三次握手与HTTP状态码

单选题里，计算机网络是必考模块。滴滴这类业务对网络质量非常敏感，网络题在笔试卷子里出现频率很高。我整理了一下，比较高频的考点集中在几个固定方向上：TCP连接建立的三次握手过程、TCP和UDP的区别、HTTP常见状态码的含义、HTTPS的加密流程、DNS解析过程、TCP拥塞控制的基本机制。

其中有几个细节是大家特别容易翻车的。比如三次握手，很多人只记住了“SYN、SYN+ACK、ACK”这三个步骤，但没注意一个问题：为什么是三次而不是两次？核心原因是为了防止“已失效的连接请求报文段突然又传到服务器端”导致服务器白白建立连接。这个考点不是单纯考记忆，而是考你有没有真正理解握手过程的设计意图。再比如HTTP状态码，301和302的区别、401和403的区别，几乎每年都会考。301是永久重定向，302是临时重定向；401是未认证，403是已认证但无权限。这四个状态码放到实际场景里特别容易混淆，答题的时候一定要抠字眼。

我在复习网络这块时，有一个比较高效的方法，就是不要死记协议细节，而是把你手机上的App当成一个案例去理解。比如你打开滴滴App下单，手机会先做DNS解析拿到服务器IP，然后通过HTTPS建立加密连接，请求会经过网关、负载均衡、应用服务器，最后查询数据库返回结果。这个全链路里，每一步涉及的协议和状态码你都串一遍，知识点就活了。

3.2 数据结构与算法：HashMap原理与排序算法

数据结构这块，笔试题一般不会考太偏的东西。高频考点有：各种排序算法的时间复杂度和稳定性、HashMap的底层实现原理、二叉树的遍历方式、链表和数组的优缺点对比、栈和队列的典型应用场景、快排和归并排序的实现思路。

HashMap的底层原理算是出现频率最高的题之一。在Java里，HashMap底层是数组加链表加红黑树的结构，当链表长度超过8且数组长度超过64时，链表会转化为红黑树，目的是优化极端情况下的查询效率。面试官和笔试题都很爱问扩容机制：默认负载因子是0.75，当元素数量超过容量乘以负载因子时，数组会扩容为原来的两倍，扩容后元素需要重新计算哈希位置。

排序算法这里，我经常提醒大家注意一个点：快速排序的平均时间复杂度是O(n log n)，但最坏情况下会退化到O(n²)。很多人只记了平均复杂度，忽略了这个最坏情况及其触发条件。这在选择题里是经典的“陷阱题”。比如给你一个已经排好序的数组，让你判断快排的表现，如果你回答“O(n log n)”就掉坑里了——如果每次选择的基准都是最大或最小元素，分区极度不均匀，快排会退化到O(n²)。所以有些版本的快排会通过随机选择基准来规避这个问题。

3.3 操作系统与数据库：死锁与索引

操作系统在测试开发笔试题里，出现频率最高的是进程和线程的区别、死锁产生的四个必要条件、进程间通信的方式、虚拟内存与页面置换算法。死锁几乎是必考中的必考：互斥条件、请求与保持条件、不可剥夺条件、循环等待条件。这四条必须一字不差记住，因为简答题也很爱考。

数据库这块，重点在索引、事务特性和SQL语句。索引方面有个比较有意思的点，很多人以为索引建得越多越好，实际完全不是。索引本身占用存储空间，写操作时需要同步更新索引，索引过多会拖慢插入和更新速度。笔试题经常考“什么情况下索引会失效”，常见的答案包括：对索引列使用函数或表达式计算、使用OR连接条件时有一侧未加索引、LIKE以通配符开头、隐式类型转换等。

事务的ACID特性也是常客。特别是隔离级别这一块，读未提交、读已提交、可重复读、串行化这四级分别能解决什么问题、会带来什么问题，需要理清楚。MySQL默认的隔离级别是可重复读，Oracle默认是读已提交，这种对比也是选择题里常见的考法。

3.4 测试基础理论：等价类与边界值

如果你是计算机科班出身，可能在大学的软件工程课上接触过这些概念，但说实话，很多同学的软件工程课就是混过去的。到笔试的时候，发现“等价类划分”“边界值分析”“判定表法”“场景法”这些词好像听过，但一让具体设计就懵。

测试基础理论在选择题和简答题里都会出现。等价类划分和边界值分析是测试设计里最基础也最实用的两个方法。举个例子，一个输入框要求输入1到100之间的整数。按等价类划分，可以把输入数据分为三类：有效等价类（1到100之间的整数）、无效等价类（小于1的数、大于100的数、非整数、非数字字符等）。边界值分析则是专门测试边界附近的输入，比如0、1、100、101。这两个方法合在一起用，能用最少的用例覆盖最多的场景。

我在笔试辅导里经常跟别人说一句话：测试设计题的本质是“用最少的用例覆盖最多的有效场景，同时对无效场景有足够防御”。这个思维不光笔试用得上，实际工作里更是核心能力。

4. 编程题真题复盘与解题思路

4.1 字符串类题目：最长无重复子串

滴滴这批测试开发笔试的编程题，难度对标LeetCode的简单到中等。两道题我印象比较清晰的，一道是字符串类的题，一道是数组类的题。

字符串这道题，给出的是一个字符串，要求找出其中最长的不含重复字符的子串长度。这个题在LeetCode上是第3题，属于妥妥的经典题。拿到这个题，首先得有意识：这是一个典型的滑动窗口问题。用两个指针维护一个窗口，右指针不断向右扩展，把新字符加入窗口，如果发现窗口内有重复字符，就移动左指针缩小窗口，直到窗口内没有重复字符。每次窗口变化时，更新最大长度。

真正写代码的时候，有几个细节要注意。一是用什么数据结构来记录窗口内字符的状态，常见的方案是用一个哈希表或数组标记字符是否出现过，也可以直接用HashMap记录字符最后出现的位置来快速跳跃左指针。二是边界条件：空字符串、长度为1的字符串、所有字符都不重复的字符串、所有字符都相同的字符串，这些都要在写完代码后自己过一遍。

这个题放在测试开发岗的笔试卷里，我个人理解是故意选了一道“写法容易、但写对不容易”的题，因为考察的不仅是你会不会滑动窗口，还有你的代码有没有防御性思维。写完主逻辑之后能不能主动去测边界情况，这本身就是测试开发的基本素养。

4.2 数组类题目：合并区间

第二道编程题是合并区间：给出一组区间，把有重叠的区间合并，返回合并后的结果。比如输入[[1,3],[2,6],[8,10],[15,18]]，输出是[[1,6],[8,10],[15,18]]。这题的做法很经典：先把所有区间按起点排序，然后遍历每个区间，判断当前区间和已合并区间的最后一个区间是否重叠。如果重叠就更新右端点，不重叠就新开一个区间。

这个题有一个比较容易踩的坑是：区间的比较逻辑写错，导致排序结果不对。所以写代码之前，要明确Comparator的返回值含义，按左端点升序排序。另外要注意的是，合并的时候，新区间的右端点要取当前区间右端点和已合并区间右端点的较大值，而不是直接用它覆盖。

这个题在测试开发岗出现，我觉得还有个考察维度：它考察的是你对“区间”这种数据结构的敏感度。实际做测试开发时，你会频繁处理类似场景，比如线上故障时间段的重叠判断、分批发布的时间窗口管理等。能快速实现区间合并，说明你具备处理这类问题的基本功。

4.3 场景模拟题：订单状态流转的验证

除了这两道纯算法题，编程题里还出现过一道和业务结合的题目：给定一批订单的状态流转记录，判断这些状态流转是否合法。比如订单状态有“已创建”“已支付”“已取消”“已完成”等几种，每种状态之间有合法的流转方向，比如“已创建”可以流转到“已支付”也可以流转到“已取消”，但“已完成”不能再流转到“已支付”。题目要求你写一个函数，输入是一系列的状态变更记录，输出是否存在非法流转。

这类题比纯算法题更能体现测试开发的业务属性。它考的是你对状态机模型的掌握，以及你对非法场景的敏感度。拿到这类题，正确思路是：先把所有合法的状态流转关系建一张映射表，然后依次遍历每条记录，检查当前状态到下一个状态是否在合法映射表里。要注意的是，有些题目还会额外加一个条件：同一订单的状态变更顺序要按时间戳递增，这时候还要加一个排序逻辑。

我之所以觉得这类题有价值，是因为它的核心思想跟日常测试工作高度一致——状态机是很多业务系统的底层模型，电商订单、出行订单、支付流程全部是状态机。测试开发如果能用代码对状态机做合法性校验，说明你具备了“自动化校验业务规则”的能力，这是比手写几个测试用例高一个层级的能力。

5. 测试设计题：从需求到用例的完整方法论

5.1 典型题目：为“发起行程请求”设计测试方案

测试设计题是测试开发笔试区别于后台开发笔试的标志性题目。滴滴这份卷子里，有一道题我记得特别清楚：给你一个“用户发起行程请求”的功能，从用户选择目的地、确认叫车、等待司机接单，到司机接单后行程开始，要求你设计一套完整的测试方案。

这道题很多人拿到手就开始罗列用例：输入起点、输入终点、点击确认、查看匹配司机……好像写了不少，但实际上都是零散的点，没有层次。阅卷人想看的是你的测试设计方法论。一道好的测试设计方案，至少要覆盖以下几个层面：功能测试，包括正常流程和异常流程；接口测试，包括入参校验、异常返回、超时处理；兼容性测试，包括不同手机型号、操作系统版本、屏幕分辨率；性能测试，包括弱网环境、高并发场景下的响应时间；安全测试，包括用户信息是否加密传输、是否存在越权访问；线上监控，包括核心指标的告警规则。

我当时自己回答这类题时，有一个固定的结构：先梳理需求全景图，明确功能涉及的角色、核心流程、辅助流程；然后按测试金字塔分层设计用例——底层是单元测试，中间是接口测试，上层是端到端的UI测试；最后单独列一个风险清单，把最容易出问题的点标出来，比如支付环节、极端天气下的派单逻辑、司机取消订单的补偿逻辑。

5.2 测试用例设计的四步法

这里我分享一个自己总结的测试用例设计四步法，笔试和实际工作都能用上。

第一步，梳理输入和输出。明确这个功能接收哪些输入数据，产生哪些输出结果。以“发起行程请求”为例，输入包括用户ID、起点位置、终点位置、车型选择、优惠券信息等；输出包括订单号、预估价格、司机信息、预计等待时间等。这一步的目标是把测试对象变成一个清晰的输入输出模型。

第二步，划分等价类并提取边界值。对每个输入项，划分有效和无效等价类，然后单独把边界值拉出来。比如起点位置这个输入，正常情况是一个具体的经纬度坐标，异常情况包括定位失败位置为空、坐标超出服务范围、坐标格式非法等；边界情况包括用户正好在服务范围的边缘、手机GPS漂移导致坐标轻微偏移等。

第三步，设计场景流程用例。以用户的实际操作路径为主线，设计一个个完整的操作场景。正常场景是用户发起请求、系统派单、司机接驾、行程开始；异常场景包括用户发起请求后无司机响应、司机接单后又取消、网络中断导致状态不一致等。每个场景都要关注状态流转的正确性。

第四步，反向补充异常与兼容用例。站在破坏者的角度想问题，比如输入数据被篡改、请求被重复提交、系统时间被修改、存储空间不足、电池电量极低等。兼容性层面，要覆盖不同iOS和Android版本、不同品牌手机对定位权限的处理差异。

用这个方法设计出来的用例，层次分明、覆盖全面，笔试时写出来会让阅卷人觉得你是有实战经验的，而不是临时背了几条用例模板。

5.3 测试设计中必答的“隐藏得分点”

除了用例设计本身，测试设计题里往往藏着几个隐形得分点。如果你只是把用例写完就结束，很容易错过。

第一个隐藏得分点是“优先级”。你要对设计出来的用例做优先级划分。P0级别的用例是核心流程相关的，一旦失败直接阻塞发版；P1级别是重要功能异常场景；P2级别是边界情况、兼容性细节。能够在答卷里体现优先级思维，说明你有测试计划管理的意识。

第二个隐藏得分点是“自动化测试方案”。在当前行业环境里，只设计手工用例是不够的，你得说明哪些用例适合做自动化、用什么框架做、在哪个阶段执行（冒烟测试、回归测试还是线上监控）。比如核心的下单链路用例，可以做成接口自动化，接入CI流水线，每次发布前自动跑一遍。

第三个隐藏得分点是“风险与依赖”。测试方案要能识别风险点，比如定位服务的第三方SDK有版本升级，可能导致定位精度变化，这就是一个需要提前介入和沟通的风险项。这也是测试开发区别于功能测试的重要能力：你做的不只是执行，还有风险识别和推动解决。

6. 常见丢分点与避坑指南

6.1 丢分点一：选择题在一两个难题上死磕

这是我在模拟笔试里反复看到的情况：有些同学在单选题上花了太多时间。遇到一道不确定的网络题，越想越慌，一耗就是五分钟，导致后面编程题时间不够。笔试题的难度分布基本是“前面简单、中间有坑、后面拔高”。遇到卡壳的题，先标记跳过去，把能拿的分全拿了，最后用剩余时间回来慢慢推。

6.2 丢分点二：编程题不做自测

编程题写完就提交，不做自测，这是最容易丢分的行为。笔试的在线评测系统和LeetCode一样，会跑隐藏测试用例。你本地跑一两个例子觉得没问题，但可能边界情况全挂了。写完之后至少留五分钟，手动过一遍这些用例：空输入、单元素输入、全相同元素、最大数值、明显会导致溢出的输入。在代码注释里写下你测试过的用例，也是加分项。

6.3 丢分点三：测试设计题只有用例没有逻辑

测试设计题最大的问题不是写得少，而是写成一盘散沙。没有需求分析、没有范围界定、没有优先级、没有方法说明，直接列二十条用例。这种答案在阅卷人眼里等于没答。正确做法是把答题分成三段：先说分析思路，再说测试策略，最后列用例。这样既显得专业，也方便阅卷人理解你的设计逻辑。

6.4 时间不够的止损策略

如果你在考试过程中明显感觉到时间不够了，我的止损策略是这样的：编程题如果还没有完整思路，直接写一个暴力解，不要死磕最优解。笔试试卷的评分通常是按测试用例通过比例来算的，暴力解能过一部分用例就有分。如果暴力解也写不完，那就用文字描述你的思路和伪代码，至少让阅卷人看到你的思考方向。最怕的是你坐在那里憋最优解，憋到最后交白卷。我见过太多这种案例了，非常可惜。

7. 笔试之后：如何衔接面试环节

7.1 笔试暴露的能力短板，面试前重点补

笔试结束到面试通知之间，通常有一到两周的间隔。这段时间很多人就干等着，其实非常浪费。你应该把笔试里做错的题、卡壳的题全部复盘一遍，这基本就是你能力短板的直接暴露。

比如选择题里网络协议相关的题错了一片，那面试前就要集中突击一下网络基础；编程题里数组类的题没写出来，那就要把LeetCode上数组和字符串相关的常见题刷一遍；测试设计题如果写得很干瘪，那说明你对测试设计方法论不熟，需要马上补一下等价类、边界值、场景法、判定表这几个常用的测试设计方法。面试官很喜欢在面试里追问笔试中的题目，你如果能在复盘后给出更好的答案，这在面试官心里的印象分会非常高。

7.2 简历上如何体现测试开发能力

笔试只是第一关，通过之后简历和面试才是决定因素。很多同学的简历上写“熟悉软件测试流程”“掌握自动化测试工具”，这种描述太泛了，没有说服力。

建议是：把每一个测试相关的能力点都落到具体的项目上。比如不要写“熟悉接口自动化测试”，而是写“基于Python和pytest框架搭建了xx项目的接口自动化测试体系，覆盖核心接口xx条，在CI流水线中集成，版本回归时间从2小时缩短到20分钟”。再比如不要写“了解性能测试”，而是写“使用JMeter对xx接口进行500并发压测，定位到数据库连接池配置不合理的问题，优化后接口P95耗时从800ms下降到250ms”。

面试官看一份简历，真正想确认的是“这个人来了能不能直接干活”。你的简历每一个描述都要能回答这个问题。笔试成绩能证明你的基础底子，但简历和面试表现才是offer的决定性一环。

写在最后的一点体会

回过头来看这套滴滴2018年测试开发的笔试题，虽然年份早了些，但它的考察框架放到现在依然不过时。基础题考的是计算机功底的扎实程度，编程题考的是代码实现的严谨程度，测试设计题考的才是你有没有真正理解测试开发这个岗位的核心职责。三个维度合在一起，基本就是测试开发工程师日常工作的缩影。

我给准备校招的同学一个比较实在的建议：不要只刷题，刷题之余一定要自己动手做几个完整的小项目，哪怕是个开源工具的二次封装、一个小型自动化测试脚本、一个接口测试的demo。因为笔试只是敲门砖，面试和后续的工作里，真正让你和别人拉开差距的，是你有没有动手解决过实际问题的经验。祝你们都能顺利拿到心仪的offer。