原文：此文的受众似乎是测试人员 https://www.hindsightsoftware.com/blog/is-bdd-testing-part-1 https://www.hindsightsoftware.com/blog/is-bdd-testing-part-2
BDD 某些活动中确实需要测试，但它并不真的是测试。
有些拗口是不是？
介绍
对行为驱动开发的态度是两级分化的。我开始做自动化执行文档分析师 (automation specialist，一个岗位？好像没合适的中文对应) 起，就关注 BDD。从喜欢BDD并滥用之，到相信 BDD 会导致测试这个岗位的消灭，历时6年，所以关于 BDD 我是有些个人经验的。
过去六年中，尽管我投入了大量心血到 BDD，但约一年前，我对 BDD 开始没那么看好，尤其是看到测试自动化的发展后。这导致我在2016年 TestBash 上发表了演讲“验收场景的致命罪(The deadly sins of acceptance scenarios)” 演讲，那段时间，我已经不再为 BDD 奔走疾呼，宣传 BDD 的伟大之处。就如此博客之前所指出的：
围绕 BDD (或验收场景) 的消极感觉就像我在微服务方面遇到的一样，我希望听到一些经过深思熟虑的积极经验报告。但事与愿违，实际收到的多是负面。所以我认为使用 BDD 不会比使用更具体的方法（如 TDD ）产生多大价值。 (Matthew Bretten)
Matt 的观点是对的，因为我的讲话并没真正说明 BDD 的全部情况，他的评论引起了我当时对此主题的一些个人看法：
- BDD 是什么
- 它是测试吗
- 还是一些别的东西
我的演讲源于一些使用 BDD 导致的各种失败与挫败感。我认为这是开发人员与测试人员没有真正理解正确利用 BDD 而导致。我试图通过列出这些错误以对其他人产生启发，避免陷入同样的陷阱。
但要把这些写成演讲稿是很难的，因为我意外地发现，随着尝试把内容整理在一起，它对我关于 BDD 的理解提出了很多挑战，我发现自己对 BDD 的理解还是极缺乏。不过，在一些大牛的帮助解惑下，我又重新建立了自己对 BDD 的理解。
给测试人员的 BDD 模型
在 TestBas Mancherster 演讲后，我觉得我太关注场景了，所以我为自己设定了以下任务：
沉浸于 BDD 语义下以更好理解它。了解测试人员的误解来自何处并建立模型，使测试人员对 BDD 更加清晰。
在一番沉思后，尽管我依然没有完全了解 BDD ，但我发现创建模型是个非常有用的练习实践。因此，本文及后续系列文章，我只想分享我关于 BDD 的模型，以帮助人们用这个模型来避免一些错误。
这是我的模型，如你所见，里面包含了一些 BDD 以外的东西： Gherkin 语法 和 自动化：
“If you’re not having conversations, you’re not doing BDD.” (Liz Keogh) 无会话，不BDD
通过与测试人员访谈，我发现他们倾向于把 BDD 视为使用 Gherkin 语法和自动化工具。（译注：现阶段我就是这样认为！）我怀疑部分原因是由于测试人员对 BDD 的初体验来自于 Dan North 的文章“introduction to BDD”，该文侧重于工具的开发，而对协作练习重视程度不高。这不是对此文的批评，因为它是第一篇关于 BDD 的文章，而多年后已经发生很多变化，甚至 Dan 自己也说过，他与 JBehave 所做的工作更多是“思考实验”。
“There are things about your domain that you don’t know, or you’ve misunderstood, or that nobody’s thought of yet. By talking through examples in groups, the chances of uncovering these gaps and misunderstandings is increased.” (Liz Keogh) 如果领域中有你所不知道的，被误解的，或没人知道的部分，可以通过分组讨论，来提升高这些空白和误解被发现的机会。
BDD 是关于对话的
从用户角度来讨论讨论域以确保构建正确的软件。邀请测试，开发，设计和业务部门成员参与非正式会议，以讨论和质疑我们计划建造什么，以消除我们可能有的任何错误假设及对所要交付的东西的误解。（译注：似乎不太可能，在我司，这个活应该是由产品经理组织的产品宣讲会）
这个会议可以使用一些工具。测试人员的目标是提出问题并确保对话不超出功能范围，可以使用以下短语：
- 5W法：what,who, where, when, why 。
- “这样问可能显得有些蠢，但是…”，一些看似是蠢问题的问题，可以消除掉很多假设。
- “确认一下…”再说一遍，要求什么将消除假设。
Gherkin / 示例
与 BDD 同义的一个工具是： Gherkin 。 Gherkin 通过使用 Given-When-Then （当-假如-那么）语法来以场景的形式描述用户用例，以演示可验收的标准行为，如：
1
2
3
4
5
6
7
# language zh-cn
功能: 购物
场景: 购物打折
当用户没下订单
假如他添加书本到购物车
那么总金额打9折
不幸的是，Gherkin 语法是测试人员的另一个绊脚石。需要明确的是，不应使用 Gherkin 来构建测试用例。Gherkin 的目标是描述一些示例以说明我们所期望的验收标准如何表现。例如，一些示例描述的关注的是特定边界值会导致的不同行为。作为测试人员，这个非常重要：将边界放到示例中是因为他是业务的核心。但不应该用示例来做边界条件测试。
Gherkin 示例用于说明行为，但不是详尽的测试。各角色一起参与的会议上，测试人员要使用其技术和知识提问并分享信息而不是设计数百个测试。顺便说一下，如果你日常测试中仍在使用测试用例，请将他们和 Gherkin 示例分开并考虑采用探索性测试等新方法（?）
示例映射
用 Gherkin 写示例不容易。Matt Wynne 创建了一个叫示例映射(example mapping)的方法，用于帮助团队将讨论保持在范围内，处理问题并确保创建正确的示例。Matt 在此文 描述了示例映射，简言之，它通过不同颜色的便利贴辅助来跟踪验收标准，示例(Gherkin 场景)和问题。详细内容可阅读以下文章：
- 体验示例映射 (Lisa Crispin)
- 如何使用示例映射 (Toby Sinclair)
结论（目前为止）
如前面所说，许多测试人员把 BDD 当成使用Gherkin 创建自动化测试用例的一种方法。尽管此文未讨论我的模型中开发外部部分，但对我而言，协作阶段是 BDD 最重要部分。关注探索并提出问题和找出我们所关注的相关信息是测试的基石。因此，要确保协作这个过程被执行，测试是必不可少的。
在协作阶段，测试人员的投入要比开发阶段要深入得多。我甚至认为，只要执行了协作部分，即使不追求自动化，也能看到巨大的利益。错过协作阶段，将使你面临失败。