蔚来 AI 测试开发一面：上线准入、评测集分层与 Agent 线上评估

《面试题目》

1. 请做一下自我介绍
2. 如何判断一个 AI 功能是否达到上线要求？
3. 朋友圈三天可见，如何设计测试用例？
4. Bad case 如何定义，哪些问题应该加入 Bad Case 集？
5. 如何设计 AI 评测集的组成和分层方式？
6. F2E 自动化生成测试代码时，如何验证生成结果可靠？
7. Case 与接口映射自动化中，如何避免映射错误造成漏测？
8. 如何验证线上 Agent 的效果评估能够反映真实用户体验？
9. Git 测试用例库是否都应该由人工编写？
10. Figma UI 稿解析工具的测试重点有哪些？

《参考解析》

上线准入不能只看整体准确率。 判断一个 AI 功能能不能上线，顺序应该是：先明确适用范围、失败成本和不可接受风险，再按场景分别设门槛。评测要覆盖常见请求、边界输入、异常输入、对抗样本和历史线上问题，并按用户群体、业务类型、风险级别分层统计；关键是高风险错误要有单独的准入阈值，不能被大量简单样本的正确率抵消（一个总体 95 分的系统，如果偶尔给出高风险错误，依然不能上线）。离线通过之后还要灰度观察任务完成率、人工接管率、时延和投诉，一旦线上分布与离线明显不同就暂停放量重新评估。

Bad Case 的定义和入集标准。 合格样本要满足三条：能稳定复现、能暴露质量问题、有代表性或高风险。反过来，单纯因为表达少见、输出风格不同，不一定算 Bad Case——把风格偏好当成缺陷会让评测集迅速膨胀而失去信号。分类上建议按错误类型组织（事实错误、意图识别错误、工具调用错误、权限违规、格式不合规、拒答不当、上下文遗忘），每条保留输入、预期行为、实际行为、失败环节、严重级别和版本信息。入集时注意去重而非堆量：同一根因的大量近似样本只保留代表样本进核心回归集，其余进扩展集，否则回归集会膨胀却没有任何新增覆盖。

评测集要分层，而且要被管理起来。 组成上应同时包含真实业务样本、人工构造的边界样本、历史缺陷样本和安全对抗样本；分层可以按任务类型、输入复杂度、风险级别和数据来源。两条容易被忽略的纪律：一是训练/调试用过的样本必须与正式评测集隔离（否则分数会虚高），并保留一部分隐藏集定期轮换，降低团队针对固定题目优化的偏差；二是评测集要有版本管理和变更记录，新增、删除或修改样本都要说明原因，并评估新旧版本分数是否可直接比较。

自动生成的测试代码必须经过四道验证才能算「可靠」。 静态检查、语法检查、依赖检查、运行时验证缺一不可——能生成、能编译都不等于可靠。内容上要检查它是否覆盖真实交互路径、定位器是否稳定、等待条件是否合理、断言是否验证业务结果而不只是「页面元素存在」；同时要关注副作用：生成的代码会不会误删数据、重复提交、或调用真实生产接口。稳妥的做法是在隔离环境先跑，并与人工编写的基准用例对照；对不稳定的用例要记录失败率和失败原因，而不是靠加重试把问题盖过去（加重试只是让问题更晚暴露）。

映射自动化为什么会漏测，以及怎么防。 Case 与接口的自动映射不能直接当作覆盖结论——尤其当多个接口名称相似、或一个需求涉及多个接口时，错配会静默地造成漏测。防护手段有四条：映射要有可校验的依据（需求标识、接口定义、字段约束、业务流程节点）；给映射结果加置信度和人工确认状态；对「未映射需求」「无关联用例的接口」「一对多关系」生成差异报告主动暴露；接口变更后自动提示受影响的用例与需求范围。最后一条是抽样审计已映射项——「存在映射」不等于「映射到了正确的接口和业务场景」。

线上 Agent 评估怎么才算反映真实体验。 自动指标（成功率、延迟、工具调用、格式异常）适合看趋势，但判断不了「答案有没有真正解决用户的问题」，所以必须叠加人工抽检和用户反馈。抽检样本要按业务类型、风险级别、失败类型分层，避免只抽高频和简单请求；用户是否重复提问、是否中途退出、是否转人工可以作为辅助信号，但不能单独作为质量结论。另外线上问题要保留版本和链路信息以支持回放分析，同时做好个人信息脱敏与访问控制。

用例库该不该全人工写，以及 Figma 解析工具的测试重点。 前者不需要全人工，但关键场景和高风险断言必须由测试人员审核：AI 适合扩展边界组合、补充参数变化、生成数据准备脚本，人工更适合确认业务语义、预期结果和风险等级；无论来源如何都要过代码审查、稳定性验证和维护成本评估，并标记用例所有者、适用版本和依赖条件，避免失效用例长期留在主回归里干扰判断。后者（Figma UI 稿解析）的测试重点是：解析结果的完整性（页面、组件、文本、尺寸、颜色、交互标注）、同一组件在不同页面/状态/响应式布局下能否被正确识别，以及复杂图层、重复命名、嵌套组件这类脏数据下的鲁棒性——解析工具的 bug 会一路传导到下游生成的代码，所以宁可在这里测严一点。