使用UI驱动程序进行BDD测试(例如Selenium用于Web应用程序)

时间:2011-01-03 12:00:45

标签: tdd bdd web-testing

可以使用UI驱动程序实现BDD(行为驱动设计)测试吗?

例如,给定一个Web应用程序,而不是:

  • 为后端编写测试,然后在Javascript中为前端编写更多测试

我应该:

  • 在实际浏览器中将测试编写为Selenium宏,模拟鼠标点击等?

我这样做的好处是:

  • 测试用一种语言编写,而不是几种
  • 他们专注于用户界面,让开发人员思考从外到上
  • 它们在真实的执行环境(浏览器)中运行,这使我们能够
    • 测试不同的浏览器
    • 测试不同的服务器
    • 深入了解真实世界的表现

思想?

6 个答案:

答案 0 :(得分:3)

我们使用WPF测试工具(WipFlash)为C#应用程序完成了这项工作,并以类似BDD的方式编写NUnit测试。

e.g。

Given.TheApplicationWindowIsOpen();
When.I.Press.OKButton();
The.Price.ShouldBeCalculated();

我们不得不自己编写很多DSL代码,不用说。但它成为商业/客户可读解决方案。

答案 1 :(得分:2)

尝试使用带有WatiN的SpecFlow :(我不确定你是否在这里使用.NET)

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

答案 2 :(得分:1)

对于Web测试,您可以尝试使用WebDriver。 Selenium团队正忙于整合WebDriver。来自Google的Simon Stewart,他创建了WebDriver,blogged here about how it works differently创建了Selenium。

WebDriver为每个浏览器使用不同的技术。对于Internet Explorer,WebDriver使用Microsoft的UI自动化 - 与@Brian Agnew提到的WipFlash相同的技术。这就像你假装点击按钮一样接近。 Simon的博客显示了为什么这种方法比Selenium的Javascript解决方案更强大。

WebDriver可从Selenium网站获得,但尚未完全实现为Selenium的一部分。

答案 3 :(得分:1)

对于BDD以及任何用例驱动的测试,能够传达测试正在进行的操作非常重要。许多测试套件的问题在于写后没有人确切地知道测试正在做什么。如果您使用非专业语言编写,这将经常出现。专业化并不一定意味着一种特殊的语言,而只是一种语言的抽象,因此很清楚发生了什么。

例如,很多测试的代码都是这样的(伪代码,我不会选择任何特定的框架):

object = createBrowser()
response = object.gotoURL( "http://someurl.com" );
element = response.getLink( "Click Here" );
response = element.doClick();

有些人很难快速转换为业务驱动程序(也许是产品经理或用户)。相反,你想要创造专门的功能,或者如果你有冒险精神,你可以创建一种语言,所以你可以拥有这个:

GotoURL http://someurl.com/
Click link:Click Here

Selenium及其宏或接口在这方面仍然相当低级。如果您确实使用它们,那么至少在它们周围构建一些包装器。

您当然也可以使用名为TestPlan的产品。它在后端有Selenium,它提供了一个高级API,以及一个用于测试的自定义语言。它还超越了网络,包括电子邮件,FTP等。上面的示例语言是一个TestPlan代码段

答案 4 :(得分:0)

您当然可以通过这种方式进行一些验收测试,但我认为大多数BDD倡导者都不建议将其用于所有测试。当然,真正的BDD倡导者不会称他们为测试......

The RSpec Book提倡两级循环,首先编写验收测试(或方案)(主要在Cucumber中),并在内循环中编写单元测试(在RSpec中)更多类似于传统的TDD。

验收测试的外部循环也可以使用像Selenium这样的工具来通过UI驱动整个应用程序(而RSpec Book的作者则花了一章时间)。但它不适合单元测试。

通过用户界面执行整个应用程序的测试更难以重复,并且比单元测试更容易变得更慢和更脆弱。

答案 5 :(得分:0)

实际上你可以做到这两点 - 创建一个以用户为中心的驱动程序接口(与GUI / tech / impl无关)。然后,您可以编写UIDriver和AP​​IDriver并选择驱动程序来运行特定测试。在UI中运行通常较慢(在proc之外,控制重绘,但最初会以某种方式创建更高的置信度)。通过API运行要快得多(在proc中,易于设置 - 拆解)。

这里的诀窍是将What与the How分开。否则,您将最终获得ObscureTests和高测试维护。确保主要关注测试而非自动化。