刚看到这个标题的时候我愣了一下。2019年的第四范式AI圈子里已经很有名了但一个做机器学习平台的公司校招测试开发笔试题能考出什么花来这是我当时脑子里冒出的第一个问题。后来真的拿到卷子发现它跟我之前刷过的所有互联网大厂测开笔试题都很不一样。常规的测试理论、数据库、Linux、网络协议这些是有的但卷子里还塞了不少机器学习的基础概念、模型评估指标甚至还有一道让你给一个模型预测接口设计测试用例的题。当时考场上一片叹气声很多人栽在“看不懂题目在问什么”这一步。现在回过头来看这套笔试题其实非常典型地反映了一个AI公司对测试开发工程师的真实期待你不仅要会“测试”还要能理解被测对象——也就是模型和AI平台本身。这篇文章我就以这套笔试题为引子拆一拆AI公司测开岗笔试背后真正想考察的东西结合我自己的实操经验把题型、解题思路、踩坑点都梳理一遍。无论你是正在准备AI公司测开面试还是单纯想看看“AI公司的测试题到底长什么样”这篇都能给你一些实在的参考。1. 笔试背后AI公司到底在找什么样的测开1.1 测开岗在AI公司的真实定位大多数人对测试开发的印象还停留在“写写自动化脚本、点点页面、提提bug”的阶段。传统互联网公司里测开确实更多围绕业务功能、接口、性能去做质量保障。但在AI公司情况完全不一样。第四范式这类公司的核心产品是什么是机器学习平台、自动建模工具、模型服务。这些产品的被测对象除了传统的前后端功能还有模型效果、训练流程、特征工程、分布式调度这些偏算法和数据的东西。这时候测试开发要做的就不只是“点击按钮看结果对不对”而是要能从数据流、特征流、模型指标的角度去设计测试方案。我在实际工作中最深的一个体会是AI公司的测开本质上是“懂一点算法的测试工程师”。你不需要像算法工程师那样去调模型、写Loss但你必须看得懂特征怎么处理、模型输入输出是什么、评估指标AUC和PR曲线代表什么含义。因为如果你连被测对象的基本原理都不懂你设计的用例就是空中楼阁连bug长什么样都判断不了。所以2019年这套笔试题里出现机器学习基础不是凑数而是在筛人。筛掉那些只会背测试理论、对模型一窍不通的候选人留下那些具备跨领域理解力的人。1.2 2019年前后这套题目的考察逻辑2019年这个时间点很有意思。那会儿AI落地的概念已经从“炫技”转向“工程化”很多AI公司开始认真思考一个问题模型上线之后质量谁来保证传统的功能测试覆盖不了模型漂移、数据分布变化、特征缺失这些问题。于是测试开发的职责被重新定义了。这套笔试题的考察逻辑可以拆成三层第一层基础工程能力包括数据结构、编程、数据库、Linux命令这是任何一个测开都绕不过去的硬底子。第二层测试专业能力包括用例设计方法、自动化测试思路、问题排查手段这是测开区别于普通开发的核心竞争力。第三层AI领域认知包括机器学习基础概念、模型评估方式、对AI产品形态的理解这是AI公司测开的加分项也是2019年校招里最有区分度的部分。我在答题的时候明显感觉到出题人想找的是那种“基础扎实、思维灵活、对AI产品有感觉”的候选人。单纯刷题刷出来的选手遇到第三层题目会非常难受因为那部分不是靠背八股文能解决的它需要你真的理解“模型是怎么工作的”。2. 核心题型拆解算法、机器学习与测试思维的组合拳2.1 编程题不考难题考基本功2019年的笔试编程题难度跟互联网大厂的中等题差不多不会出那种劝退级的hard题。我印象比较深的是有一道跟“LRU缓存”相关的题要求实现一个固定容量的缓存结构支持get和put操作时间复杂度要求O(1)。这道题在LeetCode上有原题但笔试环境里没有自动补全、没有IDE提示全靠手写很考验基本功。LRU这道题的解题思路其实很固定哈希表加双向链表。哈希表负责O(1)查找双向链表负责O(1)的节点移动。核心操作有两个get的时候如果key存在把对应节点移到链表头部返回valueput的时候如果key存在先删掉旧节点再插入新节点到头部如果容量满了删掉链表尾部的节点同时从哈希表里移除对应key。我当年手写的时候踩过的一个坑是很容易忘记处理“更新已有key时哈希表里的value也要同步更新”。如果只是把节点移到头部但没更新value后面get到的还是旧值这种bug在笔试的短时间里很难用眼睛查出来。所以后来我养成了一个习惯凡是涉及到“更新已有数据”的操作第一件事就是先想清楚哈希表里存的值是否需要一起改。还有一个细节是双向链表的边界处理。很多人写链表题最怕的就是空指针。我在笔试时习惯用一个哑结点dummy head和一个哑尾结点dummy tail这样头插、尾删都统一了逻辑不用单独判断链表为空的情况。这个小技巧能省下大量边界判断的时间强烈建议手写链表题的时候都用这个套路。2.2 机器学习基础题AUC与PR曲线的坑这部分是这套题目里最有“AI公司特色”的。题目不会让你推导复杂的数学公式而是考察对核心概念的理解。我记得有一道选择题是关于AUC和PR曲线在正负样本不平衡时的表现差异选项里设置了好几个容易混淆的表述。这里我多说一句AUC和PR曲线这两个概念很多做测开的人一开始是懵的。它们都是用来评估二分类模型好坏的指标但侧重点不一样ROC曲线关注的是真正例率TPR和假正例率FPRAUC是ROC曲线下方的面积。它的特点是当正负样本比例变化时ROC曲线基本保持稳定所以AUC对样本不平衡不那么敏感。PR曲线关注的是精确率Precision和召回率Recall当负样本远多于正样本时PR曲线能更敏感地反映模型性能的变化。所以题目如果问“在正负样本极不平衡的情况下哪个指标能更好地区分模型好坏”答案往往是PR曲线而不是AUC。这个知识点如果你只背定义不看场景很容易选错。我当时复习的时候用的是“控制变量”的思路来理解AUC和PR都涉及到样本分布但AUC同时看了正样本和负样本的排序关系而PR只聚焦在正样本的预测质量上。当负样本暴增FPR会变得极其小ROC看过去一切正常但模型对正样本的实际召回可能已经崩了。这个时候PR曲线就比AUC更能暴露问题。对测开来说理解这个点的价值在于写测试用例的时候你要知道在什么场景下该关注哪个指标。比如你测试一个用户流失预警模型流失用户占比可能只有1%这时候你用AUC来判断模型效果很可能会漏掉召回率严重下降的问题。正确的做法是PR曲线和AUC同时看再结合具体业务阈值去看精确率和召回率的具体数值。2.3 测试用例设计题等价类边界值在模型服务上的变种这套卷子里还有一类题是给一个场景让你设计测试用例。但场景不是普通的登录注册而是模型预测接口。比如给你一个房价预测API输入是房屋面积、房龄、周边学校数量输出是预测价格让你设计测试用例。很多第一次接触这类题的人会直接套用传统的等价类划分面积输入一个正常值、一个异常值、一个边界值就以为完事了。但这只答对了一半而且是流于形式的一半。模型服务接口跟普通接口最大的区别是什么它的逻辑正确性不完全取决于“返回200还是500”还取决于“返回的数值是否合理”。所以用例设计要分成两个维度功能维度参数缺失、类型错误、范围越界、必填项校验这些跟普通接口一致。模型维度输入特征的组合是否覆盖训练数据的分布异常的输入值比如面积为负数、房龄为负模型会不会产生怪异输出模型对缺失值的处理是否符合预期。我当时设计用例的时候加了一个很关键的点当一个特征异常时模型输出的结果应该是什么是直接报错还是用默认值填充后正常返回这个行为在需求文档里往往没有明确写但恰恰是上线后最容易出事故的地方。一个靠谱的测开应该把它作为单独的场景拿出来测并且主动找开发确认预期行为。3. 一道典型题目的完整实操复盘3.1 题目还原给一个房价预测API设计测试为了把这类题讲透我以当年那道题的“变体”为例带着你完整走一遍从读题到落地测试的过程。假设题目是这样某AI公司提供了一个房价预测API接口为 POST /api/house/price请求体是JSON包含三个字段area房屋面积float类型单位平方米取值范围(0, 500]age房龄int类型单位年取值范围[0, 200]school_num周边学校数量int类型取值范围[0, 50]响应体是{price: 123.45}表示预测房价万元。 请设计测试用例并说明需要关注的关键风险点。第一眼看上去这不就是个普通接口题吗但如果只盯着参数校验就掉进出题人的陷阱了。这是一道考察“AI产品测试思维”的题答题时必须体现出你理解“模型服务的特殊性”。3.2 需求分析到用例设计的完整路径我的思路是分四步走第一步先不急着写用例先确认接口的输入输出契约。请求字段的类型、取值范围、是否可空、响应结构这些是设计用例的基础。题目里给了范围但实际工作里范围往往在接口文档里可空的定义经常含糊拿到题先把这个列出来。第二步用等价类和边界值方法覆盖参数校验。这部分要写得既全面又有条理。第三步也是关键的一步设计“模型行为”维度的用例。比如合法的边界组合area500, age200, school_num50模型能不能正常输出极端组合area0.001, age199, school_num0输出是否在合理范围内特征缺省age不传时走默认值填充还是报错。第四步补充安全与性能方面的用例。安全性上要验证SQL注入、超大JSON payload性能上要关注高并发下的响应时间。最后把这些整理成一张用例表格既清晰又专业。我设计出的用例表格核心部分大概长这样用例编号测试维度输入数据预期结果说明TC01功能-正常area89.5, age5, school_num3返回200price为合理float正常输入TC02功能-边界area500, age200, school_num50返回200price合理所有字段取上边界TC03功能-下边界area0.001, age0, school_num0返回200或明确报错注意area趋近0的极端情况TC04参数异常-areaarea-10返回4xx错误信息明确负数非法TC05参数异常-age类型age五年返回4xx类型错误字符串类型非法TC06参数缺失不传school_num行为符合接口文档约定需与开发确认是否能缺省TC07模型行为-数据分布外area500, age0, school_num0输出值应在合理业务范围内验证模型对极端特征的处理TC08模型行为-特征缺失全部字段传null不返回500必须有约定行为防止NPE或模型崩溃TC09安全-注入area1; DROP TABLE house返回4xx不执行任何危险操作防SQL注入TC10性能-并发100并发请求P95响应时间在可接受范围视业务要求而定3.3 自动化测试框架的代码实现笔试第三问如果让你写一段自动化测试脚本用Python加requests库就能快速实现。下面是一个可以直接用的最小框架import requests import pytest BASE_URL http://api.test.house-price.com def predict_price(area: float, age: int, school_num: int): payload { area: area, age: age, school_num: school_num } resp requests.post(f{BASE_URL}/api/house/price, jsonpayload, timeout5) return resp def test_normal_input(): resp predict_price(area89.5, age5, school_num3) assert resp.status_code 200 data resp.json() assert price in data assert isinstance(data[price], float) def test_max_boundary(): resp predict_price(area500, age200, school_num50) assert resp.status_code 200 data resp.json() assert 0 data[price] 100000 pytest.mark.parametrize(field,value, [ (area, -10), (area, 0), (age, 五年), (school_num, 60), ]) def test_invalid_params(field, value): payload {area: 89.5, age: 5, school_num: 3} payload[field] value resp requests.post(f{BASE_URL}/api/house/price, jsonpayload, timeout5) assert resp.status_code 400 or resp.status_code 422 def test_missing_param(): payload {area: 89.5, age: 5} resp requests.post(f{BASE_URL}/api/house/price, jsonpayload, timeout5) assert resp.status_code ! 500 # 具体是4xx还是200取决于接口对缺失字段的约定这个框架里藏着几个我踩过坑之后才加进去的细节。第一个是timeout参数很多新手写requests请求时不加timeout一旦被测服务卡住测试脚本会无限期挂起在CI里特别坑。第二个是参数化用例pytest的parametrize非常适合这种“同一个操作不同入参”的用例写起来干净跑起来一目了然。第三个是断言不能只写状态码还要校验响应的结构字段因为接口返回200但缺字段的情况在微服务架构里并不少见。3.4 边界条件与数据构造的细节我在真实做AI模型接口测试时发现最容易被忽视的是“数据分布外”Out of Distribution简称OOD的样本。模型训练时看到的特征值范围是有限的如果线上请求里出现训练分布之外的输入模型会给出一个“看似合理但实际上完全不可信”的输出。举一个具体的例子训练数据里房屋面积分布在20到200平方米之间但线上有一个请求的area500。模型可能会根据学习到的线性趋势外推给出一个非常离谱的价格比如两千万。这个数值格式上完全合法接口返回200普通的功能测试根本不会发现任何问题但业务上它就是错的。所以我在设计用例时专门加了一条“分布外数据”的用例并且会在测试报告里单独标注这个场景的预期结果不能简单写成“数值合法”而是要结合业务去定义什么叫“合理”。比如跟业务方确认当面积超过300时超出训练范围模型输出的置信度不可保证需要网关拦截或者降级处理。这些内容不会出现在接口文档里但却是AI产品测试里最容易出事故的地方。4. 面试打分点与日常准备的避坑清单4.1 笔试环节最容易丢分的三个地方从我自己这些年面试候选人和复盘笔试经历来看丢分往往不是因为你不会那道题而是因为你踩了下面这三个坑。第一个坑是编程题眼高手低。很多人看到LRU缓存觉得自己会但真要手写的时候链表指针一乱就废了。我的建议是准备阶段不要只看题解一定要动手在纸上或者无IDE的编辑器里写训练自己在没有补全环境下写代码的能力。当年我能完整写出来靠的是考前在记事本里把高频链表题的代码敲了不下五遍。第二个坑是机器学习概念只背定义不理解场景。比如AUC和PR曲线出题人稍微换一个问法就懵了。要真正理解一个指标最好的方法是去构造一个极端数据分布用手算一遍或者随手画一画看指标怎么变化。我后来带新人时都是让他们这样练的效果比死记硬背好太多。第三个坑是用例设计只停留在参数校验忽略模型行为。对于AI公司的测试题你的用例如果只写了“类型错误、范围越界”这类传统用例没有体现出对模型输入分布、特征缺失、输出合理性的思考分数基本就定格在及格线以下了。哪怕你只多写了两条模型行为维度的用例都会让面试官眼前一亮。4.2 现场面试追问里藏着的加分点笔试过了之后面试官往往会拿你做过的方案继续追问。我当年被追问的一个问题是你在测试房价预测接口时发现area500时模型输出异常你会怎么定位问题这个问题的完整回答思路应该是先确认异常表现是什么是数值溢出、NaN还是业务上的不合理然后复现问题用同一组输入多次请求排除随机性接着抓取模型服务的日志看特征处理前后的值确认是特征工程环节的问题还是模型推理环节的问题最后是回归测试确定这个异常是从哪个版本开始引入的修复后有覆盖性验证。面试官问这个问题的目的不是真让你马上定位到bug而是看你有没有一套“从现象到根因”的排查方法论。我在回答时还加了一个细节我会先用小流量灰度把异常输入镜像到沙箱环境去复现避免在线上环境反复打脏数据。这个细节一出来面试官通常都会点头因为这说明你考虑到了线上安全。除了排查问题面试官还可能追问你“测试左移”的理解。在AI公司测试左移意味着你要在数据准备阶段就介入检查训练数据和线上数据的分布一致性而不是等模型上线之后再测。如果能把这一层说出来你的回答会比单纯讲自动化框架高一个段位。4.3 给新人的一份可复用的准备路线如果你现在正在准备AI公司测开岗位我给你一条实际验证过的准备路线。基础阶段先把数据结构与算法中的高频题刷一遍重点关注数组、链表、哈希表、队列能自己手写实现。这一阶段的目标是能白板写出无语法错误的代码。测试基础方面等价类划分、边界值分析、因果图、场景法这些用例设计方法要能随手举例。进阶阶段补充机器学习基础概念。不要求会推导公式但至少要知道什么是过拟合、什么是交叉验证、什么是精确率和召回率、AUC和PR的区别。推荐去看一些模型评估相关的文章理解指标背后的业务含义。如果条件允许自己用sklearn跑一个简单的二分类模型打印出ROC曲线和PR曲线对照着看不同数据分布下两条曲线的变化。专项阶段针对AI产品的特点学习如何测试模型服务。可以从一个开源的模型部署项目入手自己搭一个本地接口然后用pytest写一套覆盖参数校验、模型行为、性能、安全四个维度的自动化测试。做完这个项目后你不仅有了实战经验还能在面试时拿出一个完整的、有自己想法的测试方案来聊。还有一个小建议准备面试时不要只看“测试开发八股文”那些东西能帮你过基础面但过不了AI公司的专业面。真正拉开差距的是你对“被测对象”的理解深度。多花点时间搞清楚模型训练和推理的基本流程比多背二十道接口测试常见题有用得多。我在实际工作中带过不少新人发现一个规律凡是能在笔试和面试中表现出“对模型有基本理解”的候选人入职后的上手速度会快非常多。因为AI公司的质量保障工作核心挑战从来不是“会不会用工具”而是“能不能理解系统的行为逻辑”。工具可以学但思维方式需要提前培养。最后再分享一个小技巧笔试时如果遇到机器学习相关的题目不要慌把自己知道的原理、公式、适用场景条理清晰地写出来哪怕不能完全答对也能向面试官展示你的思考过程。我在批改面试题时最欣赏的是那种“虽然没给出最佳答案但思路完整、关键点都踩到了”的卷子。毕竟测试开发这个岗位要的就是那种能在不确定中找到问题线索的人。