验收测试驱动开发

最新推荐文章于 2024-02-18 14:21:22 发布

danpu0978

最新推荐文章于 2024-02-18 14:21:22 发布

阅读量315

点赞数

文章标签： java python linux 人工智能编程语言

在这个简短的关于验收测试的系列文章中，我之前写过关于测试人员和开发人员之间的协作以及验收测试如何帮助定义系统的明确要求的文章。

上一篇文章是理论上的，现在让我们来看一下在开发过程中将验收测试作为一种实践。我更喜欢使用验收测试驱动开发或ATDD。

简而言之

使用ATDD，您可以使用验收测试来指导功能的实现路径。您编写了失败的测试方案和所需的粘合代码。当方案失败并显示正确的消息（即测试工具可以运行验收测试并且消息正确描述缺少的功能）时，您便开始实施该功能。

就像在TDD中一样，使用最简单的方法来使场景通过，但要在功能级别上进行。在TDD中，您将以最简单的方式通过测试，然后从那里进行改进。在ATDD中，您只需以最简单的方式来实现该功能即可通过该方案。简而言之，如果您具有正确的场景集，则该功能将在最后一个场景通过时实现。

[请注意，我故意选择不使用done一词，因为在实现该功能后，我们经常需要摆弄UI些。

示例问题

例如，我们将使用ATDD为《哈利·波特》图书销售片建立购物车。客户根据所购买系列书籍的数量获得折扣。此练习摘自Coding Dojo网站上的kata列表。有关完整描述，请阅读： http : //codingdojo.org/cgi-bin/wiki.pl?KataPotter 。

《哈利·波特》系列的前五本书正在发售中。任何一本书的售价为8美元。如果您购买该系列中的两本不同的书，则可享受5％的折扣；如果您购买三本不同的书，则可享受10％的折扣；如果您购买四本不同的书，则可享受20％的折扣；如果您购买全部五本，您将获得5％的折扣。 25％的折扣。

让我们配对并一起构建此功能。

讨论和提炼

构建新功能的周期分为几个阶段。在考虑编写生产代码之前，我们必须先了解一些场景。还记得上一篇文章中我们如何谈论与业务专家的团队会议吗？这些活动构成了开发周期的第一阶段：讨论和提炼。

我们的团队安排了与业务专家的会议，讨论购物车。我们已经准备了一些问题，因此这次会议非常有效。我们的团队比在这次会议上讨论技术细节更了解。我们不想浪费任何业务专家的宝贵时间。在会议结束时，我们记下了描述购物车行为的示例。为了清楚起见，我们决定使用罗马数字列出这些书。

一世	II	三级	IV	V	式	$
1个					1 * 8	8.00
1个	1个				2 * 8 * 0.95	15.20
1个	1个	1个			3 * 8 * 0.9	21.60
1个	1个	1个	1个		4 * 8 * 0.8	25.60
1个	1个	1个	1个	1个	5 * 8 * 0.75	30.00
2					2 * 8	16.00
2	1个				2 * 8 * 0.95 + 1 * 8	23.20
2	2	2	1个	1个	4 * 8 * 0.8 + 4 * 8 * 0.8	51.20

这些行中的大多数几乎都是不言自明的。最后一行显示有2套共4本书。这可能令人惊讶，因为您期望一套5本书和一套3本书。原因是必须为客户优化折扣。在这种情况下，最好的折扣是购买2套4本书，因为这比5本书和3本书便宜0.40美元。

会议结束后，我们将从这些示例中提取验收测试，并将其保存为Cucumber方案。第一个示例的方案如下：

Scenario: buy single book without discount

  When I buy 1 copy of "Harry Potter I"
  Then I must pay $8

事实证明，第二个示例的场景与第一个示例非常相似：

Scenario: buy two distinct books

  When I buy 1 copy of "Harry Potter II"
  Then I must pay $15.20

显然，其余方案可以以相同的方式添加。但是正在出现一种模式。仅使用不同的值而必须复制和粘贴完全相同的场景将非常繁琐且重复。此外，如果我们也可以将与业务专家会面时得到的示例表也用于验收测试，那就太好了。这将使我们的方案作为文档更加有用。

黄瓜提供了方案大纲功能来提供帮助。方案大纲通过使用带有占位符的模板和示例表来更简洁地表达这些示例。我们尝试对前两个方案的方案大纲，然后决定使用该大纲添加其余方案。

Scenario Outline: buy discounted Harry Potter books

  When I buy <I> copies of "Harry Potter I"
  And I buy <II> copies of "Harry Potter II"
  And I buy <III> copies of "Harry Potter III"
  And I buy <IV> copies of "Harry Potter IV"
  And I buy <V> copies of "Harry Potter V"
  Then I must pay $<Total>

Examples:
  | I | II | III | IV | V | Total |
  | 1 | 0  | 0   | 0  | 0 |  8.00 |
  | 1 | 1  | 0   | 0  | 0 | 15.20 |
  | 1 | 1  | 1   | 0  | 0 | 21.60 |
  | 1 | 1  | 1   | 1  | 0 | 25.60 |
  | 1 | 1  | 1   | 1  | 1 | 30.00 |
  | 2 | 0  | 0   | 0  | 0 | 16.00 |
  | 2 | 1  | 0   | 0  | 0 | 23.20 |
  | 2 | 2  | 2   | 1  | 1 | 51.20 |

这还差不多。使用大纲，我们的示例阅读起来就像我们之前绘制的表格一样。

显然，尽管我们已经成功地讨论了该功能以及该讨论的精炼验收方案，但在此阶段我们还没有完成。现在，我们有一套完整的验收方案。根据业务专家的说法，我们的方案是问题的完整表示。方案的注释格式非常简单，业务专家可以查看它们。

现在我们的团队已准备好实施阶段。

实行

我们需要的第一件事是粘合代码，以便示例可以运行并通过合理的错误消息失败。幸运的是，Cucumber可以通过生成存根来帮助我们创建必要的粘合功能。在没有胶水代码的情况下进行第一次运行之后，我们可以复制并粘贴以执行挂起的步骤。

下面列出了此类针对Java生成的函数的示例。这是Cucumber场景中单个步骤的粘合代码，也称为步骤定义。

When("^I buy (\\d+) copies of \"([^\"]*)\"$")
public void I_buy_copies_of(int arg1, String arg2) throws Throwable {
    // Express the Regexp above with the code you wish you had
    throw new PendingException();
}

现在所有步骤都待处理，我们开始执行步骤以使第一种情况失败并显示相应的消息。为了完成这些步骤，我们需要添加一些基本的生产代码，稍后我们将通过实现对其进行增强。这很有趣，因为此时我们希望我们的API 能够从验收测试中获得自然流。

当第一种情况失败并显示一条描述缺少的功能的消息时，我们将实施该功能。然后，我们继续下一个，依此类推，直到所有功能通过。我们使用TDD保持代码干净。

就本文而言，步骤定义和代码的实际实现并不那么有趣。由于我也不想放弃这些细节，所以我做了练习，将代码放在了Github上。

构建新功能的最后阶段是对其进行审查。我不是在这里谈论代码审查，这些审查是在实施阶段进行的。

为了总结我们的新功能，我们进行了一些探索性测试。探索性测试通过使用自由样式来找出系统的实际工作方式。即没有要遵循的测试脚本。相反，测试用例是即时发明的，并立即针对系统执行。如果您想了解有关探索性测试的更多信息，我建议您阅读Elisabeth Hendrickson的精彩著作“ 探索它”！

在审核阶段，我们会记录通过探索性测试发现的任何不一致之处。

为了完成我们的功能，我们将其演示给业务专家并收集他们的反馈。结合探索性测试的任何结果，这对于业务专家而言是重要的输入。只有他们才能决定系统的行为方式。