4.3 BDD集成：让用例说业务语言

4.3 BDD集成：让用例说业务语言

本节摘要：行为驱动开发（BDD）用"给定—当—那么"的自然语言格式写用例，把测试剧本与自动化实现分离，让业务、产品、测试读同一份文件。本节讲清它的真实价值与适用边界：一份可执行的需求文档怎么写、步骤定义怎么映射到页面对象、什么团队该上什么团队别上。它是第 4 章的表达层——页面对象解决"怎么写不脆"，BDD 解决"怎么写可读"。

从一份读不懂的用例说起

给产品经理看一段 test_login_003 的代码：夹具、定位器、显式等待、断言——他能看懂几成？再看一场评审会的常见僵局：产品说"登录成功后应该跳到会员页"，测试说用例里写的是断言标题包含"首页"，双方争论半天，最后发现是需求文档里的页面叫法与代码里的断言对不上。协作成本的大头，从来不在技术，而在"同一件事有三套说法"。

BDD 的想法朴素：用例本来就该是需求的可执行形态。把用例写成近乎自然语言的剧本，业务方读得懂、改得动，自动化工程师在其下挂实现。用 Python 生态的 behave 或 pytest-bdd，一份"特性文件"长这样：

功能: 会员登录
  场景: 正确凭据登录成功
    假如 用户在登录页
    当 输入用户名 "qa_user" 和密码 "secret"
    并且 点击登录按钮
    那么 页面跳转到会员首页
    并且 导航栏显示用户昵称 "小明"
​

这份文件的读者是所有人。产品评审时它就是需求样例，验收时它就是验收清单，回归时它就是自动化用例——一份文字，三种身份，这就是 BDD 的全部卖点。

步骤定义：翻译层的实作

剧本不会自己跑，每个句子背后要挂一段实现，这段胶水叫步骤定义。以 pytest-bdd 为例：

from pytest_bdd import given, when, then, parsers
from pages.login import LoginPage

@given("用户在登录页")
def at_login_page(driver, base_url):
    return LoginPage(driver, base_url).open()

@when(parsers.parse('输入用户名 "{user}" 和密码 "{pwd}"'))
def input_credentials(at_login_page, user, pwd):
    at_login_page.fill(user, pwd)

@when("点击登录按钮")
def submit(at_login_page):
    return at_login_page.submit()

@then("页面跳转到会员首页")
def on_member_home(submit):
    assert "member" in submit.current_url
​

看清这层的真实身份：它几乎是纯粹的翻译，每个步骤一两行，转发给页面对象的方法。这就是 BDD 落地的第一纪律——步骤定义不写逻辑。一旦步骤定义里出现定位器与等待，你的工程就有了两套自动化代码，页面一改要同步两处，维护成本直接翻倍。剧本、步骤、页面对象，三层各司其职：剧本说业务，步骤做翻译，页面对象干实事。

第二纪律是参数用引号抽出。上面剧本里 "qa_user" 与 "secret" 是占位参数，配 parsers.parse 注入步骤函数——同一句剧本可以驱动多组数据，BDD 与参数化天然兼容。

该上与不该上：一张判断表

BDD 在社区里毁誉参半，原因多半不是技术而是用错了场合。判断依据收敛成四个问题：

四个问题全中左列，BDD 会显著提升协作质量；任何一个落在右列，就要冷静——BDD 的成本是真实存在的：每个用例多一层剧本、步骤库需要治理、句式漂移需要评审。为了"看起来先进"而上 BDD，最后通常退化成"剧本没人读、步骤当用例写"的双倍维护负担。

落地的三条务实建议

从高价值场景起步。 挑业务规则最复杂、评审争议最多的模块（结算、优惠、权限）先写十个场景，让业务方真实参与一轮评审，用反馈决定要不要铺开——而不是全仓推倒重来。句式要建词表。 剧本的可维护性取决于句式收敛：建立"假如/当/那么"的常用句式清单，新场景从词表里组句；自由发挥的句式三个月后就没人看得懂步骤库。工具别喧宾夺主。 BDD 的价值在协作流程，不在某个具体框架；如果团队现状是产品不愿写剧本，可以先在测试团队内部用同样格式写用例标题与步骤说明，把"需求即用例"的表达习惯养起来，框架可以后上。

两个真实场景：BDD 的成与败

成的一场：支付团队的结算规则复杂且争议频发，测试把结算场景写成特性文件后，产品第一次在评审会上逐句确认了"满减与优惠券叠加顺序"。会议产出的不是用例，是三个此前没人记录的规则歧义——BDD 的价值在写剧本的过程里就已经兑现了：迫使各方把"想当然"写成"可执行的句子"。上线后这批场景跑了十四个月零一次误报。

败的一场：某团队为了"方法论先进"全面推行 BDD，产品从不读剧本，剧本由测试写完自己翻译成步骤，步骤里塞满定位器。半年后页面改版，剧本与步骤双份维护，维护成本翻倍，最后剧本沦为无人更新的摆设。对照 4.3 开头的判断表，这个团队四个问题全在右列——失败的不是 BDD，是不看前提的照搬。

两场对照给出的启示可以收拢成一句话：BDD 的投入应当买"协作质量的提升"，买不到就别投入；而判断能不能买到，看的是协作文化，不是技术栈。

三个落地的追问

问：剧本写得越细越好吗？ 不是。剧本的粒度应该停在"业务可验收的步骤"——"当 提交订单"是一句好剧本，"当 点击提交按钮并且在弹窗中点击确认按钮"是把操作细节泄漏进了业务语言。细节归步骤定义与页面对象管，剧本漏掉细节才留得住读者。

问：现有的大量 pytest 用例要翻译成剧本吗？ 不需要。两套形态可以共存：回归主力继续用 pytest 直写（写与跑都高效），高争议业务域新增场景用剧本表达。BDD 是表达层的选项，不是信仰，混用是常态。

问：步骤定义之间怎么传递状态？ 靠步骤函数的返回值与参数注入——上一步返回的页面对象作为下一步的入参，运行器负责串接。这条链路一旦在某个步骤里出现 if 分支，就是业务逻辑漏进了翻译层的信号，回头检查场景拆分是否合理。

收工清单

• BDD 的本质：用例即需求文档，一份文字兼做评审样例、验收清单与自动化剧本。
• 三层分工：剧本说业务、步骤做翻译、页面对象干实事；步骤定义里出现定位器即失守。
• 四问判断：业务复杂度、协作方式、用例读者、团队纪律，全过再上。
• 落地节奏：高价值场景起步、句式建词表、工具最后才上。
• 与 4.4 的关系：剧本里的数据占位符只是展示层，数据从哪来、环境怎么切，是下一节的主角。