cucumber - BDD是否适合UI自动化？

Question

我们将决定为UI自动化框架选择最佳方法。

我们有2个选项：


带Webdriver的TestNG用于UI自动化
使用BDD构建的内部工具。


我们正处于紧急状态，要决定哪种技术更适合我们的项目。

我们的项目是具有8个模块的庞大应用程序，并且与第三方工具集成在一起。


BDD是否适合大型项目？
当测试用例数量增加时，是否会带来维护工作？
当测试用例数量增加时，会不会存在给定的重复性？


预先感谢您的所有想法。

Answer 1

BDD旨在讨论示例代码，应用程序或系统的行为示例，然后通常使用BDD工具和/或自动化框架捕获这些示例。仅仅从Wiki上捕获示例就可以使很多人获得价值。人们开始使用工具前要先four things I like to see in place，尤其是如果您要在应用程序级别执行此操作时：


放眼大局
质疑和探索的能力
发现和拥抱不确定性的能力
人与人之间的良好关系。


如果您没有这些，请非常小心自动化。如果您没有捕捉到真实的对话，我建议您避免使用Cucumber和JBehave之类的英语框架。连接英语G / W / T的额外开销以及缺少英语的重构工具，意味着仅当您的业务涉及场景的编写或阅读时才值得使用这些工具。

我喜欢使用一些DSL like this one，您可以像在NUnit中一样轻松地在TestNG中创建它。只需将您的疑虑归类为“给定/何时/然后”步骤，不要害怕重构。它比英语工具更易于维护。不利的一面是，企业阅读起来比较困难，并且往往更多地侧重于测试方面而不是对话方面。

因此，回答您的问题：


是的，BDD适用于大型项目。有一些项目比您正在使用的项目大得多。
是。如您所料，大量方案确实将很快变得难以维护。如果您还没有遇到过测试金字塔，我建议您获取一份Agile Testing的副本，该副本比我在这里能更好地解释它，并为您提供一些获取它的提示。从根本上讲，您需要很少的自动化UI方案，更多的集成/ API测试以及在底部的大量较小的单元测试。如果您可以算出代码对用户的价值并提供一些示例，那么通常在UI级别就足够了。例如，如果您正在编写验证，则仅举几个示例，其中指导用户填写表单，然后在类级别编写其余验证的测试。减少所需场景数量的另一种方法是找出代码区域何时稳定，然后将其提取到自己的库和/或微服务中。这样您就可以将方案从主构建中删除。尽量不要为无聊的事情写场景，以至于它可以正常工作并且永远不会被碰到（例如：登录名，电子邮件网关等）。如果您感到很慷慨，可以编写一个小玩具应用程序来显示如何使用这些服务并使这些服务的方案在玩具应用程序上运行；这也将帮助将来的开发人员了解如何使用您的服务。 JBehave本身就是使用这种技术编写的。然后，您可以使用API​​测试或集成测试来检查您的应用程序是否已正确连接到服务，而不必担心面向用户的功能。
有时。参见数字2以减少测试用例的数量。另外，将有趣的场景放在顶部，而不是在底部，并且不要害怕删除任何在您阅读更多有趣的场景之后显而易见的内容，例如：“弗雷德以折扣价购买微波炉并得到“退款”更有趣，涵盖了“弗雷德无折扣地购买微波炉并获得退款的所有功能”的所有功能。


如果您不确定要走哪条路线，我强烈建议您花一小会儿重复一下。尝试使用TestNG方法和您自己的工具。如果使用Page Object模式，则可以同时使用这两种模式，因此开销很小。由此，您将能够确定哪一个最适合您的项目。

我可以确认，从基于代码的DSL迁移到英语框架要比其他方法容易一些，因此，如果有疑问，请寻求代码。