“小满”这个内部代号，指的是我们部门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；接口层适合对业务接口做自动化回归，框架选pytest+requests，配合allure做报告；UI层成本最高、稳定性最差，只适合核心主流程的冒烟测试，框架可选Selenium或Playwright。能写出UI自动化的维护成本是接口自动化的数倍、ROI更低，这道题基本就拿捏了。
有人写“我们项目适合Appium做App自动化”，这没问题，但需要你补充一句为什么——是App的业务占比高，还是跨端需求频繁，或者是为了配合CI做云测机集群。没有理由的工具选型就是堆名词。
简答题是整张卷子里最能看“经验感”的部分。知识可以突击，选择题可以刷，但简答题里的思维框架和边界意识，需要你真正做过事、踩过坑、总结过。这种软实力，恰恰是笔试筛人的第一道滤网。
4. 编程题复盘：代码颜值和边界处理是隐形评分项
编程题是两题，一easy一medium，时间90分钟。说实话，这个时间和题量，压力不大，重点考察的不是你算法多强，而是你写出来的代码够不够干活标准。
4.1 第一题：合并两个有序数组
第一题是经典的原题变体：给定两个升序排列的整数数组nums1和nums2，合并为一个升序数组，并要求空间复杂度为O(1)。题目附带了一个前提：nums1的长度是m+n，前m个是有效元素，后面n个位置是预留空间。
很多人的解法是从前往后合并，这会导致元素覆盖，必须额外开数组。而正确的思路是从后往前填充——因为nums1尾部预留了空间，从后往前比较两个数组的尾部元素，大的放到nums1尾部，这样就不会覆盖还没处理的元素。这个解法空间O(1)，时间O(m+n)。
我批卷时发现有意思的现象：很多人能写出正确的双指针代码，但代码里有一些细节问题。比如边界条件写错了，把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行是最低标准，写上关键术语和思考过程才会得到认可。
笔试中遇到不会的题，别急着放弃。先写下你的理解框架，哪怕结论是问号，也要展现思路。测开的活水就是解题思路，思路本身就是最重要的工作能力。
最后，如果你已经走到了准备笔试这一步，说明你对测试开发岗是有真实兴趣的。这个岗位不轻松，质量责任大、技术栈杂、沟通成本也不小，但它是很少见的能把“写代码”和“守护产品底线”结合起来的工作。笔试只是第一道窄门，跨过去之后，你会看到一个完全不一样的技术世界。加油。
