Alistair Cockburn 经典著作重构
Use Case = Contract
用例不仅仅是功能描述，它是利益相关者（Stakeholders）之间关于系统行为的契约。系统必须保护这些利益。
User Goal
用例围绕一个特定的、即时的目标展开。
判断标准：“咖啡休息测试” —— 主角完成这件事后，是否可以心满意足地去喝杯咖啡？
Scenarios
一个用例包含多个场景：
1. 主成功场景 (MSS)：一切顺利。
2. 扩展 (Extensions)：发生异常、失败或分支。这是最有价值的部分！
编写用例步骤的黄金法则：保持简单，使用主动语态。
| 原则 (Principle) | ❌ 糟糕的写法 (The Bad) | ✅ 优秀的写法 (The Good) |
|---|---|---|
| 上帝视角 Bird's Eye View |
"输入卡号和密码..." (这就不知道是谁在做) |
"顾客输入卡号和密码。" (明确主语，谁拿着球？) |
| 显示意图，而非动作 Intention over UI |
"用户按下Tab键，点击确定按钮。" (这是UI设计，不是需求) |
"用户确认提交订单。" (描述意图，保持界面独立性) |
| 验证而非检查 Validate vs Check |
"系统检查密码是否有效。" (暗示了if-else，导致主流程分叉) |
"系统验证密码有效。" (主场景只写成功；失败去扩展写) |
| 推进一步 Move Forward |
"系统显示欢迎界面。" (原地踏步) |
"系统向用户展示账户概览。" (信息传递，流程推进) |
3a. 密码错误：系统提示用户重试。
用例不是一次性写完的文档，它是随项目演进的“不断展开的故事”。
重点： 识别所有执行者(Actors)和他们的目标(Goals)。
产出： Actor-Goal List (执行者-目标列表)。不需要写步骤，只需要划定系统边界（Scope）。
重点： 选取高风险或高价值的用例，编写主成功场景(MSS)。
产出： 包含主要步骤的用例草稿，开始头脑风暴可能的失败扩展。
重点： 补全所有扩展(Extensions)和错误处理。这是开发人员编码和测试人员编写测试用例的依据。
意义： 此时用例即需求规格说明书。
用途： 用例转变为用户手册的基础，也是验收测试（UAT）的标准。
状态： 如果业务逻辑变更，必须先更新用例，再修改代码。