# 从需求到测试点：一句话的需求，为什么能拆出十几个要验的东西

讲清测试依据、测试点、测试用例三个层次的分工，以及需求含糊、残缺时该怎么把它变成可验的清单

> 测试分析 · 需求与测试依据 · 测试用例设计 · 约 7 分钟 · 09 月 19 日

## 本篇要点

1. 测试依据是设计测试所依据的知识体，可能是需求、验收标准、设计文档、用户故事，也包括没有写下来的共识。
2. 测试分析是读依据、找出要验什么的活动，它的产出是测试点（测试条件）；测试设计才是决定怎么测，产出是具体的用例。
3. 测试点回答“要验什么”，用例回答“怎么验”，一份需求通常拆出多个测试点，一个测试点又长出多条用例。
4. 拆测试点的第一步是把复合需求拆成可以单独验证的原子规则，再对每个规则在正向、反向、边界三个方向追问可能出错的情形。
5. 需求里写明的限定词往往自带反面情形，比如“已登录用户”直接意味着“未登录”需要单独验；需求没提但用户默认的行为（大小写、空格、重复提交、依赖超时）属于隐含条件，靠经验补。
6. 遇到模糊需求不要自己挑一种解释往下测，而要把它改写成选择题问回去，再把答案落到文字上，因为它要当预期用。
7. 来不及问清的假设必须显式写进用例和测试报告，才能在后来说明假设出错时界定受影响的用例范围。
8. 需求写得含糊或残缺本身就是缺陷，而且是最早、最便宜就能修掉的一类。
9. 覆盖核对要看两个方向：需求没有对应测试点，可能是漏测或需求不可测；测试点没有对应需求，可能是正当的隐含条件，但必须标出来源。

---

上一篇留下一个悬念：预期是判断对错的前提，而预期最靠得住的来源是需求。真到动手时，最先撞上的问题不是“用例怎么写”，而是“需求就这一句话，我到底该验哪几件事”。

看一条很常见的需求：

> 已登录用户可以在结算页输入优惠码。有效优惠码按指定比例抵扣商品小计。每个优惠码每位用户限用一次。过期优惠码给出错误提示。抵扣后订单总额不得为负。

你打开页面，输入一个有效码，折扣出来了，就算测完了吗？这一句需求里至少藏着十来个要验的点。把它们找出来，是测试里一个单独的动作，它有名字，也有方法。

## 先把三个层次分开：依据、测试点、用例

新手最容易混的是这三个词，它们其实是三个不同的东西 [1][2][3]：

- **测试依据（test basis）**：你据以设计测试的那个“知识体”。常见的是需求文档、验收标准、接口约定、设计说明、用户故事，也可以是代码本身，甚至是团队里没有写下来、但大家都默认的口头共识。
- **测试条件（test condition）**，中文里也常叫**测试点**：从测试依据里识别出来的、可以被验证的一个方面。它只回答“要验什么”，不回答“怎么验”。
- **测试用例**：具体的前置条件、输入数据和预期结果。它回答“怎么验”。

从依据里把测试点找出来的这个动作，叫**测试分析（test analysis）**：读需求，然后识别出有哪些点需要验。它和分析完之后的“测试设计”是两件事——前者决定测什么，后者决定怎么测 [6]。

这三个层次是漏斗形的：

```mermaid
flowchart LR
  A["测试依据：一份需求文档"] --> B["测试点：要验的若干方面"]
  B --> C1["用例：一组数据 + 预期"]
  B --> C2["用例：另一组数据 + 预期"]
```

一份需求可以拆出几个到十几个测试点，一个测试点又能长出好几条用例。中间这一层不是为了好看，它有两个实在的用处。

第一是**核对覆盖**。需求条目和测试点能一一对上，你才说得清“这次覆盖了多少”。跳过这一层，你手里只有一堆用例，漏没漏哪块谁也看不出来。

第二是**排优先级**。测试点是“要验的事”，比用例好排序：可以先给每个点各派一条用例趟一遍，再对高风险的点补数据。真实项目里时间永远不够，这个顺序决定了先保什么。

## 第一步：把一句话拆成原子陈述

上面那条需求看起来只有五句话，但它其实由多条独立的规则拼起来。逐句拆：

| 需求里的原子规则 | 由它导出的测试点（部分） |
| --- | --- |
| 已登录用户可用优惠码 | 未登录用户使用优惠码应被拒绝 |
| 按比例抵扣商品小计 | 抵扣额按指定比例计算正确；抵扣只作用于商品小计 |
| 每位用户每码限用一次 | 第二次使用被拒；换个用户用同一个码可以通过；换设备、换会话后再用仍被拒 |
| 过期码给出错误提示 | 过期码不产生折扣，且提示内容正确 |
| 抵扣后总额不为负 | 折扣超过小计时总额停在 0；小计为 0 时用码仍为 0 |

这一步的要点是：**一个测试点对应一条可以被单独验证的规则，而不是一段需求原文**。像“已登录用户”这种限定词，本身就意味着“未登录”是一个必须验的反面情形——它写在需求里，但很容易被读过去。

除了需求写明的，还有一类点需求从来没提，用户却默认它是对的：码的大小写、前后多打的空格、根本不存在的码、同一个请求被连点两次提交、抵扣服务超时。这些叫隐含条件，是经验和新手的差别所在。做法很简单：对每个测试点追问一句“还有什么可能出错”，通常在正向、反向、边界这三个方向上都问一遍就够了。

## 测试点还不是用例

拿“抵扣后订单总额不得为负”这个点展开，它自己不给数据，用例才给：

- 小计 10 元，折扣 100%，预期总额 0 元；
- 小计 10 元，折扣 150%，预期总额 0 元，而不是负数；
- 小计 0 元，用任何有效码，预期总额 0 元。

这里要回到上一篇的那句话：**每条用例都必须写出预期，而预期得有出处**。上面这三条的出处在需求里写得很明白（“不得为负”），直接引用就行。如果需求没写、你又说不清依据，那这条用例的结论就站不住——这正是测试点分析要尽早做的原因，它在你写用例之前就把这类空洞暴露出来了。

## 需求写得含糊、残缺时怎么办

现实里的需求很少像上面那样整整齐齐。问题可以分三类：

- **模糊**：一句话能读出两种意思。比如“工作日 24 小时内到账”，是自然日还是工作日？“满 100 元免运费”，刚好 100 元算不算？
- **缺失**：根本没提。比如超时、重复提交、并发操作时系统该怎样。
- **矛盾**：两处规则打架。比如一处写“每人限用一次”，另一处写“同一账号每天可用三次”。

处理这类需求，有一套动作顺序。

**第一步，不要替需求方做决定。** 新手最常见的反应是“那我按合理的来”，自己选一种解释往下测。等测完一轮再发现理解偏了，这批用例基本全废——这是最贵的错。

**第二步，把模糊点变成选择题问回去。** 不要问“这条需求是什么意思”，对方很难回答；改问“工作日是指周一到周五、不含法定节假日，还是指自然日？”列出你想到的两种以上解释，让对方挑。对方一句话就能答完，也顺带证明你读懂了这条需求。这是整套动作里性价比最高的一招。

**第三步，把答案落到文字上。** 答案写在需求文档、需求单的评论或验收标准里，别停留在口头。因为它接下来要当预期用，将来会有人拿它来判断“这到底算不算 bug”。

**第四步，实在问不到人的时候，把假设显式写下来。** 假设写进用例的备注，同时在测试报告里单独列一节。这样一旦后来发现假设错了，靠需求条目和测试点之间的对应关系，你能很快圈出受影响的是哪几条用例，而不是全部重测。

**第五步，需求本身的问题要报出来。** 一条写不清楚的需求就是缺陷，而且是最早、最便宜就能修掉的那类：它还没变成代码，改一行字比改一行代码、比上线后打补丁都便宜。

## 最后做一次覆盖核对

把需求条目列在一边，测试点在另一边，连起来看两个方向：

- 有需求、没有对应的测试点？要么你漏了，要么这条需求根本不可测（“系统应界面友好”“响应要快”这类没有可测量标准的话就属于此类）[4]。
- 有测试点、找不到对应的需求？可能是隐含条件，这很正常，但要标注它的出处，别让后面的人以为是凭空加的。

这个核对做完，你手上才算有一份“要验什么”的清单，而不是一堆散落的用例。下一步再挑测试设计方法（等价类、边界值那一类），把每个点变成具体的数据和预期。

## 术语表

- 测试依据（test basis）：你据以设计测试的那份知识或材料，例如需求文档、验收标准、设计说明、用户故事，也包括团队里默认但没写下来的共识。
- 测试分析（test analysis）：读测试依据、识别出有哪些点需要验证的活动，产出是一份要验什么的清单。
- 测试条件（test condition，测试点）：从测试依据里识别出的、可以被单独验证的一个方面，只说明要验什么，不含具体数据和预期。
- 隐含条件：需求里没写、但用户和业务方默认成立的期望，例如大小写、空格、重复提交、依赖服务超时，需要靠经验补出来。
- 覆盖核对：把需求条目和测试点对应起来检查两个方向，用来发现漏测、不可测的需求和来源不明的测试点。

## 来源

1. [ISTQB 官方术语表 — 测试依据、测试条件、测试分析等术语的通行定义](https://glossary.istqb.org/)
2. [ISO/IEC/IEEE 29119-1 标准页面 — test basis、test condition、test case 的规范定义](https://standards.ieee.org/ieee/29119-1/10779/)
3. [BrowserStack: What is Test Analysis — 测试分析的实务流程，含需求缺失、边界与失败路径的例子](https://www.browserstack.com/guide/test-analysis)
4. [Guru99: Test Analysis and Test Basis — 测试依据的来源分类与可测性检查（可测量、无歧义、完整）](https://www.guru99.com/test-analysis-basis.html)
5. [Berry & Kamsties: From Contract Drafting to Software Specification — 需求文本中歧义类型的系统梳理](https://cs.uwaterloo.ca/~dberry/handbook/ambiguityHandbook.pdf)
6. [ISTQB CTFL: Test Analysis and Design — 测试分析产出测试点、测试设计产出用例这一分工的说明](https://mastersoftwaretesting.com/certification-guides/istqb/ctfl/ctfl-test-analysis-design)

---

原文：https://pangzhengboyin.com/articles/from-requirements-to-test-conditions-8e95bd84

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com