# Backend Testing

> 单后端闭环测试执行器（stack-agnostic / project-agnostic）。当一个后端 feature 收尾、需要补 superpowers/spec-kit 开发期 TDD 与契约测试覆盖不了的后端结构性测试缺口时使用：先读项目栈 （package.json / pyproject.toml / go.mod / pom.xml 等）按栈实例化对应工具，再针对实际命中的缺口 RED→GREEN 补测并固化为回归。覆盖四类后端结构性缺口——真库数据层/迁移/事务/约束、鉴权与越权 （BOLA/BFLA）、并发/竞态/限频原子性、韧性/故障注入（重试/超时/降级）。触发词：单后端测试 / 后端缺口补测 / backend testing / 真库测试 / 越权测试 / 并发测试 / 韧性测试 / 后端集成测试 / 后端回归补测。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束（只写 tests/、断言 不可弱化、禁伪造修复、有界重试、产 PR 人审）。被 test-routing-advisor 在判定"单后端"时调用，也可直接触发。

- Skill: `fufankeji/backend-testing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fufankeji/backend-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fufankeji/backend-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fufankeji (https://skillmd.com/u/fufankeji)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fufankeji/backend-testing

---


# backend-testing · 单后端闭环测试执行器

## 这个 skill 解决什么

开发期 TDD（superpowers）和契约/spec 测试（spec-kit）覆盖的是"功能是否如规约工作"。
但后端有一类**结构性缺口**，它们不属于单个功能点、而属于系统的运行时性质——真实数据库行为、跨身份的访问控制、并发下的不变量、外部依赖故障时的韧性。这些缺口在开发期 TDD 里几乎不会被自然写到，等到生产事故才暴露。

本 skill 是这些缺口的**闭环补测执行器**：在一个后端 feature 收尾时被调用（由 `test-routing-advisor` 路由判定为"单后端"，或直接触发），把命中的结构性缺口用 RED→GREEN 补齐、固化为回归，并按蓝本纳入发布门。

> 关键洞：**code-review ≠ test**。代码评审只靠阅读发现问题、不生成可重复运行的回归；评审里"看出并修掉"的缺陷，没有固化成测试就会在下次重构中复发。本 skill 的产物是**能再次跑红/跑绿的测试**，不是一份评审意见。缺陷固化的方法论可复用 `superpowers:test-driven-development` 与 `superpowers:systematic-debugging`。

遵循 `testing-system-blueprint` 蓝本（按名引用即可）：风险分级排序、可追溯 ID、发布门、三层节奏。

---

## 两条绝对约束（先读，贯穿全程）

1. **stack-agnostic（栈无关）**：四类缺口一律用"**能力描述 + 按栈实例化 lookup**"表达，绝不把某一栈写死为唯一答案。每类能力都给多栈示例，并明确：**先读项目栈文件，再实例化该栈对应的工具**。项目用什么栈、装什么库，由项目自身决定，本 skill 只提供能力到工具的映射。
2. **project-agnostic（项目无关）**：不出现任何业务名词。允许使用通用后端概念（BOLA / BFLA / 真库 / 迁移 / 事务 / 约束 / 并发 / 竞态 / 限频 / 契约 / 故障注入）。

---

## 工作流（六步闭环）

### 步骤 0 · 识栈

读项目栈文件，确定语言与运行时，后续所有工具选择都基于此实例化：

| 栈线索文件 | 语言/运行时 | 后续工具来源 |
|---|---|---|
| `pyproject.toml` / `requirements.txt` / `setup.py` | Python | 见各缺口的 Python 行 |
| `package.json`（含 `tsconfig.json`） | Node / TS | Node 行 |
| `go.mod` | Go | Go 行 |
| `pom.xml` / `build.gradle` | JVM | JVM 行 |
| 其他 | 按需 | 用"能力"反查该栈生态等价物 |

> 找不到栈文件就停下来问，别假设。多栈 monorepo 则对被测后端目录就近识别。

### 步骤 1 · 条件命中（防过度测）

**不是四类全测**，只对该 feature 实际命中的子集补。逐项判断：

| 缺口 | 命中条件 | 不命中示例 |
|---|---|---|
| 真库数据层 | feature 涉及 DB 写入 / 唯一约束·外键·CHECK / schema 迁移 | 纯只读聚合、无迁移 |
| 越权 BOLA·BFLA | 存在多用户对象归属 / 特权（管理员）端点 | 单租户内部工具、无身份隔离 |
| 并发/竞态 | 存在共享资源争用 / 限频 / 配额 / 计数器 / 库存式扣减 | 无共享可变状态的纯函数式处理 |
| 韧性/故障注入 | 调用外部依赖（HTTP API / 第三方 SDK / 消息队列 / 远程缓存） | 纯本地逻辑、无外呼 |

纯逻辑 / 纯读的 feature 很可能只命中 0–1 项——这是正常的，不要硬凑。

### 步骤 2 · 覆盖区分

对每个**命中**的维度，先判断它是否已被开发期 TDD/契约测试覆盖，再决定是否补：

- `✅ 已被开发期 TDD/契约覆盖（跳过）`——别重复造。
- `🔧 结构性缺口（待闭环补）`——需要本 skill 补。对每个 🔧 再标注实例化方式：
  - `现成工具 ✅ 可装`——该栈有成熟库，装上即用。
  - `需自建 🔧`——该栈无即用方案，按模式自建 fixture/脚手架（越权类几乎总是这种）。

把这一步的结论写成一张小表（维度 / 命中 / 覆盖状态 / 实例化方式），作为后续补测的清单。

### 步骤 3 · RED→GREEN 闭环补测

对每个 `🔧` 缺口，逐个走：

1. **RED**：先写会失败的测试，确认它确实跑红（红得有意义——是因为缺陷/未覆盖而红，不是因为测试写错而红）。
2. **GREEN**：让测试跑绿。
   - 若缺陷是真实存在的（评审已发现但没固化），按 `superpowers:test-driven-development` / `superpowers:systematic-debugging` 修复产品码使其转绿。
   - 若只是缺覆盖（行为本就正确），补测后即应为绿，无需改产品码。
3. **固化为回归**：测试留在 `tests/`，进入回归集，下次自动跑。

> 具体工具与代码模式见 `references/gaps.md`，按步骤 0 识别的栈取对应行。

### 步骤 4 · 按蓝本归档

每个新增的回归测试：

- 按 `testing-system-blueprint` 的**风险分级**排序（高风险缺口优先、优先进发布门）。
- 挂**可追溯 ID**（关联 feature / 缺口 / 若有则关联缺陷来源）。
- 纳入**发布门**：明确哪些是阻断发布的（如越权可绕过、约束失效），哪些是告警级。
- 对齐**三层节奏**（蓝本定义的快/中/慢分层；真库与并发类通常落在较慢层，单测层只放纯逻辑）。

### 步骤 5 · 交付（产 PR · 人审）

补测以 PR 形式交付，**由人审核合并**，与蓝本及自愈护栏一致。PR 说明里列出：命中维度、跳过维度及理由、每个新增回归对应的缺口 ID 与风险级别。

---

## 四类缺口速览（详见 references/gaps.md）

1. **真库数据层 / 迁移 / 事务 / 约束**——能力：起真实 DB 容器 + 跑迁移 up/down 往返，断言约束、事务回滚、迁移可逆。
2. **鉴权 / 越权 BOLA·BFLA**——能力：造两个不同身份/权限的 token fixture，参数化遍历对象级与特权级端点，断言跨身份访问被拒（403/404）。**框架无关，几乎总是自建**。
3. **并发 / 竞态 / 限频原子性**——能力：并发打同一端点/资源，断言不变量与原子性（无超卖、无双花、限频准确）。
4. **韧性 / 故障注入**——能力：拦截外呼注入超时/错误序列，断言重试、超时、降级、熔断按预期生效。

每类都是"能力 + 按栈 lookup"——**读栈后实例化对应工具，而不是锁定单一栈**。

---

## 自愈护栏（不可越过）

补测过程允许有界自动迭代（RED→修→GREEN），但受以下护栏约束：

- **只写 `tests/`，不改产品码**——除非该缺口是评审已确认的真实缺陷且需 GREEN，此时改动须最小、可追溯、并在 PR 中单独说明。默认动作是补测，不是改实现。
- **断言不可弱化**——禁止为了让测试转绿而放松断言（如把 `403` 改成 `or 200`、把并发不变量删掉）。转绿必须靠正确的产品码或正确的测试，不能靠降低标准。
- **禁伪造修复**——不得用 sleep、mock 掉被测逻辑本身、跳过/`skip` 标记等手段伪装通过。
- **有界重试升级**——自动迭代有上限；连续失败达上限即停止并升级给人，不无限刷。
- **产 PR 人审**——所有产物以 PR 交付，人工审核后合并（可 reference 蓝本的审核约定）。

护栏的目的：让闭环可以自动跑，但任何"看起来绿了其实没测到"的捷径都被堵死。

---

## 与上下游的关系

- 上游：`test-routing-advisor` 判定"单后端"时调用本 skill（也可被用户直接触发）。
- 蓝本：所有归档/分级/发布门/节奏遵循 `testing-system-blueprint`（按名引用，不在此复制其内容）。
- 方法论复用：缺陷固化与调试复用 `superpowers:test-driven-development` 和 `superpowers:systematic-debugging`。