什么时候应该编写 BDD 测试场景？ [关闭]答案

【问题标题】：When should the BDD test scenarios be written? [closed]什么时候应该编写 BDD 测试场景？ [关闭]
【发布时间】：2010-04-09 11:35:26
【问题描述】：

我正在研究 Scrum 场景中的 BDD 测试，并意识到 BDD 场景更类似于规范而不是测试。

因此，是否应该在开发人员进行预先规划之前编写它们，以便确定所有功能，以便在该会议中进行更好的估算、优先排序等？

【问题讨论】：

标签： scrum bdd

【解决方案1】：

如果 BDD 的意思是“行为驱动开发”，那么您可能会因为在其中添加“测试”这个词而被绊倒。

它们不是测试，即使您可以从中获得免费测试。如果您将它们视为测试，那么您将使用它们。

它们是规格。如果您以这种方式接近它们，您可以看到它们如何融入您的流程。

这取决于您，但您将获得最大的好处，即强迫自己不再将它们视为测试，而是始终如一地将它们视为规范。没有什么可以阻止您滥用它们（作为测试），但滥用它们将保证您不会从该方法中受益 - 而且它是实质性的。

【讨论】：

谢谢布雷特，这正是我现在接近他们的方式。

【解决方案2】：

通常，在 Scrum 中，您希望用户故事也具有满足条件。意思是，如果满足这些条件，作为产品负责人，我会对故事的完整感到满意。

最好让产品负责人编写这些内容，如果它们以 Given/When/Then 格式编写则更好。这样，团队可以根据满意度条件创建 BDD 测试。当测试通过时，故事就完成了。

应该有尽可能多的满足条件，产品负责人认为有必要确认故事已经实施，并且这些条件应该为冲刺计划会议及时准备好。它们不需要编码，但应该写出来，以便团队了解完成故事的预期内容。

团队可能会在 sprint 期间添加自己的 BDD 测试，但要等到初始 BDD 测试通过后，故事才会完成。

【讨论】：

【解决方案3】：

如果您正在寻找 BDD（也称为验收测试驱动开发），您可能愿意在 Sprint 计划发生之前尽早开始编写验收测试。其他一些“更敏捷”的方法倾向于将其推迟到最后负责任的时刻，我一直在指导几个团队，其中验收标准也在 Sprint 期间随着时间的推移而得到改进。

开发团队的“测试人员”在为下一个 Sprint 准备待办事项（称为前瞻）期间与产品负责人密切合作，并且在当前 sprint 期间，当他们看到符合 PO。

这在很大程度上还取决于您如何执行这些测试...如果您能够自动化，那么事情就更清楚了 :-) 我们确实广泛使用 Cucumber 或 Fitnesse 来自动化验收测试，并且作为您会使用 TDD（没有 A）您会尝试在承诺发生之前这样做，至少在基本级别上（您不需要定义所有这些 - 请记住它不应该看起来像合同） .

BDD 的目标是从行为的角度推动软件的开发，这应该为您提供关于如何以及何时编写验收标准的非常清晰的“方法”。我发现它们与用户故事的 INVEST 清单以及 Ready for you Backlog 的定义相结合非常有用。

HTH 安德烈

【讨论】：

【解决方案4】：

我希望你提到了行为驱动开发。如果我是对的，这是一个与开发人员、QA 和非技术或业务参与者交互的过程。这也是开发人员代码的目的和好处。您可以在他们预先计划时开始 Scrum 场景。

估计和优先级不在其中。

【讨论】：

感谢 Vijay，但我认为您可能错过了问题的重点，即估计和优先级划分不是 BDD 的一部分，而是 BDD 的输出对估计和优先级划分有用。