【AI Native开发-10】为什么“管理员删除成功”不是一套测试设计？

30 秒看懂这篇

“管理员删除成功、列表消失、弹窗出现”三条用例看起来完整，却可能同时漏掉权限、状态、并发和副作用。问题不在测试语法，而在没有从需求系统展开场景。

flowchart TB
    A["Spec 中的 REQ"] --> B["逐条展开六个维度"]
    B --> C["正常 · 权限 · 异常"]
    B --> D["边界 · 并发 · 副作用"]
    C --> E["Given / When / Then 文本用例"]
    D --> E
    E --> F["人审业务风险与隐含场景"]
    F --> G["REQ → TEST 追踪矩阵"]
    G --> H["再选择自动化层级"]

文本用例是产品、测试、开发与 AI 的共同评审面：AI 可以批量生成候选场景，人确认业务语义、风险与优先级。用例的价值在断言什么，而不是步骤写得多长。

本篇给出六维展开法、Given/When/Then 写法和追踪矩阵。REQ 推导是回归测试的骨架；探索性测试、可用性、性能与安全测试还可以从风险与质量目标另行补充，不必强行一一对应单条 REQ。

一个典型场景

删除文章功能要测了。你让 AI”给删除功能写点测试用例”，它很快给出一份：

1. 管理员删除草稿文章，成功
2. 删除后文章不在列表里
3. 删除时有确认弹窗

看起来没错，但这份用例漏掉了最危险的东西：

普通用户 / 未登录用户能不能删？（权限）
已发布文章能不能删？（状态约束）
重复点删除、同时发两个删除请求会怎样？（幂等 / 并发）
删除失败时列表状态对不对？（异常）
删除请求被拒后，文件到底还在不在？（副作用）
取消确认时到底有没有发请求？（非目标行为）

AI 给的三条全是” happy path “。这不是它偷懒，是你没给它推导用例的锚点。“写点测试”这种指令，它只能按最常见的正常流程铺。要让它测全，必须让它对着 Spec 的每条 REQ、按固定维度去穷举。

核心问题：为什么先写文本用例，不直接写测试代码

有人会问：AI 写测试代码很快，为什么还要多此一举先写一遍中文文本用例？

三个原因：

文本用例的评审成本极低。 看一句”普通用户删除应返回 403 且文件仍在”，任何人都能判断对不对；看一段测试代码，要理解 mock、fixture、断言，业务同学根本参与不了。文本用例让产品、测试、开发在同一张桌子上评审”测什么”。
文本用例是防漏的网。 在中文层面把”权限、异常、并发、边界”穷举一遍，比在代码层面补便宜得多。漏一条用例在评审时发现是改一行字，漏在自动化里是一个没被测的风险。
文本用例是自动化的稳定输入。 下一篇用 AI 把文本用例翻译成测试代码时，每条 TEST 都对应明确的 Given/When/Then，翻译就不会跑偏。直接让 AI 从 Spec 蹦到测试代码，中间缺了”测哪些场景”的显式决策。

一句话：文本用例回答”该测哪些情况”，自动化用例回答”怎么用代码测这些情况”。把两个问题混在一起，两个都做不好。

正确流程：从 REQ 逐条推导用例

本文的删除接口、HTTP 状态码和测试路径均为假想全栈项目示例；本博客当前没有这些运行时 API 或测试脚本，真实项目应先以代码和 package.json 核实。

第一步：列出需求追踪矩阵的骨架

把 Spec 里所有 REQ 编号列出来，作为用例的源头：

REQ-001  管理员可删除未公开文章（hide: true），删除后文章不可见
REQ-002  未登录返回 401；已登录但非管理员返回 403；两者均无副作用
REQ-003  已公开文章（hide: false 或缺省）不可删除，返回 409
REQ-004  删除前需二次确认；取消则不执行删除
REQ-005  删除后重新构建仍不存在
REQ-006  删除失败时，列表保持原状态，给出错误提示
REQ-007  目标不存在返回 404，重复删除无额外副作用

规则：每条 REQ 至少有一个用例覆盖；没有对应用例的 REQ，就是没被测的需求。

第二步：对每条 REQ，按六个维度展开场景

不要只写正常情况。对每条需求，依次过这六个维度，看哪些适用：

1. 正常（happy path）：满足所有条件，操作成功
2. 权限：不同角色（管理员/普通用户/未登录）、越权访问
3. 异常：操作失败（网络错、依赖失败、校验不通过）时的行为
4. 边界：状态边界（hide: true 未公开 / hide: false 已公开）、参数边界
        （不存在的 id、非法 id）、空值
5. 并发 / 幂等：重复提交、同时提交、重试
6. 可恢复 / 副作用：操作后系统状态对不对？
        失败后数据有没有被破坏？不该发生的副作用有没有发生？

以 REQ-002（仅管理员可删除）为例，展开权限与异常场景；管理员成功路径则归 REQ-001：

TEST-001-1 正常：管理员删除未公开文章（hide: true）→ 成功，存储中文章消失
TEST-002-1 权限：普通用户直打删除接口 → 403，文件仍在（副作用）
TEST-002-2 权限：未登录调用删除 → 401，文件仍在
TEST-002-3 权限：普通用户伪造 admin 角色参数 → 服务端仍按真实身份拦截 403，文件仍在
TEST-007-2 异常：删除不存在的 id → 404，无额外副作用

注意权限用例都带副作用断言——不只是“返回 403”，还要直接确认受控存储中的文件还在。这是文本用例最容易漏、也最有价值的部分。

第三步：用 Given/When/Then 写清楚

每条用例用统一结构，避免”步骤写一堆、预期一句话”：

TEST-002-1 普通用户不能删除未公开文章（权限 + 副作用）
Given 普通用户已登录，存在一篇未公开文章（hide: true，id=A1，文件存在）
When   该用户调用删除接口 DELETE /api/articles/A1
Then   接口返回 403
And    直接检查受控存储，文章文件 A1 仍然存在
And    列表中该文章仍可见
And    没有任何删除相关的副作用发生（图片、索引不受影响）

TEST-003-1 已公开文章不可删除（状态边界）
Given 管理员已登录，存在一篇已公开文章（hide: false，id=A2）
When   调用删除接口 DELETE /api/articles/A2
Then   接口返回 409（或约定的业务错误码）
And    文章文件 A2 仍然存在
And    错误提示说明"已公开文章不可删除"

TEST-004-1 取消确认不执行删除（非目标行为）
Given 管理员已登录，在列表页点击未公开文章的删除按钮
When   弹出确认框后，点击"取消"
Then   不发起任何删除请求（断言：无 DELETE 请求发出）
And    文章文件仍然存在

TEST-007-1 重复提交删除的结果明确（并发/幂等）
Given 管理员已登录，存在一篇未公开文章（hide: true，id=A3）
When   短时间内连续发起两次删除请求
Then   第一次返回成功；第二次返回 404（文章不存在）而非 500
And    系统不出现重复操作导致的错误状态

TEST-004-1 值得专门说：它断言的是**“什么都没发生”**。这类用例最容易被漏——大家都想着测”点了确认能删”，没人想测”点了取消是不是真的没动”。但 REQ-004 的本质就是”取消 = 无副作用”，不测它，这条需求等于没验证。下一篇会看到，这个用例在自动化里用 Playwright 监听 DELETE 请求来实现。

第四步：人审业务风险和遗漏

AI 可以按 REQ 和六个维度批量生成候选场景，人则应重点审查业务里的隐含假设与风险接受：

人工审查必问：
- 文章引用的图片 / 附件是独有还是共享？保留、删除还是先做引用检查？
- 删除后，文章的 URL、列表、标签、搜索结果应怎样表现？
- 是否需要审计？谁删的能否追溯？
- 是否存在误触、批量操作或关联数据风险？

AI 也能提出这些问题，但不能替业务确认答案。文本用例阶段让产品与熟悉系统的人参与，能以较低成本识别规则空白；发现“共享图片如何处理”这类问题，应回流 Spec，而不是在测试里临场决定。

需求追踪矩阵（测试侧）

文本用例完成后，形成 REQ → TEST 的追踪表：

REQ 编号   需求摘要              覆盖用例
REQ-001    管理员删未公开文章成功  TEST-001-1
REQ-002    仅管理员可删除        TEST-002-1, TEST-002-2, TEST-002-3
REQ-003    已公开文章不可删      TEST-003-1, TEST-003-2
REQ-004    取消确认不删除        TEST-004-1
REQ-005    删除后重建仍不存在    TEST-005-1 / 构建产物验证
REQ-006    失败时保持列表状态    TEST-006-1, TEST-006-2
REQ-007    目标不存在/重复删除    TEST-007-1, TEST-007-2

检查：
- 每个 REQ 至少有一个 TEST？           （无 = 需求覆盖缺口）
- 回归用例能否追溯到 REQ 或明确风险？  （防止无目的重复）
- 权限/异常/副作用是否得到风险匹配的覆盖？（不能全是 happy path）

这张矩阵会在后面一路延伸：TEST → 自动化代码 → 执行结果 → Verify 证据。它是整条测试线的脊梁。

每条用例要带的元信息

除了 Given/When/Then，用例还要标注：

TEST-xxx-<序号>
- 优先级：P0（核心，阻塞发布）/ P1（重要）/ P2（一般）
- 风险维度：正常/权限/异常/边界/并发/副作用
- 前置数据：需要什么状态的文章、什么角色登录
- 环境要求：是否依赖特定环境（如生产构建行为）
- 自动化建议：单元 / 接口 / E2E 哪一层（下一篇用）

优先级用来决定执行顺序和准出判断：P0 / P1 未闭合默认不得发布；P2 是否阻塞也必须按预先约定的风险接受规则决定，记录接受人、理由和补偿措施，不能仅因优先级较低就忽略失败。

文本用例准入准出

准入：

Spec 已过 Gate 1，REQ 编号齐全；
有明确的角色、状态、权限定义；
业务隐含场景经过人工确认（级联、审计、关联数据）。

准出：

每条 REQ 至少有一条可执行用例，矩阵无空行；
每条用例有明确的前置、操作、预期结果（含副作用断言）；
六个维度都过了一遍，权限 / 异常 / 边界 / 副作用类用例占比合理；
没有”应该正常""提示错误”这种模糊预期——预期必须具体到状态码、数据状态、界面表现；
隐含业务场景经人审过，发现的规则缺口已回流 Spec；
每条用例标注了优先级和建议测试层级。

测试设计反模式

反模式一：只写 happy path。 AI 默认倾向 + 人懒得想异常，导致用例全是”正常操作成功”。权限、异常、副作用才是 bug 藏身处。对策：六维度强制逐项过。

反模式二：预期结果写”功能正常”。 “删除后应该正常""提示错误信息”——这种预期无法判定通过还是失败。好的预期具体到：返回什么码、数据变成什么、界面表现如何。

反模式三：只断言动作，不断言副作用。 “返回 403”不等于”没造成破坏”。必须补”文件还在、数据没变、无副作用”。权限和异常用例尤其如此。

反模式四：跳过文本用例直接写代码。 看似省一步，实际把”测什么”的决策混进了”怎么测”的代码里，业务同学无法参与评审，遗漏场景直到上线才暴露。

回退与评审

规则矛盾、隐含场景或不可测验收回 Spec；预期与 Spec 不一致则修测试设计。AI 负责展开候选场景和维护矩阵，人确认级联资源、审计等业务空白、优先级与真实覆盖。

结语

测试用例的数量不重要，重要的是每条需求都有能检验它的场景。文本用例把“我觉得测过了”变成“我能指出 REQ-002 由 TEST-002-1～3 覆盖，并知道各自验证哪种角色边界”的那张网。

文本用例回答了”测哪些场景”。下一篇解决”怎么用代码把这些场景测起来”：怎么让 AI 把 Given/When/Then 可靠地翻译成单元、接口、E2E 自动化代码——为什么先选测试层级再写、为什么要复用项目现有的 fixture 而不是让 AI 新造一套、怎么断言业务不变量而不是绑定实现细节，以及怎么保证每条自动化用例都能回溯到它对应的那条文本用例。

.Sam