测试岗校招面试的“分水岭题”已经换了：不是会不会写用例，是会不会测一个不确定的系统

上周跟一个刚面完腾讯的学弟吃饭，他掏出手机给我看了一道面试题，说：“哥，这道题我准备了一暑假，结果还是没答上来。”

我看了一眼，题不长：

“我们有一个AI客服，用户问‘我的订单到哪了’，它可能回答‘您的包裹正在派送中’，也可能说‘预计明天送达’，还可能先反问‘请问您的订单号是多少’。这三种回答都算合理。你作为测试，怎么判断它‘测通过了’？”

他答的是：设计用例，预期结果是“正确回答订单状态”，然后断言返回内容包含“派送中”或“明天送达”。

面试官追问了一句：“那如果它回答‘您的订单已签收’，但用户实际还没收到呢？你这条用例，能发现这个问题吗？”

他卡住了。

这道题就是2026年测试岗校招的“分水岭”。 它不考你会不会写用例，它考的是：你能不能测一个“没有标准答案”的系统。

一、为什么“背用例模板”答不上这道题？

你准备了一暑假的用例设计：等价类、边界值、判定表、场景法。这些方法有一个共同的前提——存在一个确定的“预期结果” 。

输入正确的手机号，预期“登录成功”。输入错误密码，预期“提示密码错误”。预期结果是唯一的、可枚举的、可断言的。

但AI客服这道题，预期结果本身就是一个集合。“派送中”“明天送达”“请提供订单号”，三个回答都合理。你没法写assertEquals(expected, actual)，因为expected不是一个值，是一个范围。

你背的模板解决的是“确定性问题”。面试官问的是“不确定性问题”。这是两种不同的测试思维。

二、从“验算题”到“体检报告”：两种测试思维

我用一个比喻来讲这个区别。

传统软件测试，像“验算数学题”。 题目是2+2，答案是4。你算出来是4，就对了；算出来是5，就错了。对错分明，没有中间地带。

AI系统测试，像“看体检报告”。 没有“标准健康人”这个东西。你拿到一份报告，看的是：各项指标在不在正常范围内？趋势有没有恶化？有没有异常信号？你判断的不是“对不对”，是“可不可接受”。

这个思维转变，对应三个具体的能力变化：

第一，从“比对预期值”变成“定义可接受范围”。 你不再问“它回答得对不对”，你问“它的回答有没有超出可接受边界”。AI客服说“派送中”可以，说“已签收”不行——因为后者和事实矛盾。边界比答案更重要。

第二，从“单次验证”变成“多次统计”。 同一个问题问十遍，AI可能给出十种不同但都合理的回答。你测的不是“某一次回答对不对”，你测的是“十次里有多少次在可接受范围内”。准确率、召回率、一致率，这些统计指标替代了单次断言。

第三，从“测功能”变成“测失效模式”。 你不只测“它能不能正确回答”，你更要测“它在什么情况下会错、错的时候错得多离谱、错了之后能不能被发现”。AI系统一定会出错，测试的目标不是证明它不出错，是证明它的错在可控范围内。

三、回到那道题：一个能拿分的回答框架

面试官问“怎么判断AI客服测通过了”，你可以按这个结构答。

第一步：先定义“什么算对”——建立判定标准

不要上来就写用例。先问清楚业务规则：

• 订单状态的“事实来源”是什么？（数据库里的订单状态）
• AI的回答必须和事实一致，还是允许一定偏差？
• 哪些回答是“不可接受”的？（比如把“未发货”说成“已签收”）

这一步的目的是把“不确定的回答”映射到“确定的判定标准”上。 回答可以千变万化，但“和事实一致”这个标准是确定的。

第二步：分层验证——不是只验“回答内容”

AI客服的回答，至少分三层验证：

事实层：回答里的订单状态，和数据库里的真实状态是否一致。这是硬断言，不能妥协。

语义层：回答的意图是否合理。用户问“到哪了”，AI回答“请提供订单号”是合理的；AI回答“今天天气不错”就不合理。这一层可以用语义相似度或LLM-as-Judge来评分。

安全层：回答有没有泄露其他用户的信息、有没有承诺做不到的事、有没有给出违规建议。这一层是红线，触发了就是失败。

第三步：用“统计”代替“单次断言”

设计一组测试样本：100个不同状态的订单，每个订单问3种不同问法，共300次对话。

然后统计：

• 事实一致率：回答中的状态和数据库一致的比例。目标：100%。
• 意图合理率：回答和用户问题语义相关的比例。目标：≥95%。
• 安全违规率：出现信息泄露、越权承诺的比例。目标：0%。

“测通过”的定义不是“某一次回答对了”，是“300次对话里，事实一致率100%、意图合理率95%以上、安全违规率为0”。

第四步：主动构造“它可能出错”的场景

AI客服最危险的不是“答不上来”，是“答得太自信但答错了”。

你要主动构造这些场景：

• 订单状态刚变更，缓存还没更新——AI会不会用旧状态回答？
• 用户问的是别人的订单号——AI会不会泄露信息？
• 订单状态是“已取消”，用户问“什么时候到”——AI会不会编一个配送时间？
• 同一个问题问三遍——AI的回答会不会前后矛盾？

这些场景，才是“不确定系统”真正会翻车的地方。

四、一个真实的对比：两种回答，两种评价

普通回答（背模板的人）：

“我会设计测试用例，覆盖正常查询、订单不存在、订单号格式错误等场景。预期结果是正确返回订单状态。”

面试官听完，心里想的是：这个人还在用确定性的思维，测一个不确定的系统。

分水岭回答（懂不确定系统的人）：

“我会先定义判定标准——回答中的状态必须和数据库一致，这是硬性要求。然后我会用统计的方法，设计300次对话样本，统计事实一致率、意图合理率和安全违规率。最后我会主动构造‘缓存滞后’‘越权查询’‘状态矛盾’这些场景，看它在边界情况下会不会出错。‘测通过’的定义不是单次回答正确，是三个统计指标都达标。”

面试官听完，心里想的是：这个人知道不确定系统的测试，核心是定义边界和统计失效，不是比对预期值。

五、避坑指南

坑一：还在找“标准答案”。 AI系统的测试没有标准答案，只有可接受范围。你越是想找一个“唯一正确的预期结果”，越答不到点上。

坑二：只测正常流程。 AI在正常流程上表现通常不错。真正的风险在边界场景——缓存滞后、状态矛盾、越权查询、多轮对话中的上下文丢失。

坑三：用单次结果下结论。 问一次答对了，不代表系统稳定。不确定系统的测试，必须用统计，不能用单次。

坑四：忽略“安全层”。 事实正确、语义合理，但泄露了用户信息——这是最严重的失败。安全层是红线，不能放在最后测。

坑五：把“AI测试”和“传统测试”对立起来。 传统测试的基本功（边界值、异常场景、分层验证）依然有用。你需要的是在传统测试的基础上，加一层“不确定性思维”，不是丢掉传统测试。

六、这道题背后，是测试岗的定义在变

过去测试岗的核心能力是“验证”——我给你一个需求，你验证实现符不符合需求。

现在测试岗的核心能力正在变成“定义”——系统没有确定的预期结果，你来定义什么算可接受、什么算越界、什么算失败。

这个变化不是因为AI来了才发生的。微服务、分布式、高并发，早就让系统变得“不确定”了——一次请求可能成功、可能超时、可能部分成功。AI只是把这种不确定性，从“系统层”推到了“语义层”。

面试官问这道题，不是在考你懂不懂大模型。他是在确认：当系统不再给你一个确定的“预期结果”时，你还能不能做测试。

最后

回到开头那个学弟。他后来问我：“那我该怎么准备这类题？”

我说：“别再背‘预期结果’了。练习一件事：拿到一个没有标准答案的场景，先定义‘什么算可接受’，再设计‘怎么统计它可不可接受’。 ”

他愣了一下：“就这？”

“就这。能把‘不确定’拆成‘可判定的边界’，就是2026年测试岗最值钱的能力。 ”

用例设计模板不会过时。但只会用例设计模板的人，会在“分水岭题”前面停下来。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。