2010-10-23 24 views
7

我在看SpecFlow的例子,它的MVC样品中含有用于测试一些备选方案:基于验证由控制器产生的结果如何在SpecFlow,Cucumber或其他BDD验收测试框架中选择不同的测试类型?

  • 验收试验
  • 使用MvcIntegrationTestFramework进行集成测试;
  • 使用硒的自动验收测试;
  • 当提示测试人员手动验证结果时,手动验收测试。

我必须说我对SpecFlow示例的写法(以及我在下载后几分钟内运行它们,只需配置数据库并安装Selenium远程控制服务器)印象深刻。看看测试的替代方案,我可以看到它们大多数是相辅相成的,而不是替代方案。我能想到这些测试以下组合:

  • 控制器在TDD风格的测试,而不是使用SpecFlow(我相信鉴于/时/然后测试类型,应在更高的应用,终端到终端的水平;他们应该对各个部件提供良好的代码覆盖;在开发会话中运行的集成测试时
  • MvcIntegrationTestFramework是有用的,这些测试还将每天的一部分建立;
  • 虽然基于硒测试自动化,它们是缓慢的,并主要是在QA会议期间启动,以快速验证页面和网站工作流程中没有违反逻辑;
  • 提示测试人员确认结果有效性时的手动验收测试主要是验证页面的外观和感觉。

如果您在Web开发中使用SpecFlow,Cucumber或其他BDD验收测试框架,请分享您在不同测试类型之间进行选择的实践。

在此先感谢。

回答

6

这都是行为。

给定一个特定的上下文,当一个事件发生时(在一个特定的范围内),那么应该发生一些结果。

范围可以是整个应用程序,系统的一部分或单个类。即使是一个函数也是如此,输入作为上下文,输出作为结果(也可以将BDD用于函数式语言!)

我倾向于在类或集成级别使用单元框架(NUnit,JUnit,RSpec等),因为受众是技术性的。有时我会在评论中记录Given/When/Then。

在场景级别,我试图找出谁真正想帮助读取或写入场景。即使商业利益相关者也可以阅读包含几个点和括号的文本,因此拥有像MSpec或JBehave这样的自然语言框架的主要原因是,如果他们想自己写场景,或者将它们展示给真正被点击的人和括号。然后,我看看框架将如何与构建系统一起工作,以及我们如何赋予相关利益相关者适当的读写能力。

Here's an example I wrote显示您可以使用简单的DSLs场景做的事情。这只是写在NUnit。

Here's an example in the same codebase显示给定,何时,然后在类级别的示例注释。

我抽象背后的步骤,然后我把屏幕或页面放在那些背后,然后在屏幕和页面中调用我使用的任何自动化框架 - 可以是Selenium,W​​atir,WebRat,Microsoft UI Automation等。

我提供的示例本身就是一个自动化工具,所以这些场景通过演示假gui的行为来演示自动化工具的行为,以防万一发生混淆。无论如何希望它有帮助!

+0

谢谢你一个很好的答案,并且这些例子非常好。我会仔细看看你的WipFlash。虽然我没有在我的curreny项目中使用WFP,但WipFlash可能会提供关于自动化和测试UI的一些想法。 – 2010-11-01 06:25:56

2

由于验收测试是一种功能测试,总体目标是测试您的应用程序与他们端到端。另一方面,您可能需要考虑测试自动化的效率(实现测试自动化需要多少努力),可维护性,性能和可靠性。测试自动化很容易适应开发过程,这也很重要,因此它支持一种“测试优先”方法(以支持外部开发)。

所以这是一种折衷,对于每种情况都可能不同(这就是为什么我们提供了替代方案)。

我敢肯定,今天最广泛的选择是在控制器层进行测试。 (也许随着UI和UI自动化框架的发展,这将会发生变化。)

相关问题