您如何通过声明式验收测试捕获需求？答案

【问题标题】：How do you capture requirements with declarative acceptance tests?您如何通过声明式验收测试捕获需求？
【发布时间】：2018-01-24 01:50:05
【问题描述】：

背景

我正在努力帮助我的团队组织一个新的移动应用项目。我们选择关注BDD（另请参阅BDD definition）以获取简单的英语要求，从而形成利益相关者和开发人员之间针对每个用户故事的合同。

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

我们将 Acceptance Criteria 定义为规则列表（例如：输入验证、默认值等），将 Acceptance Tests 定义为 Cucumber 场景列表。我们计划使用Calabash 进行移动测试。

我觉得验收标准/测试对更正式的需求文档来说更灵活，因此是更好的解决方案。

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

问题

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

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

我可能盗用了“Acceptance Test”这个词。在我的使用中，验收测试与单元测试不在同一范围内。我将验收测试视为高级别的integration test。

示例

作为客人
我要登录
访问应用功能

命令式测试

场景：有效登录
- 鉴于我在“登录”屏幕上
- 当我在“电子邮件”中输入“email@domain.com”时
  - 我在“密码”中输入“密码1”
  - 然后我点击“登录”
- 然后我看到“登录成功”

声明式测试

场景：有效登录
- 假设我有一个有效的帐户
- 然后我就可以登录了

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

问题

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

【问题讨论】：

Dan North（BDD 的创建者）对此事有一些很好的想法：dannorth.net/2011/01/31/whose-domain-is-it-anyway。请记住，一个场景应该只针对两个领域：该功能的用户和将要实现该功能的开发人员。该方案应向两个域阐明将如何发生（例如：“用户使用电子邮件和密码登录”，而不是“用户使用用户名和密码登录”等）
blog.cyrusinnovation.com/2013/04/… 表示，当利益相关者关心给定场景的用户体验时，命令式是合适的。通过声明性来追求简洁是有意义的，而在需要时用命令式来明确。
这个问题似乎是题外话，因为它是关于项目规划的。我认为应该迁移到programmers.stackexchange.com。
我不认为这是题外话，因为问题是关于命令式与声明式 BDD 测试，而不是关于项目规划。可能值得重命名问题标题？

标签： cucumber bdd calabash acceptance-testing

【解决方案1】：

问题写得很好！

您如何使用声明式捕获功能的需求步骤？

功能的要求记录在步骤定义中。

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

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

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

采用这种声明性方法意味着您失去了功能的（必要的）要求（即需要执行哪些确切步骤），使企业更难确切地了解这些场景是什么只需阅读功能文件即可。但是，您得到的好处是测试变得不那么脆弱了，因为完成任务的具体步骤记录在步骤定义中，并且此步骤定义可以在许多功能之间共享。

在我的公司，我们也遇到了同样的问题，我们发现在某些情况下使用命令式比使用声明式更好，反之亦然。例如，在您的情况下，构成“鉴于我有一个有效帐户”的步骤可能会在许多功能中使用，因此使其具有声明性是合理的。但是，如果您有一个输入许多不同字符串值的功能，那么在这种情况下，最好以命令方式编写它们。

"Horses for courses!"

从 SO 社区看到这个问题的其他答案会很有趣。

【讨论】：

我可以看到在每个用户故事中强制定义验收测试，然后在实际黄瓜场景中以声明方式定义验收测试以使其不那么脆弱的一些价值。感谢分享！
考虑一下，我们可以使用接受标准来列出“有效帐户”的详细信息（例如：电子邮件和密码，而不是用户名和视网膜扫描）。这样可以让场景更简短，同时仍然为每个用户故事捕获足够的需求以供开发人员完全实施......我喜欢这个想法。
另外，您可以在方案标题中添加有关验收标准的“刚刚好”的详细信息。因此，在您的示例中，您可以使用“场景：仅使用视网膜扫描登录”和“场景：使用电子邮件和密码登录”。
是的，我同意。我为一个糟糕的例子道歉！我应该说的是“场景：使用有效电子邮件和无效密码登录”，“场景：使用无效电子邮件和有效密码登录”和“场景：使用有效电子邮件和密码登录”。
我很高兴有人问这个问题，因为我遇到了同样的问题

【解决方案2】：

我最近访问了一家商店/在线购买了洗衣机和洗碗机。我只想买一个用水少、洗得快的。但是我遇到的细节是压倒性的；如转速、内筒厚度、总连接负载（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     | ?       |

您可能希望阅读的另一个链接How to implement UI testing without shooting yourself in the foot

【讨论】：

很好的插图，但在这个例子中，真正的问题是指定登录的含义、订购商品、邮资的货币以及邮资的地区/国家是为了。就像我在问题中提到的那样，我想知道在使用声明性步骤时在哪里定义实现要求。谢谢。