2020年第四范式秋招测试开发岗的笔试我到现在还记得很清楚。起初我以为不过是刷两道LeetCode、写几条测试用例、再考考Linux命令结果拿到试卷才发现这份卷子是直接把“算法工程师候选人的题”和“测试工程师候选人的题”搅在一起出。这也正常第四范式本身就是做AI平台的公司测试开发要面对的是模型训练、数据流转、推理服务这些复杂系统。如果你只会点UI自动化进公司基本干不了活。笔试是想在90分钟里过滤掉那批只会“点点点”的候选人。这篇文章不是简单回忆题目而是从备考角度把这类笔试的考察逻辑、典型题型和解题方法彻底拆开讲适合准备AI公司测试开发岗位的同学对照复习。1. 先聊聊第四范式测试开发笔试的“出题逻辑”1.1 AI公司对测试开发的双重期望先想一个问题为什么测试开发岗位笔试要考算法和编程传统互联网公司的测试开发主要工作是写自动化测试框架、做接口测试、维护测试平台。代码能力当然要有但不需要特别硬核很多人是工作以后才慢慢补起来的。可在AI公司被测对象本身高度依赖算法测试人员连算法都不懂就很难设计出靠谱的验证方案。举个我实际遇到的问题一个推荐模型的AUC值比上个版本涨了0.02这个涨值到底是真的效果提升还是因为训练样本切分不当造成的如果测试人员不理解AUC的计算逻辑、不知道样本分布会影响评测结果看到报表上数字涨了就直接通过那上线之后业务效果可能反而下降。所以第四范式的笔试很少出“背概念”的题更多是让你在具体场景里去解决问题。看起来是一道算法题实际上是在考察你写代码时对边界条件的敏感性看起来是一道测试题实际上是在考察你对数据设计和系统全局的理解。这种交叉出题的方式恰恰是AI公司测试开发岗位的特点——你既要有测试的严谨性又要有开发的实现能力还要对机器学习基础概念不陌生。1.2 笔试题量与考察模块分布我拿到卷子后大概扫了一眼90分钟题量在20道左右包含选择题、填空题、简答题和两道编程大题。按知识点归类的话权重比较接近下面这张表考察模块大致占比典型题型算法与编程基础30%数组、指针、字符串、链表测试理论与用例设计25%等价类、边界值、场景法Linux与数据库20%常用命令、SQL查询机器学习基础15%模型评估、数据划分网络与协议10%TCP/UDP、HTTP状态码这个比例不是官方数据是我根据当年的印象估的但方向上八九不离十。大家复习的时候可以按这个权重分配时间别把时间都耗在刷难题上。我当时一个很深的感受是题量虽然不算变态但知识跨度特别大。你可能刚写完一道C语言改错题下一道就直接跳到SQL分组查询再过两道又变成机器学习评估指标。如果平时积累不够扎实很容易在切换过程中消耗掉大量时间。2. 算法编程题数组与指针这类经典题怎么拿分2.1 数组和指针基础中的杀手题C/C方向数组和指针几乎是必考。我当年复习时也犯过典型错误以为背住“数组名是常量指针”就万事大吉结果一道二维数组步长计算直接把我问住了。题目大概是这样的int a[3][4];请问a 1和a 1分别代表什么很多人第一反应是“都指向第二行”。实际上两者步长完全不同。a的类型是int[4]a 1是按一行的大小去偏移所以它指向a[1][0]而a的类型是int(*)[3][4]指向整个二维数组a 1会跳过整个3行4列的数组指向数组尾部的下一个位置。如果你在笔试里写“都指向第二行”这题的分就没了。这种题考的不是你会不会背结论而是你有没有真正写过、打印过地址。我建议备考时把这类小片段跑一遍#include stdio.h int main() { int a[3][4] {0}; printf(a %p\n, a); printf(a1 %p\n, a 1); printf(a %p\n, a); printf(a1 %p\n, a 1); return 0; }把打印出来的地址差一算你就不会再混淆了。我在本地跑的时候a1和a的地址差是16字节也就是4个inta1和a的地址差是48字节也就是12个int。这个验证过程比死背结论有用一百倍。类似的送命题还有sizeof和strlen的区别、指针数组与数组指针的声明方式、函数指针的用法。这些点单个看都很简单组合在一起就容易乱。我自己的方法是整理一份“指针步长速查表”指针类型决定了加减整数的步长这是核心。写测试代码的时候很多人遇到崩溃第一反应就是去查业务逻辑却忽略了底层指针越界的问题所以笔试考这些点是有实际意义的。2.2 字符串处理与内存安全第二类高频题是手写字符串函数比如实现strcpy、strlen、strcat。别觉得题目简单能满分写出来的人不多。大多数人的实现长这样char* strcpy(char* dest, const char* src) { while (*src ! \0) { *dest *src; } *dest \0; return dest; // 问题很大 }第一返回值不对。dest被移动到了字符串末尾返回它就没意义了应该在一开始保存原始指针第二忽略了src和dest内存重叠的情况。更标准的写法是用restrict关键字或者在拷贝前处理重叠。测试开发写这类函数时还要额外想想如果src是空指针怎么办如果dest空间不够怎么办这些边界情况正是笔试面试官想看到的。我记得当时笔试里有一道类似的改错题题目给了一段strcat实现里面没有检查dest的剩余空间。绝大多数同学直接说“没问题”但测试开发岗位的人应该立刻指出这是一个典型的缓冲区溢出漏洞轻则程序崩溃重则被利用做内存注入攻击。这种题考察的不只是语言基础更是一种安全敏感性。2.3 Java方向的集合与并发考点如果你是Java方向数组和指针的直接考察会少一些但会换成HashMap原理、ArrayList与LinkedList的区别、ConcurrentHashMap的线程安全机制。别小看这些题“Java笔试题大全带答案”里翻来覆去就那么几个点但AI公司的笔试会换个马甲考你。比如有一道题HashMap在并发场景下往多个线程同时put会发生什么只答“死循环”已经过时了Java 8以后要答“可能出现数据覆盖严重时CPU飙高甚至形成循环链表”。测试开发岗位遇到这类问题不能只说原理还要会设计并发测试用例去复现问题。比如用多线程同时put一万次看看有没有丢数据这就是把一道Java基础题升华成测试设计题。2.4 LeetCode热点题型的应对思路除了语言基础题还会有少量LeetCode风格的算法题。常见方向是数组遍历、双指针、滑动窗口、链表反转。复习的时候建议不要盲目刷题先按标签分类把双指针、哈希表、字符串处理这三类刷熟基本能覆盖笔试的编程题。我遇到的一道题是“给定一个字符串找出最长无重复字符子串的长度”。这题用滑动窗口做时间复杂度O(n)空间复杂度O(字符集大小)。很多同学一上来就写两层for循环虽然也能跑但面试官要的是最优解。笔试不是只对运行结果打分思路清晰也是加分项。写在卷面上的代码要注意变量命名和关键步骤注释别让阅卷人猜你的意图。3. 测试理论题用例设计是拉开差距的关键3.1 等价类划分和边界值分析不能只会背测试理论在笔试里占的分量不低而且它考察方式很直接给你一个功能描述让你设计测试用例。我遇到的一道题是设计一个“用户注册”功能的测试用例。如果只回答“输入手机号、验证码、密码”肯定不及格。你需要按等价类和边界值的方法去拆解有效等价类正确的手机号格式、6-20位密码、合法验证码无效等价类错误手机号格式、密码长度不足、含特殊字符边界值手机号11位数字的第11位密码长度6位和20位验证码有效期前后1分钟然后再补上异常场景手机号已被注册、网络超时、重复提交、服务器返回错误码每个场景都要写清楚预期结果。我改过很多同学的用例最常犯的问题是只写“输入错误密码”不写“错误密码的边界和类型”这会让用例数量爆炸且重复。3.2 场景法把用户路径想到极致比等价类更高一层的是场景法。比如一道“购物车结算”的用例设计题考察的不只是怎么添加商品而是整个流程添加商品 → 修改数量 → 计算金额 → 选择优惠券 → 提交订单 → 支付 → 订单状态变化库存不足时的回滚逻辑支付过程中断网、取消支付、重复支付回调多端同时操作同一账号的并发问题场景法的核心是把自己当成真实用户把操作路径画出来再对每条路径设计正常的、异常的、并发的情况。我在笔试时用的方法是在草稿纸上画一个简单的状态流转图然后逐个节点找分支。状态流转图不用画得多标准自己看得懂就行。这里我顺便说一下最近很多人讨论用AI辅助写测试用例比如通过对话式的工具把需求描述拆成用例。思路没问题但笔试的时候你必须能脱离这些工具靠自己的脑子把主路径、备路径、异常路径想清楚。工具可以提高效率替代不了逻辑训练。3.3 测试用例评审中常见的丢分点根据我的经验笔试里的测试设计题最提分的几个方向是数据测试比如输入为null、输入为超长字符串、输入为emoji等情况幂等性重复的请求是否会导致库存多扣、订单重复创建兼容性不同浏览器、不同分辨率、不同操作系统的行为是否一致安全性SQL注入、越权访问等测试点。有些同学觉得笔试时间紧用例设计只要“列出来”就行。实际上阅卷人看的恰恰是你有没有系统性思维宁可少写几条也要把层次理清楚功能、异常、性能、安全各自独立分类每一条写明“前置条件、输入、操作步骤、预期结果”。我自己的习惯是先写一个总纲再按类目展开。总纲可以是一句话“从接口入参校验、业务逻辑、异常链路、并发一致性、安全防护五个维度设计用例。”这样就算某条用例写得不够细阅卷人也知道你有结构感。4. Linux、数据库与网络测试开发的硬底子4.1 高频Linux命令会查日志才是好测试测试开发每天都要在服务器上排查问题离开Linux命令寸步难行。第四范式笔试题中有一定比例是Linux相关难度不算大但要求熟练。我印象比较深的命令有这些tail -f/grep -A -B看日志必备ps aux/netstat -tunlp/lsof -i查进程和端口top/free看CPU和内存awk/sed文本处理find/xargs定位文件和批量操作。笔试偶尔会给你一段日志让你用命令找出某个时间段的报错数量。例如cat app.log | grep ERROR | awk {print $1} | sort | uniq -c这个组合命令既能统计错误出现次数又能按日期归类是测试开发日常高频操作。备考时建议自己在Linux环境里把常用命令练熟别只看不敲。我当时在虚拟机里搭了一个测试环境故意往日志里写各种格式的报错然后用管道命令去统计练了几次就熟练了。4.2 数据库SQL查询必须会写三种以上写法数据库题大多集中在查询比如多表联查、聚合函数、分组过滤。笔试常考的题型包括查询一个部门的平均工资输出高于平均工资的员工信息用一条SQL查出重复记录统计每类商品的销售笔数并按降序排列。以“查出重复记录”为例经典的写法是SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) 1;一定要记住WHERE是在分组前过滤HAVING是在分组后过滤这个区别是选择题和填空题的高频考点。另外LEFT JOIN和INNER JOIN的区别也要能用白话讲清楚前者以左表为主左表行都会保留右表没有匹配就补NULL后者只保留两边都匹配的记录。我遇到一道题是“统计每个用户的订单总金额且只列出金额大于1000的用户”。这题看着简单但很多人会忘记先GROUP BY user_id再HAVING SUM(amount) 1000而不是用WHERE去过滤聚合结果。这种细节恰恰是测试开发写SQL验证数据时最容易出错的点。4.3 网络协议排查问题绕不开的基础网络部分的题不多但也会考。比如TCP的三次握手和四次挥手、HTTP状态码含义、HTTPS证书验证的过程。我还遇到过一道选择题一个HTTP接口突然超时作为测试开发最先排查的点是什么正确答案一般不是“重新启动服务”而是依次确认网络是否通ping、端口是否监听netstat、服务是否过载top、日志里有没有异常堆栈。这种排查思路比单独背协议更能体现测试开发的价值所以笔试干脆用选择题的方式考整个排查链路。再补充一点HTTP状态码是高频考点尤其要区分401和403401是未认证403是已认证但没权限。测试接口权限功能的时候这两个状态码是最直观的判定依据。还有5xx并不是永远代表服务端错误有时候网关配置错误也会返回502、504测试排查时要结合代理层日志一起看。5. 机器学习与AI测试第四范式笔试题里的隐藏考点5.1 模型评估指标不只是背公式第四范式的笔试中会有一些机器学习基础题权重不高但很重要。因为这不是单纯的技术岗位筛选而是在筛“能否在AI产品里做测试的人”。我印象深刻的一道题一个二分类模型测试集正负样本比例是9:1模型的AUC是0.95准确率是0.90请问这个模型的表现能直接说很好吗答案是不能直接说好。因为样本不平衡准确率会被多数类拉高。比如全部预测为负类准确率也有90%。所以需要看精确率、召回率、F1以及AUC和PR曲线。这道题的考点是测试人员不能只盯着一个指标而要结合数据分布去分析和验证。5.2 数据切分与特征工程的测试视角我记得还有一道关于训练集和测试集划分的题目。它问你如果训练集和测试集的分布不一致会导致什么问题这其实是在考察你对“数据泄漏”和“分布漂移”的理解。测试开发如果能从数据层面发现train和test分布不一致就是在帮算法团队挡掉一个上线事故。另外特征工程里的“特征穿越”也是个容易踩的坑。比如用未来的数据预测当下这在离线测试时效果会好得不可思议但上线就崩。测试开发在AI产品里要做的不只是功能测试还要会构造测试数据去验证模型对这类情况的鲁棒性。复习这部分不需要看得太深把评估指标、过拟合/欠拟合、交叉验证、样本不平衡这几个概念弄明白再用测试思维去想“怎么验证这些点”就够了。测试开发的岗位不是让你去调模型而是让你设计测试方案去保证模型质量和上线安全。5.3 数据质量测试AI测试与传统测试的最大差异AI测试和传统功能测试最大的差异在于传统测试有明确的预期输入输出而AI测试很多时候没有绝对的对错。比如图像识别模型同一张图片在不同光照条件下结果可能不一样推荐系统给不同用户推的列表也不一样怎么断言结果是正确的所以AI测试要关注数据质量。我见过一个真实案例训练数据里有一类样本被错误地打了很多错误标签模型学到了错误规律上线后那一类用户的体验暴跌。测试开发如果只测代码不测数据根本发现不了问题。笔试里考数据划分、模型评估本质上就是在测你有没有这种数据敏感的测试思维。6. 手写代码综合大题从需求到测试方案的一次完整输出6.1 编程题实现一个功能并补齐测试用例我记得笔试里有一道综合性的大题要求实现一个“字符串去重并保持原有顺序”的函数同时为它设计测试用例。这个题看似简单却能同时考察编程能力和测试设计能力。写代码时要注意几点不要用暴力双重循环先想到用哈希表记录出现过的字符注意大小写是否区分对空字符串、只有一个字符的字符串做特殊处理空间复杂度和时间复杂度都要考虑。参考实现大致是这样def remove_duplicates(s: str) - str: if not s: return seen set() result [] for ch in s: if ch not in seen: seen.add(ch) result.append(ch) return .join(result)写完代码后还要为这个函数设计用例。这里我建议按下面几个维度组织正常输入abac→abc边界输入空字符串、单字符、所有字符都重复性能输入超长字符串异常输入包含空格、数字、中文、甚至null。这类题的隐藏评分点不在代码写得有多花哨而在你是否有测试开发的思维。很多编程强的同学会把函数写得很好但测试用例设计得很敷衍反而丢了测试部分的分数。6.2 如何编排“从需求到测试”的完整输出再拔高一点笔试里也出现过类似“用自然语言描述一个简单的登录功能然后写实现方案和测试方案”的题。这类题其实就是把从需求到设计到开发到测试的完整闭环压进一张卷子里。我自己的答题模板是这样的需求理解功能要解决什么问题输入和输出是什么设计拆分核心模块怎么划分接口怎么定义代码实现核心函数写清楚边界条件不遗漏测试方案按功能、异常、性能、安全四个维度列出用例风险点比如说登录接口的防爆破、并发重复提交等问题。这套模板写出来以后阅卷人一眼就能看出你有工程化思维而不只是“会写代码”。现在很多团队在推行AI辅助开发用工具从需求直接生成代码和测试用例但这反而要求测试开发更懂需求拆解和逻辑验证。工具能生成内容可哪些用例优先级高、哪些场景必须覆盖、哪些异常可能导致线上事故还是需要人来判断。6.3 一套可复用的测试计划示例拿登录功能举例我笔试时写测试方案的思路可以拆成这样分类测试点预期结果功能正确账号密码登录登录成功跳转首页功能错误密码连续5次账号锁定或触发验证码异常网络超时提示请重试按钮置灰防重复点击性能1000人同时登录响应时间小于3秒无内存溢出安全SQL注入登录请求被拦截返回参数错误这个表看起来简单但它是测试开发的核心产出物。笔试不是让你真的去执行测试而是验证你有没有把需求转成可执行测试用例的能力。把表格列清楚比写一堆看起来专业但零散的话更有说服力。7. 复习策略与真实踩坑记录7.1 按权重分配复习时间我给自己定的复习比例是40%时间刷题数组、指针、字符串、链表、双指针、哈希表25%时间练测试设计把常见的注册、登录、购物车、订单、支付场景的用例都写一遍20%时间补Linux和数据库每天在真实环境里敲几十条命令把SQL的聚合多表查询练熟15%时间理解机器学习基本概念主要看模型评估、数据划分、过拟合这些核心点。不建议一上来就刷难题更不建议背“八股文”而脱离场景。笔试里很多题看着是概念题实际最后一定落在“你怎么用它去解决测试问题”上。比如问你HashMap原理不如问你并发场景下怎么验证HashMap是否安全问你AUC公式不如问你样本不平衡时AUC还能不能作为唯一指标。7.2 三个亲身踩过的坑第一个坑是我最开始只刷LeetCode忽略了C/C的指针底层题。结果遇到指针步长的题直接懵了。后来我花了一下午把指针、数组、sizeof、strlen这几个点集中整理成表格才算补上漏洞。建议不要觉得C/C是老技术就不复习AI公司底层很多是C写的推理引擎测试开发要看得懂这类代码。第二个坑是测试用例设计题我写了功能测试和异常测试但完全没有写性能和安全性。有一次模拟练习之后我发现只要把安全测试比如越权、SQL注入和性能测试比如并发、超时也分类型补充上去测试方案会立刻显得专业很多。后来我把“性能、安全、兼容性”写成一个固定检查项每道用例设计题都过一遍丢分就少了。第三个坑是网络协议题不要只背定义。比如TCP三次握手一定要结合抓包去理解能说出各状态对应的实际场景。不然碰到“接口超时排查”这类题你只能说出一堆名词却串不成一条排查链路。我自己的办法是拿一个真实接口关掉服务端再用curl看返回错误逐个排除法理解网络层、传输层、应用层各负责什么。7.3 笔试之外的长期能力积累笔试只是第一关真正的测试开发能力是在项目里练出来的。如果你还有时间建议自己手写一个小项目比如一个简单的接口服务或者命令行工具然后给这个项目补全测试方案。这个练习能同时锻炼编码能力、测试思维和对全流程的把控。最近社区里经常有人讨论用AI工具辅助开发测试框架我觉得这个大方向值得关注但核心还是你自己的逻辑要清晰。AI能生成代码、生成用例模板可它不知道你的业务风险点在哪不知道哪条用例该优先执行不知道线上事故最容易出在哪个环节。这些判断力需要靠长期的项目积累。笔试只是检验这些能力的一个切面不是终点。如果你正在准备AI公司测试开发的笔试我最后想说的是不要把刷题当成唯一目标。哪怕每天只做三道题也要确保每道题背后涉及的语言机制、数据结构、边界条件都弄明白了再配合测试设计的思维去思考“如果这是我测的功能我会怎么测”。这样坚持两个月你会发现笔试里那些“跨界”的题其实一点都不难。