AI 生成的测试套件可以有五十条写得很漂亮的用例，却漏掉“过期优惠券不能退款”这条规则。数量不能替代来源。

为什么需要这个 Skill

AI 生成测试评审要判断每条生成用例能否发现错误的生产行为。它把测试接回规则和风险，检查实际代码路径与断言，并追问哪种最小缺陷仍可能漏过。

Skill 用来做什么

只评审输入范围中实际找到或由用户指定的测试类型。逐条比较目标行为、实际执行的生产行为、可观察断言、期望值独立性、mock 边界和可能逃逸的缺陷。

Awesome QA Skills 按语言和测试阶段组织 Skill。系列总览 解释通用安装方式，本文只聚焦 AI 生成测试评审。

当 AI 编写的测试看起来合理、覆盖率有所增加，但回归保护、规则来源、数据隔离或维护风险还缺少证据时，可使用这个 Skill。

它不做什么

AI 生成测试评审 Skill 可以整理逐条判定和证据缺口，但它不能替代：

  • 业务或领域负责人对规则、范围和风险的确认。
  • 真实环境、账号、数据、日志或运行结果；静态分析不会自动升级为运行证据。
  • 发布、合规、生产操作和残余风险接受等授权决定。
  • 在输入相互冲突时替团队选择一个未经确认的事实。

它主要检查哪些内容

这个 Skill 的价值不在于把关键词再列一遍，而在于把每个关注点接到可观察的输入、判断和收口动作。先用源 Skill 已定义的输出字段整理一张小矩阵：

评审维度每条测试都要追问要保留的证据
范围与追溯实际有哪些测试类型？这条用例对应哪项规则/风险？测试位置、来源规则、版本或范围缺口
行为与预言机是否执行生产逻辑？断言了什么可观察结果？错误实现能否仍然通过？目标行为、实际路径、断言、独立期望值、最小逃逸缺陷
假绿灯风险被测对象是否被 mock？是否吞错？准备、数据、清理、等待或并行是否不安全？具体测试/代码证据和影响
逐条判定对真实回归有强保护、部分保护，还是几乎没有？STRONG、WEAK 或 FAKE，附置信度和理由
修复与优先级最小改动是什么，能让相关缺陷被发现？有证据的 P0/P1 问题或 P2 改进与验证顺序

如果某一行只有经验判断、没有来源或验证方法，就把它留在待确认项里，不要提前写成通过。

开始之前先审计输入

判断测试强弱前，先识别范围内实际存在的测试类型并分类已有证据。若没有测试代码或可审查测试，应报告范围缺口；不要评估一个模板，也不要把所有规则文件套成全局检查表。

状态含义本 Skill 的处理方式
known材料直接证明的事实标出来源、版本和时间，允许进入判断
missing本轮需要但尚未提供的材料列出最小补证动作，结论保持受限
conflicting来源之间互相矛盾并列来源和冲突点，交给负责人裁决
stale材料存在但版本或时间已经过期标出新鲜度，不把旧结论当当前事实
out_of_scope有关但不在本轮范围内明确排除，避免分析悄悄扩大
assumptions为继续分析而暂时采用的假设写出验证方式和失效条件

至少把输入版本、范围、环境、证据位置和负责人放在一起。没有运行记录时，只能交付分析、设计或验证计划，不能写执行通过。

从问题到结构化发现

先把来源、范围、证据状态、分析判断、责任角色、动作、关闭条件和验证方式连起来，再写结论。下面的案例保留这个 Skill 的专属编号和领域语境。

分层写法

围绕追溯矩阵，不要把四种语气揉成一句“建议通过”：

层次写法本文应用
事实材料直接显示了什么引用来源中的重点、版本、输入或运行记录
基于证据的推断多个事实共同支持的判断说明推断链，并保留不确定性
建议下一步最小动作是什么指定补证、复核、执行或回归路径
人工决策谁需要决定什么由负责人确认范围、风险接受、资源和发布含义

一个完整案例

本节按输入、分析、发现、决策和验证展开；材料不足时保留 missing、conflicting 或 assumptions，不把它们改写成通过。

输入

材料这次提供什么缺失时怎么处理
评审范围测试路径/类型、测试代码、被测代码、运行结果和框架没有找到可审查测试时，询问测试路径或类型
行为来源需求、验收标准、API 契约、风险和版本规则缺失时列为待确认，不虚构产品缺陷
测试机制数据、fixture、mock、期望值、清理、等待和并行执行只检查已发现测试类型中适用的机制

可以这样调用：


请使用 ai-generated-test-review Skill。

任务：评审提供的、用于促销引擎的 AI 生成 API 测试；该引擎组合客户等级、优惠券有效期和购物车金额门槛
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]

先审计输入。分开写事实、假设和待确认问题。没有运行记录时不要声称已经执行。

分析

这里只演示评审方法，本文没有提供真实测试套件。假设来源规则写明过期优惠券不得改变订单总额，而某条生成的 API 测试只断言 HTTP 200。先确认运行的是促销逻辑本身，而不是被测对象的 mock。如果生产逻辑确实执行，该测试可能为 WEAK：过期优惠仍可能被应用，状态码却保持 200。最小逃逸缺陷就是错误地应用过期折扣；修复应根据来源规则断言折扣被拒绝且订单总额不变。如果测试只调用 mock 的促销对象并检查预设响应，可能是 FAKE；先核对 mock 边界再分类。真实评审若缺少规则或测试代码，应保留未评估状态并报告范围缺口。

交接产物要同时保留输入版本、时间窗口、证据索引、负责人和下一次验证动作。Skill 可以整理不确定性，不能制造缺失的产物。

发现

示例发现：把一次问题写成可交接动作

下面的字段示例只展示记录方式，不代表真实环境已经执行。

每条待审测试都记录目标行为、实际断言及仍可能逃逸的最小相关缺陷。下面的示例依赖上文假设规则与测试，不是对真实仓库的发现。

评审字段假设的 API 测试记录
范围与来源过期优惠券 API 测试；假设来源规则要求过期优惠券不得改变订单金额
目标行为与实际断言拒绝过期优惠并保持订单金额；生成测试只断言 HTTP 200
逃逸缺陷API 仍返回 200，同时错误应用过期优惠
判定与置信度仅当生产促销逻辑实际运行时可判为 WEAK；若被测对象被 mock，需先核对边界再判断是否为 FAKE
证据缺口与修复检查测试代码、执行路径和独立期望金额；增加有来源支持的业务状态断言
优先级、负责人和验证只有影响证据支持时才定 P0/P1/P2；测试负责人确认最小回归检查并保留运行结果

这类记录的重点是让下一位同事能从发现回到来源，再执行一项能改变结论的动作。

决策

责任角色和待决策问题应由对应负责人确认；Skill 不替他们做风险取舍。

验证

关闭前按发现中的验证方式执行，并保留原始产物；没有执行记录时，状态仍然保持未验证。

发现如何进入下一阶段

交接产物

输出必须包含的信息示例状态
范围与证据找到的测试类型、评审路径、来源规则、版本和待确认问题无测试时为 scope gap
逐条判定测试名、STRONG/WEAK/FAKE、置信度、行为、断言、逃逸缺陷、结论按单条测试评估，不按套件数量打分
发现与修复有证据的 P0/P1 风险、P2 改进、缺失断言和修复方向没有影响证据就不定优先级
覆盖与验证适用路径、数据/隔离/清理风险、剩余风险和建议验证顺序没有证据时为 unverified

不要把通过数量或覆盖率直接当成质量证据。真正有用的测试会因正确的缺陷而改变断言：独立比较期望值，确认相关生产逻辑确实执行，并在来源契约要求时验证持久化结果或业务不变量。正向、失败、边界、权限/状态转换和恢复检查，只应用于已识别的测试类型。

下一步路由

逐条交接测试位置、来源规则、判定理由、逃逸缺陷、证据缺口、负责人、修复建议和验证顺序。测试缺陷、产品缺陷与缺失证据要分别记录。

怎样准备更好的输入

如果第一次调用只有一行目标，输出就应该保持受限。补充来源版本、受影响对象、环境、已知缺陷和决策负责人，才能从“看起来完整的清单”推进到可用评审。

和其他 Skill 怎么配合

容易踩的坑

  1. 把自然语言写得通顺当成需求覆盖。
  2. 接受无法区分正确与错误行为的预期结果。
  3. 因为措辞不同就保留重复用例。

安装与调用

全局安装这个 Skill：


npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/ai-generated-test-review -g

安装后使用 ai-generated-test-review Skill，并附上真实项目材料。

常见问题

评审者只看生成的用例可以吗？

不可以。需求来源才是依据，生成套件只是被评审对象。

每条生成用例都需要修好吗？

不需要。修复需要编造产品行为时，应删除没有依据的用例。

参考

源 Skill 与执行契约

完整执行契约位于 AI 生成测试评审 提示词。调用 Skill 前先阅读它；提示词定义了详细流程和输出契约。源目录 中还包含入口文件以及实际存在的配套资料。

入口文件重点约束来源追溯、编造行为、边界覆盖、预言机质量和维护成本。写结论前先阅读配套提示词，并保留这个 Skill 的决策边界。

参考链接

安全测试白盒测试背靠背测试本地化测试边界测试
分享