Question

我们正在尝试使用BDD创建Web服务以向网页提供数据，然后保存用户的更改。

我到目前为止的故事

Given I want the data for order number  1234
When I load the data
Then I have the data for order number 1234

我的方法中缺少什么？用户故事不适合这种任务吗？我如何制定有意义的用户故事？

[更新]

As a customer
I want to see my order
So that I can check it is what I expect

Given I have entered the order number
When I Click GO
Then I should see my order displayed on the screen

Answer 1

以下是我到目前为止所写的内容：

Feature:
  As a customer
  I want to be able to view and change my orders
  So that I can check that they're being processed as I expect and deal with them if they're not

  Scenario:
    Given I am a customer
    And I have an order
    When I go to the order
    Then I should see the order

（我缩小了我的工具似乎希望我缩进Cucumber的方式，这是我使用的，但这并不重要。）

这至少是我以这种方式重写它的一些原因：

通常情况下，若干场景与相同的产品功能（在这种情况下为订单管理）位于同一个功能文件中，因此功能部分应具有比单个场景更广的范围。也许这个功能甚至应该包括首先下订单。
Given是在场景所涉及的时间段之前是真实的事情，例如客户和订单的存在。场景中的操作属于When s。
最好避免使用“点击”和特定按钮名称以及“显示在屏幕上”等UI细节。该场景应该关注行为。 When I go to the order步骤可以封装进入屏幕的详细信息，您可以在其中输入数字，输入数字，然后单击按钮。
同样，对于应该可见的订单的不同字段的所有检查都可以封装在Then I should see the order中。
我说“订单”而不是“我的订单”，因为And I have an order确定有一个与场景有特殊关系的订单，并且最好在所有场景中建立一种语言来建立这种关系明确 - 在这种情况下我总是使用“the”。（这是一个非常小的问题。）

有了这些风格点，这是一个好的方案，我当然写了很多类似的。然而，要找到真正的问题：

当Specflow类型工具真正发挥作用时，您可以使用它们来描述完整的用例/用户故事。例如：

  Scenario:
    Given I am a customer
    And there is a product

    When I go to the product page
    Then I should see the product

    When I add the product to my cart
    And I check out
    Then I should see that the order has been placed
    And I should receive an order confirmation email

    When I go to my orders
    Then I should see the order listed

    When I go to the order
    Then I should see the order

    When I cancel the order
    Then I should see that the order has been cancelled
    And I should receive an order cancellation email

    When I go to my orders
    Then I should not see the order listed

这作为验收测试更有价值，因为它可以捕获更多的需求，并且它作为集成测试更加强大，因为它可以运行更多的系统，并且可以减少它的使用量。（在短期情况下，我们必须人工创建一个订单。这里我们通过系统来完成。）

创建有意义的用户故事

1 个答案: