2017年秋招那会儿滴滴出行测试岗的笔试热度非常高投递人数多、筛人比例也大。最让我印象深刻的是很多同学误以为测试岗笔试就是“点点点”思路随便答一下结果真正坐到在线笔试界面才发现前面是计算机网络、Linux、数据库的选择题中间夹着两道编程题最后还有一道“如何测试实时定位功能”的业务设计题连蒙带猜很难做完。虽然时间已经过去几年但这套笔试的考察逻辑放到今天的测试岗面试里依然非常典型计算机基础、测试用例设计、编程能力、业务理解能力四件事一起考。这篇文章就结合当年的真题回忆和常见的题目变体把滴滴测试岗笔试的核心考点、题型分布和答题思路完整拆一遍给准备测试岗笔试的同学一份可以照着的复习框架。1. 2017年滴滴秋招测试岗笔试复盘题型分布与考察目标1.1 这份笔试想筛出什么样的测试工程师很多人对测试工程师的印象还停留在“功能点一遍发现bug上报”的阶段但滴滴这种规模的互联网公司业务复杂度决定了它需要的测试人员绝不是执行型角色。当年的岗位描述里反复出现几个关键词理解业务、设计测试方案、开发自动化工具、推进质量体系建设。翻译成白话就是你得懂技术、懂业务、能写代码、会从用户角度思考问题。这决定了笔试的考察维度不是单一的知识点而是看你能不能把多个领域的知识组合起来解决一个具体的质量问题。比如后面会详细讲的“如何测试实时定位功能”表面上是功能测试实际上涉及GPS、网络协议、App前后台切换、地图数据校验、异常场景兜底等多个层面。这种题没有标准答案但能看出一个人的测试思维是否完整。1.2 题型结构与时间分配根据当年考生回忆滴滴测试岗在线笔试时间大约90到120分钟题量不算小题型大致如下题型大致题量考察方向单选题20-30道计算机基础、测试理论、逻辑判断简答题3-5道测试分析方法、缺陷定位思路用例设计题2-3道功能测试设计、业务场景覆盖编程题2道字符串、数组、算法逻辑业务场景题1-2道移动出行相关场景分析从题型分布能看出来选择题占了很大比例这部分如果拿不到分后面写再多也可能没时间。所以我的建议是选择题必须练到“秒杀”的程度——看到考点就能立刻出答案把时间留给需要展开论述的题目。1.3 各模块知识点占比从整体分值看计算机基础和编程题加起来接近一半测试理论加上用例设计约占三成剩下的就是业务场景题。这个比例说明了测试岗笔试的一个真相基础不牢后面很难用技巧弥补。计算机基础部分高频出现的是TCP/IP协议、HTTP状态码、DNS解析过程、进程与线程、内存管理这几个考点几乎逢考必有。Linux部分重点是文件操作、日志查看、进程管理、网络排查命令。数据库部分以SQL查询为主尤其喜欢考分组统计、排序、多表关联。这些内容不是单纯记忆而是要理解原理因为笔试会出很多“换了个场景考同一个知识点”的题目。2. 测试基础题用例设计是笔试的命门2.1 等价类、边界值、场景法先吃透这三板斧用例设计题是测试岗笔试和普通开发岗笔试最大的区别所在也是最能体现测试专业度的地方。当年滴滴笔试里虽然没有直接写“请解释等价类划分”但后面的用例设计题全靠这几种方法来支撑。等价类划分的核心思想是“用最少的用例覆盖最多的有效数据”。以“用户年龄输入框”为例需求规定了年龄必须在1到150之间那么有效等价类是1到150的整数无效等价类包括小于1的数字、大于150的数字、非数字字符、空值。设计用例时从每个等价类里取一个代表值就能保证覆盖。边界值分析本质上是等价类划分的补充因为大量bug恰恰集中在输入范围的边缘。还是年龄这个例子除了验证中间的某个值还必须测0、1、150、151这些边界。实际开发中很多代码用if (age 1 age 150)判断一旦把写成就只有在边界值用例下才能暴露。场景法则侧重于用户操作路径。比如注册新用户核心路径是输入手机号、获取验证码、填写信息、提交注册备选路径包括验证码错误、网络超时、手机号已被注册、提交时断网。用例设计的高下之分往往就体现在有没有把备选路径和异常路径覆盖完整。2.2 真题示例“手机号注册”功能测试用例设计当年几乎所有测试岗笔试题都绕不开账户注册类功能滴滴也不例外。它的变体很多有的考邮箱注册有的考短信验证码登录但核心套路一样。这类题想要拿高分应该先拆解需求再写测试点。注册流程涉及三个输入域手机号、短信验证码、用户信息昵称、密码。手机号要校验格式、长度、运营商号段验证码要关注发送频率、有效期、错误次数密码要关注长度、复杂度、二次确认还要考虑注册成功后数据落库是否正确。表格化的用例展示会清晰很多。用例编号模块操作步骤预期结果优先级TC01手机号校验输入正确的11位手机号点击获取验证码提示发送成功60秒后可重新获取P0TC02手机号校验输入10位手机号点击获取验证码提示“手机号格式不正确”按钮不置灰P0TC03手机号校验输入非法字符或字母输入框过滤或提示格式错误P1TC04验证码校验输入正确的6位验证码校验通过进入下一步P0TC05验证码校验输入错误的验证码提示“验证码错误”可重新输入P0TC06验证码校验输入已过期的验证码提示“验证码已过期请重新获取”P1TC07验证码校验同一手机号1分钟内重复获取提示“获取过于频繁请稍后再试”P1TC08注册提交填写完整信息点击注册注册成功自动登录并跳转首页P0TC09注册提交手机号已注册再次提交提示“该手机号已注册可直接登录”P0TC10异常场景点击注册后断网提示“网络异常”数据不被重复提交P1TC11并发场景两个请求同时注册相同手机号只有一个成功另一个提示已被注册P2这只是一个精简版但已经能看出高分答案和低分答案的区别。低分答案可能写了五六个正常路径用例就停了而高分答案会覆盖异常、边界、安全、并发和数据一致性。2.3 低分考生的通病只写正常流程在批改这类题目的过程中我最常见的问题不是“不会写”而是“写得不够”。很多同学写用例题时只覆盖了功能正常流转的路径然后草草收尾。这里想提醒大家用例设计题考察的从来不是你会不会用这个功能而是你能不能发现它什么时候会出问题。所以写完之后一定要回头检查三件事。第一有没有覆盖输入域的非法值和边界值第二有没有覆盖网络异常、超时、中断等外部环境变化第三有没有考虑数据层面的问题比如重复数据、脏数据、并发操作。一个实用的技巧是拿到题目后先在草稿纸上列几个大类正常流程、输入校验、异常环境、数据一致性、权限与安全、性能表现。按照这六个维度逐个展开一般就能保证不遗漏关键测试点。3. 计算机网络、Linux和数据库看似送分全是陷阱3.1 计算机网络考点怎么结合测试场景出题计算机网络是测试岗笔试选择题的重头戏但考法并不死板。同样是TCP三次握手开发岗可能直接问“为什么是三次而不是两次”测试岗则可能换成“当用户进入页面时一直加载不出来请你从网络协议角度分析可能的原因”。这类题目在滴滴笔试题里特别常见因为移动出行App对网络环境的要求很高。我印象比较深的一道简答题是用户反馈刷新订单列表一直转圈请列出你的排查思路。这道题的完整回答应该从客户端到服务端逐层排查。第一步看客户端网络状态是WiFi还是4G信号是否正常第二步抓包确认请求是否发出有没有收到HTTP响应第三步看响应状态码是500服务器错误、404接口不存在还是200但数据异常第四步查服务端日志确认接口是否有报错、数据库查询是否超时第五步对比不同版本客户端的表现判断是兼容性问题还是线上环境问题。另外一个高频考点是HTTP和HTTPS的区别、常见状态码的含义。这个必须熟练掌握200表示成功301和302是重定向401是未认证403是禁止访问404是资源不存在500是服务器内部错误502是网关错误503是服务不可用。测试时看到状态码要能快速判断问题出在哪一层。3.2 Linux命令测试工程师的看家本领工作中经常要登服务器查日志、看进程、验证部署这些操作在笔试里会以命令选择题或者简答题的形式出现。滴滴的笔试里曾经考过“如何查看实时更新的日志文件”、“如何查看某个端口是否被占用”、“如何结束一个进程”本质上就是最常用的几个命令。命令使用场景示例tail -f实时查看日志输出tail -f /var/log/app.loggrep按关键字过滤日志grep ERROR app.logps -ef查看进程详情ps -ef | grep javanetstat -tunlp查看端口占用netstat -tunlp | grep 8080curl模拟HTTP请求curl -i http://localhost:8080/apitop查看系统资源占用top -p 12345准备这类题目时不要死记命令参数要结合真实测试场景去理解。比如你要排查一个线上问题第一件事往往是tail -f加grep组合使用先看日志里有没有报错如果日志正常再用netstat确认服务端口是否正常监听进程还在但接口就是超时那就要top看一下是不是CPU或者内存被打满了。这些命令是连环使用的每条都有它的位置。3.3 数据库SQL验证数据一致性的必备能力测试过程中经常要验证数据库里的数据是否符合预期比如下单后订单状态是否更新、退款后金额是否回到用户账户。滴滴业务与资金、订单强相关SQL查询题基本上是必有的一环。常见的考法是给出一个订单表让你统计用户消费总金额或找出消费最高的用户。参考题目已知订单表orders字段包括order_id、user_id、amount、statuspaid表示已支付请查询消费金额排名前10的用户。SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status paid GROUP BY user_id ORDER BY total_amount DESC LIMIT 10;这道题考察的是基本的聚合查询能力但很多人在细节上翻车。比如没有用WHERE status paid过滤未支付订单或者排序方向写反或者忘记LIMIT。写完SQL之后一定要自己代入一组数据验证一下这是测试人员写SQL和开发写SQL最大的不同——你会下意识地用测试思维去检查自己的结果。4. 编程与逻辑题测试岗位为什么也考代码4.1 测试越来越依赖自动化编程是刚需2017年滴滴测试岗笔试里出现编程题让不少非科班同学感到意外。但如果看过测试行业的变化趋势就会明白这是必然的。一个只会手工点点点的测试很难在快速迭代的互联网业务中跟上节奏。测试开发、自动化测试、性能测试、持续集成这些方向全部依赖代码能力。拿功能性测试举例回归测试如果全部用手工完成每次发版都要重复执行几百条用例写一个脚本把核心流程自动化效率能提升数倍。即使不直接写框架测试工程师也要能看懂自动化代码、能改造用例、能调试脚本。所以编程题的出现并不是为了难为人而是在筛选具备自动化测试潜力的候选人。考的内容也不会特别偏基本都是字符串、数组、简单算法这类基础题。4.2 两道典型编程题及解题思路第一道高频题是“找出字符串中第一个只出现一次的字符”。这个题目有多种解法最简单的思路是先用字典统计每个字符出现次数再遍历原字符串找到第一个计数为1的字符。from collections import Counter def first_unique_char(s): counter Counter(s) for ch in s: if counter[ch] 1: return ch return -1这道题隐含的边界条件是空字符串返回什么、没有唯一字符时返回什么、字符串包含大写小写是否区分。这些细节恰恰是测试思维的体现你在写代码的时候就应该把这些边界情况想清楚。第二道高频题是“数组去重并保持原有顺序”。这个问题看似简单但如果额外要求不借助外部存储或者保持稳定性难度就会上来。def deduplicate(arr): seen set() result [] for x in arr: if x not in seen: seen.add(x) result.append(x) return result这是一道典型的使用哈希表辅助的题目时间复杂度O(n)空间复杂度O(n)。面试官如果追问“能否原地去重”那就是另一套思路了。笔试阶段能写出基础版本并说明复杂度基本就够了千万不要为了秀操作写出难以理解的代码。4.3 逻辑思维题用测试思维拆解经典谜题滴滴这类出行公司对逻辑思维也很看重因为测试人员在设计用例时经常要从复杂的业务规则里理清逻辑关系。逻辑题的代表是那个经典的“只有一个水龙头如何用一个3升桶和一个5升桶量出4升水”。解题步骤很清晰先把5升桶装满倒入3升桶此时5升桶剩2升把3升桶倒空将5升桶中的2升倒入3升桶再把5升桶装满继续往3升桶中倒水3升桶只能再装1升所以5升桶里剩余的就是4升。很多同学看完答案会觉得简单但考场上的关键是你能不能把思路分步写清楚。逻辑推理题即使没想出答案写出尝试的思路和排除的过程也能拿到一部分分数。因为这类题考察的不只是结果更是推理路径是否清晰。5. 移动出行业务场景题从“测功能”到“测业务”5.1 地图与定位功能怎么测业务场景题是滴滴笔试里最有辨识度的部分因为一般的互联网公司不会考地图、拼车、计价这类专业功能。这类题目看起来让人无从下手其实只要掌握了拆解思路反而比基础题更容易出彩。以“如何测试乘客打开App自动定位当前位置”为例。首先明确这个功能的输入GPS信号、网络数据、用户授权状态、App前后台状态、历史缓存位置。然后围绕这些输入展开测试点。测试维度具体场景预期结果权限处理用户拒绝定位权限提示需要开启定位引导去设置页权限处理用户选择仅使用期间允许后台运行时定位停止信号环境GPS关闭切换为基站或WiFi定位或提示定位失败信号环境地下车库、隧道等无GPS区域使用最后已知位置并提示定位可能不准网络环境4G、WiFi切换定位结果不中断数据准确性跨城市定位显示当前城市并更新自动定位结果前后台切换App从后台切回前台自动重新定位并刷新位置性能表现定位响应时间3秒内完成定位不阻塞页面操作5.2 拼车计价场景的测试点怎么拆拼车计价是滴滴业务里很典型的功能结合了价格规则、实时计算和资金安全笔试出现这种题完全在预料之中。拆这道题的时候可以把自己想象成产品经理加测试工程师。先列业务规则起步价、里程费、时长费分别怎么算多人拼车成功后再折扣行驶路线偏离是否重新计价乘客取消订单后费用如何处理。再围绕这些规则设计测试点。计价的正确性要重点验证在同一个订单里预估价格和实际价格是否一致行驶过程中实时刷新价格里程和时长的计算是否准确拼车成功前后的价格变化是否按规则计算。金额边界也要覆盖比如里程为0时是否只收起步价路线特别长时是否有封顶价优惠券叠加后会不会出现负数金额。并发和一致性同样不可忽视。两个乘客同时点击确认拼车系统是否只响应一次计费系统下发新价格时客户端和服务器的数据是否同步如果用户下单时价格是20元实际支付时计费规则已经调整应该按哪个价格计算。这些问题在业务场景题里写出来立刻就能看出你的测试思维是否完整。5.3 支付相关功能资金安全是红线支付功能是移动出行里最敏感的部分因为它直接和钱相关出任何问题都是严重事故。笔试里常见的考题是“如何测试支付成功后订单状态没有更新”或者“如何测试一笔订单的退款流程”。这类题目要突出核心资金相关功能测试的关键是幂等性和对账。用户支付成功后支付平台回调服务端如果回调发送了两次服务端只能有一个订单变成已支付不能出现重复处理。退款也一样用户点击一次退款系统接收到重复的退款请求实际退款只能执行一次。具体测试点包括余额不足时是否提示用户并引导使用其他支付方式支付过程中断网重新连接后订单状态是否恢复支付成功但App端展示失败以服务端账单还是客户端展示为准优惠券、拼车折扣、订单改价叠加后的应付金额是否正确。每个测试点都要从用户角度和系统角度各想一遍。5.4 业务场景题的方法论先拆规则再写用例业务场景题最容易出现的错误是拿到题目就开始写用例结果写了十几个点依然零散杂乱。正确的方法应该是先拆规则。第一步画出功能涉及的对象和状态。拿拼车举例对象包括乘客、司机、订单、价格规则订单状态包括待接单、已接单、行车中、已完成、已取消。第二步梳理状态流转的触发条件比如什么情况下从未支付变成已支付、什么情况下可以取消订单、取消后费用如何变化。第三步在状态流转的每个节点上补充异常场景比如支付超时、取消超时、司机取消、乘客取消。第四步再考虑数据一致性、并发、性能等通用维度。这套思路可以用在任何业务场景题上包括后面几年常见的智能座舱测试、车载测试、物联网设备测试。功能变了但拆规则的方法不会变。6. 从2017年真题延伸到今天的备考实战6.1 核心能力模型四根支柱回头看滴滴2017年这套测试岗笔试本质上只考察四件事计算机基础、测试设计能力、编码能力、业务理解能力。这四根支柱放到今天依然成立甚至因为行业的自动化测试和测试开发占比越来越高编码能力的权重还在上升。计算机基础是地基尤其是网络和数据库。测试工程离不开接口测试接口测试又逃不开HTTP、TCP、SQL这些基础。测试设计能力是饭碗等价类、边界值、场景法、正交试验这些方法决定了你面对一个功能时能不能系统地拆解。编码能力决定天花板一个能写自动化测试脚本的测试工程师产效比是纯手工执行的数倍。业务理解能力决定你能否发现问题隐患一个完全不懂拼车计价的测试很难设计出针对计价异常的深层用例。6.2 一个月笔试冲刺激训计划准备时间充足的情况下建议按四条主线并行推进。第一周集中强化测试理论和用例设计方法每天至少手写三道用例设计题覆盖输入校验、状态流转、接口返回等不同类型。第二周集中刷计算机网络、Linux、数据库的基础题每道题不仅要选对答案还要能解释其他选项为什么错。第三周集中练编程题每天一到两道从字符串、数组、哈希表开始逐步接触更复杂的题目。第四周做业务场景题和模拟笔试卡着时间完整走一遍流程。刷题的重点不应该放在猜题上而是放在建立稳定的分析框架上。测试岗笔试考来考去就是那几种题型只要分析方法稳定下来不管题目怎么变都能应对。6.3 答题细节与考场经验最后说几个实用的考场细节。写用例设计题时尽量用编号加表格的形式组织答案方便阅卷人快速看到你的覆盖范围如果题目要求写十个测试点宁可多写也不要少写因为判卷是按点给分。写编程题时先写下对边界条件的处理思路再写主逻辑哪怕代码有缺陷思路清晰也能抢救一部分分数。写逻辑题时如果没有完整答案也要把中间步骤写出来展示思考过程直接留空白是最亏的。时间分配上选择题每道不要超过一分钟拿不准的先标记跳过等后面的题写完了再回头检查。简答题和用例设计题才是拉开分数的地方一定要留足时间。回头再看2017年这套滴滴测试岗笔试我最直观的感受是它其实向所有求职者传递了一个信号测试已经不是那个“谁都能做”的岗位而是需要技术理解力、业务敏感度和编程基础的专业岗位。我自己这些年带测试团队时判断一个测试新人有没有潜力看的也是这几项。所以如果你正在准备测试岗笔试与其焦虑地收集各种版本的题库不如沉下心来把用例设计方法、基础知识和编程能力逐项练扎实这套基础打好了无论题目怎么变你都不会慌。