AI公司测试开发笔试深度拆解：从算法到用例的设计之道

2020年第四范式秋招，测试开发岗的笔试我到现在还记得很清楚。起初我以为不过是刷两道LeetCode、写几条测试用例、再考考Linux命令，结果拿到试卷才发现，这份卷子是直接把“算法工程师候选人的题”和“测试工程师候选人的题”搅在一起出。

这也正常，第四范式本身就是做AI平台的公司，测试开发要面对的是模型训练、数据流转、推理服务这些复杂系统。如果你只会点UI自动化，进公司基本干不了活。笔试是想在90分钟里过滤掉那批只会“点点点”的候选人。

这篇文章不是简单回忆题目，而是从备考角度把这类笔试的考察逻辑、典型题型和解题方法彻底拆开讲，适合准备AI公司测试开发岗位的同学对照复习。

1. 先聊聊第四范式测试开发笔试的“出题逻辑”

1.1 AI公司对测试开发的双重期望

先想一个问题：为什么测试开发岗位笔试要考算法和编程？

传统互联网公司的测试开发，主要工作是写自动化测试框架、做接口测试、维护测试平台。代码能力当然要有，但不需要特别硬核，很多人是工作以后才慢慢补起来的。可在AI公司，被测对象本身高度依赖算法，测试人员连算法都不懂，就很难设计出靠谱的验证方案。举个我实际遇到的问题：一个推荐模型的AUC值比上个版本涨了0.02，这个涨值到底是真的效果提升，还是因为训练样本切分不当造成的？如果测试人员不理解AUC的计算逻辑、不知道样本分布会影响评测结果，看到报表上数字涨了就直接通过，那上线之后业务效果可能反而下降。

所以第四范式的笔试很少出“背概念”的题，更多是让你在具体场景里去解决问题。看起来是一道算法题，实际上是在考察你写代码时对边界条件的敏感性；看起来是一道测试题，实际上是在考察你对数据设计和系统全局的理解。这种交叉出题的方式，恰恰是AI公司测试开发岗位的特点——你既要有测试的严谨性，又要有开发的实现能力，还要对机器学习基础概念不陌生。

1.2 笔试题量与考察模块分布

我拿到卷子后大概扫了一眼，90分钟，题量在20道左右，包含选择题、填空题、简答题和两道编程大题。按知识点归类的话，权重比较接近下面这张表：

这个比例不是官方数据，是我根据当年的印象估的，但方向上八九不离十。大家复习的时候可以按这个权重分配时间，别把时间都耗在刷难题上。我当时一个很深的感受是：题量虽然不算变态，但知识跨度特别大。你可能刚写完一道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("a+1 = %p\n", a + 1); printf("&a = %p\n", &a); printf("&a+1= %p\n", &a + 1); return 0; }

把打印出来的地址差一算，你就不会再混淆了。我在本地跑的时候，a+1和a的地址差是16字节，也就是4个int；&a+1和&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 场景法：把用户路径想到极致

比等价类更高一层的是场景法。比如一道“购物车结算”的用例设计题，考察的不只是怎么添加商品，而是整个流程：

1. 添加商品 → 修改数量 → 计算金额 → 选择优惠券 → 提交订单 → 支付 → 订单状态变化
2. 库存不足时的回滚逻辑
3. 支付过程中断网、取消支付、重复支付回调
4. 多端同时操作同一账号的并发问题

场景法的核心是把自己当成真实用户，把操作路径画出来，再对每条路径设计正常的、异常的、并发的情况。我在笔试时用的方法是在草稿纸上画一个简单的状态流转图，然后逐个节点找分支。状态流转图不用画得多标准，自己看得懂就行。

这里我顺便说一下，最近很多人讨论用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和403：401是未认证，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 如何编排“从需求到测试”的完整输出

再拔高一点，笔试里也出现过类似“用自然语言描述一个简单的登录功能，然后写实现方案和测试方案”的题。这类题其实就是把从需求到设计到开发到测试的完整闭环压进一张卷子里。

我自己的答题模板是这样的：

1. 需求理解：功能要解决什么问题，输入和输出是什么；
2. 设计拆分：核心模块怎么划分，接口怎么定义；
3. 代码实现：核心函数写清楚，边界条件不遗漏；
4. 测试方案：按功能、异常、性能、安全四个维度列出用例；
5. 风险点：比如说登录接口的防爆破、并发重复提交等问题。

这套模板写出来以后，阅卷人一眼就能看出你有工程化思维，而不只是“会写代码”。现在很多团队在推行AI辅助开发，用工具从需求直接生成代码和测试用例，但这反而要求测试开发更懂需求拆解和逻辑验证。工具能生成内容，可哪些用例优先级高、哪些场景必须覆盖、哪些异常可能导致线上事故，还是需要人来判断。

6.3 一套可复用的测试计划示例

拿登录功能举例，我笔试时写测试方案的思路可以拆成这样：

这个表看起来简单，但它是测试开发的核心产出物。笔试不是让你真的去执行测试，而是验证你有没有把需求转成可执行测试用例的能力。把表格列清楚，比写一堆看起来专业但零散的话更有说服力。

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公司测试开发的笔试，我最后想说的是：不要把刷题当成唯一目标。哪怕每天只做三道题，也要确保每道题背后涉及的语言机制、数据结构、边界条件都弄明白了，再配合测试设计的思维去思考“如果这是我测的功能，我会怎么测”。这样坚持两个月，你会发现笔试里那些“跨界”的题其实一点都不难。