1. 这份试卷到底在考什么从试卷结构反推测试开发的能力模型2017年我还在准备校招的时候做过不少测试开发工程师岗位的笔试试卷爱数科技这份是印象比较深的。当时最直观的感受是它不是简单堆一套基础题而是有意识地用一张卷子把测试开发工程师这个岗位需要的能力边界画了出来。多年后再回头看这份试卷的价值已经超出了刷题本身——它其实是一个很清晰的岗位能力模型。很多人对测试开发工程师有误解觉得这就是会点点点、会写几个自动化脚本的岗位笔试随便准备准备就行。但这份卷子传递的信号完全相反它考计算机网络、操作系统、数据结构、编程语言、数据库、测试理论覆盖面非常广。因为测试开发工程师在一个团队里的真实角色是——既要有开发工程师的代码功底又要有测试工程师的批判性思维。你写的代码不是用来实现业务功能的而是用来验证别人写的代码是否可靠的所以你的基础必须比一般开发更扎实因为你面对的是系统里最容易被忽略的犄角旮旯。从试卷结构看这类校招笔试通常分几个板块选择题/填空题用来筛基础知识的掌握程度简答题用来考察理解深度编程题和时间允许情况下的测试用例设计题用来考察动手能力。爱数这份卷子里最有意思的部分是它把测试用例设计和代码阅读放在了一起。这种组合的潜台词是好的测试开发工程师既要能读懂代码背后可能出错的点还要能把这种判断转化成可执行的测试方案。这两件事看起来是一件事的两端实际是两种完全不同的思维模式能把这两种模式同时装进脑子里的人才是这个岗位真正想要的人。我当时做完卷子的体会是如果考前只刷算法题不补测试理论肯定会被用例设计题打懵如果只背测试理论不练代码题编程题也会很难看。这份试卷的难度不在于某一道题有多刁钻而在于它考验的是你知识体系的完整度。2. 计算机网络与操作系统测试开发笔试里的送分题与送命题2.1 TCP三次握手考的不是记住是画出状态变迁计算机网络是几乎所有测试开发岗位笔试的必考科目爱数这份卷子也不例外。TCP三次握手是高频中的高频但很多人的准备方式就是背下那句客户端发送SYN服务器回复SYNACK客户端再发ACK然后觉得稳了。等到试卷上换一种问法比如画出TCP建立连接过程中客户端和服务端的状态变化或者如果第三次握手丢了会发生什么就答不上来了。这里我建议所有准备校招的测试开发工程师复习TCP握手时不要只背交互流程要连状态一起记。客户端一开始是CLOSED主动打开后变成SYN_SENT收到SYNACK后变成ESTABLISHED服务端从LISTEN变成SYN_RCVD收到ACK后变成ESTABLISHED。这个状态迁移过程比三次握手本身更重要因为测试工作中你看到的客户端日志、服务端日志里都是状态和标志位不是抽象的交互对话。理解了状态你才能应付第三次握手丢包后服务端会重传SYNACK这类变体题也才能在工作后真正理解为什么线上会有那么多TIME_WAIT连接。为什么说它是送命题因为笔试里考TCP阅卷人不是要看你背得熟不熟而是看你有没有真正建立连接、排查过连接问题。如果能把状态迁移和重传机制答出来已经赢过一半的候选人了。2.2 进程线程与死锁从是什么考到怎么测操作系统板块里进程与线程的区别、死锁产生的四个必要条件互斥、持有并等待、不可剥夺、循环等待几乎是必考。爱数这份卷子在这部分没有出太偏的题但有一个细节我记得很清楚它把死锁和活锁的区别也列进了选项里。很多人只知道死锁不知道活锁笔试的时候看到这个选项就蒙了只能随手选一个。其实活锁对比死锁理解起来并不难死锁是多个进程互相等对方释放资源大家都不动活锁是多个进程都在主动让出资源给对方但因为步调一致导致谁也没拿到资源系统虽然一直在跑但跑不出任何结果。可以类比两个人迎面走过一条窄路两个人都往左边让发现还是碰上了又同时往右边让结果还是碰上——这种状态就是活锁。对这个概念有印象选择题就能保住分。顺便提醒一下死锁这部分经常和如何避免死锁一起考。比如银行家算法这个名字要认得出来能说出它是通过预判系统是否处于安全状态来避免死锁的鸵鸟算法就是遇到死锁直接忽略因为死锁发生的概率足够低处理它的成本反而更高。这些概念不需要深入源码级别但要知道它是干什么的因为它对应的是测试开发工程师在压测和并发测试时需要实际面对的问题——线上系统卡死到底是死锁还是性能瓶颈判断错了排查方向就全错了。2.3 从笔试到面试这些基础考点为什么反复出现有一个现象值得准备校招的人注意像TCP握手、进程线程、死锁这些考点笔试考完面试还会再问一轮。这不是面试官不出新题而是这些知识点本身就很难用—面试问答和笔试填空两种方式分别考察了不同的能力维度。笔试考的是广度你是否系统地学过这些基础课是不是科班出身不重要但这些知识你有没有接触过、听说过一张选择题就能筛出来。面试考的是深度面试官往往会追着某一个点往深里问比如你刚说完死锁的四个必要条件他马上问那你工作中遇到死锁怎么排查先看日志还是先看监控。这种问题没有标准答案考察的是你有没有真正把书本知识和工程实践连起来。所以我给准备笔面试的同学一个可操作的建议每复习完一个基础知识点都问自己一句——如果我是测试开发工程师这个知识点在我日常工作的哪一个场景里会出现TCP握手对应连接超时排查进程线程对应并发缺陷复现死锁对应数据库连接池耗尽。想清楚这个问题你从笔试到面试都会顺畅很多。3. 数据结构与算法笔试里真正拉开差距的部分3.1 排序算法怎么考稳定性、复杂度、手写实现一个都不能少数据结构与算法在测试开发笔试里的地位相比后端开发岗略有降低但也绝不含糊。爱数这份卷子在算法部分没有出特别难的动态规划而是把重点放在了排序算法上这在当年校招笔试里是很有代表性的选择。排序题最常见的考法有三种第一种是选择题问下列排序算法中哪些是稳定的——这里要记住关键结论冒泡、插入、归并是稳定的选择、快排、堆排是不稳定的。第二种是简答题让写出某个排序算法的时间复杂度和空间复杂度以及最好最坏情况。第三种就是手写代码让你实现快速排序或者归并排序。手写排序算法的时候有一个很多人会忽略的失分点代码里没有处理空数组和单元素数组的边界情况。比如写快排的递归实现如果数组长度小于等于1就直接返回很多人会漏掉这个判断导致递归死循环或者越界。这种错误在笔试里其实比算法本身不对更可惜——逻辑是对的因为边界没处理好被扣分甚至直接判错。所以我在准备阶段就养成一个习惯任何手写代码题不管题目要不要要求都把边界条件写在最前面。这是程序员的基本素养阅卷人看到这种代码也会觉得你平时写代码是有规范意识的。3.2 树的遍历与递归转迭代考的是代码功底除了排序树的遍历也是测试开发笔试的高频题。前序、中序、后序、层次遍历这些概念本身不难但爱数这类的卷子往往会加一个进阶要求用非递归方式实现某种遍历。递归转迭代核心是显式地用栈来模拟函数调用栈。以中序遍历为例递归写法是先遍历左子树再访问根节点最后遍历右子树改写成迭代的时候逻辑是定义一个栈当前节点不为空或者栈不为空就循环先把当前节点一路压栈往左走到底然后弹栈访问节点再把指针移动到右子树。这个思路看起来简单真到手写代码的时候很多人会在指针为空时该pop还是该继续push这种地方卡住写出来的代码逻辑绕来绕去自己都说不清楚。我建议复习的时候把递归和迭代版本对比着写不要只看不练。笔试考场上时间紧练熟了才能形成条件反射。另外这段代码在测试开发实际工作中也是有用的——你在做自动化测试的时候如果把测试用例的组织结构理解成一棵树遍历这棵树的逻辑就是你自己写的那时候你就会感谢当年在笔试里狠狠练过的非递归遍历了。3.3 手写代码的共性套路边界条件比主逻辑更容易丢分整理了一下测试开发笔试里的手写代码题不管题目是排序、遍历还是字符串处理失分点其实高度集中在几个地方第一是边界条件也就是空输入、单元素输入、超长输入。第二是参数合法性校验很多人一上来就写核心逻辑完全不检查入参是不是null这种代码在真实工程里是要被code review打回去的。第三是算法的退化情况比如快排在数组已经有序时时间复杂度会退化到O(n²)有些笔试会专门问怎么优化如果你能答出随机选取基准值或者三数取中就是明显的加分项。第四个失分点比较隐性注释和命名。笔试阅卷人一天要看很多份卷子如果你的变量名都是a、b、c函数名是f就算逻辑对了阅读体验也很差。反过来用mergeSort这种名称、用left和right命名左右指针阅卷人扫一眼就能看懂你的思路这种程序员的界面友好度也是能实际影响分数的。大家别觉得这是小事在测试开发岗位里你写出来的用例和脚本是给整个团队维护的可读性本来就是职业素养的一部分。4. 编程语言与数据库测试开发的双料基本功4.1 面向对象与代码阅读考的其实是描述测试对象的能力爱数这份试卷的编程语言部分没有死板地考语法细节而是用了一种很有测试开发特色的方式给一段代码让考生指出其中可能存在的问题。这种题在普通开发岗笔试里很少见但在测试开发岗位的卷子里非常合理——因为找Bug本来就是测试开发日常工作的核心方式之一。我记得其中一道题和面向对象相关大致是给了一个类里边的字段直接用public暴露外部代码可以直接修改对象内部状态。这种设计在功能上没问题但在面向对象的角度存在封装性问题。做测试的同学如果对设计模式有了解就会意识到字段直接暴露意味着对象的内部状态无法被有效约束任何外部代码都可以绕过类的行为逻辑去改数据这会导致系统的可维护性和稳定性下降。这个考点背后藏着测试开发工程师的一个重要视角你不仅要知道代码能不能跑还要知道代码好不好改、容不容易出错。测试用例设计本质上是在描述被测对象的各种状态和行为如果你的被测对象本身封装得不好、状态很容易被外部意外修改你的测试用例就会变成一个永远填不满的坑。所以笔试里考面向对象考的不是概念背诵而是你在设计测试方案时能不能一眼看穿代码的结构性风险。4.2 找Bug题这种题目最接近真实工作当时卷子里有一类题让我印象很深给定一段代码找Bug并说明理由。这种题没有标准答案但非常能反映一个人的代码功底和测试思维。比如有一道题给出了一个数组去重函数代码本身逻辑看起来没有大问题但如果你仔细看就会发现它用了一个很隐蔽的方式比较元素导致在大数据量下性能很差——这就是一个功能性Bug之外的性能Bug。在真实测试工作里性能问题往往比功能问题更难发现因为它不会直接报错而是让系统慢慢变慢、用户体验逐渐变差。测试开发工程师的职责之一就是要有能力在代码审查阶段就嗅出这类隐患。所以这种题目表面上在考代码阅读实际上在考察你有没有性能意识、有没有工程经验。面对这类找Bug题我给一个答题框架先看功能逻辑有没有错再看边界条件有没有处理再看性能有没有隐患最后看代码风格和可维护性。按这个顺序作答即使你找到的不是阅卷人预设的那一个Bug整个答题过程也会显得专业且有层次不容易丢分。4.3 数据库与数据一致性数据管理公司的隐藏考点爱数科技的背景是数据管理所以它的试卷里数据库相关的题目比重比一般公司要高这一点我当时就注意到了。数据库方面考了几种常规操作比如SQL的增删改查和分组统计这些都是基本功。但更有区分度的是它涉及了数据一致性的概念比如事务的ACID特性、脏读、不可重复读、幻读这些隔离级别相关的问题。很多非科班出身或者基础薄弱的同学看到事务隔离级别就头疼觉得离自己太远。但对测试开发工程师来说这个知识点非常重要你在测试一个涉及数据库写入的功能时如果不理解事务的隔离级别就很难解释为什么高并发下会出现数据对不上的问题。比如两个并发事务同时更新同一行数据如果你的测试结论是功能没问题但线上生产环境的高并发场景下出现了数据错乱那这个测试就是失职的。准备这一类知识点我建议不要死记硬背四种隔离级别的定义而是用并发问题这个主线把它们串起来读未提交会脏读读已提交解决脏读但不可重复读可重复读解决不可重复读但可能幻读串行化解决所有但性能最差。理解了这条演进线笔试里不管怎么变着法子问你都能找到答案的落点。5. 测试理论与用例设计有没有测试思维一题见分晓5.1 等价类划分与边界值老生常谈但答法有高下如果说前面的基础科目考的是你会不会写代码那测试理论部分考的就是你会不会做测试。爱数这份试卷的测试理论题出得很有水平它不考概念定义而是给一个具体场景让你设计测试用例。这种题型哪怕到现在也是各大厂校招笔试的主流考察方式。等价类划分和边界值分析是两种最基础的测试设计方法几乎一定会考到。但答法是有高下的。低分答法是把有效等价类和无效等价类列出来就完事了高分答法会再补充边界值——比如一个输入框要求1到100之间的整数除了划分有效等价类1-100和无效等价类小于1、大于100、非整数、空值还要单独去测0、1、100、101这四个边界点因为实践证明错误最容易发生在边界附近。还有一个很多人容易漏掉的地方有效等价类本身可能是无穷多个的你不能穷举所以你需要从有效等价类里选几个有代表性的数据而不是以为所有有效数据都一样。比如1到100的整数你要测50这个中间值也要测1和100这两个边界值。这背后的逻辑是即使在同一个等价类里边界附近的行为也可能和中间区域不同。把这一层说出来阅卷人一眼就知道你是真的理解这些方法而不是背了书上的定义。5.2 一道登录功能的测试用例怎么答出层次感我记得这份卷子里有一道很经典的场景题设计一个登录功能的测试用例。很多同学看到这种题就兴奋觉得太简单了噼里啪啦写了几十条用例比如输入正确的用户名和密码登录成功输入错误的密码提示错误等等。但这样的答案得分往往不高因为它没有层次。高分的答题思路应该是分层的。第一层是功能测试正确的账号密码能登录、错误的账号密码不能登录、密码大小写敏感、账号不存在、账号被锁定等。第二层是界面测试输入框是否支持复制粘贴、密码是否掩码显示、错误提示文案是否友好等。第三层是安全测试是否支持SQL注入、密码是否明文传输、登录失败多次后是否有防暴力破解机制等。第四层是兼容性和性能测试不同浏览器是否正常、高并发下登录接口的响应时间等。为什么同样的题目、同样的知识点有人得分高有人得分低因为测试用例设计的本质不是尽可能多地列用例而是用最少的用例覆盖尽可能多的风险。分层作答能让阅卷人看到你的思维模型——你脑子里有一个完整的测试维度框架而不是东一榔头西一棒子地瞎凑。这个能力就是测试开发工程师区别于普通测试员的核心竞争力。5.3 从笔试看测试开发与功能测试的区别多说一句既然标题里有测试开发工程师这个岗位名我想聊聊笔试里体现出来的岗位定位差异。功能测试的笔试通常更侧重于测试理论和业务理解而测试开发工程师的笔试明显更偏向开发能力测试思维的融合。这一点从爱数这份卷子的题型比例就能看出来代码题占了很大一块测试用例设计题也要求你在有限时间内用结构化方式作答纯粹的找Bug题更是在暗示这个岗位的核心职能是理解代码、发现问题、用代码解决问题。对一个校招新人来说想清楚这个岗位定位很重要。如果你只是喜欢测试两个字而不喜欢写代码那测试开发工程师这个岗位可能并不适合你。反过来如果你享受用代码构建测试工具、用脚本自动化解放手工劳动、从代码层面推动产品质量提升那这个岗位给你的成长空间会非常大。笔试只是第一道门它筛的就是那些真正理解这个岗位双重属性的人。6. 复盘之后的几点体会笔试准备不要太功利试卷复盘到这里很多核心考点都聊透了。但抛开具体的题目不谈我对这份试卷最大的感受其实是它提醒了我一件事面试准备不能太功利。很多人准备校招笔试的方法是搜面经、刷题库、背结论这确实能帮你通过一部分选择题和简答题但到了代码题和用例设计题如果没有真正理解背后的原理临时抱佛脚是抱不出来的。因为像这段代码哪里有Bug和这个功能你怎么测这种开放题考的不是记忆而是平时积累的思维习惯。你平时写代码的时候有没有边界意识你看别人代码的时候有没有质疑精神你测一个功能的时候有没有维度框架这些都不是考前突击能改变的。所以我给后来人的建议是从准备校招的第一天起就把自己当成一个真正的测试开发工程师来要求。写代码的时候多问自己一句这个函数的边界情况处理了吗看别人的代码时多问一句如果这里面有Bug最可能藏在哪测功能的时候多问一句除了正常路径还有哪些异常路径——带着这三个问题去学习和练习你不仅能通过笔试和面试更重要的是入职后的第一个月你会比同期新人更快进入状态。最后分享一个小技巧是我当年笔试后养成的习惯每次做完一套笔试试卷不管结果如何都把错题和卡壳的题目整理成一个文档按基础知识类、算法类、测试设计类分类然后把正确答案背后的原理用自己的话写一遍。这个习惯帮我撑过了整个校招季到现在我做技术分享和带新人的时候偶尔还会翻开当时的笔记看到那些当年搞不明白后来彻底想通的知识点会觉得那段准备时光特别值。