AI 测试基础与 AI 辅助测试面试题

本文档包含 22 道 AI 测试入门 + AI 辅助测试方向的高频面试题，覆盖基础认知、AI 辅助生成用例与脚本、缺陷分析提效、视觉驱动自动化、主流工具与平台。AI 测试相关内容拆为四章，本章是第一章，后续 LLM/RAG、Agent/AIGC、ML 模型/AI 安全分别独立成篇。

一、AI 测试基础认知（8题）

Q1: 什么是 AI 测试？AI 测试与传统测试有什么区别？

答案：

AI 测试有两层含义，面试时最好先把这点说清楚再往下展开。

第一层是「测试 AI 系统本身」（Testing AI），对象是机器学习模型、大语言模型、Agent、推荐系统这类含有 AI 组件的产品。第二层是「用 AI 做测试」（AI for Testing），对象还是普通软件，只是借助大模型、视觉模型等手段提升测试效率。

跟传统测试比，AI 测试主要在三个维度不一样：

输出确定性。传统软件给定输入应当输出固定结果，可以用断言精确匹配；AI 系统输出有不确定性，同样输入可能给出不同回答，需要用相似度、范围、分布等"软断言"。

正确性定义。传统测试有明确的预期值；AI 测试很多时候没有唯一正确答案，要靠评估指标、人类判断、对比基线综合判断。

测试对象。传统测试关注代码逻辑；AI 测试还要关注训练数据质量、模型版本、Prompt、上下文、外部依赖（向量库、工具、模型 API）等更多变量。

Q2: AI 测试的两条主线分别解决什么问题？

答案：

可以理解为「攻」和「守」两条线，工程师同时要会两边，但偏重不同岗位会有差异。

「用 AI 做测试」（AI for Testing）解决效率问题。常见落点是用大模型自动生成用例草稿、自然语言驱动 UI 自动化、缺陷自动归类去重、根因分析、测试报告自动总结、评审摘要等，目标是把测试同学从重复劳动里解放出来。

「测试 AI 系统」（Testing AI）解决质量问题。常见落点是 Prompt 回归、幻觉检测、RAG 评估、Agent 路径校验、模型行为测试、安全合规测试、上线监控等，目标是让 AI 产品上线后不出大事故。

实际工作中两条线经常交叉，比如做 LLM 应用测试时也会用另一个 LLM 做 Judge，本质上既是「用 AI」也是「测 AI」。

Q3: 什么是 AI 测试金字塔？有哪些层次？

答案：

AI 测试金字塔是从传统测试金字塔演化来的，从下到上一般分四层：

最底层是数据测试。包括数据完整性、分布、标注质量、去重、敏感信息脱敏等，是模型质量的根基，"垃圾进垃圾出"这句话在 AI 项目里尤其成立。

中间一层是模型测试。覆盖模型功能（行为测试、CheckList）、效果指标（Accuracy、Precision、Recall、F1、AUC）、推理性能、可解释性、公平性等。

再往上是系统集成测试。把模型嵌进应用之后端到端测，比如 API 接口测试、上下文拼接、工具调用、向量检索、缓存、降级策略。

最顶层是业务/用户体验测试。从真实用户场景出发，看产品能不能解决业务问题，包括 A/B 测试、灰度、用户反馈、长期留存影响。

数量上跟传统金字塔一样，越底层越多越快、越顶层越少越贵；不同的是 AI 项目的"数据测试"通常占比最大，传统软件项目里反而是单元测试占比最大。

Q4: AI 测试工程师的能力模型包含哪些维度？

答案：

业内常见的 AI 测试岗位对能力的要求大概有五块：

测试基本功。传统测试方法、自动化、性能、安全这些底子要有，AI 测试不是凭空出现的新工种，而是测试能力的延伸。

AI/ML 基础。理解监督学习、无监督学习、深度学习、Transformer 架构、Embedding、向量检索、Prompt、RAG、Agent 等基本概念，不要求会写训练代码，但要看得懂论文摘要、能看懂模型评估报告。

工程能力。Python 是底线（绝大多数 AI 工具是 Python 生态），能写脚本、能调 API、能用 LangChain/LlamaIndex 之类框架做 PoC，能在 Docker/K8s 里跑起来评估流水线。

数据与统计直觉。能看懂混淆矩阵、能算 P-value、能识别样本不平衡、能判断评估结果是不是有统计显著性，避免把噪声当结论。

业务理解和沟通。AI 项目跨职能（算法、工程、产品、业务），测试同学常常承担"翻译者"角色，需要能跟算法同学讨论指标、跟产品同学讨论用户体验、跟业务方解释风险。

Q5: 为什么说 AI 系统的测试比传统软件更难？

答案：

主要难在四个地方：

输出不可预期。同样的输入跑两次结果可能不一样，不能用 assertEquals 一锤定音；要用相似度、阈值、分布判断，断言本身就需要更复杂的设计。

正确性边界模糊。一个对话回答到底"好不好"经常没有标准答案，需要靠评估指标 + 人工判断综合，主观成分高。

变更影响难追踪。Prompt 改一个字、温度调 0.1、模型升级一个版本、向量库重新索引，都可能让结果显著变化，回归成本极高。

依赖项多且不可控。模型 API 可能限流、外部知识库可能更新、工具可能升级，测试环境很难做到 100% 可复现，定位问题难度上一个台阶。

应对策略上常见的是建评估集、自动化评估流水线、用快照对比、Prompt 版本化、模型版本锁定，把"不可控"逐项收敛。

Q6: AI 测试中常见的"不确定性"问题如何应对？

答案：

不确定性几乎是 AI 测试绕不开的问题，常用的应对手段有几类：

控制变量。测试时把温度调到 0、固定随机种子、固定模型版本，让输出尽量稳定，方便回归对比。但要注意线上往往不会用 0 温度，所以这类测试只能验证"基本对不对"，不能验证"用户实际体验"。

软断言代替硬断言。不要求字符串完全一致，改成用相似度（cosine、ROUGE、BERTScore）、关键词命中、JSON 字段校验、LLM-as-Judge 等手段判断"是否合格"。

样本量与统计显著性。单条用例的偶然失败说明不了问题，要跑一组用例看通过率和分布，对比不同版本时用统计检验避免被噪声误导。

评估集分层。冒烟集、回归集、对照集、压力集分开管理，关键场景必须 100% 通过，长尾场景按通过率达标。

监控线上分布。把线上输入和反馈采样回流，定期更新评估集，避免离线测试与线上脱节。

Q7: AI 项目的测试生命周期跟传统项目有什么不同？

答案：

传统项目的测试生命周期通常是计划→设计→执行→评估→维护一条线，AI 项目在这条线上多了几个阶段。

数据准备与评估阶段。测试同学要参与数据集设计、标注规范制定、数据质量验收，相当于多了一个"测数据"的环节。

模型评估阶段。模型训练完成后要做离线评估，跟基线对比、跟竞品对比，形成评估报告作为是否可上线的依据。

灰度与 A/B 阶段。AI 模型很难一次性切流，多采用灰度发布、流量分桶、AB 实验，测试要参与实验设计和指标验收。

线上监控阶段。模型上线后要持续看核心指标、看数据漂移、看用户反馈，触发条件达到时回滚或重训，相当于"测试右移"在 AI 项目里更刚需。

整体上 AI 项目的测试更像产品研发的伴随过程，而不是传统瀑布里的"开发完才介入"。

Q8: AI 测试的核心评估维度有哪些？

答案：

跨场景看下来，AI 系统的评估维度大致可以汇成五组：

效果维度。看模型/系统输出是否准确、有用，比如分类准确率、生成质量、检索相关性、Agent 完成率。

性能维度。响应延迟、吞吐量（QPS/TPS）、显存占用、Token 成本、并发能力，跟传统性能测试类似但指标更细。

稳定性维度。同样输入多次输出的一致性、长时间运行的衰减、突发流量下的退化、外部依赖故障时的兜底。

安全与合规维度。对抗鲁棒性、Prompt 注入抵抗、内容安全（涉政涉黄违法）、隐私保护、合规标注。

公平性与体验维度。对不同人群、不同语言、不同场景的表现一致性，以及用户实际感受（满意度、留存、转化）。

具体项目按重要性挑核心几项做硬指标，其他做软指标和监控，不要追求所有维度都做到 100%。

二、AI 辅助测试用例与脚本（8题）

Q9: 如何用大模型生成测试用例？流程是什么？

答案：

用大模型生成用例是当下提效最直接的场景，常见流程分四步：

输入准备。把需求文档、PRD、接口定义、UI 截图、历史用例等作为上下文喂给模型。文档质量直接决定生成质量，必要时先让模型对文档做"可测性分析"，发现歧义提前澄清。

Prompt 设计。给模型角色（资深测试），明确任务（生成等价类/边界值/异常场景用例），约定输出格式（JSON、Markdown 表、Excel），举一两个示例（Few-shot）。常用方法学（边界值、判定表、状态法）写在 Prompt 里能显著提升质量。

模型生成。调用大模型 API（OpenAI、Claude、文心、通义、Qwen 等），如果用例量大，分模块分批生成，避免一次塞过多上下文。

人工审校与入库。生成结果不能直接用，要由测试工程师审一遍：补漏、去重、调整优先级、关联需求 ID。审完后导入用例管理系统。

成熟团队会把这套流程做成内部工具或平台，需求一变更自动触发用例草稿生成，测试同学只做审核和补充。

Q10: AI 生成的测试用例质量如何评估和把关？

答案：

不能盲目信 AI 生成的内容，要从几个维度做质量把关：

需求覆盖率。生成的用例是不是覆盖了所有需求点和验收标准，可以用矩阵图反查，未覆盖的让 AI 补一轮。

场景多样性。是否覆盖正常、异常、边界、极端、并发、安全等场景，AI 默认偏正向覆盖，异常和边界容易遗漏，需要专门提示。

可执行性。步骤是否清晰、前置条件是否完整、预期结果是否可验证，避免出现"系统应正常工作"这种含糊描述。

去重与合并。AI 容易生成相似度很高的多条用例，要做合并；可以用 Embedding 相似度做自动去重。

事实正确性。涉及业务规则、接口字段、技术细节时容易"一本正经胡说八道"，必须人工核对，必要时让 AI 引用文档片段以便溯源。

把关流程上推荐"AI 生成 → 自动去重 → 测试评审 → 业务/开发抽审 → 入库"，最后一步抽审是为了交叉验证，避免测试同学也被 AI 带偏。

Q11: 用 AI 辅助编写自动化脚本有哪些常见模式？

答案：

目前几种主流模式：

代码补全模式。在 IDE 里用 Copilot、Cursor、通义灵码这类工具，写脚本时实时补全。适合已有框架内写新用例，效率提升一般在 30%-50%。

自然语言生成脚本。给定描述（"打开登录页，输入账号密码，断言跳转到首页"），AI 直接生成 Selenium/Playwright 代码。适合快速 PoC，但生成结果通常需要调整定位器和等待逻辑。

视觉驱动模式。Midscene、Skyvern、Browser Use 等工具用大模型分析页面截图，直接根据自然语言指令操作元素，不需要写定位器。适合 UI 频繁变动的场景。

录制 + AI 优化模式。用工具录制基础脚本，再用 AI 做断言补全、参数化、用例拆分。

接口脚本生成模式。给 AI Swagger/OpenAPI 文档，让它生成接口测试脚本和 Mock 数据。

实战中很少只用一种，通常是"自然语言生成骨架 + IDE 补全细节 + 人工调优"组合用。需要注意 AI 生成的代码必须经过 review，否则容易混入低质量等待和不稳定定位策略，反而加大维护成本。

Q12: 视觉驱动 UI 自动化（如 Midscene、Skyvern）跟传统 Selenium 有什么区别？

答案：

两者的核心差异在「怎么找到元素」和「怎么决定动作」上：

实战里通常组合用：核心稳定流程用传统框架做高速回归，新功能、特殊页面、不易自动化的场景用视觉驱动方案。

视觉驱动方案的几个注意点：成本可控（评估每条用例 Token 消耗）、关键步骤加截图留底、对模型决策做日志记录方便复盘、必要时降级到传统方式。

Q13: 如何用大模型做缺陷自动归类与去重？

答案：

缺陷归类与去重是 AI 提效里收益最明显的场景之一，做法分两步：

去重判断。把新提交的缺陷标题和描述用 Embedding 模型转向量，跟历史缺陷库做相似度检索（cosine similarity），相似度高于阈值的提示"可能是已有缺陷"。常用工具是 Sentence-BERT、OpenAI Embedding、Voyage、BGE 等。

分类打标。把缺陷喂给大模型，让它判断模块归属、严重等级、缺陷类型（功能/性能/安全/兼容）、可能根因。可以用零样本（zero-shot）让模型自由判断，或用小样本（few-shot）给几个示例引导，分类准确率会显著提升。

落地时几个关键点：

阈值要可调，相似度太高会漏报、太低会误报，建议在历史数据上做 ROC 调优。

人工兜底，AI 给出建议但不替代人决定，提交者可以确认或拒绝合并。

闭环反馈，把人工判断结果回流，定期微调或更新 Prompt，让模型越用越准。

去重和分类的指标要持续监控，准确率突然下降可能是新模块上线、术语变化或模型漂移导致。

Q14: 如何用 AI 做缺陷根因分析？

答案：

根因分析是更深的应用，主要在缺陷量大、代码库复杂的项目里有价值：

数据准备。把缺陷描述、报错日志、堆栈、最近一段时间的代码变更（commit log + diff）、相关测试用例、监控数据汇总到一起，作为 LLM 的输入。

让 LLM 做关联分析。Prompt 里明确目标（找出最可能的根因和可疑代码位置），引导模型从堆栈往代码定位、从代码变更看是哪次提交引入的、从相似历史缺陷找类似根因。

输出建议。包括可疑模块、可疑函数、可疑提交、修复方向、需要确认的问题列表。

人工确认。开发拿到建议后做最后判断，结果再回流给模型作为反馈。

成熟方案如 Sentry、Datadog 的 AI Root Cause Analysis、自研的根因分析平台，都是这个思路的工业化版本。

注意几点：根因分析对上下文质量要求很高，日志和变更数据不全的话效果会差；模型给出的根因不能 100% 信，需要把它定位为"加速器"而不是"决策者"；涉及生产数据时要做脱敏。

Q15: AI 辅助生成测试报告与摘要的实践方法？

答案：

测试报告自动生成是 AI 在测试领域最容易落地的场景之一，因为输入结构化、输出格式相对固定：

数据采集。从 CI 流水线、用例管理系统、缺陷系统、监控系统拉取本次测试的全量数据：用例总数、通过/失败/阻塞数、缺陷新增数、严重缺陷列表、性能数据、覆盖率数据。

报告生成。把数据喂给 LLM，让它生成几个层次的内容：结构化数据（图表能用的）+ 自然语言摘要（执行情况、风险点、建议）+ 上下文比对（跟上次的差异、趋势分析）。

按角色定制。测试 Lead 看详细问题，开发看自己模块的失败用例，产品和管理层看摘要和趋势。一份数据多视角呈现。

自动分发。通过邮件、IM（飞书/钉钉/企业微信）、看板等渠道按订阅推送。

落地几个细节：数据准确性是底线，错的数据写得再漂亮也是负资产；摘要要保守，不要让 AI 编造没有的趋势或结论；关键风险点要醒目突出，不要被淹没在大段文字里；持续收集读者反馈，不断优化 Prompt。

Q16: 用 Cursor、Copilot 等 AI IDE 提升测试效率有哪些技巧？

答案：

AI IDE 用得好可以让测试同学的脚本编写效率翻倍，几个实操技巧：

充分利用上下文。Cursor 这类工具支持把整个项目纳入上下文，写新用例时让 AI 参考已有用例的风格和工具方法，避免每个用例都重新造轮子。

结构化提示。不要只说"帮我写个登录测试"，而是给清楚目标、技术栈、断言要求、命名规范、错误处理偏好。Prompt 越具体输出越准。

让 AI 帮你看代码。审核别人的自动化代码时让 AI 先做一轮审查，找出冗余等待、不稳定定位、缺失断言等常见问题，再人工复核。

让 AI 帮你迁移。框架升级、Selenium 4 升 Playwright、JUnit 4 升 JUnit 5 这类工作，AI 批量改造效率很高，人工只需要 review 关键变化。

让 AI 帮你解释。看陌生测试代码时让 AI 用自然语言总结逻辑、潜在问题、改进建议，比自己一行一行读快得多。

风险提示：AI 偶尔会写出能跑但有问题的代码（错的断言、Race Condition、信息泄露），所有 AI 产出都要走代码评审，不能因为是 AI 写的就放低标准。

三、AI 测试工具与平台（6题）

Q17: 主流 AI 测试与评估工具有哪些？分别解决什么问题？

答案：

可以按用途分四类，组合起来覆盖常见场景：

国内方面，字节的 Midscene、阿里的通义灵码、百度的文心一言评估、腾讯的混元评估等都在快速发展，企业内部也越来越多自研评估平台，把上面这些能力集成进自家流水线。

选型时看四点：跟现有栈是否兼容（语言/框架/CI）、是否支持自定义指标、社区活跃度、商业化与开源策略。

Q18: DeepEval 是什么？典型使用场景？

答案：

DeepEval 是 Confident AI 出品的开源 LLM 评估框架，定位是「LLM 应用的 PyTest」，让评估像写单测一样写。

它的核心能力包括：

内置指标。Faithfulness、Answer Relevancy、Hallucination、Toxicity、Bias、Contextual Precision/Recall 等十几种开箱即用的指标，都基于 LLM-as-Judge 实现。

自定义指标。支持用 G-Eval（基于 Prompt 的评估）或纯代码方式写自定义指标，灵活性高。

测试用例与数据集。可以写单条 testcase 或加载数据集批量评估，结果输出到本地或 Confident AI 平台。

CI 集成。提供 PyTest 插件，可以直接写 test_xxx 函数，跑 pytest 就出评估结果，方便接 GitHub Actions / GitLab CI。

红队测试（Red Teaming）。新版本提供对抗测试模板，自动生成攻击 Prompt 测试模型的鲁棒性。

典型使用场景：LLM 应用迭代时做 Prompt 回归、RAG 应用上线前做综合评估、模型版本升级时做对比测试、CI 流水线里做质量门禁。

Q19: Promptfoo 是什么？怎么用它做 Prompt 回归？

答案：

Promptfoo 是开源的 LLM Prompt 评估与测试工具，定位偏「Prompt 工程师的 PyTest」，跟 DeepEval 有重叠但更聚焦在 Prompt 层。

核心能力：

声明式配置。用 YAML 写测试用例和评估规则，不用写代码也能跑，对非工程背景同学友好。

多模型对比。支持同时跑多个模型/Provider（OpenAI、Anthropic、本地模型），生成对比矩阵，选型时特别有用。

丰富的断言。除了相似度、关键词、JSON Schema 校验，还支持 LLM Rubric（用 LLM 当裁判）、Code Eval（自定义 JS/Python 函数）。

CLI + Web UI。命令行跑评估，Web UI 看结果矩阵和详情。

CI 集成。可以阻断 Prompt 退化的合并请求。

做 Prompt 回归的典型流程：

把当前可用的 Prompt 写到 yaml；为每个目标场景定义测试用例（输入 + 预期断言）；引入新 Prompt 版本作为对比组；CI 跑 promptfoo eval；结果在 Web UI 里对比，新版本通过率不低于基线才允许合并。

适合场景：Prompt 频繁迭代的产品、需要做模型选型的项目、希望评估配置代码化的团队。

Q20: LangSmith / Helicone / Langfuse / TruLens 这类 LLMOps 平台的定位与差异？

答案：

这几个工具都属于 LLMOps 范畴，覆盖 LLM 应用从开发到上线的可观测性、评估、版本管理，定位略有差异：

LangSmith：LangChain 官方出品，跟 LangChain/LangGraph 框架深度集成。强项是调用链路追踪（Trace）、Prompt Hub 版本管理、评估编排、Dataset 管理。商业化产品（有免费额度）。

Helicone：定位 LLM 调用代理，所有请求经过它做记录、缓存、限流、成本统计。强项是不需要改代码就能接入（改 base URL 即可），适合快速接入做监控。开源 + 云服务双模式。

Langfuse：开源 LLMOps 平台，类似 LangSmith 的开源替代。提供 Trace、Prompt 管理、评估、用户反馈收集等能力，可以自部署，对数据敏感的企业很友好。

TruLens：TruEra 出品的评估专精平台，强项是 RAG 评估、反馈函数（Feedback Functions）、多模型对比，跟 LangChain、LlamaIndex 集成度高。

实际选型时按数据合规要求、技术栈、预算综合考虑，必要时混用（如自部署 Langfuse + 用 Promptfoo 做 CI 评估）。

Q21: 如何选型 AI 测试工具？评估维度有哪些？

答案：

选 AI 测试工具跟选其他工具的逻辑类似，但要多关注几个 AI 特性维度：

场景匹配。先想清楚要解决什么问题（Prompt 回归、RAG 评估、Agent 测试、模型监控、UI 自动化），不要被「全能工具」忽悠。多数情况下专精工具组合优于一站式平台。

模型与框架兼容。是否支持你用的 LLM Provider（OpenAI、Claude、Bedrock、本地模型）、是否兼容你用的 LangChain/LlamaIndex/自研框架、是否支持你用的语言（Python/Node/Java）。

可观测性与可调试性。能不能查到每次失败的完整上下文（Prompt、模型、输出、评分理由），能不能在失败时方便定位到原因。

数据合规与部署模式。涉及生产数据的评估优先选支持自部署或私有云的方案；纯研发阶段 SaaS 可以接受。

成本可控。LLM-as-Judge 类评估每条用例都要调 LLM，规模大时成本不低，要算清楚每月评估预算和缓存策略。

社区与持续性。这类工具迭代非常快，半年前热门的工具可能已经被新工具替代，看社区活跃度、Star 数趋势、商业化支撑。

学习曲线。团队当前能力下手成本，能不能在两周内跑通一个真实场景。

Q22: 在传统 CI/CD 流水线中如何集成 AI 测试？

答案：

把 AI 测试接入 CI/CD 是让评估持续化的关键，常见做法是分层介入：

提交时（Commit / PR）。跑轻量级评估：Prompt 单元测试、关键场景 LLM-as-Judge、低成本指标。目标是几分钟内反馈，阻断明显劣化。常用工具是 Promptfoo / DeepEval 的 PyTest 插件。

合并前（Merge Request）。跑回归集，覆盖更全的用例和指标，包含 RAG 端到端评估、关键 Agent 场景、性能基线对比。可以用 CI 的并发能力跑批量评估。

发布前（Pre-release）。跑全量评估和压力测试，包括对抗测试、安全测试、长链路 Agent、上线 Checklist。耗时可以更长，结果作为发布门槛。

发布后（Post-deploy）。线上监控 + 采样评估，把真实流量回流做离线评估，发现问题及时报警和回滚。

落地几个关键点：

成本控制。LLM 评估按调用计费，要做缓存（同样 Prompt 不重复跑）、采样、夜间跑全量。

结果可视化。评估结果接到看板，趋势看得到，劣化才好预警。

阻断策略。哪些指标必须 100% 通过、哪些只需达到阈值、哪些只是参考，要事先约定，避免 CI 经常红被忽略。

模型版本锁定。CI 里要固定模型版本和参数，避免「环境的事让评估不可复现」。

把 AI 评估当成一类新的"测试"看待，沿用 CI/CD 一切既有最佳实践（覆盖率、阻断、报告、复盘），不要从零造一套流程。