把踩过的坑固化成边界用例库

结论要变成可执行的检查。本文给出一条用例该有的五样东西（含「曾经的错误行为」）、用例的四个来源、让它不腐烂的四个做法与三个反模式。

踩过的坑要"固化"，而不是"记住"

每次线上出问题，团队都会开个复盘 ✔ —— 结论常常是"以后注意" ✗。

三个月后同样的问题再来一次 ✔，因为**结论没有变成可执行的检查** ✔。

**把踩过的坑固化成"边界用例库"** ✔：每条坑对应一个可复跑的用例 ✔。

```

① 输入（能复现问题的最小输入 ✔）

② 期望行为（正确的表现是什么 ✔）

③ 曾经的错误行为（当时发生了什么 ✔）

④ 关联信息（事故编号/日期/影响 ✔）

⑤ 归属（属于哪一类失败 ✔ —— 见失败分类那篇 ✔）

```

**第 ③ 项很关键** ✗→✔：它让后人理解"为什么要有这条用例" ✔，

否则容易被当成"多余的测试"删掉 ✔。

**线上事故**（每次事故至少一条 ✔）；

**人工审核的修改**（审核员改得最多的类型 ✔ —— 见审核队列那篇 ✔）；

**用户反馈**（点踩 + 人工确认过的 ✔ —— 见反馈回填那篇 ✔）；

**红队/对抗测试**（注入、越权、极端输入 ✔ —— 见红队那篇 ✔）。

**要点**：来源要与"实际发生过"挂钩 ✗ ✔，而不是凭空设计 ✔。

**进评测集**（每次改动都跑 ✔ —— 见评测接进 CI ✔）；

**有归属类别**（同类坑集中看，能发现系统性原因 ✔）；

**定期复查**（功能变了、用例过时了 → 更新或退役 ✔，但要留记录 ✔）；

**公开可见**（谁都看得见"我们踩过哪些坑" ✔ —— 这对新人是极好的教材 ✔）。

**复盘只写文档** ✗（没有可执行用例 ✔）；

**用例只增不整理** ✗（几千条跑不完，最后跳过 ✔）；

**用例没有"曾经的错误"说明** ✗（被当成冗余删掉 ✔）。

```

① 把最近 3 次事故各写成 1 条用例（共 3 条 ✔）

② 接进冒烟集（30 秒能跑完 ✔）

③ 以后每次事故/重大修改都补 1 条 ✔

④ 每季度整理一次：合并同类、退役过时 ✔

```

> 半年前那次事故的触发输入 ✔，今天能否**自动**被检查出来 ✔？

> 不能，说明复盘结论没有固化成用例 ✗。