2017年秋天我投了爱数科技的测试开发工程师校招岗。笔试在一个周六下午进行线上答题一共90分钟题型分选择、简答、编程三块。那时候“测试开发”这个概念在校园招聘里已经是热门方向不少同学一边刷LeetCode一边背测试理论但拿到卷子才发现这张卷子考的东西比想象中更“全栈”有网络协议、有操作系统、有SQL、有测试用例设计甚至还有数据库索引优化。今天回头看这套题几乎就是测试开发能力模型的缩影。这篇文章不是简单把题目列一遍而是想借这套试卷聊聊测试开发工程师到底考什么、面试官想通过题目看到什么以及如果你是今年准备投测试开发岗位的同学应该怎么准备。无论你是科班出身还是半路转行只要目标是测试开发这套题的拆解思路都能直接用上。1. 试卷整体结构与考点分布1.1 笔试考了哪些题型为什么这样设计爱数科技当年的试卷我印象里分四大块单选题、多选题、简答题、编程题部分题目还会结合场景出成填空或者改错。整体结构大致可以归纳为下面这张表题型题量分值占比考察重点单选题20题左右30%计算机网络、操作系统、数据结构、数据库基础多选题10题左右20%边界情况、多知识点交叉、对概念理解的准确性简答题4-5题25%测试用例设计、测试流程、Linux命令、SQL编写编程题2-3题25%代码能力、边界条件处理、算法基本功这套结构放在今天看依然很经典。单选题覆盖“广度”用最小的成本筛掉基础不牢的人多选题是想看你对概念是不是真懂因为多选错一个就全错比单选更能暴露“背答案”的情况简答题则是考察你能不能把脑子里的测试思维落到纸面上尤其是测试用例设计题几乎是所有测试岗位笔试的必考项编程题则是在区分“只会点测试、不会写代码”的人测开发招聘的核心就是“能写代码的测试工程师”。还有一个容易被忽略的点试卷没有考特别深的算法比如动态规划、图论之类基本没出现。这说明企业招测试开发时并不指望应届生一上来就是算法高手而是希望你有“能把功能测透”的逻辑能力同时具备必要的代码功底去写自动化、做工具、分析日志。这点和开发岗的笔试有明显区别。1.2 从考点倒推测试开发岗位的能力模型如果把这张试卷的所有题目按能力归类你会看到三条清晰的线第一计算机基础包括网络、操作系统、数据库这是你排查问题、分析Bug时必须具备的底层知识第二测试专业能力包括用例设计、测试流程、缺陷管理这是测试岗位区别于开发岗位的核心竞争力第三工程能力包括SQL、Linux、编程这是你未来写自动化测试框架、搭测试平台、做性能测试的工具。这三条线放到现在的“测试开发学习路线”里依然完全适用。很多人问测开和纯功能测试有什么区别我的理解是功能测试把“手动执行用例”做到极致测开则要把“能自动化执行的测试工具和流程”做出来。你可以不懂框架源码但至少要能读懂接口文档、能写接口自动化脚本、能定位问题是前端还是后端、能在Linux环境下部署一套被测系统。爱数科技当年这张试卷本质上就是在用笔试的手段筛选同时具备这三种能力的人。哪怕时间已经过去这么多年这个筛选逻辑一直没有变变的只是知识点的热度比如现在会更多问到容器、微服务、链路追踪但在2017年这些还不是校招主流。2. 核心考点逐题拆解2.1 计算机网络与操作系统基础题里的送分题和陷阱题先说说选择题和简答题里反复出现的计算机网络考点。我印象中比较典型的有这几类TCP三次握手的过程、HTTP状态码的含义、TCP和UDP的区别、进程和线程的区别。这些题目本身不难但选项里会有很多“看起来对其实错”的干扰项。举几个典型例子“TCP三次握手的第二次握手服务端发送的报文是ACK还是SYNACK”正确答案是SYNACK。很多同学会选成ACK理由是第二次握手只是确认。这里的核心在于TCP同时需要确认对方的SYN并且同步自己的序列号所以必须同时带上SYN标志。这个细节教材里写过但考场上容易丢分。“HTTP 500、301、403、404分别表示什么”500是服务器内部错误301是永久重定向403是禁止访问404是资源不存在。看似送分但多选里如果问“哪些状态码属于4xx客户端错误”很多同学会把403、404选上却忘了一个常见的连接超时是408。这类题的陷阱不在难而在“你平时有没有真正观察过接口返回”。“进程和线程共享哪些资源进程拥有独立地址空间同一进程的线程共享堆和方法区但每个线程有自己的栈和程序计数器。”如果你只是背结论不理解为什么要这样设计换一个提问角度就会懵。操作系统这里还有一个高频考点是死锁的四个必要条件互斥、持有并等待、不可剥夺、循环等待。笔试中经常会让考生判断某个场景是否会产生死锁或者问“破坏死锁的方法”。这种题在学习路线里属于“八股文”性质的题目但非常重要因为测开在排查线上接口卡死、性能瓶颈时会用到这些思路。2.2 数据库与SQL数据准备能力是测开的基本功数据库这块几乎是必考。爱数科技的笔试卷里有简单的单表查询也有多表关联、分组统计、子查询。我当年印象最深的一道题大概是这样的假设有两张表一张employee员工表字段包括 id、name、department_id、salary一张department部门表字段包括 id、dept_name。要求查询“平均薪资大于5000的部门名称及其平均薪资”。这个题的常规写法是SELECT d.dept_name, AVG(e.salary) AS avg_salary FROM employee e INNER JOIN department d ON e.department_id d.id GROUP BY d.id, d.dept_name HAVING AVG(e.salary) 5000;这里需要特别注意WHERE是在分组前过滤HAVING是在分组后过滤。很多人会把HAVING写成WHERE或者干脆忘了加GROUP BY里所有的非聚合字段导致在 MySQL 5.7 以下版本能跑通但结果错误。还有一个高频考点是LEFT JOIN和INNER JOIN的区别。测试开发为什么要会这个因为你在准备测试数据、校验数据库数据时经常需要查“哪些用户没有下单”这类问题SELECT u.id FROM user u LEFT JOIN orders o ON u.id o.user_id WHERE o.user_id IS NULL;如果写成INNER JOIN就会把没有订单的用户直接过滤掉结果完全不同。这个坑我在实际工作中亲眼见过不止一次。另外试卷里还可能会问索引相关的内容比如“给查询频繁的字段建索引能提升性能但为什么不要对每个字段都建立索引”答案是索引会占用额外存储空间并且每次增删改都要维护索引反而降低写入性能。对于测开来说你不需要成为DBA但至少要能读懂慢查询日志知道什么是全表扫描这样在定位性能问题时才不会两眼一抹黑。2.3 测试用例设计从“登录框”到“电梯”考察的是什么简答题里的重头戏一定是测试用例设计。爱数科技当年有一道“给登录功能设计测试用例”的题后来我在很多公司的笔试卷里也看到过类似版本给一个登录页面包含用户名、密码、登录按钮、记住我选项要求尽可能全面地设计测试用例。这类题没有标准答案但有明显的得分点。考官想看到的是第一你有没有测试理论的基本框架比如等价类、边界值、场景法、错误推测法第二你能不能把业务逻辑和异常场景结合起来第三你想得够不够细比如弱网、并发、安全、兼容性、数据库一致性这些点有没有覆盖到。我通常建议按下面几个维度去展开功能测试正确用户名密码能登录成功错误密码提示“用户名或密码错误”用户名不存在有明确提示空值校验密码大小写敏感。边界值分析用户名长度上限、密码长度下限比如要求6-20位那5位、6位、20位、21位都要测。安全性密码是否加密传输登录接口是否存在暴力破解风险是否需要验证码或锁定机制是否存在SQL注入可能Token/Cookie是否正确设置过期时间。兼容性Chrome、Safari、Firefox 等主流浏览器Windows、macOS、iOS、Android 等不同操作系统。体验与异常弱网环境下点击登录的响应连续多次登录失败后的行为登录成功后刷新页面是否正常。数据一致性登录成功后用户信息是否正确写入Session多端登录是否互踢退出登录后本地缓存是否清除。类似的题还有“设计电梯的测试用例”“设计水杯的测试用例”“设计购物车功能的测试用例”。本质都是考察逻辑覆盖面。当时试卷上那道登录题我写了好多条并且特意把“密码明文传输”这条也写上去了。后来和面试官交流才知道那正是他想看到的点之一。2.4 编程题手写代码考察的不只是算法编程题部分在当年大概是两道一道是常见的“判断括号是否匹配”另一道是“实现二分查找”。难度都不高但想拿满分并不容易因为笔试题的评判不仅看能否跑通还看边界条件、时间复杂度和异常输入处理。先看二分查找。标准实现如下def binary_search(arr, target): left, right 0, len(arr) - 1 while left right: mid (left right) // 2 if arr[mid] target: return mid elif arr[mid] target: left mid 1 else: right mid - 1 return -1这个代码里最容易被忽略的是循环条件要写成left right而不是left right否则当你查找数组中不存在的元素时可能在只剩一个元素时提前退出逻辑就会出问题。另一个细节是mid (left right) // 2在极端情况下可能溢出更稳妥的写法是left (right - left) // 2。这种细节在校招笔试中非常加分因为它体现了你对代码质量和潜在问题的敏感度。再来看括号匹配def is_valid(s): stack [] mapping {): (, ]: [, }: {} for ch in s: if ch in mapping: top stack.pop() if stack else # if mapping[ch] ! top: return False else: stack.append(ch) return not stack这个题的考点是“栈”这种数据结构的应用。很多人能写出来但容易忽略输入为空、只有左括号、只有右括号、左右括号顺序交错这些边界场景。我当时在代码末尾特意写了一段注释说明空字符串和单个字符的处理逻辑其实就是在向面试官传递一种“测试思维”——不仅写代码还会自动考虑测试用例。这些编程题放到今天的“测试开发面试题八股文”里已经属于入门级了。但它们的价值不在于难度而在于筛选出“能写代码、会想边界、懂逻辑闭环”的人。3. 实操过程与核心环节实现3.1 一份可参考的测试用例设计模板如果你现在要准备测试开发岗位我建议你提前整理一套自己的测试用例模板笔试和面试时都能直接用。不要只背概念最好能形成肌肉记忆。我常用的模板结构是这样的用例编号测试标题前置条件操作步骤输入数据预期结果优先级是否自动化TC_001正确账号密码登录成功已注册用户进入登录页输入账号密码点击登录user001 / 123456页面跳转首页显示用户名P0是TC_002密码错误提示已注册用户输入正确账号错误密码user001 / 000000提示“用户名或密码错误”P0是TC_003用户名为空浏览器打开登录页不输入用户名点击登录空登录按钮置灰或提示必填P1否TC_004弱网环境登录使用抓包工具模拟弱网正常输入账号密码user001 / 123456页面显示加载状态最终成功或明确超时提示P1否TC_005SQL注入尝试登录页可访问用户名输入 OR 11特殊字符串不允许登录提示输入不合法P0是这个模板的核心思路是每条用例必须可执行、可验证、有优先级。面试官看重的不是你写了多少条而是你的用例能不能被别人直接拿去执行。我当时在笔试卷上写登录用例时其实没有列这么规范的表格但思路是一样的只是用文字分点列出了类似的内容。3.2 接口测试与自动化脚本的落地笔试里的SQL和编程题只是起点真正到了工作里测开最常做的一件事就是接口自动化。我习惯用 Python 的requests加pytest搭一套轻量级接口测试框架。登录接口的例子可以写成这样import requests import pytest BASE_URL http://127.0.0.1:8000 def login(username, password): url f{BASE_URL}/api/login payload {username: username, password: password} resp requests.post(url, jsonpayload, timeout5) return resp def test_login_success(): resp login(user001, 123456) assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][token] ! def test_login_wrong_password(): resp login(user001, 000000) assert resp.status_code 200 assert resp.json()[code] 1001 pytest.mark.parametrize(username,password, [ (, 123456), (user001, ), (None, 123456), ]) def test_login_invalid_params(username, password): resp login(username, password) assert resp.status_code 400这段代码覆盖了几个常见维度正常场景、错误密码场景、参数异常场景。用pytest.mark.parametrize实现数据驱动后增加测试数据的成本极低。我在实际项目中还会加一层请求封装把Token自动加进Header把日志自动打印出来这样脚本跑挂了可以快速定位。很多人会问笔试又不考这个为什么要写这些因为笔试的代码题只是“门票”真正决定你能不能拿到Offer的是面试中你能不能讲清楚自己写过的测试工具、踩过的坑、优化的过程。你可以没有真实项目经验但不能没有动手写过类似脚本。3.3 用常见工具完成功能/性能测试除了自己写脚本测试开发工程师还要熟练使用常用测试工具。2017年那会儿Postman、JMeter、Charles 已经是测开岗位的标配。笔试卷里可能不直接考工具操作但面试官很可能会问“接口测试你用什么工具”“性能测试怎么做的”“如何抓包分析问题”。我建议至少掌握三样第一Postman用于接口调试和简单的集合测试重点是环境变量、断言脚本和批量执行第二JMeter用于压力测试和负载测试要会配置线程组、聚合报告、查看结果树第三Charles 或 Fiddler用于抓包和弱网模拟要会设置断点、修改请求和响应、模拟超时。这些工具的掌握程度不需要到专家级但你要能回答出接口测试的核心是校验请求、响应、状态码、业务码性能测试的核心是先定目标比如“接口响应时间不超过300ms、错误率不超过0.1%”再去设计并发模型抓包的核心是能分清请求有没有发出、响应有没有返回、数据是否正确。另外提一句如果你之后接触的是设备端或者上位机开发测试这类场景还可能会遇到串口调试工具、Modbus模拟器、硬件信号模拟等工具。本质上思路是一样的构造输入、观察输出、判断是否符合预期。测开的核心能力不是绑定某一个工具而是快速理解一个系统该怎么测。4. 常见问题与避坑技巧4.1 当年考生容易踩的坑我在复习和笔试中踩过的坑以及后来帮学弟学妹看简历时发现的高频问题汇总成下面这张速查表误区具体表现改进方法只刷算法不重视测试理论LeetCode刷了几百题却写不出一条完整的登录用例每天用15分钟练习“测试设计”覆盖功能、边界、异常、安全SQL只会单表查询一遇到GROUP BY和HAVING就懵找实际业务题练手比如“查询每位顾客最近一笔订单”用例设计没有优先级写了几十条但全是P1等于没有优先级按影响程度给每条用例定优先级 P0/P1/P2编程题不写边界判断代码只考虑正常情况输入为空或长度超过限制就崩写完代码后主动补边界条件并在注释里说明测试策略不了解Linux命令问怎么看日志、怎么查端口答不上来至少掌握tail -f、grep、ps、netstat这几个高频命令忽略数据库数据校验只测页面表现不查数据库落库是否正确养成习惯操作完功能后用SQL验证数据变更这些坑看起来很小但在校招笔试和面试里却是区分度最高的地方。比如“登录成功之后数据库里的登录时间有没有更新”这种角度很多没接触过真实项目的人根本想不到但你参加过测试实习或者平时有意识地验证就能轻松答上来。4.2 今天的测开面试如何准备如果你现在才开始准备测试开发岗位我建议不要直接背面试题而是按下面这条路线来。这条路线同样适合把“测试开发学习路线”作为关键词搜索到这篇文章的同学第一打好基础计算机网络、操作系统、数据库、数据结构四门课先过一遍。不用追求完全吃透但高频考点要能用自己的话讲清楚比如三次握手、进程与线程、事务的ACID。第二掌握测试理论功能测试、等价类边界值、因果图、场景法、探索性测试、缺陷报告规范。这部分是测试岗位的基本盘不能丢。第三动手写自动化从一个简单的系统或公开接口开始用 Python 写接口自动化用例再用 Selenium 或 Playwright 做一层UI自动化的冒烟测试。不需要特别复杂能跑通、能出报告就好。第四会用工具Postman、JMeter、Charles 至少各做一次完整的练习Postman 里跑一套接口集合JMeter 里跑一次并发测试Charles 里抓一次HTTPS请求。第五准备项目经验如果没有真实实习可以自己模拟一个项目。比如自己搭一个待办事项系统然后围绕它做全套测试需求分析、用例设计、接口测试、性能测试、Bug记录。面试时能把这个链条讲清楚会比背十套八股文有用得多。至于“测试开发面试题八股文”可以在基础知识掌握得差不多之后用它来做查漏补缺但千万不要本末倒置只背不练。面试官只要追问一个“为什么”你就能分辨出对方是真懂还是背答案。4.3 AI工具对测开岗位的影响从“会用工具”到“会教工具”这两年AI测试开发的词越来越热很多人担心测试开发岗位会被取代。我的观点是AI不会取代测试开发但会用AI的测试开发会取代不会用AI的测试开发。现在的AI工具已经能帮你做很多事情根据需求文档生成测试用例、根据接口文档生成接口自动化脚本、分析失败日志并给出可能原因、辅助生成压测脚本。甚至可以用像 OpenCode 这类 AI 编程工具从需求到设计到开发到测试把一个小型项目的完整链路跑通这在几年前是想都不敢想的效率。但关键点在于AI生成的东西需要人来判断对不对。比如AI生成的用例可能是全的但它不知道业务优先级不知道哪些场景容易出线上故障AI生成的接口脚本可能需要适配你的公司环境需要完善断言需要接入CIAI写的代码也可能有安全问题或逻辑遗漏。所以测开的工作重心正在从“手工写用例”转向“定义测试策略、审核AI产出、维护自动化资产、解决复杂问题”。这对应了一个新的能力要求把需求转化成AI能理解的结构化描述。举个例子你说“帮我测一下登录接口”AI顶多生成一个简单请求但如果你告诉它“登录接口需要覆盖正确密码、错误密码、空参数、弱网超时、密码包含特殊字符、连续失败三次后需验证码断言要检查业务码和Token过期时间”它就能生成一套高质量用例。这就是从“会用工具”到“会教工具”的转变。所以我的建议是在准备笔试面试的同时去尝试用AI工具跑一个小型测试任务比如让它解析一份接口文档并生成 pytest 脚本然后你手动改断言。这件事本身就能成为面试中的加分项目。最后再分享一点个人经验时间过去这些年我自己也从当年的考生变成了带测试团队的人。现在看到新人来面试我很少问“你用过哪些测试工具”而是更爱问“你给自己写过的代码设计过哪些测试用例”。这个问题的回答最能看出一个人有没有测试思维。如果你正在准备测试开发岗位我最大的建议就一句话不要做一个只会执行用例的测试员要做一个能设计测试方案、能写测试工具、能分析问题根因的工程师。笔试卷里的每一道题都是在朝这个方向选拔人。把基础打牢把代码练熟保持对业务的敏感度这张试卷背后的能力模型放到今天依然不过时。