我应该使用 BDD 吗？

Question

几年前，我们公司决定告诉 QA 团队开始使用 Cucumber 和 bdd。

问题是人们开始将我们的手动测试直接转化为 bdd 场景。这导致步骤以命令式而不是声明式的形式编写，并且还有许多 when 和 then 步骤。

我的任务是研究如何改进我们编写它们的方式，但我认为这是不可能的。

在我们公司，几乎所有测试都是完整的客户旅程，这意味着几乎所有测试都经过完整的预订流程，并且我们的断言发生在最后，例如。如果我们的测试是预订有额外费用的航班，您需要转到流程的末尾以确保已预订。

我们可以有一个场景，我们将部分流程放在后台，并在场景中测试额外预订，但总是要求在后台部分测试大量不同的数据，所以这是不可能的。由于产品的工作方式，我们也无法使用我们的测试数据预加载数据库。

此外，除了 QA 之外，几乎没有其他团队支持转换为 BDD。没有任何需求是用 BDD 编写的，除了测试人员之外，没有人会查看我们的功能文件。

在我看来，我们应该使用数据驱动测试来实现我们的目标，但我很想知道其他人的想法

Answer 1

根据我的经验，BDD 的最大好处是协作 - 在业务、开发和测试团队之间找到对应用（系统）行为的共同理解。

因此，BDD 最大的投资回报率是在开发阶段，而对于它应该如何工作存在误解。如果您已经有一个可以运行的大型测试套件，为什么不继续使用它呢？您可以尝试为一个新的（较小的）项目引入一个较小的团队子集，看看它是否会给您带来成果。