如何通过声明性验收测试捕获需求？

Question

背景

我正试图帮助我的团队组织一个新的移动应用程序项目。我们选择遵循BDD (也请参阅BDD定义)，以捕获每个用户故事的利益相关者和开发人员之间形成契约的简单英语需求。

我们使用验收测试来记录每个用户故事的需求。验收测试是在短跑计划之前编写的。开发人员在sprint计划期间对测试进行细化和添加。

我们将接受标准定义为规则列表(例如:输入验证、默认值等)，验收测试定义为Cucumber场景列表。我们计划使用葫芦进行移动测试。

我觉得接受标准/测试是一种更灵活的方法，因此更好地解决了更正式的需求文档。

我觉得我找到了一个有效的解决方案，但我想了解其他人是如何收集需求和编写验收测试的。

问题

在祈使与陈述式测试步骤的Cucumber社区中存在着争论。我倾向于命令式，因为开发人员必须知道可交付的用户故事是什么样子的。

我不觉得UI耦合，也就是脆弱的测试是个问题。有一些方法可以将UI与测试分离(例如：页对象)。我也不觉得有详细的步骤会让非技术利益相关者很难理解(除非他们不知道如何使用网络浏览器或移动设备，但这是另外一个问题)。

我可能挪用了"验收试验“这个词。在我的使用中，验收测试与单元测试的范围不同。我认为验收测试是一个高级别的集成试验。

示例

• 作为客人
• 我想登入
• 访问应用程序功能

命令式测试

• 场景:有效登录
  • 如果我在“登录”屏幕上
  • 当我在“电子邮件”中输入“”时
    • 我在“密码”中输入"password1“
    • 我点击“登录”

​ - Then I see "login successful" ​ 陈述性测试

• 场景:有效登录
  • 如果我有一个有效的账户
  • 然后我就可以登录

​ 这两者都可以涵盖相同的功能，后者更短，但它并没有说明我是否可以登录用户名、电子邮件或facebook/twitter/google/etc帐户。仅仅编写一个解决方案是不够的 问题 如何通过声明性步骤捕获特性的需求？

Answer 1

写得很好！

如何通过声明性步骤捕获特性的需求？

特性的要求记录在step定义中。

因此，在您的祈使示例中：

When I enter "email@domain.com" in "email"
And I enter "password1" in "password"
And I tap "login"

这可以通过将其重写为：

Given I login using valid credentials

导航到有效帐户的步骤(即实现定义“有效”含义的验收标准)可以在此场景语句的步骤定义中实现。同样的情况也适用于相反的情况。

Given I login using invalid credentials

同样，满足接受标准的实现此场景的步骤可以在底层步骤定义中实现。

采用这种声明式方法意味着您失去了特性中的(命令式)需求(即需要执行的确切步骤)，使得业务很难从读取特性文件中确切地看出这些场景正在做什么。但是，您得到的好处是测试变得不那么脆弱了，因为实现任务的具体步骤记录在步骤定义中，并且这个步骤定义可以在许多特性之间共享。

在我的公司，我们努力解决同样的问题，我们发现在某些情况下，使用祈使句比声明式更好，反之亦然。例如，在您的示例中，构成“给定我有一个有效帐户”的步骤可能在许多特性中使用，因此使其具有声明性是合理的。但是，如果您有一个输入许多不同字符串值的特性，那么在这种情况下，最好是不令性地编写它们。

“马匹上菜！”

看到SO社区对这个问题的其他答案会非常有趣。

Answer 2

最近我去一家商店/网上买了一台洗衣机和一台洗碗机。我只想买一个用水少，洗得快的。但我遇到的细节是压倒性的，如RPM，内鼓厚度，总连接负荷在千瓦时等。

从上面简单的例子来看，命令式可能看起来很合适，但实际上它会使阅读场景变得更加困难和乏味。您可以通过阅读一个项目中没有直接涉及到技术/日常级别的10个场景来体验它。

考虑到使用黄瓜的目标之一是在整个项目，特别是非技术用户中增加透明度，声明式风格在让管理人员积极参与方面要好得多。我在我的项目中看到了这一点。

这是一个虚构的故事。试着用祈使的方式来实现它，再过几天再读一遍，你会发现它太无聊了。

Feature: Delivery 
    Free delivery is offered to customers who order two or more items

  Scenario Outline: Calculate postage for delivery
    Given I am signed-in
    When I "<order>" items
    Then postage should be "<postage>"   

    Examples:
    | order | postage |
    | 1     | 0.99    |
    | 2     | 0       |
    | 3     | 0       |
    | 0     | ?       |

您可能希望阅读如何实现用户界面测试而不自取灭亡的另一个链接