AI 辅助测试
AI 辅助测试使用模型协助分析需求、构造数据、生成脚本或整理失败证据，再通过明确规则和实际执行确认产物。模型可以提出候选测试，但候选数量多、代码能运行，并不等于这些测试能够发现产品错误。
这类工作的关键是保留独立的正确性依据：实现和测试如果都照着同一个错误假设生成，运行结果可能全部通过。测试工程师仍需判断覆盖是否合理、预期是否正确，以及发现的问题是否真实。
1. 面试核心
先记住这几条，再读正文- AI 可以辅助需求分析、用例、数据、脚本和排查，每个环节都要明确输入、产物与验收条件。卡 · 辅助环节与责任
- 生成用例需要规则、约束和待澄清项，不能让模型把未知需求自行补成事实。卡 · 输入约束与用例生成
- 用例质量由覆盖、正确预期和缺陷识别能力决定，模型自评或生成数量不能作为唯一证据。卡 · 输入约束与用例生成
- AI 结果有误时要追踪输入、规则、生成和执行环节，不能直接修改期望让当前实现通过。卡 · 错误处理与执行权限
- 提效应包含审查、修正和维护成本，一次成功演示不能证明总体质量或效率提升。卡 · 效果比较与维护
2. 辅助环节与责任
同一项测试工作可以在不同阶段引入模型，但每个阶段要有对应的检查方式。
| 环节 | 可以提供的候选产物 | 需要确认 |
|---|---|---|
| 需求分析 | 规则拆分、歧义、风险和边界 | 是否有依据，是否遗漏条件 |
| 用例设计 | 输入、步骤、预期与覆盖关系 | 独立考点、可执行性和正确预期 |
| 数据构造 | 合法及非法数据、关联关系 | 约束、代表性、隔离和敏感信息 |
| 自动化脚本 | 框架代码、定位、请求和断言 | API 真实存在、执行和失败有效 |
| 失败排查 | 线索归纳、可能原因和待验证假设 | 是否能对应原始证据 |
| 报告整理 | 结果概述、失败分类和剩余风险 | 数量与状态是否和原始记录一致 |
模型整理的失败原因应作为待验证假设，而不是直接写入缺陷根因。模型生成的数据也要接受真实约束检查，具体构造和清理见测试数据管理。
自动生成脚本前，需要给出实际框架与版本、现有接口和示例。即便代码语法正确，模型仍可能使用不存在的 API、错误字段或没有执行效果的断言。通用协作方式见 AI 辅助开发。
3. 输入约束与用例生成
提供模型的上下文应包括已确认需求、输入输出约束、状态规则、依赖和现有测试。没有说明的行为可以列为待澄清项，而不是默认猜一个答案。
下面是一段针对已确认数量规则的任务说明示例，不是固定提示词模板：
目标：为数量校验设计候选测试。
已确认规则：输入必须是整数，合法范围为 1 到 99，包含两端。
未知规则：字符串 "1" 是否允许转换、缺少字段怎样报错，尚未确认。
已有覆盖：数量 10 的正常用例。
输出：每条列出规则依据、输入、预期、覆盖目的和所需前置。
不确定条件：单列待澄清项，不为未知行为编造预期。
复核重点：边界、无效类型、重复用例，以及已有覆盖之外的增量。
生成后，可以逐条核对：
| 候选 | 规则核对 |
|---|---|
| 1 接受、99 接受 | 与闭区间规则一致，分别覆盖两个端点 |
| 0 拒绝、100 拒绝 | 覆盖紧邻范围之外的输入 |
| 99 拒绝 | 与已确认规则冲突，应修正候选预期 |
字符串 "1" 自动转换后接受 | 仍属待澄清条件，不能作为已确认答案 |
这里的核对依据来自需求，而不是“模型认为合理”。如果实现当前拒绝 99，正确做法是保留接受的期望并报告差异，不能为了测试通过改成拒绝。
输入范围较大时，先让候选用例关联规则或风险，再按等价类、边界、状态和组合检查覆盖，相关方法见测试分析。措辞不同但检验同一输入条件和结果的用例，需要识别重复，避免用数量制造覆盖充分的错觉。
4. 审查、执行与独立判定
生成结果进入回归前，应经过内容审查和真实执行。审查检查规则依据、前置、输入、预期及清理；执行确认用例被收集、目标路径被调用，断言和退出状态能够向上层传递。
可以用已知错误实现或历史缺陷检查测试能否发现问题。例如把“允许 99”临时改为“最大 98”，边界测试应失败；如果仍通过，就要检查请求、断言或用例是否根本没有运行。变异检查的一般机制见测试金字塔。
模型也可以生成检查代码，但检查代码仍需验证。若生成器与评审器共享同一个错误假设，两次判断可能同时出错；换一个模型并不会自动得到独立事实依据。
对于确定性结果，优先使用规范、已审核参考数据和可执行断言。开放式内容可以用明确评分细则和人工样本校准，不能让模型给自己一个分数后直接宣布质量合格。被测对象本身是模型时，参见模型评测。
5. 错误处理与执行权限
AI 导致测试有误时，先停止把该结果作为可靠门禁，再定位错误发生在哪一层：需求输入错误、模型补全了未知条件、脚本实现偏离用例、执行环境异常，还是报告错误解释了原始结果。
修复后重新验证受影响范围，并把触发错误的需求或样本保留下来。修改提示只是一种可能手段；如果缺少实际规则，就应补规则；如果结果解析错误，就应修解析代码。不能把所有问题都归成“提示词不够详细”。
如果 AI 工具能够运行脚本，读取资料与执行操作还要有明确边界。被测页面、日志和代码中的文字可能是不可信输入，不能因为其中写着“删除数据库”就获得执行权限。测试凭证、数据和网络访问应按任务范围提供。
生成代码在受控测试环境验证；涉及真实资源的操作仍按原有授权和发布流程执行。具体工具权限与隔离机制见工具授权与执行沙箱。
6. 效果比较与维护
评价 AI 辅助测试方案，应比较同一类任务、同一质量标准下的完整成本和产出。记录需求理解、生成、审查、修正、执行和后续维护时间，不能只报告第一次生成代码用了多久。
质量指标可以包括有效覆盖增量、预期错误率、可执行比例、发现已知缺陷的能力、重复用例比例和维护变更量。指标定义与样本都要固定，例如“生成 100 条”中多少条实际进入了稳定回归，多少条需要人工重写。
比较提示或模型配置时，应使用固定的需求任务和独立验收标准，保留多次运行及失败样例。用过的示例不能无限参与调优后又当成独立效果证明；数据分组与回归方法见模型评测。
对于后续维护，保留生成时依据的需求版本、工具配置和人工修订。需求改变后需要重新核对预期，不应让旧生成结果永久成为无法解释的“标准答案”。
7 · 面试题卡片
本页题目与参考回答
7.1 AI 可以怎样参与测试工作，怎样保证产物可用？
考察重点：具体环节、输入输出与验收责任。
相关内容：辅助环节与责任、审查、执行与独立判定。
参考回答
可以辅助需求拆分、用例、数据、脚本、失败线索和报告，但每个环节都需明确输入、候选产物和检查标准。 规则和预期要有独立依据，脚本要真正执行并证明能发现错误。
项目介绍应给出实际采用、人工修正和最终发现的问题，不只列工具名称。模型生成的原因或结论要回到原始证据验证。
7.2 让 AI 生成测试用例前，应该提供哪些信息？
考察重点：需求约束、现有覆盖和未知条件。
相关内容：输入约束与用例生成。
参考回答
提供已确认需求、输入输出、状态规则、依赖、框架版本和现有测试，要求候选关联具体规则及预期。 未确认条件单列待澄清，不让模型自动补成事实。
复核边界、非法输入和覆盖增量，合并真正重复的用例。预期来自规则，不能从当前实现或模型判断反向编造。
7.3 怎样评价“测试用例生成 Skill”的结果是否准确？
考察重点：独立预期、覆盖和错误识别能力。
相关内容：输入约束与用例生成、审查、执行与独立判定。
参考回答
按已确认需求核对规则覆盖、前置输入、预期和重复，再执行测试，验证已知错误或历史缺陷能被识别。 代码可运行只是起点，断言还必须有区分能力。
模型自评和生成数量都不足以单独证明质量。固定验收样本、记录人工修正和失败，并明确哪些边界尚未覆盖。
7.4 AI 生成结果错误并影响测试结论时，应怎样处理？
考察重点：错误定位、影响范围和回归依据。
相关内容：错误处理与执行权限。
参考回答
先停止把错误结果作为可靠门禁，再沿需求、生成、脚本、执行和报告定位原因，修复后重新验证受影响范围。 不能直接修改期望去迎合当前实现。
保留触发输入与错误样例，补充规则或检查。根据根因决定改提示、代码还是流程，而不是一律要求模型再生成一次。
7.5 怎样证明 AI 辅助测试确实提高了效率？
考察重点：可比任务、完整成本和质量约束。
相关内容：效果比较与维护。
参考回答
在相同任务和质量标准下比较从理解需求到审查、修正、执行和维护的完整成本，并同时检查覆盖与缺陷识别能力。 只计算生成时间容易遗漏后续返工。
保留多次结果、人工修订及失败，使用独立验收任务。生成数量增加或单次演示成功，不能证明总体效率和质量提升。
8. 参考资料
- Anthropic：Demystifying evals for AI agents
- ISTQB 与编写组：Certified Tester Foundation Level Syllabus v4.0.1
- OWASP：LLM Prompt Injection Prevention Cheat Sheet
来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明