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

Question

背景资料

我试图帮助我的团队组织一个新的移动应用程序项目。我们选择遵循BDD（另请参见BDD定义），以捕获简单的英语需求，这些需求在涉众和开发人员之间形成了针对每个用户故事的合同。

我们使用验收测试来记录每个用户故事的需求。验收测试是在冲刺计划之前编写的。开发人员在冲刺计划期间改进并添加到测试中。

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

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

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

问题

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

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

我可能盗用了“验收测试”一词。在我的使用中，验收测试与单元测试的范围不在同一级别。我将验收测试视为高级集成测试。

榜样

• 作为客人
• 我要登录
• 访问应用html" target="_blank">程序功能

命令式测试

• 场景：有效登录

声明性测试

• 场景：有效登录
  • 鉴于我有一个有效的帐户
  • 然后我就可以登录

  这两者可以涵盖相同的功能，后者更短，但没有说明我是否可以使用用户名、电子邮件或facebook/twitter/google/etc帐户登录。仅仅编写解决方案是不够的

  问题

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

Answer 1

我最近去了一家商店/网上买了一台洗衣机和一台洗碗机。我只想买一个用水量少、洗得快的。但我遇到的细节是压倒性的；例如转速、内筒厚度、总连接负载（KW）等。

从上面的简单例子来看，命令式风格可能看起来很合适，但实际上它会使阅读场景变得更加困难和枯燥。通过阅读一个项目中的10个场景，您可以体验到这一点，其中您没有直接参与技术/日常层面的工作。

考虑到cucumber的目标之一是为整个项目带来透明度，特别是非技术用户，声明式风格更能让管理层积极参与。我在我的项目中看到了这一点。

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

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     | ?       |

您可能希望阅读的另一个链接是如何在不伤自己的情况下实现UI测试

Answer 2

写得不错的问题！

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

特征要求记录在步骤定义中。

因此，在您的命令式示例中：

When I enter "[e-mail]" 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社区对这个问题的其他答案将非常有趣。