测开笔试考点拆解：从命题视角看测试开发岗如何准备

“小满”这个内部代号指的是我们部门2023年春季启动的应届生招聘。我作为技术面试官之一参与了第一批笔试的出题和阅卷。批完卷子之后一直想写点什么拖到现在才动笔。一是因为这批卷子暴露出的问题非常典型值得后来者参考二是因为测试开发岗的笔试和纯开发岗、纯测试岗都不一样很多人在准备时完全跑偏了方向。这篇文章没有标准答案也没有原题复述而是从命题人的角度拆解一份测试开发岗笔试在考什么、为什么考这些、以及你该怎么答才能命中考察点。如果你正准备投测开岗或者对“测开到底做什么”还比较模糊这篇值得仔细看完。1. 笔试前夜我重新理解了测试开发岗先说一个背景。我所在的团队做的是基础质量平台服务的对象是公司内部几十条业务线。测开岗的日常工作不只是一行行写自动化脚本也不只是点点点找bug而是用工程化的手段去解决质量保障问题——可以是自动化测试框架的开发可以是性能压测平台的建设可以是CI流水线里的质量卡点也可以是线上监控数据的产品化落地。这个岗位画像直接决定了笔试的出题方向。纯开发岗笔试侧重算法和系统设计因为它要的是能独立扛需求的人纯测试岗笔试侧重用例思维和业务理解因为它要的是能读懂需求、把质量边界划清楚的人。测开岗要的是两者交集之上再叠加一层工程落地能力你既要有开发者的代码功底又要有测试者的怀疑精神还得有把想法变成工具的工程意识。所以这份笔试卷子的结构从一开始就不是按“考你多少知识”来设计的而是按“你在真实工作中会遇到什么问题”来设计的。整张卷子分四个部分客观题、简答题、编程题、测试设计题。四个部分对应四个能力维度知识储备、表达能力、编码落地、测试思维。批卷时发现得分分布非常有规律。基础扎实的同学客观题和编程题不会差但简答题往往写得单薄思维活跃的同学测试设计题能写出花来但编程题边界处理一塌糊涂。真正高分的人四块都均衡且每块都能超出“及格线”一点点。这也是我想先说的第一件事准备测开笔试千万别只刷LeetCode也千万别只背测试理论。你在这张卷子上看到的每一道题背后都是在模拟一个真实的工作场景。你得站在“我将来是要用代码和工程手段解决质量问题的人”这个位置去答题而不是站在“我是一个学生我来考试”的位置。2. 客观题的坑考察范围之广远超你的想象第一部分的客观题三十道涵盖编程语言、数据结构、操作系统、网络、数据库、Linux、测试基础理论。很多人觉得这部分就是送分题实际上笔试分数段的第一个大分水岭就在这里。2.1 编程语言别只盯语法多想想运行机制语言题里有一道很典型的Python中列表和元组的本质区别以及分别在什么场景下选择哪个。这个题目本身不难但很多人在“什么场景下选择哪个”上答不完整。有人只写“列表可变元组不可变”然后就没有然后了完全没提性能差异和哈希场景。实际上元组因为不可变可以被哈希能作为字典的key这是工作中一个非常实用的特性。写代码时如果你需要把一组固定配置传给函数且不希望被改动用元组比用列表更安全。另一道更刁钻一点Python默认参数会不会被多个调用共享。这道题考察的是对函数定义时默认参数求值机制的理解。工作中写接口自动化框架时经常遇到这个问题如果你定义函数用了可变对象作默认参数第二个调用就会拿到第一次调用改过的脏数据这种bug排查起来极其隐蔽。批卷时看到不少人是知道这个机制的但说不清楚底层原理——为什么会共享因为函数定义时默认参数就已经被求值并绑定到函数对象上了而不是每次调用时重新求值。Java和C也会考但比重低一些毕竟团队主流栈是Python和Go。如果你是Java选手也不必慌核心考点仍然是语言特性和运行时机制比如Java里HashMap在并发场景下的问题Go里goroutine和channel的基本用法。这些都是团队日常开发真会用到的东西不是课本上的死知识。2.2 网络和数据库背八股没用得能解决实际问题网络题基本围绕HTTP协议展开。有一道题目是一个接口偶发超时请列出你能想到的排查步骤。这已经是场景题了但放在客观题里以选择形式出现。选项里有“查看服务端日志确认慢调用”“在客户端抓包看耗时分布”“直接重启服务”“检查数据库连接池配置”之类。有人选了“直接重启服务”这在应急时可以理解但它不是排查手段是规避手段。批卷时这道题目的选择情况基本能反映一个人有没有线上排查经验。数据库题也很有意思。有一道是给出一张订单表和一张商品表让你用一条SQL查出销量前10的商品。这个难度中等考察的是基础SQL编写能力连表、分组、排序、limit。大部分人都写对了但有个细节很多人没注意——销量是按什么维度算的是订单量还是商品件数。题目里明确写了“销售件数”但有人直接在订单表上做count(order_id)完全忽略了订单里可能有多个商品、每个商品可能买多件。你写的SQL必须对得上业务口径这也是工作中最常踩的坑。还有一道索引题一条慢查询WHERE里有两个条件ORDER BY一个字段你该怎么建索引。选对的人不多。很多人知道联合索引最左前缀但不知道排序字段怎么参与索引设计。实际上在无法做到索引覆盖排序的情况下MySQL会在拿到结果集后做filesort如果结果集很大性能就很差。把排序字段也纳入联合索引的末尾让它走索引排序往往是更优解。这种题没有标准答案考察的是你有没有索引优化的实战意识。2.3 操作系统和Linux查日志、看资源、定位进程客观题里操作系统占比不高但必考。今年考了进程和线程的区别、死锁的四个必要条件、虚拟内存的作用。都是经典概念题不算难但要把四个必要条件默写完整有人只写了三个就丢了分。顺便说一句死锁题我在面试时的追问频率也很高因为并发场景在测试平台开发里太常见了你写一套任务调度系统如果对死锁没有概念迟早要出事。Linux题则非常务实统计一个日志文件里出现次数最多的IP、查找某个进程的PID并杀掉、把一个目录下所有超过100M的文件列出。这些命令在工作中每天都会用到。有人连awk和grep的配合都不熟悉这会让面试官对你有很大顾虑——你连服务器都玩不转怎么去做接口测试、怎么去排查问题客观题部分的整体评分逻辑不是看你对了多少道而是看你的知识结构分布是否合理。测开岗要的技能栈就是广而杂你不需要每一样都精通但每一样都不能是完全空白。就像建一栋楼客观题打的是地基地基不牢后面编程题和测试设计题答得再好也免不了被质疑“基础不扎实”。3. 简答题的命题逻辑考的不是背诵是边界意识十几道客观题之后是四道简答题。这四道题我印象很深因为很多人的差距就在这部分被拉开的。简答题没有绝对的标准答案考察的是你思考问题的维度和边界感。3.1 POST和GET的区别别只答“GET参数在URL上”第一道简答题是“简述POST和GET请求的区别并说明在接口测试中分别需要注意什么”。这题老套吗老套。但能答好的人不多。常规区别比如GET参数在URL上、POST在body里几乎人人都会写。但“在接口测试中分别需要注意什么”这个角度答好的人骤降。GET请求需要注意URL长度限制、参数会被日志记录导致敏感信息泄露、幂等性设计POST请求需要注意Content-Type的选择form还是json、body的序列化与反序列化、请求体大小限制、服务端对重复提交的处理。只有这些写到点上才说明你不是背概念而是在真实接口测试中踩过对应的坑。这道题我在阅卷时最看重的一个词是“幂等”。GET应该是幂等的POST不保证幂等这个理解会直接影响到你在写接口自动化用例时怎么设计测试数据、怎么判断断言结果。能写出“幂等”二字的卷子至少说明这个人有接口测试的基本功。3.2 如果你来测试一个登录功能你会怎么设计测试用例第二道简答是一个典型的测试设计题登录功能。这个题目在面试里也几乎必问笔试考它是想看你在没有对话引导的情况下能不能独立地把一个功能拆解成一套完整的测试方案。很多人写的是输入正确的用户名密码能登录输入错误的用户名密码提示错误密码为空提示不能为空用户名不存在提示用户不存在。然后就没了。你写这东西面试官第一反应是这个人没有做过测试。正确打开方式是分层次作答。功能层面要覆盖正常登录、错误密码、用户不存在、账号锁定、密码过期、多终端登录互踢、记住密码、自动登录安全层面要覆盖SQL注入、暴力破解、验证码机制、密码传输是否加密、登录态Token的失效机制异常层面要覆盖网络超时、服务端5xx、数据库连接失败时前端如何提示、弱网下的重试机制兼容性层面要覆盖不同浏览器、不同操作系统、不同分辨率。如果你还能写上“登录接口的并发测试同一账号同时多处登录服务端怎么处理”那这道题的得分就会明显拉开。3.3 一个线上bug的完整处理流程第三道简答是线上发现了一个紧急bug描述你的处理步骤。几乎每个人都会写“先复现然后定位原因修复验证上线”。这是骨架但少了血肉。加分的步骤包括第一时间评估影响范围——这个bug影响多少用户、影响哪些核心功能、有没有绕过方案必要时先临时下线功能或切流量止血永远在定位之前复现时注意记录复现条件、环境信息、操作路径、以及线上和测试环境的数据差异定位时先查日志和监控而不是直接看代码修复后要补回归用例并复盘为什么测试阶段没发现是漏测、用例设计问题还是环境数据差异。有一个高频误区是很多人写“先回滚代码”。回滚不是第一选择因为如果数据库结构已经变更回滚代码可能引入更多不一致。线上的正确处理是评估、止血、定位、修复、验证、复盘这个顺序本身就是工程经验的体现。3.4 自动化测试的适用场景与框架选型第四道简答是你们项目适合做自动化测试吗如果适合你会选择什么框架这题考察的是对自动化测试价值的理性认知而不是盲目追新。回答的要点是分层。单元测试层适合对核心算法、工具函数做自动化框架选pytest接口层适合对业务接口做自动化回归框架选pytestrequests配合allure做报告UI层成本最高、稳定性最差只适合核心主流程的冒烟测试框架可选Selenium或Playwright。能写出UI自动化的维护成本是接口自动化的数倍、ROI更低这道题基本就拿捏了。有人写“我们项目适合Appium做App自动化”这没问题但需要你补充一句为什么——是App的业务占比高还是跨端需求频繁或者是为了配合CI做云测机集群。没有理由的工具选型就是堆名词。简答题是整张卷子里最能看“经验感”的部分。知识可以突击选择题可以刷但简答题里的思维框架和边界意识需要你真正做过事、踩过坑、总结过。这种软实力恰恰是笔试筛人的第一道滤网。4. 编程题复盘代码颜值和边界处理是隐形评分项编程题是两题一easy一medium时间90分钟。说实话这个时间和题量压力不大重点考察的不是你算法多强而是你写出来的代码够不够干活标准。4.1 第一题合并两个有序数组第一题是经典的原题变体给定两个升序排列的整数数组nums1和nums2合并为一个升序数组并要求空间复杂度为O(1)。题目附带了一个前提nums1的长度是mn前m个是有效元素后面n个位置是预留空间。很多人的解法是从前往后合并这会导致元素覆盖必须额外开数组。而正确的思路是从后往前填充——因为nums1尾部预留了空间从后往前比较两个数组的尾部元素大的放到nums1尾部这样就不会覆盖还没处理的元素。这个解法空间O(1)时间O(mn)。我批卷时发现有意思的现象很多人能写出正确的双指针代码但代码里有一些细节问题。比如边界条件写错了把i 0 j 0写成i 0 j 0导致第一个元素漏处理比如最后没有处理nums1已经遍历完、nums2还有剩余的情况比如函数参数命名是a、b、i、j完全不看题目给的语义化命名。测试开发的代码是给机器跑的更是给人看的。你写的自动化用例、框架代码、工具脚本会被团队其他成员review、维护、扩展。如果你的代码可读性差、边界处理粗糙在团队里就是个灾难。所以这道题不光是算法题也是“你的代码是否具备工程素养”的试金石。4.2 第二题字符串中第一个不重复字符第二题是给定一个只包含小写字母的字符串s找到并返回第一个不重复字符的索引如果不存在返回-1。可以用两次遍历第一次统计频率第二次找第一个频率为1的字符。也可以用哈希表存索引一次遍历搞定。这道题Easy难度但很多人在返回值的处理上翻车了。有人返回的是字符本身不是索引题目要求是索引有人没有考虑大小写混合的情况虽然题目说了只含小写字母有人用Python里的str.count()方法对每个字符扫一遍整个字符串复杂度O(n²)在这个题的数据规模下不会超时但不是最优解。批卷时这类题我还会额外看一个东西你有没有写测试用例。题目没要求提交测试用例所以绝大多数人没写。但那些写了测试用例的人我给了更高的印象分。哪怕只是在代码注释里写几个断言比如assert func(leetcode) 0、assert func(aabb) -1、assert func() -1都说明这个人有测试开发该有的自我验证意识。4.3 编程题的隐形评分规则编程题不是只跑用例跑通就能得满分。阅卷是人工自动相结合人看的维度大概有四个思路是否清晰有没有写注释解释关键步骤代码风格是否规范命名是否语义化函数长度是否可控边界是否考虑完整空数组、极端值、特殊输入有没有覆盖复杂度是否合格有没有更优解。有人把LeetCode上背的模板原样写出来连变量命名都是一模一样的这种一眼就能看出来。你要是真能把思路讲明白把代码按照规范的工程风格写出来比雷同的模板解法更能拿分。编程题的核心与其说是考算法不如说是考你“像不像一个靠谱的写代码的人”。测开要把测试需求变成自动化工具代码质量直接决定了工具能不能被团队用起来、能不能持续维护下去。这个隐性标准在笔试时就有了苗头。5. 测试设计题一场没有标准答案的场景推演最后一道大题分值最高没有一个固定答案但几乎所有人都知道自己答得好不好——题目是为一个电商App的商品搜索功能设计测试方案。这题我给所有人的时间都是25分钟答案形式不限。5.1 拿到题目先做需求分析而不是先写用例很多人看到题目就直接开始列用例“输入关键词点击搜索显示结果”。这是最大的误区。测试设计的第一步永远是需求分析——你连功能的边界都没搞清楚就急着写用例写出来的东西一定是散的。这道题我会看你有没有先定义“商品搜索”的功能范围。比如是否包含关键词联想、搜索历史、搜索推荐、筛选排序、分页加载、空结果处理、网络异常处理。如果你把这些子流程在开头梳理一遍后面的用例才是成体系的。没有这个梳理过程直接列五十条用例反而显得思路不清晰。5.2 我期待的答题框架从业务场景到异常边界的四层覆盖第一层是功能维度。关键词命中标题、命中品牌、命中分类的搜索分词逻辑、多关键词空格分隔、大小写混合输入精确搜索和模糊搜索的策略差异搜索结果的排序规则综合排序、销量排序、价格排序的交互逻辑筛选条件和关键词的组合搜索分页加载与滑到底部自动加载更多的交互。第二层是数据维度。空关键词时前端是否拦截还是直接发请求超长关键词比如100个字符是否截断或提示特殊字符比如HTML标签、SQL关键字、Emoji是否会引发异常纯空格、特殊符号、不存在的关键词结果页如何展示搜索到数万条结果时分页是否正常搜索关键词有大小写、繁体简体差异时底层是如何归一的。第三层是异常与兼容维度。弱网、断网、超时时前端提示与重试机制是否合理服务端返回500、504时页面是否崩溃后端数据为空时是展示空状态还是报错iOS和Android双端行为是否一致不同分辨率、不同系统版本下搜索框UI和结果布局是否异常。第四层是性能与安全维度。关键词输入时前端是否有防抖还是每敲一个字符就发一次请求搜索接口的响应时间在弱网下的表现并发搜索时服务端的稳定性搜索关键词是否会被记录、脱敏展示有没有SQL注入或XSS攻击的防护。这四层不是孤立的。你在产品中真实看到过的问题、在业务方反馈中听到过的case能对上哪一层就补充到哪一层。测试设计题从来不考“你把用例写得多么全”而是考“你有没有一套自己的拆解逻辑并且用这套逻辑把一个不知道的东西拆明白”。5.3 你为什么总觉得用例写不完很多人写这种题的时候会越写越虚。写完功能部分感觉还有筛选没写写完筛选感觉还有权限没写写完权限又冒出数据上报没考虑。最后交上去的答案变成了一锅粥。怎么应对我给一个这些年实际在用的方法论先列维度再列场景最后补边界。维度是方向比如功能、数据、异常、兼容、性能、安全场景是每个维度下的具体业务操作比如“输入关键词点击搜索”就是一个场景边界是这个场景的极端情况比如“关键词超长”“断网重试”“结果为空”。你只要把提纲列清楚每一层往下想几个真实场景再补一两个极端边界这道题的结构就完整了。写得简洁清晰远胜于列50条没有分类的碎片用例。这道题没有标准答案但高分答案有一个共同特征有层级、有场景、有异常推导过程而不是写成一张单纯的功能确认清单。你写的不是用例大全而是一个测试工程师的思维过程。6. 从笔试看测开岗的真实工作方式笔试结束后我作为出题人把整张卷子的考察点和工作场景做了一次对齐。落到一句话就是测试开发不只是一个写脚本的岗位它是用工程手段解决质量问题的岗位。那些能通过笔试的人往往是已经能在自己的项目里用代码解决问题的人而不是只会刷题和背概念的人。6.1 知识技能地图笔试之外你还需要什么笔试只能覆盖全部能力中的一部分结合团队实际工作我建议准备测开的同学在笔试之外再认真打磨这几项第一接口自动化测试的完整闭环。从接口文档的理解、造数、断言设计、数据清理到CI集成、报告输出、失败重跑每一步你都要亲手做过。笔试只能考你分析能力但真正工作中的测试框架搭建需要的是实打实的代码能力。第二排查问题的思路和手段。线上bug了怎么查日志怎么定位数据库慢查询怎么分析监控指标怎么界定。笔试里的简答题只是入门真正的战场复杂得多。多去练习排查你才能在面试聊case时不虚。第三对被测系统的理解能力。很多同学会测但不会想只关注功能逻辑不关注业务价值。测试设计题里如果你能写出“搜索结果为空时前端要展示推荐商品而不是空页面因为这会直接影响转化率”面试官会觉得你是有业务sense的人。第四代码能力不能丢。测开虽然不像纯开发那样硬核考算法但代码质量、工程规范、工具落地能力是底线。写出来的框架要好维护、好扩展、好上手而不是只会堆代码。6.2 给下一届的备考建议先说结论时间富裕的话走“项目刷题复盘”三条线并行时间紧张的话优先把手头的一个测试项目吃透用真实作品说话。项目怎么选不要选那种烂大街的“图书管理系统的自动化测试”。挑一个能体现思考和深度的方向比如“针对订单系统的接口自动化测试平台”说明白你怎么设计断言、怎么处理数据依赖、怎么和CI打通、怎么定位失败用例。在笔试的测试设计题里把项目里踩过的一个坑揉进去比如“我们的订单状态机有流转限制测试时需要构造多步骤的数据链这个很坑”立马会让阅卷人觉得你有实战经验。笔试形式上很多人不习惯手写场景题建议提前在纸上模拟不依赖编辑器自动补全和语法提示把代码写清楚、写准确。另外简答题作答时不要太简短写3-5行是最低标准写上关键术语和思考过程才会得到认可。笔试中遇到不会的题别急着放弃。先写下你的理解框架哪怕结论是问号也要展现思路。测开的活水就是解题思路思路本身就是最重要的工作能力。最后如果你已经走到了准备笔试这一步说明你对测试开发岗是有真实兴趣的。这个岗位不轻松质量责任大、技术栈杂、沟通成本也不小但它是很少见的能把“写代码”和“守护产品底线”结合起来的工作。笔试只是第一道窄门跨过去之后你会看到一个完全不一样的技术世界。加油。