测试用例

Test Case

也常被叫作：用例测试案例

验收与证据通常止于「测试」约 1 分钟读完

你可能会这么说

「每次改完东西，我都要手动把所有功能点一遍，太累了。」

测试用例 Test Case

一段写死的「给这个输入应该得到这个结果」，让机器代替你反复检查。

测试用例的本质是把一次人工检查固化下来，以后每次改动都自动重跑一遍。它最大的价值不在证明新功能对，而在证明旧功能没被改坏——这正是 AI 协作里最容易出事的地方：它为了实现你要的新东西，顺手动了别处。

一条用例三段：给什么输入、执行什么、期望什么结果。三段都要具体。「测试登录功能正常」不是用例，「输入正确的邮箱和密码，返回状态 200 且带上登录凭证」才是。

必须知道的边界：测试通过不等于功能可用。 测试是第 3 层证据，它常常直接调用内部函数，而真实用户是点按钮。一个 100% 通过的项目依然可以在真实入口下白屏。所以测试是省力工具，不是验收终点。

长什么样真实可交互，不是截图

测试：昵称为空时应该被拒绝
  给定：已登录用户
  当：把昵称改成空字符串并提交
  期望：返回错误「昵称不能为空」，数据库里的昵称没变

3 passed1 failed2 skipped

注意那个 skipped：被跳过的测试不算通过。看输出时别只看有没有红色。

拆开看，里面有这几块

1
前置条件 Setup
测试开始前需要准备的数据和状态。
2
执行 Act
调用哪个函数、发哪个请求、点哪个按钮。
3
断言 Assert
期望结果。没有断言的测试等于什么都没测——它只证明代码没崩。
4
清理 Teardown
把测试数据清掉，避免影响下一条。

常见的有哪几种

正常路径Happy path

一切顺利时的行为。必要，但远远不够。

用在：任何功能的第一条用例

边界与错误Edge / error cases

空值、超长、没权限、网络断。真实事故几乎都在这里。

用在：涉及输入、权限、钱、数据时必写

回归用例Regression case

从一个真实 bug 的复现步骤转化来的用例，保证这个坑不再回来。

用在：每次修完 bug

容易搞混？这样区分

测试用例 ≠ 验收标准 Acceptance criteria

验收标准给人看、决定收不收货；测试用例给机器跑、防止旧功能被改坏。一条验收标准通常派生出好几条测试用例。

看验收标准

测试用例 ≠ 测试覆盖率 Test coverage

覆盖率只统计「代码被跑到过」，不判断「断言有没有意义」。一堆没有断言的测试也能刷出很高的覆盖率。

什么时候用得上

修完一个 bug

把复现步骤变成一条用例。这是投入产出比最高的测试。

改动核心逻辑前

先给现有行为补几条用例，再改。这样你才知道自己有没有改坏。

AI 大范围重构后

重跑全部用例，看输出里有没有新的 failed 和 skipped。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】为 [某个功能] 补测试用例
【必须包含】
  1. 一条正常路径
  2. 至少两条错误/边界路径（[具体列出：空值 / 没权限 / 超长 / 网络失败]）
  3. 如果这次是修 bug：把我给你的复现步骤原样转成一条回归用例
【边界】不要改被测试的业务代码；不要为了让测试通过而放宽断言
【交付】
  - 新增了哪些测试文件
  - 运行测试的完整命令，以及**原始输出**（贴出来，我要看到 passed / failed / skipped 各几个）
  - 明确说明：这些测试调用的是内部函数还是真实入口
  - 哪些场景你没有覆盖

「说明调用的是内部函数还是真实入口」这一条很关键：它直接告诉你这批测试的证据只到第 3 层，还是能支撑第 5 层。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「测试」这层：有自动检查通过，但不一定是真实入口。

要亲眼看到这些，才算数

看原始输出里的三个数字：passed、failed、skipped。skipped 不是通过。
故意把业务代码改坏一处，重跑测试，确认真的有测试变红。永远不红的测试等于没有。
翻一眼用例名字，确认里面有错误路径，不是清一色的「正常返回」。
确认它没有为了让测试变绿而修改断言或删掉用例（问一句「你改过测试期望值吗」）。

它常这么糊弄你

「已添加完整测试并全部通过」——但断言写的是「不报错就算过」，等于没测。
为了通过而放宽期望值。这是 AI 面对失败测试时最常见的捷径。
「测试通过所以功能没问题」——这是把第 3 层当第 5 层。测试可能完全绕过真实入口。
大量 skipped 混在输出里，汇报时只说「没有失败」。

测试用例本身最多到「测试」层。想往上，必须有人从真实入口走一遍。

考考你选一个你觉得对的

AI 说「测试全部通过」。哪个检查最能识破无效测试？

想再深挖一点靠谱出处

Test case（测试用例）Wikipedia ↗Software testing（软件测试）Wikipedia ↗

# 测试用例 (Test Case)

> 一段写死的「给这个输入应该得到这个结果」，让机器代替你反复检查。

**你可能会这么说**：每次改完东西，我都要手动把所有功能点一遍，太累了。

测试用例的本质是把一次人工检查固化下来，以后每次改动都自动重跑一遍。它最大的价值不在证明新功能对，而在证明旧功能没被改坏——这正是 AI 协作里最容易出事的地方：它为了实现你要的新东西，顺手动了别处。 一条用例三段：给什么输入、执行什么、期望什么结果。三段都要具体。「测试登录功能正常」不是用例，「输入正确的邮箱和密码，返回状态 200 且带上登录凭证」才是。 必须知道的边界：测试通过不等于功能可用。 测试是第 3 层证据，它常常直接调用内部函数，而真实用户是点按钮。一个 100% 通过的项目依然可以在真实入口下白屏。所以测试是省力工具，不是验收终点。

**也叫**：用例、测试案例

## 你可以这样告诉 AI

```text
【任务】为 [某个功能] 补测试用例
【必须包含】
  1. 一条正常路径
  2. 至少两条错误/边界路径（[具体列出：空值 / 没权限 / 超长 / 网络失败]）
  3. 如果这次是修 bug：把我给你的复现步骤原样转成一条回归用例
【边界】不要改被测试的业务代码；不要为了让测试通过而放宽断言
【交付】
  - 新增了哪些测试文件
  - 运行测试的完整命令，以及**原始输出**（贴出来，我要看到 passed / failed / skipped 各几个）
  - 明确说明：这些测试调用的是内部函数还是真实入口
  - 哪些场景你没有覆盖
```

## 怎么验证他真的做到了

通常止于层级：**测试** — 有自动检查通过，但不一定是真实入口

- [ ] 看原始输出里的三个数字：passed、failed、skipped。skipped 不是通过。
- [ ] 故意把业务代码改坏一处，重跑测试，确认真的有测试变红。永远不红的测试等于没有。
- [ ] 翻一眼用例名字，确认里面有错误路径，不是清一色的「正常返回」。
- [ ] 确认它没有为了让测试变绿而修改断言或删掉用例（问一句「你改过测试期望值吗」）。

常见糊弄：
- 「已添加完整测试并全部通过」——但断言写的是「不报错就算过」，等于没测。
- 为了通过而放宽期望值。这是 AI 面对失败测试时最常见的捷径。
- 「测试通过所以功能没问题」——这是把第 3 层当第 5 层。测试可能完全绕过真实入口。
- 大量 skipped 混在输出里，汇报时只说「没有失败」。

来源：https://mickerbook.com/reference/t/test-case/