实例化需求是什么
实例化需求(Specification by Example)由 Gojko Adzic 总结:不写抽象需求条款,而是用具体的业务实例描述期望行为,团队围绕实例澄清规则、消除歧义,再把实例自动化成验收测试。它让需求本身可验证——每条规则都有对应的正反例,验收标准不再靠会议纪要传递。常与 Gherkin 等案例化表达配合使用。
基本信息
| 核心思想 | 用具体实例替代抽象描述,实例就是需求的验收标准 |
|---|---|
| 协作形式 | 业务、开发、测试三方围绕实例澄清,当场确认期望 |
| 产出物 | 实例清单、规则说明、可自动化的验收用例 |
| 与 BDD 关系 | BDD 提供 Given/When/Then 的表达形式,实例化需求是其上游实践 |
| 维护要点 | 实例与需求同步演进,过时实例及时下线 |
| 工具配合 | Cucumber、Behave、Fitnesse 等可按实例驱动执行 |
实例化表达示例
实例化表达示例
规则:订单满 99 元免运费
实例 1(正例):购物车 99 元 -> 运费 0 元
实例 2(边界):购物车 98.99 元 -> 运费 6 元 # 边界两侧都要给实例
实例 3(反例):购物车 0 元 -> 不可下单
# 用 Given/When/Then 改写即可自动化:
# Given 购物车内有 99 元商品,When 结算,Then 运费为 0典型使用场景
- 需求澄清会:用实例把模糊条款聊清楚,当场消除歧义。
- 验收标准定义:每个功能点配正例、边界与反例,验收有据可依。
- 自动化前移:实例直接改写为验收测试脚本,减少二次翻译。
- 跨团队协作:业务、开发、测试对同一条实例达成一致理解。
- 知识传递:实例是活的文档,新人读实例比读条款更快。
实例要覆盖规则边界与例外:只写 happy path 的实例无法替代验收标准。
别让它变成新文档工程:实例的终点是可执行的验收用例,规格说明只是副产品。
业务方参与是关键:测试单方面写实例,等于闭门翻译需求,歧义照旧。