首页/开发/软件测试速查/实例化需求(Specification by Example)
用例设计方法62 条

实例化需求(Specification by Example)

用具体示例澄清与固化需求:从业务目标提炼关键示例,协作评审后作为验收标准与自动化用例的共同来源。

软件测试速查开发更新于 2026-10-13

实例化需求是什么

实例化需求(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 的实例无法替代验收标准。
别让它变成新文档工程:实例的终点是可执行的验收用例,规格说明只是副产品。
业务方参与是关键:测试单方面写实例,等于闭门翻译需求,歧义照旧。

易错点

  • 实例只写了正例:边界与异常没覆盖,验收时说不出问题在哪。
  • 实例与需求脱节:需求变了实例不更新,自动化跑的还是旧规则。
  • 变成文档表演:实例写得很精美,没人执行也无人评审。
  • 自动化过度绑定界面:实例绑定到易变的界面细节,维护成本高。
  • 三方未对齐:测试写完直接开工,业务方首次见到实例是在验收会上。

数据来源与参考

  • Gojko Adzic《Specification by Example》
  • Cucumber 官方文档(BDD 与实例化需求)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌