2019年那阵子即时配送正热点我达的校招测试开发岗位放出来后身边做测开方向的同学几乎全投了。我当时也在准备测试开发校招对这类笔试印象很深。测试开发笔试和普通开发笔试有个本质差别开发岗主要筛代码能力测开岗位用一套卷子同时筛代码能力、系统思维和测试设计的综合素养。所以很多只刷算法题的同学会栽跟头而真正理解测试思维的人反而不慌。这篇文章就把当年那场笔试的题型分布、考察逻辑和备考方法综合做一个复盘给正在准备类似岗位的后来人一些参考。不用被测试开发四个字吓住这类笔试其实有很明确的套路。1. 为什么点我达这类业务公司测开笔试会这样出题1.1 即时配送场景决定了考察侧重点点我达的业务核心是即时配送一个订单从用户下单、商家接单、骑手取货、配送中、已送达再到售后中间有大量状态流转。这类系统对稳定性的要求极高一个订单状态错了损失的不只是用户体验还有骑手结算、商家货款、平台信用等一系列连锁反应。测试开发在这个体系里不是帮忙点点按钮的角色而是要能站在全局视角判断系统可能在哪里出偏差、如何用代码手段提升验证效率。这个背景直接决定了笔试的出题方向。纯开发岗笔试喜欢考偏底层的数据结构和算法优化测开岗笔试则会刻意加入大量系统逻辑、异常场景和用例设计的考察。说白了公司要找的不是最会写快排的人而是能在复杂业务里发现风险、并能用自动化手段守住质量线的人。业务理解越深的候选人越容易通过这类笔试。我身边一个参加过的同学当时就反馈卷子里有一道关于订单状态流转的简答题问的是骑手点击已送达但用户未收到货系统可能发生哪些问题你作为测试如何设计验证方案。这种题目没有标准答案但能看出来一个人是真的理解业务还是只会背概念。这道题几乎成了整场笔试的分水岭。1.2 笔试的典型结构和高分策略根据当年参加笔试的同学复盘加上我自己对同类型公司的调研点我达这届测开笔试整体可分为四块选择题、简答题、测试用例设计题、编程题。四块的侧重点完全不同。题型主要考察点建议用时选择题单选多选计算机网络、操作系统、数据库、Linux命令20分钟别恋战简答题概念理解、测试理论、业务场景分析30分钟答到点子上测试用例设计题用例设计方法、异常场景覆盖、测试思维50分钟最拉分编程题基础算法、代码规范、边界处理40分钟至少做出一道选择题考的是基本功底不会特别刁钻但覆盖面广网络、OS、数据库、编程语言基础都可能有。简答题主要考察对测试的理解比如等价类划分、边界值分析在某个具体功能里怎么用。测试用例设计是整张卷子的大头通常给一个具体功能要求写出完整用例。编程题则明显比开发岗的题简单一档重点在代码正确性和边界条件处理。想拿高分核心策略是选择题快速过不要在纠结的题目上浪费超过两分钟简答题把概念写准写全尽量结合业务场景举例用例设计题一定要写结构清晰的表格或列表让阅卷人一眼看到覆盖维度编程题先做自己有把握的那道保证AC一道比两题都半途而废强得多。2. 计算机基础笔试测开岗绕不开的三座山2.1 计算机网络和操作系统是选择题大户测开笔试里的计算机网络题一般集中在TCP三次握手和四次挥手、HTTP与HTTPS的区别与常见状态码、TCP与UDP的应用场景这几个方向。操作系统则常考进程和线程的区别、死锁产生的四个必要条件、常见的进程调度算法。这些内容看着像开发岗才会考的硬核八股为什么测开也考因为做接口测试、性能测试时如果不懂网络协议连超时、重试、长连接这些基础问题都定位不了做稳定性测试时如果不理解进程和线程的资源模型就解释不了内存泄漏和死锁现象。举个例子选择题里很可能出现一个TCP连接建立过程中第二次握手失败可能的原因是这种题。看起来在考协议其实是在考察候选人对网络故障的敏感度。这种敏感度在测试环境问题排查时非常关键——很多时候测试用例执行失败不是功能bug而是网络连接被重置。2.2 数据库SQL的隐藏分值数据库在测开笔试里的出现率非常高而且往往是简答和编程之外的第三种考察方式。常见形式是给你两张表要求写出SQL查询某个时间段内订单数最多的骑手、统计每个区域的超时订单占比或者用一条update语句把某类订单状态批量更新。这类题对测开来说有实际意义因为无论是准备测试数据、清理脏数据还是写自动化测试的断言脚本都离不开SQL。备考时不用啃数据库内核掌握单表查询、多表join、聚合函数group by和having、简单的子查询、事务四大特性、索引的基本原理就够了。当时我一个同学就因为没复习group by和having的区别在一道筛选订单数大于100的商家的SQL题上卡了很久。其实这就是一个很基础的考察点但现场紧张起来就容易混淆。2.3 八股文到底怎么准备才高效说起测试开发面试题八股文很多人第一反应是死记硬背但我不建议这么做。八股文的价值不在于背下来而在于帮你建立知识结构的骨架。比如TCP四次挥手如果你只是背FIN、ACK、FIN、ACK四个字过两天就忘但如果你理解了连接关闭时双方都可能还有数据要发所以需要双向确认这个知识点就能自然地内化。我建议的备考方式是拿一套常见题单把每道题按是什么、为什么、在测试中怎么用三层结构梳理一遍。比如进程和线程是什么——进程是资源分配的最小单位线程是CPU调度的最小单位为什么——引入线程是为了更好地并发和资源利用在测试中怎么用——压测一个接口时线程数设置多少跟系统资源模型直接相关。这样梳理完笔试无论怎么出题你都能从根上回答问题。3. 测试用例设计题真正拉开差距的核心战场3.1 一道典型的用例设计题长什么样当年笔试的用例设计题典型的形式是给出一个具体的业务功能要求设计测试用例。比如用户下单成功后App地图页展示骑手实时位置或者用户申请退款退款金额原路返回。这类题目不写代码只要求用例设计看起来简单其实最能反映测试思维是否成体系。为什么这类题能拉开差距因为大部分候选人只会写正常流程的用例——用户下单成功骑手位置正常展示。但测开岗位要的是能考虑各种异常和边界的人用户关闭了定位权限怎么办骑手位置长时间不更新怎么办弱网环境下地图加载超时怎么办退款金额和支付金额不一致怎么办支付渠道返回失败但系统显示成功怎么办每一个异常分支都是系统性思维的体现。3.2 我习惯用的五层用例设计框架经过多年的实践我总结出一个可以直接套用的用例设计框架笔试和实际工作都适用。拿用户下单成功后展示骑手实时位置这个功能举例第一层是功能测试。覆盖正常路径用户下单成功、骑手接单、地图上出现骑手头像并随真实位置移动。这里要写清楚前置条件是用户已登录且有定位权限操作步骤是完成一笔订单支付预期结果是地图加载成功骑手位置每5秒刷新一次。第二层是异常和分支测试。覆盖各种失败场景下单失败时不应展示骑手位置、骑手取消订单后位置状态应自动清理、定位权限被关闭后应弹出引导授权提示、网络断开时地图应显示加载失败且不崩溃。第三层是边界测试。找到系统设计的边界值配送距离的上限是多少超过之后是否还展示实时位置骑手位置连续多少次刷新失败后应该转为文字提示位置更新延迟退款金额为0或者超过原支付金额时的系统行为。第四层是兼容性和专项测试。覆盖不同手机型号、不同操作系统版本下地图展示的差异还有电量低、内存不足、后台运行被系统收回、从其他App切回后地图是否重新加载等场景。第五层是安全和性能。地图接口是否有鉴权是否可能被篡改请求伪造骑手位置多用户同时查看同一骑手位置时服务端是否能承受地图加载时间是否超过3秒。在实际笔试中不需要每个功能都写这么多层但至少正常路径、异常路径、边界值和兼容性这四层是必须覆盖的。而且写用例时格式要规范前置条件、操作步骤、预期结果三要素缺一不可。3.3 怎么让阅卷人一眼觉得这个候选人懂测试除了覆盖维度全还有几个容易被忽视的加分点。首先是使用专业的测试方法术语比如在用例里注明利用等价类划分将支付金额分为有效等价类和无效等价类利用边界值法分别验证金额为0.01、无上限值、刚好等于上限值的情况。其次是异常预期结果要写具体不要只写系统不崩溃。比如骑手位置刷新失败超过三次页面提示位置更新延迟并提供重新加载按钮且用户仍可查看订单基本信息。这种具体的预期结果能体现你对用户体验的理解。还有一个很加分的细节在用例的末尾加一个风险与备注栏列出你暂时不确定的测试点、需要开发配合验证的接口逻辑、需要真实设备验证的弱网场景。这会让阅卷人觉得你有项目实战经验而不是只会做笔试题。我在实际面试中见过不少候选人就是因为用例里多了这一栏评价立刻上一个档次。4. 编程题算法之外测开更看重代码的严谨性4.1 笔试编程题的考察范围测开笔试的编程题通常比同场开发岗的题简单一档一般不会出现复杂的动态规划和图论常见的题型集中在数组、字符串、链表、二叉树这些基础数据结构上偶尔会出现一道排序算法的手写题。以我看到的同级别公司题目为例比较常见的有反转链表、判断括号是否有效、字符串中的首个不重复字符、两个有序数组合并、冒泡或快排的手写实现。整体难度约等于剑指Offer的入门到中等难度不需要刷大量hard题。重点是代码能一次写对变量命名规范逻辑边界清晰。4.2 容易被忽略的测试思维型编程题测开笔试编程题里有一种特殊题型值得单独说给你一段现成的代码要求找出其中可能存在的bug或者为这段代码设计测试用例。这种题比手撕算法更贴近测开的工作日常。举个例子题目可能给出一个函数功能是把字符串转换成整数然后要你分析哪里可能出错。如果你能答出输入为空字符串时可能抛异常、字符串包含正负号时应做特殊处理、整数溢出时应该返回特定值或抛错、字符串包含非数字字符时如何处理这些点就已经抓住了这道题的得分关键。你会发现这些点本质上就是在考察你平时给函数写单测时会不会覆盖边界条件。所以在备考时不仅要会写算法题还要养成看代码时主动思考这段代码会有什么边界问题的习惯。看到数组就想到空数组和越界看到字符串就想到空字符串和特殊字符看到整数运算就想到溢出和除零这些思维一旦内化笔试和面试都会很占优。4.3 编程题的临场发挥建议我当年踩过一个坑笔试平台只支持在线编译又没有本地IDE的自动补全手写代码时连类的import都容易写错。后来的经验是平时练习就直接在文本编辑器里写不开自动补全逼自己把常用的数据结构API记牢。还有一个建议编程题一定要先读清输入输出格式尤其是多行输入和以特定字符结束的输入最容易在格式上翻车。见过太多人算法思路完全正确却因为没处理输入结束条件导致只通过部分测试用例。如果平台支持多个测试用例一定要把边界值、空值、极端输入都当成测试数据来思考这就是测开岗的天然优势——你比纯开发候选人更懂怎么测试自己的代码。5. 从这场笔试倒推出来的测试开发学习路线5.1 基础期语言、数据结构和计算机功底如果现在离校招还有半年以上第一优先级是把一门编程语言学扎实推荐Python或Java测试行业这两者的生态最成熟。Python上手快写自动化脚本很顺手Java在大型后端和Android相关的测试环境里更常见。选定一门之后至少要把数组、字符串、链表、栈、队列、哈希表、二叉树这几种基础数据结构的增删改查写熟。同期要铺开计算机基础知识的复习覆盖计算机网络重点TCP/IP、HTTP、操作系统进程线程、内存管理、死锁、数据库SQL语法、事务、索引三门。这个阶段的目标不是刷题而是建立知识的完整框架。我当时是用每章读完画一张思维导图再挑出三五个高频考点用三层结构写一遍的方法来做积累的。5.2 理论期测试方法与设计思维具备编程基础之后开始系统学习软件测试理论。重点包括软件生命周期、测试流程与测试计划、测试用例设计方法等价类、边界值、因果图、场景法、正交实验、bug的生命周期与提交规范、黑白盒测试的区别。这部分内容不深但一定要能举例说明而不是只背定义。学习理论的同时要动手练习用例设计。找一个生活中常见的功能比如登录框、搜索框、购物车结算用五层框架把用例写出来再对着需求文档检查覆盖度。我当时每周坚持练两到三个功能练到后来看到任何功能脑子里会自动蹦出正常路径、异常分支、边界值、兼容性这些维度这个状态在笔试里非常重要。5.3 工具期从接口测试到自动化测试框架测开和功能测试最大的区别在于能用代码和工具代替人工重复劳动。所以工具链的学习是必须的。接口测试阶段要掌握Postman的基本用法、接口鉴权方式、常见状态码的含义再学会用JMeter做简单的接口压测和参数关联。UI自动化测试阶段要掌握Selenium或Appium的基本操作学会用pytest或TestNG编写自动化脚本。Linux命令和日志排查也需要同步学习。因为真实工作中测试环境的问题排查基本都要通过查看服务端日志来定位。至少要学会使用tail、grep、awk、top、free、df这些基础命令能读懂常见应用日志的报错信息。这块内容笔试里不会直接考操作但面试环节极大概率会问线上出现接口超时你会怎么排查这类问题。5.4 项目期用一个完整项目串起知识体系学完工具之后一定要做一个完整的测试开发项目。比如自己搭建一个简单的Web应用然后用Python的pytest框架为它编写接口自动化测试脚本接入Jenkins做每日定时执行测试结果通过邮件发送报告。做完这个项目你对接口测试、自动化测试、持续集成的理解会从碎片变成体系。这个项目对笔试的直接影响是简答题里遇到自动化测试的收益和挑战如何设计一套可持续维护的自动化用例这类话题时你不需要编答案直接讲自己项目里怎么做的包括遇到的坑和优化方案。这些真实经验远比背出来的八股更有说服力。6. 笔试踩坑实录这些细节每年都有人翻车6.1 时间分配不当导致崩盘我当年那个考场有个同学前40分钟全耗在选择题上结果最后编程题只剩20分钟一道都没写完整。这种崩盘方式几乎每年都有。笔试题量看着不大实则每道题都需要思考和书写时间非常紧凑。正确的策略是先用三分钟快速浏览整张卷子心里对题目难度有个排序。然后按先做有把握的题、再做分值高的题、最后啃硬骨头的顺序来。选择题每题控制在1分钟以内如果超过就跳过因为部分选择题的分值可能还不如一道填空题高。用例设计题和编程题才是拿分关键无论如何至少留50分钟给这两块。6.2 编程题死在边界条件上还有一类常见的翻车是代码逻辑本身没问题但边界条件全漏了。比如写数组排序后取中位数这道题很多人算好了有序数组的逻辑却忽略了数组长度为偶数时中位数应该取中间两个的平均值。在本地IDE里可能因为测试用例不够没有暴露但在笔试平台的判题系统里这几个边界用例一跑就挂了。平时刷题的时候我习惯对每道题额外想五个边界输入空值、单元素、已排序、全逆序、含重复元素。把这些情况在草稿纸上先跑一遍确认逻辑无误后再写代码。这个习惯考试时不一定能帮你做出难题但至少能救回一两道大方向对但边界全偏的题。6.3 用例设计题的隐藏扣分点很多人用例设计题写得不少但思路混乱想到哪写到哪。阅卷人看起来就很吃力。我的建议是动笔之前先在草稿纸上搭一个结构框架明确从功能、异常、边界、兼容性/性能、安全这五个维度分块去写每一块内部再按正常、异常、边界的顺序排列。另一个扣分点是用例预期结果写得太笼统。比如验证搜索功能正常系统不报错这类描述等于没写。正确写法应该是输入含空格的商品关键词点击搜索后页面展示匹配的商品列表且关键词中的首尾空格被去除。预期结果越具体说明你对功能的理解越深入阅卷人给的评价自然越高。6.4 笔试现场避开的一些杂项最后提醒几个杂项都是真实发生过的教训。第一看清笔试题的作答要求是要求写代码还是写伪代码是必须用指定语言还是不限定语言这直接决定你的答题策略。第二如果平台支持本地编译器尽量先在本机跑通再复制上去避免在线编译环境的各种诡异报错。第三简答题不要只写关键词阅卷是按点给分每个点最好用一两句话解释清楚但也不要长篇大论控制在三到五行为宜。还有一个小技巧笔试前把TCP/UDP对比表、HTTP状态码分类、SQL常用聚合函数、Linux基础排查命令、用例设计方法清单过一遍。这种目录式复习法比临时刷题有效得多因为笔试考的就是这些知识点的有无和准不准不需要你现场重新推理。回头复盘这整场笔试其实它考察的并不是单一能力而是把测试开发日常需要的知识、方法和工程素养浓缩到了一张卷子里。谁能用业务场景去理解这些考点谁就能在准备过程中少走很多弯路。测试开发这个岗位说到底是在代码和业务之间做翻译笔试只是这个翻译能力的第一次检验。