标签: acceptance-testing

验收测试和功能测试之间的真正区别是什么？

每个的亮点或目标是什么？我读到的每个地方都模糊不清.

你是为了一个还是另一个？或两者？

我的理解是单元测试:

• 从开发人员的角度验证系统
• 帮助开发人员练习TDD
• 保持代码模块化
• 帮助检测低粒度级别的错误

验收测试:

• 从业务和QC/QA的角度验证系统
• 往往是高级别的,因为它们通常由不熟悉代码内部工作的人编写

我觉得两者都是必要的.但是,为了最大限度地减少冗余工作,尝试将单元测试纳入验收测试是否是个好主意？换句话说,让后者称之为前者.相反的方向是否有意义？

您对单元测试与验收测试的一般想法是什么,以及如何相互管理它们？

或者,如果你有BDD测试,你需要像Fitnesse这样的东西吗？

Ruby在Selenium之上有一个很棒的抽象层,称为Capybara,您可以使用它进行功能/接受/集成测试.它还有另一个名为Cucumber的库,它更进了一步,让你真正用英语编写测试.

这两个库都是在Selenium之上构建的,可以用来测试任何主要的浏览器,但由于它们的抽象层,使用它们编写测试非常容易(好吧,就像功能测试一样简单).

我的问题是:Python有类似的东西吗？我发现Pythonistas使用各种工具进行功能测试但是......

A)Splinter:不使用Selenium(并且没有IE驱动程序)

-EDIT- 看来Spliter现在确实使用了Selenium(见下面的答案).

B)Alfajor:一年多来没有更新; 看起来死了

C)Selenium(原始):很多人似乎直接使用Selenium,但它似乎是一个抽象层可以使它更容易使用

那么,对于Python来说,有没有人知道类似Capybara的东西,或者更好的类似Cucumber的东西(它不必实际使用Selenium,但它需要支持所有主流浏览器)？

*编辑*

对于那些不熟悉Capybara的人来说,它基本上只是添加了一个API,因此您可以执行以下操作来代替正常的Selenium API:

When /I sign in/ do
  within("#session") do
    fill_in 'Login', :with => 'user@example.com'
    fill_in 'Password', :with => 'password'
  end
  click_link 'Sign in'
end

它被Cucumber使用,让你进一步抽象(几乎到英文):

Scenario Outline: Add two numbers
Given I have entered <input_1> into the calculator
And I have entered <input_2> into the calculator
When I press <button>
Then the result should be <output> on the screen

Examples:
| input_1 | input_2 | button | output | …

建议的做法是什么？我应该将fitnesse文件夹下的my子文件夹添加到版本控制中吗？

上下文:在单个开发人员rails pet项目上工作.我的版本控制(Subversion)下我的rails项目,但我的fitnesse维基页面位于fitnesse程序文件夹下.

Fitnesse似乎有自己的版本控制...(我看到编号的拉链以及我的每个维基页面)它可靠吗？它在哪里存储修订版？

因为我可以使用selenium-standalone和xpath来测试应用程序.但测试SPA可能会在某个时候发生挑战.

但是,例如angularjs的团队为此提供了量角器.

我可以看到量角器背后的原因是量角器等到angularjs将被加载并且还有更多的功能:

Protractor提供了一些新的定位器策略和功能,这对于AngularJS应用程序的自动化非常有用.示例包括:waitForAngular,By.binding,By.repeater,By.textarea,By.model,WebElement.all,WebElement.evaluate等.

所以,问题是:在Vuejs中进行e2e测试是否是任何工具或最佳实践？

UPD:随时发布指向教程的链接,示例以及关于vue.js中e2e-testing的一切.谢谢.

对于我的Rails Web应用程序的集成测试,我使用Steak(类似Cucumber).Steak的规格位于名为spec/acceptance的文件夹中.Steak/Cucumber现在用于集成或验收测试吗？我一直认为这是不同的东西.

我们已经意识到在定义典型的CRUD场景时有两种指定测试数据的选项:

选项1:描述要使用的数据,并让实现定义数据

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have typed in a valid name
      And I have typed in a valid code
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the created region details

选项2:明确说明要使用的测试数据

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have filled out the form as follows
        | Label | …

我知道丹北的制订BDD的意图之一是移动的词汇从测试域的复杂性了.但是,在实现从外到内的方法时,似乎我们仍然需要对模拟行为(或者如果您愿意,还是存根行为)有所了解.North在这段视频中建议,如果我从最外层的域对象开始并向内工作,我会在发现它们时模拟协作者,然后用适当的实现替换它们.所以最后,我最终得到了一系列端到端测试.

Martin Fowler似乎在这篇博文中看到了一点不同,当时他定义了两个TDD阵营:"经典TDD"尽可能使用真实对象,必要时使用模拟,而"mockist TDD"在大多数情况下更喜欢模拟.他看到BDD倾向于后者.也就是说,在开发一个功能的最后,"mockist"方法会在实际测试中留下嘲笑(很遗憾在BDD讨论中使用该词).

公平地说,这两种材料都已经存在多年了,随着BDD在单元级应用和接受级别之间的界限发展,事情也变得更加清晰.

但我对社区的问题基本上是:当我的故事完成后,我的场景实际上应该进行多少端到端测试？ North 解释说BDD需要抽象.例如,当我测试登录行为时,我的方案将详细说明登录过程的含义.但是,当我正在做其他需要但不是登录的场景时,我不想一遍又一遍地执行这些步骤.我想要一个简单的抽象,简单地说"鉴于我已登录",所以我可以执行我的其他行为.

因此,我的抽象方法似乎是我模拟某些协作者(或提供"测试双重"),并且某些场景可能比其他场景更多地使用它们.例如,我是否总是模拟外部资源,例如数据库或邮件服务器？

也许我问的是错误的问题.BDD就是沟通,缩短反馈周期,发现你不知道的东西.即使我们感兴趣的行为确实有效,也许什么也不是模拟是一个无关紧要的问题.我很好奇其他人的方法是什么.

我参与开发沙盒式Microsoft Dynamics CRM 2011 Online插件并拥有一组测试,我可以从本地计算机上的xUnit前端驱动,因为我右键单击Package并选择Deploy选项(并求助于当不起作用时使用插件加载器示例).

我希望能够在我的CI装备上自动运行我的测试,我需要它在每次运行时上传一个新的二进制文件.

我们已经看过http://pluginregcrm2011.codeplex.com/,但它有阻止它在网上工作的错误,简而言之,它不再被维护,我不想热衷于拥有应该是什么平台/生态系统应该拥有的工具.

是否有人以非交互方式使用该工具或其他插件上传器？我错过了什么吗？