问BDD对UI自动化有好处吗？

EN

BDD是关于如何处理代码、应用程序或系统的示例，然后捕获这些示例，通常使用BDD工具和/或自动化框架。很多人只是通过在wiki上捕捉这些例子就获得了价值。在人们使用工具之前有我想看到的四件事，特别是当您要在应用程序级别执行此操作时：

• 着眼于大局
• 质疑和探索的能力
• 发现和接受不确定性的能力
• 人与人之间的良好关系。

如果你没有这些，那么要非常小心地对待自动化。如果您没有捕捉到真正的对话，我建议您不要使用像Cucumber和JBehave这样的英语语言框架。连接英语G/W/T的额外开销，加上缺乏用于英语的重构工具，意味着只有当您的业务参与方案的阅读或编写时，才值得使用这些工具。

我喜欢使用一个小的DSL 就像这个，您可以像在TestNG中一样轻松地在NUnit中创建它。只需将您的关注点分组到给定的/时间/然后的步骤中，不要害怕重构。它比英语工具更容易维护。缺点是，业务很难阅读，而且倾向于将更多的精力放在测试方面，而不是会话方面。

所以，回答你的问题：

1. 是的，BDD对于大型项目是很好的。有一些比你的大得多的项目正在使用它。
2. 是。正如您已经猜到的，大量的场景确实会很快变得无法维护。如果您还没有看到测试金字塔，我建议您获得一份敏捷测试的副本，这将比我在这里更好地解释它，并给您一些获得它的提示。从基本意义上讲，您需要的是很少的自动化UI场景、更多的集成/ API测试以及大量底层的小单元测试。如果您能够计算出代码对用户的价值，并提供几个这样的示例，那么通常在UI级别上就足够了。例如，如果您正在编写验证，只需以两个示例为例，其中指导用户填写表单，然后在类级别为其余的验证编写测试。

另一种减少所需场景数量的方法是发现代码中的区域正在稳定，然后将它们引入自己的库和/或微服务中。这将使您可以将场景从主构建中删除。尽量不要为任何非常无聊的事情编写场景，因为这些场景很简单，而且再也不会被碰触(例如:登录、电子邮件网关等)。

如果你觉得很慷慨，你可以编写一个小玩具应用程序，展示如何使用这些服务，并让这些服务的场景在玩具应用程序上运行；这也将帮助未来的开发人员了解如何使用您的服务。JBehave本身就是使用这种技术编写的。

然后，您可以使用API测试或集成测试来检查应用程序是否正确地连接到服务，而不必担心面向用户的功能。

1. 有时候。有关减少测试用例数量的技术，请参见第2条。另外，将有趣的场景放在顶部，而不是底部，并且在阅读了更多有趣的场景之后，不要害怕删除任何显而易见的场景。

例句：“佛瑞德买了一个折扣微波炉，得到退款的那个”更有趣，它涵盖了“弗雷德买了一个没有折扣的微波炉并得到退款的那个”的所有功能。

如果您不确定该走哪条路，我强烈建议您在一段时间内重复您的工作。尝试TestNG方法和您自己的工具。如果您使用页对象模式，这两者都可以重用，因此开销将很小。从这一点上，你将能够确定哪一个最适合你的项目。

我可以确认，从基于代码的DSL迁移到英语语言框架要比从相反的方式更容易一些，所以如果有疑问，可以选择代码。

BDD不是一种技术，它是一种软件开发的方法，它除了促进许多其他事情之外，还促进了协作。这意味着，您的选项1也可以使用BDD方法。

其他有用信息：

应用BDD - http://skipoleschris.blogspot.com/2010/11/best-way-to-apply-bdd.html的最佳方法