配额只是 API 契约的一部分：计数事件、身份范围、时间窗口、重置规则和客户端提示共同决定场景能检查什么。只有输入契约明确规定时，才把特定状态码或 Retry-After 当作预期。

为什么需要这个 Skill

API 限流测试把已记录的配额规则转成可追溯的场景候选。评审可以在实际执行前发现身份范围、计数事件、窗口边界、突发额度、响应提示和恢复规则中的缺口。

Skill 用来做什么

当团队需要围绕“配额身份、窗口边界、突发流量、响应元数据、重试时机和恢复”设计有限范围的评审时，使用 API 限流测试 Skill。它整理场景候选和证据需求，不负责执行。

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

有效的初步设计会记录配额上限 N、计数事件、身份键、窗口算法、时间来源、突发额度、重置行为和响应契约。规则明确时，可比较 N-1、N、N+1、契约允许范围内的控制请求、窗口边界、突发流量、另一个身份以及恢复情况。计数或时钟规则缺失时应列为待确认项，不凭惯例补齐。

适用场景包括：团队需要重复评审配额身份、窗口边界、突发流量、响应元数据、重试时机和恢复；多个证据来源互相矛盾；交接时必须说明哪些内容仍未验证。

它不做什么

API 限流测试 Skill 可以组织配额策略、证据和下一步动作，但它不能替代：

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

它主要检查哪些内容

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

证据范围从来源材料提取候选检查
配额账本上限 N、成功/拒绝请求中哪些事件计数、用户/租户/路由键、窗口和时间来源计数规则明确时比较 N-1、N、N+1；保留一个契约允许范围内的控制请求
突发与重置文档中的突发额度、算法、重置规则和边界语义检查约定的突发及窗口前/中/后情况；不推断固定、滑动或令牌桶算法
响应与重试契约规定的状态、剩余额度字段、重试提示、客户端预算和副作用仅检查契约承诺的字段；把遵循提示的重试、总重试预算和失败请求是否计数保留为候选
隔离与恢复身份维度以及对其他主体的预期影响一次只比较一个身份维度；检查未受影响主体和过早/过晚恢复

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

开始之前先审计输入

围绕配额契约开始分析时，先把输入分成六种状态。缺口不会自动变成失败，但也不能被隐藏在结论里。

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

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

从问题到结构化发现

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

分层写法

围绕限流判断，不要把四种语气揉成一句“建议通过”：

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

一个完整案例

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

输入

材料这次提供什么缺失时怎么处理
限流契约配额、计数事件、窗口算法、突发额度、身份键、重置和响应字段未文档化的规则标为缺失，不补入惯例默认值
场景边界主体、接口、获准环境和允许流量将建议场景与真实负载或测试执行分开
恢复证据契约规定的重试提示、剩余数量、时间来源和恢复条件缺少时钟或重试规则时保持未评估

可以这样调用：

请使用 api-rate-limit-testing Skill。

任务：为一个同时存在用户级和租户级配额、浏览器客户端可能在达到限制后重试的报表导出 API 设计有证据边界的场景
输入材料：[需求、版本、链接、日志、报告或数据路径]
范围：[本次包含和排除的对象]
未知项：[缺失的环境、账号、数据或权限]
期望输出：[按风险排序的发现、证据状态和下一步动作]

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

分析

先为报表导出 API 设计一个范围有限的候选集。如果输入策略规定了用户级上限 N、计数事件和窗口，可列出 N-1、N、N+1 场景及一个允许范围内的控制请求。只有为区分契约规定的身份范围时，才增加第二个用户或租户。策略明确时再补充突发和窗口边界场景。只有契约承诺时，才把 429、剩余额度字段或 Retry-After 列为预期证据。没有真实运行记录时所有候选都标为 NOT_RUN；设计评审不应耗尽共享配额。

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

发现

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

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

当配额规则或场景需要可追溯判断时，使用 ARL-## 记录。下面的例子保留缺失策略细节，不声称测试已经执行。

ARL-01 字段报表导出的用户级配额
对象与前置条件报表导出的用户级配额；先确认真实上限、计数事件、窗口和时间来源，再设计边界场景
关注行为N-1、N、N+1 请求是否符合文档配额规则；状态码和响应头依赖契约
来源与证据状态未提供配额策略/版本：missing；候选为 NOT_RUN
影响与优先级依据证据说明受影响用户或租户；影响未知时由责任人确定优先级
负责人和关闭条件策略/API 负责人确认范围与计数语义；来源和预期结果可复核后关闭设计缺口
验证后续获准运行时记录身份、请求顺序、时间戳、原始响应和窗口后行为；取得记录前执行状态保持 NOT_RUN

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

决策

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

验证

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

发现如何进入下一阶段

交接产物

输出必须保留的信息示例状态
配额账本N、计数事件、主体键、窗口/时间来源和来源版本策略缺失时为 missing
场景候选前置条件、边界或突发行为、允许的控制请求、预期契约证据有运行产物前为 NOT_RUN
隔离/恢复其他主体是否受影响、重试预算和恢复条件规则或观察缺失时为 unassessed

没有运行记录时不要写“已通过”。设计阶段一次只改变一个身份维度；若来源定义了时间依据，就按该来源规划，并写清需要观察的限流期间与恢复后行为。规则缺失时记录缺口，不自行假设等待时间或状态码。

下一步路由

至少交付来源、证据状态、负责人、关闭条件和验证动作；下一阶段的结论仍受证据状态约束。

怎样准备更好的输入

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

这里补充信息会改变结果，因为配额身份、窗口边界、突发流量、响应元数据、重试时机和恢复必须接回证据，不能只靠熟悉的测试套路推断。

和其他 Skill 怎么配合

容易踩的坑

  1. 只测试一个身份。
  2. 忽略时钟偏差和重试响应头。
  3. 不检查未受影响用户和租户，就把 429 响应直接称为公平。

安装与调用

全局安装这个 Skill：

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

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

常见问题

限流测试必须使用真实配额吗？

这个 Skill 只设计场景，不消耗配额。后续经授权运行时，应使用隔离配额或可控策略，不要耗尽共享生产容量。

缺少 Retry-After 怎么办？

记录契约缺口。除非适用契约明确规定，不要假设 Retry-After、其他响应头、状态码或客户端等待时间。

参考

源 Skill 与执行契约

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

入口文件重点约束配额身份、窗口边界、突发流量、响应元数据、重试时机和恢复。要保留它的决策边界，不要把静态设计写成执行结论。

参考链接

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