4

可以使用 UI 驱动程序实现 BDD（行为驱动设计）测试吗？

例如，给定一个 Web 应用程序，而不是：

  • 为后端编写测试，然后在前端用 Javascript 进行更多测试

我是不是该：

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

我看到这样做的好处是：

  • 测试是用一种语言编写的，而不是几种语言
  • 他们专注于 UI，让开发人员从外向内思考
  • 它们在真实的执行环境（浏览器）中运行，这使我们能够
    • 测试不同的浏览器
    • 测试不同的服务器
    • 深入了解实际性能

想法？

4

6 回答 6

3

We've done this for a C# application using a WPF testing tool (WipFlash) and writing NUnit tests in a BDD-like fashion.

e.g.

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

We had to code a lot of the DSL ourselves, needless to say. But it becomes a business/customer readable solution.

于 2011-01-03T12:06:30.760 回答
2

尝试将 SpecFlow 与 WatiN 一起使用：（我不确定您是否在这里使用 .NET）

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

于 2011-01-03T12:04:49.813 回答
1

对于 Web 测试，您可以尝试 WebDriver。Selenium 团队目前正忙于集成 WebDriver。来自 Google 的 Simon Stewart 创建了 WebDriver，他在博客中介绍了它与 Selenium 的工作方式有何不同。

WebDriver 为每个浏览器使用不同的技术。对于 Internet Explorer，WebDriver 使用 Microsoft 的 UI 自动化—— @ Brian Agnew 提到的 WipFlash 所基于的技术相同。这与您假装单击按钮一样接近。Simon 的博客展示了为什么这种方法可以比 Selenium 的 Javascript 解决方案更强大。

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

于 2011-01-03T12:28:58.803 回答
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 片段

于 2011-01-05T18:36:42.307 回答
0

实际上你可以两者都做——创建一个以用户为中心的驱动界面（与 GUI / tech / impl 无关）。然后您可以编写一个 UIDriver 和一个 APIDriver 并选择一个驱动程序来运行特定的测试。通过 UI 运行通常较慢（超出过程，控制重绘，但最初以某种方式创建了更高的置信度）。通过 API 运行要快得多（在 proc 中，易于设置-拆卸）。

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

于 2011-09-28T05:32:53.790 回答
0

您当然可以通过这种方式进行一些验收测试，但我认为大多数 BDD 倡导者不会建议在所有测试中都使用这种方式。当然，真正的 BDD 拥护者不会称它们为测试......

RSpec Book提倡两级循环，首先编写验收测试（或场景）（主要在Cucumber中），然后在更类似于传统 TDD 的内部循环中编写单元测试（在RSpec中）。

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

通过 UI 执行整个应用程序的测试更难重复，并且比单元测试更慢且更脆弱。

于 2011-01-03T12:48:33.143 回答