Question

我正在尝试学习BDD黄瓜，我正在尝试使用有效和无效的用户名编写用于登录方案的功能文件。对于有效用户将被记录并且将注销但是对于无效的用户名，将要求用户再次进入登录页面并要求写出正确的凭证。

我想问一下，我们可以在＆＃34;情景大纲＆＃34;中有正面和负面的情景吗？你能帮我写一下这个简单场景的完美特征文件吗？看看我的功能文件代码（PS，我是初学者:)）

Feature: Login Action 
    Description: This feature will test a LogIn and LogOut functionality


Scenario Outline: Login with valid and Invalid Credentials 

    Given User is on Home Page 
    When User navigate to Login Page
    Then User enters "<username>" and "<password>" 
    And Keeping case as Valid
    Then User should get logged in
    And Message displayed Login Successfully
    Then User enters "<username>" and "<password>" 
    And Keeping case as InValid
    Then user will be asked to go back to login page
    And Provide correct credentials

Examples: 
        |username|password|Case|
        |abc@gmail.com|12345|Valid|
        |abc1@gmail.com|dfsd2|InValid|


Scenario: Successful logout from application 

    When user logs out from application 
    Then Message displayed Logout successfully 
    And Browser quit by driver

Answer 1

＆＃39;完美＆＃39; - Ain不是这样的......

您编写的ScenarioOutline非常令人困惑，可能是对scenariooutline如何工作的错误解释。基本上，您正在使用示例表的每一行登录两次，即。相同的用户名和密码（SO中的第3行和第7行）。在scenariooutline中，将使用您在示例中提供的每行数据重复所有步骤。请参阅可用的多个教程。

为什么要混淆有效和无效的登录？将它们放在不同的场景中。易于遵循。
将注销移动到单独的功能文件。然后，您可以将登录方案的前3个步骤移动到后台。减少重复。

对于检查多个数据的有效案例的登录功能，您将遇到问题。一旦有效用户登录，那么大多数Web应用程序都会将登录凭据存储在cookie等中。因此，当为登录页面发出新请求时，它可能只是跳过登录页面并且可能会让我们说主页。然后，当selenium代码查找userid输入框时，您将获得NoSuchElementException。因此，对于有效案例，您也需要注销。

@Login
Scenario Outline: Login with valid and Invalid Credentials 

    Given User is on Home Page 
    ....
    ....

@Valid
Examples: 
        |username|password|Case|
        |abc@gmail.com|12345|Valid|

@InValid
Examples: 
        |username|password|Case|
        |abc@gmail.com|12345|Valid|

要运行有效登录个案，请使用转轮中的标签选项{"@Login","@Valid"}或黄瓜2 @Login and @Valid。对于无效的替换为@InValid。

Answer 2

Scenario: Good sign in
  Given I am registered
  When I sign in
  Then I should be signed in

Scenario: Not registered sign in
  Given I am not registered
  When I sign
  Then I should not be signed in
  And ...

Scenario: Registered with wrong password
  Given I am registered
  When I sign in with a bad password
  Then I should not be signed in
  And ...

提示：

保持简单
不要使用大纲
详细了解您如何使用方案做事
每条路径都有一个方案
10个简单场景优于复杂场景。

您可以在https://github.com/diabolo/cuke_up/tree/master/features查看有关如何编写此类场景（在Ruby中）的详细信息。

警告：

这只是一个人的意见
你需要能够编写代码才能以这种方式工作（当你用黄瓜和帮助代码推送事情的所有细节时）。
注册是登录的先决条件

Answer 3

如此处出色回答所指出-每个方案本质上都是一个测试用例，因此必须明确分开。

尽管如此，至关重要的是要了解，Given / When / Then（在最基本的本质上）等同于系统测试的传统三个阶段：Arrange / Act / Assert，因此：

给出：将系统安排为已知状态

何时：命令系统（要测试的内容）

然后：确认结果符合您的预期。

就是这样！（当然，BDD的功能远不止这些-但这是可执行规范的基础）

Given User is on Home Page并未将系统安排为已知状态，但是Given I am registered 是。尽管仅仅说明这一点可能还不够，因为一旦您了解了场景的原因和后果，您就会很快意识到您缺少一些更具体的示例。

释义先前的答案：

{Given I am registered->设置用户（但是这与谁无关）在系统中注册（数据库条目？），并注册了什么？对结果有影响吗？

When I sign in->向系统发出登录命令（谁？）-这可以通过Web表单或API（或通过电话？）完成。请问您什么时候登录，可以立即登录吗？

Then I should be signed in->检查来自Web应用程序，数据库，会话的响应？ Cookie？

要说的是，登录场景可能不值得使用BDD来解决，因为它们的定义与CRUD一样明确-几乎不需要分析。

如何在Cucumber

3 个答案: