异常测试不是往接口里随便塞一串乱码。它应该明确说明 API 必须拒绝、保持不变或解释什么。

为什么需要这个 Skill

API 异常测试根据契约规则、边界、授权、状态转移和依赖行为设计失败场景。

Skill 用来做什么

提取字段类型、必填/可空规则、范围、长度与大小限制、身份/权限规则、错误契约和依赖行为，再将它们转成 ANT-## 候选，记录前置条件、关注行为、来源证据、验证方法、影响/优先级、责任角色和关闭条件。

字段约束与授权规则要分别追溯。遇到缺失、冲突或不适用的规则时，保留待确认项，不要臆造响应。候选数量不证明覆盖率，这个 Skill 也不执行测试。

Awesome QA Skills 按语言和测试阶段组织 Skill；系列总览 介绍通用安装方式。

它不做什么

它不会替代完整测试策略、补写 API 未定义的行为，也不会自行决定应该使用什么状态码。它也不会因为响应拒绝，就推断没有产生副作用；记录、事件和部分成功行为需要单独的证据。

它主要检查哪些内容

规则类别候选变体需要保留的证据
字段必填与类型缺失、null、空值、类型错误字段规则、有效邻近对照、响应和状态
数字或字符串限制低于、位于或超出有来源的边界；编码与大小约束来源、精确变体和响应
身份与权限错误主体、权限缺失、禁止访问对象授权来源、身份上下文、允许/拒绝结果
状态转移从不符合条件或终态发起请求状态规则、起始状态和最终状态
依赖与限流文档规定的故障或限流条件故障策略、重试含义和持久化副作用

对相互独立的规则一次只改一个因素。只有交互本身存在风险时才组合多种无效因素，并注明各因素对应的规则。保留有效邻近值，以区分正确拒绝与过度拒绝。

开始之前先审计输入

围绕“异常用例”开始分析时，先把输入分成六种状态。缺口不会自动变成失败，但也不能被隐藏在结论里。

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

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

从问题到结构化发现

ANT-## 发现字段

每个候选要注明约束或权限规则、输入变体、前置条件、允许/拒绝预期、响应与副作用观察、来源证据、证据状态、影响/优先级、责任角色、关闭条件和验证方法。字段规则与权限规则分别追溯；不要把不同无效类别合并为一个结果。

一个完整案例

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

输入

材料这次提供什么缺失时怎么处理
契约规则必填字段、格式、限制、枚举值和状态转移生成用例前先列规则
无效分区单个无效因素、组合无效因素和格式错误载荷保留拒绝原因
安全证据状态码、错误体、持久化记录和下游事件必须证明拒绝没有产生错误写入

可以这样调用：


请使用 api-negative-testing Skill。

任务：用格式错误行、超大批次、重复记录和非法状态转移挑战批量导入 API
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]

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

分析

先从一个边界清楚的小回合开始：用格式错误行、超大批次、重复记录和非法状态转移挑战批量导入 API。对导入行分别测试未知币种、负金额、重复外部 ID，以及更新已关闭账户的请求。除了断言错误契约，还要确认除非 API 明确承诺部分成功，否则有效行不会被部分提交。

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

发现

以下是记录格式示例，不是执行结果：

字段示例
编号与对象ANT-01 —— 批量导入中对已关闭账号的更新
前置条件与关注行为账号处于关闭状态；有来源的状态规则可能禁止这项更新
证据状态获取适用规则、响应和持久化状态查询前为 UNASSESSED
影响/优先级与负责人说明受影响记录或下游效果；指定 API/数据负责人；按项目标准评分
关闭条件与验证用可重复的隔离检查核验允许/拒绝结果、逐行持久化状态和事件账本

决策

由 API 或领域负责人确认状态和字段规则是否适用。如果导入契约未说明是否允许部分成功，就把事务决策留为待确认，不要假设所有写入都成功或全部回滚。

验证

在隔离环境中使用已批准的安全数据。将响应与适用规则比较，再查询相关记录和下游事件；仅凭拒绝状态码不能证明没有发生修改。

发现如何进入下一阶段

交接产物

输出字段它要回答什么示例状态
异常用例无效条件和预期拒绝对应规则来源
响应判断状态码、错误码、安全消息和可重试性客户端动作
变更检查不应变化的记录或事件状态证据

没有运行记录、查询结果或原始产物时，不要写“已通过”。好的异常套件是分区设计的，不是表演式的。先找出违反一条规则的最小输入，再只在交互本身有风险时增加组合。

下一步路由

将“约束到输入变体”表、有效对照、响应预期和状态变化检查交给执行者。候选设计、实际执行结果和未解决的事务策略应分别记录。

怎样准备更好的输入

提供有版本的 Schema、字段规则、授权模型、错误契约、限流或依赖策略，以及受影响记录和事件的证据。说明是否允许部分成功；若未知，就保留为契约缺口。

和其他 Skill 怎么配合

容易踩的坑

  1. 生成无效数据，却没有对应规则。
  2. 断言被拒绝，却忽略部分写入。
  3. 所有失败类别都使用同一个格式错误载荷。

安装与调用

全局安装这个 Skill：


npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/api-negative-testing -g

安装后使用 api-negative-testing Skill，并附上真实项目材料。

常见问题

异常测试应该直接打生产吗？

应使用隔离环境或获批准的安全数据；设计用例不等于授权破坏性请求。

无效组合要测多少？

覆盖独立规则和高风险交互即可，按影响排序，不按组合数量堆积。

参考

源 Skill 与执行契约

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

入口文件重点约束无效结构、边界值、禁止状态、授权、依赖失败和安全响应。写结论前先阅读配套提示词，并保留这个 Skill 的决策边界。

参考链接

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