前段时间有位粉丝去参加面试，回来总觉得答得不太好，找到我，想让我帮他复盘一下。题目拿过来一看，里面有几道问题挺典型的，挑几道出来，跟大家分享一下。

面试聊的是他做的测试用例 Agent 项目，面试官问得挺细，从提效数据怎么统计，一直问到方案本身有什么短板。每道题我都站在面试官的角度拆了一下，这道题面试官到底想听什么，怎么答能答到点子上。大家可以先自己想想，再对照我的思路看。

候选者的回答，应粉丝要求，就不展示了~

面试题一

面试官问：测试用例 Agent，用例编写从 68 小时缩短到 23 小时（简历中有提到），这个数据怎么统计的？

这道题面试官想考什么？

面试官问这个问题，不是单纯要计算公式，这是一道典型的 “数据真实性/严谨性” 追问题。面试官想考察的不是数字本身，核心考察的是，你是不是拍脑袋编的数字，有没有清晰、可复现的统计口径，以及你是否诚实对待数据的局限性，有没有盲目夸大收益。

面试口述完整思路

面试官您好，这个时长我们是有针对同等复杂度需求做过对照统计的：

基线 68 小时： 是我们在引入 Agent 之前的基线，取自项目管理平台（如 Jira/禅道）中同一类任务的历史工时。我们选了引入前 2~3 个迭代、同一团队、同类复杂度的需求作为样本，比如 50 个需求、累计 500 条用例，统计的是从需求评审完成到用例评审通过的端到端耗时，而不是只算 ‘打字’ 的时间——包括用例设计、编写、自查、评审返工。”

23 小时：是引入 测试用例 Agent 之后，我们在相同口径下度量：同样的团队、相近复杂度的需求，同样从需求评审完成到用例评审通过。数据来自任务工时记录 + 用例评审记录。统计的是人在这个链路里的实际投入工时，Agent 自动生成的耗时不计入人工工时。

并且，为了尽量减少干扰，我们特意做了几件事保证可比性：

• 同类需求对比：我们固定了需求规模、业务模块，按需求的复杂度分级（如接口数、页面数、场景数），只和同级别需求比；
• 同一团队：排除人员熟练度差异；
• 多迭代观察：23 小时是最近 N 个迭代的稳定值，不是最好的一次。"

这里在回答时，还可以主动拆解时间去哪了（体现深度）

比如，原来 68 小时里，设计约 20h、编写约 30h、评审返工约 18h。Agent 主要压缩的是编写环节（30h→8h），设计和评审环节仍以人为主。所以提升的本质是人机分工，而不是 AI 替代了全部。

如果候选者，能主动拆解一下，是很能打动面试官的——说明你理解提效来源，而不是甩一个数字。

可能的追问

68h →23h，节省了这么多，那能不能继续往下压？瓶颈在哪？

建议回答：现在瓶颈不在打字、结构化罗列，而是需求里没有写清楚的隐性规则、业务耦合场景、风险判断，这些 Agent 目前阶段很难自动识别，必须靠测试人员理解业务、和产品对齐。这部分工时很难再大幅压缩。

面试题二

面试官问：AI 生成的测试用例，怎么保证可执行、场景覆盖完整？边界、分支场景怎么保证不漏？

这道题面试官想考什么？

这是上一题的延伸，面试官在考察你对 AI 生成内容的质量工程的理解。核心答题思路：不要说 “我们靠人工看”，AI Agent 本身不能自动保证全覆盖，它擅长结构化、显性规则；边界、分支、隐性业务约束是短板。我们主要是靠「多层约束 + 校验机制 + 人工兜底闭环」来保障可执行性和场景覆盖，而不是信任模型一次性输出。

面试口述完整思路

我们是主要分四层来保障：输入约束、生成时的推理引导、自动化校验、人工评审 + 持续反馈闭环，同时会分开解决【可执行】和【覆盖完整】两个问题。

第一，先解决可执行性。

1. 给 Agent 固定输出规范：强制对齐我们内部测试用例模板，包含前置条件、操作步骤、预期结果、断言、数据准备、环境依赖，禁止自由文本；
2. 接入元数据：接口文档、字段枚举、参数类型、数据库字典、接口返回结构，Agent 生成断言的时候直接引用字段，而不是写模糊描述（比如不能写 “返回成功”，要写 code=0）；
3. 内置校验规则：生成后先做轻量静态检查，比如参数是否合法、前置条件是否冲突、有没有缺少测试数据、断言和接口返回字段是否匹配，不符合规则直接打回重生成；
4. 可执行标准定义：这条用例交给自动化脚本或者测试人员，不需要额外猜业务、不需要二次脑补就能直接跑。

第二，解决分支、边界、异常场景不漏，这块是重点，也是 AI 最容易翻车的地方：

1. 生成前做场景拆解前置。不是直接丢需求给大模型，Agent 先做一步控制流 / 业务分支解析：梳理主流程、分支判断点、状态机、枚举值、判断条件（if/else、开关、权限、角色），先输出分支清单，再基于清单生成用例。 比如订单有支付状态、退款开关、用户等级，先把所有组合枚举出来，再生成用例，而不是模型自己脑补；
2. 内置边界值知识库：对数字、长度、时间、数组、分页、ID 这类通用类型，内置边界策略：正常值、最小值、最大值、临界值、越界、空、null、空字符串、特殊字符、超长；
3. 风险场景清单注入：把历史缺陷库、高频踩坑点、业务禁忌规则做成 prompt 知识库，比如幂等、并发、重复提交、跨租户、权限越权、事务回滚，强制 Agent 优先覆盖；
4. 组合爆炸控制：分支太多的时候，不盲目全量枚举，采用等价类 + 正交试验策略，优先覆盖高风险组合，低风险组合做抽样，避免用例泛滥。

第三，覆盖度校验，用来发现漏掉的场景： 生成完用例之后，我们会反向做覆盖率对账：

• 接口层：核对入参分支、枚举值、状态流转有没有都被用例命中；
• 业务层：对照前面拆解出来的分支清单，标记哪些分支已经有对应的用例，哪些是缺失缺口； 缺口清单直接抛给测试人员，由人判断：是不需要覆盖，还是需要补充用例。

重点：不是 AI 自己判断有没有覆盖，而是 “拆解清单” 和 “生成用例” 做比对，把遗漏点显性化。

第四，人工闭环 + 持续迭代，解决隐性规则。 需求文档里很多隐性逻辑、业务潜规则、历史兼容逻辑，文档不会写，AI 看不到。所以：

• Agent 输出的是初稿，不是终稿；测试同学重点核对：隐性约束、业务风险、跨模块联动场景；
• 评审发现的遗漏场景、错误用例，全部回流到 Agent 的示例库 / 知识库，作为 Few-shot 样本，持续优化 prompt 和拆解逻辑，同类问题下次减少漏场景。

最后我也会主动提局限性： 对于强耦合、复杂业务、多系统联动、产品口头约定的特殊规则，Agent 依然很难自动识别，这部分的兜底责任还得是测试专家，Agent 是辅助拆解和生成，而不是替代覆盖设计。

可能的追问

如果需求本身写得模糊，Agent 会不会生成一堆无效场景？

建议问题：Agent 识别到需求歧义点时，我们设计了一个机制：先抛出疑问清单，而不是自行脑补假设去生成用例，由测试找产品确认之后再继续生成，避免基于错误假设产出一堆错的用例。

面试题三

面试官问：覆盖度检查只能代表需求维度覆盖，不等于逻辑正确，怎么解决？

面试口述完整思路

您说得非常对，这也是我们落地时踩过的坑：覆盖率检查只能解决「有没有覆盖这个分支 / 场景」，也就是覆盖广度；但覆盖上了，不代表用例的逻辑、预期、业务规则是对的。覆盖度 ≠ 正确性。

我们的方案是把两个事情分开：

1. 【覆盖检查】：管广度 —— 有没有漏掉分支、边界、状态
2. 【逻辑正确性校验】：管深度 —— 这条用例本身的判断、预期、流转、约束是不是符合业务真实逻辑，这块是另一套独立校验链路，分四层做。

第一层：结构化元数据做硬校验（确定性规则，机器自动卡） 把接口 Schema、枚举字典、数据库约束、状态流转图、配置规则作为知识来源，而不是靠模型脑补。 比如：

• 字段类型、长度约束、必填校验、外键约束，和接口文档对比；
• 幂等、唯一键、金额计算这类可计算规则，自动校验预期值是否符合计算公式。

这一层的特点：有标准答案，规则可代码化，不依赖大模型主观理解，优先在这里拦截低级逻辑错误。

第二层：业务规则校验器（规则引擎 + 知识库） 针对固定业务约束，我们沉淀了业务规则库，写成规则，不是交给模型自由发挥。 比如：退款金额不能大于原支付金额、未结算订单不能销户。 Agent 生成预期结果之后，会送入规则引擎跑一遍：如果用例的操作 + 预期违反了业务规则，直接标记【逻辑冲突】，返回错误提示给 Agent 重生成。

第三层：用例自洽校验 + 因果推理校验（大模型负责复杂逻辑审查） 适合没有办法写成硬代码规则的复杂业务逻辑，交给一个专门的「评审子 Agent」，它不生成用例，只做审查，固定问 3 类问题：

1. 前置条件、操作步骤、预期结果之间有没有矛盾？比如前置是订单已取消，操作写发起支付，预期写支付成功，属于自相矛盾；
2. 这个操作带来的上下游联动是否合理？比如退款成功之后，优惠券、积分、库存的联动是否符合业务逻辑；
3. 有没有违反隐性风险规则，比如资金类场景是否存在超扣、重复入账。

这里要注意：模型审查只是告警，不能作为判定正确的依据，只输出风险疑点清单，交给人复核。

第四层：人工分级评审 + 回归闭环，解决最核心的 “隐性业务逻辑” 硬规则、规则库、模型审查都只能处理文档化、沉淀过的逻辑。 很多业务逻辑是历史兼容、口头约定、特殊例外场景，没有写进文档，也没有进规则库，机器识别不了。 所以我们做分级评审：

• 低风险、通用基础场景：机器校验通过即可，抽查；
• 资金、权限、结算、核心链路：测试专家必须逐条核对业务逻辑正确性； 评审发现的逻辑错误，分两条回流： ① 如果是通用规则，补充到规则引擎 / 元数据，后续自动拦截； ② 如果是特殊业务例外，存入 Few-shot 样本库，下次同类场景 Agent 生成时参考。

最后补充边界，主动暴露局限性（加分项）： 这套体系依然不能做到 100% 自动保证逻辑正确。它的目标是：把低级、确定性的逻辑错误自动化拦截，把人的精力从查分支有没有漏，转移到校验复杂业务逻辑、特殊例外场景上。

面试题四

面试官问：这套测试用例生成 Agent 方案本身存在什么问题？

面试口述完整思路

这个 Agent 我们给它的定位，主要是用于解决标准化、显性规则类用例的提效，当然它不是万能的，这套方案我们在落地过程中，确实有几个绕不开的短板，越是复杂、隐性、强业务语义的场景，短板越明显，我一个个说：

1、依赖输入素材质量，输入脏，输出就一定差（最核心痛点）

整套流水线的起点是：需求文档、接口文档、知识库。

• 如果需求描述模糊、前后矛盾、缺少前置约束；接口文档更新不及时、和线上代码不同步；
• 它拆解清单的时候就会拆错分支、漏条件，基线本身就是错的。 后面的对账、正确性校验，都是在一个错误基线上面做检查，属于 “错的全覆盖”。
• 隐性口头约定、历史兼容逻辑，文档没有写，Agent 天然感知不到，必须靠人补充。

2、规则引擎、知识库、Few-shot 样本持续维护成本高，容易变成技术债务

前面我们提到：Schema 校验、状态流转规则、业务约束、缺陷样本库，都是正确性校验的核心。

• 业务频繁迭代、产品规则经常改，规则库、枚举、状态机要同步更新；一旦更新滞后，就会出现大量误拦截、漏校验；
• 业务多、模块多的时候，规则会爆炸，不同业务线规则不一样，很难一套通用规则；
• 样本库如果持续堆积，不做清理、分类，模型会收到冲突样本，输出不稳定，一会儿对一会儿错。 简单说：省了写用例的时间，但是增加了治理元数据和规则的工作量。如果业务迭代快、测试人力紧张，这块维护很容易跟不上。

3、复杂多条件组合、跨系统联动场景，推理能力不稳定

对于单接口、单状态流转、简单分支，效果很好； 但是遇到：多服务联动、分布式事务、异步回调、多角色多配置叠加、时序相关场景（先后操作顺序影响结果），大模型容易出现因果错乱：

• 能拆解出分支清单，场景也覆盖上了；
• 但是梳理不清楚上下游副作用、异步延迟、数据最终一致性，预期结果很容易写错；

4、校验链路有盲区，正确性校验无法做到完全自动化

我们分了三层校验：硬规则、规则引擎、评审 Agent：

• 硬规则只适合确定性的结构化约束；
• 大量业务逻辑属于 “软约束”，没法写成代码规则；
• 评审 Agent 本身也是大模型，它只能输出疑点，会误报、也会漏判。 也就是说：逻辑正确性的最终把关人永远是人，机器只能做过滤、降噪。 当业务复杂度高、新人经验不足的时候，评审环节依然有漏判风险，不会因为有 Agent 就自动规避。

5、产出物容易 “形式正确，但脱离实操”，可执行性依然有坑

虽然我们强制绑定模板、接口 Schema，但 AI 容易写出 “纸面可用” 的用例：

• 忽略真实测试环境依赖、特殊造数成本、数据隔离、权限准备、第三方 mock 依赖；
• 只考虑理想测试路径，不考虑测试人员实际执行时的卡点； 极端情况：清单覆盖齐全、语法校验全部通过，但是这条用例在测试环境根本跑不起来，需要大量改造。

6、人的能力退化风险，团队侧软问题

长期依赖 Agent 生成初稿，测试同学会慢慢减少自己主动做等价类、边界、状态分析的习惯； 新人如果直接依赖 Agent 输出，缺少用例设计的训练，识别异常、判断业务风险的能力会变弱； 评审的时候容易变成 “看一眼 AI 写的，直接放行”，把 Agent 的输出当成标准答案，放松审查，反而引入隐性风险。

7、模型本身的不确定性，输出不稳定

同样一份需求、同样的知识库，不同时间生成的清单、用例质量会波动； 这次拆解很完整，下次可能少拆一个分支； 给评审带来额外负担：每次都要重新仔细核验，没办法稳定信任输出。

面试题五

面试官问：用量上来之后，怎么持续保证 AI 生成用例正确？人工审核也有漏审风险怎么办？

面试口述完整思路

规模上来之后，肯定不能再单纯靠 “人工逐行审” 来兜底了，大体可以分成四块来讲：事前准入、事中多层校验（减少流入人工的错误）、评审机制改造（降低漏审概率）、事后观测与自动回流（漏出去的问题自动捕获反哺）

1、事前：分级准入，从源头减少错误流入

规模大了，最忌讳所有需求一股脑丢进 Agent。

1. 按业务风险、复杂度做准入分级
   • L1（低风险：普通查询、配置接口、简单 CRUD）：Agent 自动生成 + 自动化校验通过，抽查放行，不强制全审
   • L2（中风险：普通流程、简单状态流转）：Agent 生成 + 机器校验 + 抽样人工复核
   • L3（高风险：资金、权限、结算、分布式异步、核心交易）：Agent 仅作为初稿辅助，强制专家评审，甚至人工主导设计
2. 基线版本化管理 拆解清单、状态机、业务规则、枚举这些基准数据，做版本记录；需求变更时，先变更基线，再重新生成用例。 避免多人并行改需求、知识库混乱，导致同样的输入，输出随机漂移。
3. 输入质量门禁 增加前置检查：需求是否有歧义、接口文档是否和线上对齐、状态图是否缺失。识别到输入质量差，直接拦截，不进入生成流程，防止 “错基线批量产出错误用例”。

2、事中：机器校验分层加固，把大部分错误拦在人工评审之前（减少人工压力）

前面提到的硬校验、规则引擎、评审 Agent，规模化之后要做可量化、可告警、可统计，而不是简单输出疑点：

1. 确定性硬规则（Schema、状态流转、枚举、字段约束）：强拦截，不允许进入评审队列，直接打回重生成，这一层零人工介入。
2. 业务规则引擎：区分阻断型规则（退款金额不能大于原单）和告警型规则（非强约束建议）。阻断型不通过直接驳回；告警型标记风险标签，推给评审人重点看。
3. 独立评审 Agent 做疑点提取，不丢完整用例给人看，只丢高风险疑点片段 ，比如一份用例 20 条，Agent 只标出 3 条有风险的：“这条状态流转异常”“预期金额和规则冲突”。 人容易漏审，主要是因为枯燥、量大、逐行看，注意力涣散。通过这种方式，可以让评审人员不再通读全部用例，优先核查疑点，疑点无问题再看其余；聚焦式评审，大幅降低疲劳导致的漏审。
4. 同需求差分对比（非常适合规模化）需求迭代变更时，新版本 Agent 生成的用例，和上一版做 diff，只展示新增、修改、删除的用例和变更点。评审只看变更部分，不变的历史稳定用例免审。 这个手段在版本迭代场景下，对降低漏审效果很明显。

3、评审机制改造：用交叉、抽检、多人复核减少漏审

人工一定会漏，所以不能依赖单人一次评审就放行，靠机制降低概率：

1. 风险分级匹配评审策略
   • L1 低风险：机器校验通过后自动放行，后台随机抽检，抽检发现问题，直接回滚并优化 Agent 样本，不阻塞流程；
   • L2 中风险：单人评审 + 系统随机盲抽复核（一部分会随机派给第二个专家复核）；
   • L3 高风险：强制双人复核，两个人独立评审，意见不一致进入评审会议。
2. 评审 checklist 标准化，减少 “凭感觉评审” 给评审人固定检查清单：基线清单是否对齐、状态流转是否合规、上下游联动、异常边界、预期结果、造数依赖。 系统强制勾选，不允许直接一键通过，避免 “闭眼点同意”。
3. 评审痕迹 + 风险标签沉淀 每一条疑点、每一处修改，都打上标签：【基线错误】【模型推理错误】【业务隐性规则】，方便后续统计哪一类错误高发，定向优化知识库 / 提示词。

这里要坦诚：这套机制只能降低漏审概率，无法彻底消灭漏审，所以必须有事后兜底。

4、事后：执行侧、线上侧的观测闭环，捕获漏审出去的问题，自动回流

这是规模化持续保证正确最关键一环，也是很多方案缺失的：

1. 测试执行阶段的反馈采集 用例执行时，如果出现【预期结果和实际返回不一致】，区分原因：
   • 程序 bug：正常提缺陷；
   • 用例本身写错（Agent 生成错误、漏审放过）：标记为【用例错误样本】，自动进入样本库，同时触发告警给负责人； 这类错误样本，自动作为 Few-shot，同类场景下次生成时规避。
2. 线上漏测缺陷反向归因 线上出现缺陷，回溯：是不是属于应该覆盖的分支、是不是用例预期写错。 如果是 Agent 生成 + 评审漏审导致，归入负样本，同时检查基线、规则是否缺失。
3. 持续指标看板，监控 Agent 质量趋势，而不是只看单次结果 规模化之后要盯趋势指标，而不是单点：
   • 机器拦截率、评审疑点检出率
   • 评审阶段发现的错误密度
   • 执行阶段发现的用例错误率（核心指标，代表漏审流出率）
   • 不同业务模块、不同需求类型的错误分布 一旦某个模块用例错误率持续走高，自动告警，暂停该模块 Agent 自动放行，改为强制人工全审，先治理知识库。

面试题六

面试官问：大模型本身存在幻觉，为什么还用大模型做用例质量校验，而不是纯规则？这个矛盾点有没有考虑过？

面试口述完整思路

这个矛盾我们有重点考虑过的。

我们的策略是分层：能固化成确定性规则的，全部用规则引擎校验，优先用规则，避免大模型幻觉；只有那些复杂联动、业务因果、语义自洽这类很难写成规则的场景，才交给大模型评审 Agent。

也就是说，我们并不是用大模型替代规则校验，而是二者分工互补，各自只干自己擅长的事，并且有明确的权责边界。

下面还可以分层展开讲一下：

第一层：先分清两类校验对象，哪些适合纯规则，哪些规则很难写

1. 适合纯规则引擎（优先用，能写规则绝不交给大模型） 这类是确定性、硬约束： 字段类型、枚举范围、金额不能为负、退款金额≤原支付金额、必填参数校验、接口 Schema 约束。 这些条件边界清晰、不会经常变，写成代码 / DSL 规则， 在我们流水线里，这一层是强阻断层，优先跑，不经过大模型。只要命中违规，直接打回，不流入评审环节。
2. 很难写成纯规则，或者写规则成本极高的场景（才交给大模型评审 Agent） 这就是纯规则的短板：
3. 多服务联动、异步回调、上下游连锁影响；
4. 业务隐性约束、多条件交叉的业务因果；
5. 语义层面的自洽性检查：前置条件、步骤、预期之间有没有逻辑冲突；
6. 需求里的自然语言业务意图校验、风险场景识别（比如有没有越权、资损风险）。

第二层：怎么隔离幻觉风险

核心设计有三条：

1. 大模型只有 “疑点上报权”，没有 “放行 / 驳回的决定权” 规则引擎的结果是判定：通过 / 不通过，直接生效。而大模型评审输出给的是【风险疑问清单】。

2. 对大模型的疑点做分级，并且统计它的幻觉（误报）指标，用于持续收敛 ：

• 模型告警 → 人工复核后判定：真错误 / 幻觉误报 积累误报样本，持续优化 Prompt、增加 RAG 上下文、调整它的评审范围； 如果某一类问题模型误报率长期很高，直接把这个检查项下线，改成纯规则或者人工检查，不再交给模型。

1. 模型评审的输出，作为补充信号，不是唯一信号 一个用例最终能不能往下走，决策来源是：
   • ✅ 硬规则校验结果（最高优先级）
   • 🟡 大模型评审疑点清单（参考信号）
   • 👤 人工评审裁决

第三层：讲清楚边界和兜底，主动暴露局限，体现思考深度

我们有明确的红线： 凡是资损、权限、核心交易类的强校验，绝不依赖大模型评审，全部下沉到规则引擎。 大模型只用来处理那些：规则不好写、变更频繁、属于业务语义、因果推理类的软校验。

当然这个方案确实也存在短板，比如： 大模型有概率漏报（幻觉的另一种形式：看不出明显错误），所以我们不会因为模型没报疑点，就认为这条用例没问题。 所以配套了：抽样复核、变更 diff 评审、事后执行反馈闭环。

可能的追问

既然大模型会漏报，那它的价值是不是很低？

建议回答：价值体现在提前发现大量规则覆盖不到的隐性逻辑问题。很多跨模块联动、隐性业务约定，我们很难提前预知、提前写成规则。模型可以低成本批量扫描，帮人聚焦可疑点；它不能替代人，但可以降低人漏掉复杂因果问题的概率。

写在最后

最后从面试官的角度，说说这类问题该怎么答，侧重什么。

这类围绕 AI 项目的追问，问来问去想确认的就是一件事，这东西你有没有真做过。

数字被追问时，把口径和对照讲清楚，比提升百分比本身更重要；聊质量保障，说清机器拦哪层、人守哪层；问到方案短板时，大胆承认，能主动说出局限的候选人，面试官反而放心。别一味的甩出结论，记得要把过程讲出来、期间遇到什么问题又是怎么解决的，这些反而比结论更重要。