BDD适合UI自动化？

Question

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

我们有两个选择:

1. 带有webdriver的TestNG用于UI自动化
2. 使用BDD构建的内部工具.

我们处于危急的境地,决定哪种技术对我们的项目更好.

我们的项目是巨大的应用程序,有8个模块,并与第三方工具集成很多.

1. BDD对大型项目有利吗？
2. 当测试用例数量增加时,它是否会引入维护工作？
3. 当测试用例的数量增加时,是否存在重复性？

提前感谢所有的想法.

Answer 1

BDD讲述的是一段代码,一个应用程序或一个系统应该如何表现,然后通常使用BDD工具和/或自动化框架来捕获这些示例.很多人只是通过在维基上捕获示例来获得价值.有四件事情我喜欢的地方,看到的人移动到工具之前,特别是如果你即将在应用层面做到这一点:

• 关注大局
• 提问和探索的能力
• 能够发现和接受不确定性
• 人与人之间的关系很好

如果您没有这些,请非常谨慎地对待自动化.如果您没有捕捉到真正的对话,我建议您避开像Cucumber和JBehave这样的英语框架.连接英语G/W/T的额外开销,以及缺少英语重构工具,意味着如果您的企业参与阅读或编写方案,则仅使用这些开销.

我喜欢使用类似这样的 DSL ,你可以在TestNG中创建,就像我在NUnit中这样做一样容易.只需将您的关注点分组到Given/When/Then步骤中,并且不要害怕重构.它比英语工具更容易维护.缺点是业务难以阅读,并且倾向于更多地关注测试方面而不是会话方面.

那么,回答你的问题:

1. 是的,BDD适用于大型项目.有些项目比你的项目大得多.

2. 是.正如您所猜测的那样,大量情景确实会变得迅速无法维持.如果您没有遇到测试金字塔,我建议您获取敏捷测试的副本,这将比我在这里更好地解释它,并为您提供一些提示.从基本的角度来说,您需要很少的自动UI场景,更多的集成/ API测试以及底部的大量小型单元测试.如果你可以弄清楚代码的价值是什么,并提供了几个例子,那么在UI级别通常就足够了.例如,如果您正在编写验证,只需参考几个示例,其中引导用户填写表单,然后在类级别为其余验证编写测试.
   
   减少所需场景数量的另一种方法是确定代码区域何时稳定,然后将它们绘制到自己的库和/或微服务中.这将让您从主构建中获取场景.尽量不要为任何非常无聊的东西编写场景,它只是起作用而且永远不会被再次触摸(例如:登录,电子邮件网关等)
   
   如果你感觉很慷慨,你可以写一个小玩具应用程序,显示如何使用服务并使这些服务的场景在玩具应用程序上运行; 这也将有助于未来的开发人员了解如何使用您的服务.JBehave本身就是用这种技术编写的.
   
   然后,您可以使用API​​测试或集成测试来检查您的应用程序是否正确连接到服务,而不必担心面向用户的功能.

3. 有时.有关减少测试用例数量的技术,请参见第2项.此外,将有趣的场景放在顶部,而不是底部,并且一旦您阅读了更多有趣的场景,就不要害怕删除任何明显的内容.
   
   例如:"弗雷德购买带折扣的微波炉并获得退款的那个"更有趣,涵盖了"弗雷德买了一台没有折扣的微波炉并得到退款的那个"的所有功能.

如果您不确定哪条路线会发生故障,我强烈建议您在短时间内重复工作.尝试TestNG方法和您自己的工具.如果使用Page Object模式,则可以重复使用它,因此开销很小.由此,您将能够找出哪一个最适合您的项目.

我可以确认,从基于代码的DSL迁移到英语语言框架比使用其他方式更容易,所以如果有疑问,请转到代码.