在本教程中，我们将向您介绍Gherkin - BDD语言(业务驱动开发)。我们将尽力详细回答这些问题
原文点击这里     

 

免费英语视频教程可见微信公众号：【软测小生】里面，请关注公号更新相关文章和视频资源。

 

另外有一个中国团队在做类似的事情，详情可见：http://cuketest.com/zh-cn/

• Gherkin是什么?
• 使用Gherkin有什么用?

接下来，让我们从一些细节开始学习。

 

什么是Gherkin-BDD语言?

在深入研究Gherkin之前，有必要了解跨项目不同领域的公共语言的重要性和需求。我所说的不同领域是指客户、开发人员、测试人员、业务分析师和管理团队。让我们先讨论开发项目中的常见问题，然后再讨论解决方案，在此过程中，我们将遇到对公共语言的需求。
插播：

Gherkin(剧本语法)是用于编写Cucumber、Specflow或类似的BDD框架规范的语言。这是一种业务人员可读懂的，特定领域的语言，它可以让你描述软件的行为，而不用详细说明如何实现这个行为。有几个约定：

• 一个gherkin源文件包含单个功能的说明。
• 源文件具有扩展名* .feature。
• 每个gherkin场景都有一个基本的模式，其中包括：（假如），事件（当）和结果（那么）

 

假设您是技术团队(开发人员和测试人员)的一部分，并且您有一个与业务团队(业务所有者和业务分析师)协作的任务。您必须提出项目的需求，这些需求将是你的开发团队将要实现的，而测试团队将进行测试。此外，你必须在你的电子商务平台上做一个小的搜索功能，这个功能将允许用户在您的网站上搜索产品。

正如我们在经验中可能都遇到过的，业务团队给出的需求是非常粗糙和基本的。例如，在这个场景中，我们可能会得到以下要求:

3. 功能需求
3.1 搜索功能
3.1.1 用户应该能够搜索产品
3.1.2 只显示与搜索字符串相关的产品。

以上需求提出的问题

正如我们所看到的，这些需求很好，也很有用，但并不准确。它们描述了系统的广泛行为，但没有指定系统的具体行为。让我通过分析第一个需求来说明它，第一个需求说用户应该能够搜索产品，但是它没有指定以下内容：

-搜索字符串的最大可搜索长度是多少?
-如果用户搜索无效的产品，搜索结果应该是什么?
-什么是可以用来搜索的有效字符?
*以及应用程序的一些更详细的行为。

通常在一个项目中，我们最终会向业务团队提出上述问题，并得到答复，大多数答复会到达项目文档，但不幸的是，这些答复会在电子邮件和电话对话中丢失。并且这些答复也可以解释，例如:
问业务负责人:如果用户搜索无效的产品，搜索结果应该是什么?
来自业务负责人的回复:无效的产品搜索应该在搜索页面上显示以下文本:没有找到产品(No product found)。

这些问题的回答导致更多的怀疑和解释

我们可以从业务团队那里得到问题的答案，但也可以通过以下方式进行解释或提出疑问:

-无效产品的定义是模糊的，不同的团队成员会以不同的方式解释。一个人可能认为一个无效的产品不存在于库存中，而其他团队成员可能认为一个无效的产品是一个拼写错误。
-业务团队的回答是“没有找到产品(No product found)”的文本应该显示在页面上。它是否说应该为用户提供一个新的搜索选项? 或者应该为用户提供一个相关的 / 类似的搜索选项?

这些是系统中引入有误差的精确点。此外，如果我们分析第二个疑问，我们将看到用户业务团队希望向用户提供一个新的搜索选项和 相关或者类似的搜索选项。然而，当被问到这个问题时，他们却想不出这个情景。因此，在上面的例子中发生的是：

1. 业务团队和技术团队在两个不同的层次上进行沟通，业务团队含糊其辞，而技术团队力求精确。
2. 系统中引入了模糊性，这里通过对“无效产品(invalid product)”的定义。
3. 没有给业务团队足够的洞察力，这样他们就可以提出新的场景。
4. 项目的一些细节在电子邮件和电话交谈中丢失了。

如何改进需求?

现在，让我们改进业务团队给出的第一个需求，并尝试使其更加精确:

“当用户在没有拼写错误的情况下搜索库存中的产品名称时。所有名称相似的产品均应展示”

“当用户在没有拼写错误的情况下搜索库存中的产品名称时。搜索结果应先显示准确的匹配项，然后再显示相似的匹配项。”

在这里，我们可以看到需求变得多么清晰，有了这些清晰的需求，我们就可以对系统进行更多的思考。例如：在第二个需求的情况下，读完后我们可能会想到其他的场景，比如:

• 如果没有精确和相似的匹配会发生什么?
• 应该给用户一个错误消息吗?
• 或者向用户提供一条消息，说明产品预计什么时候进入库存。

 

我们在这方面取得了什么成就?

我们已经迫使客户考虑细节。有了这种改进的思想，业务团队就有了更精细的需求。这进而减少了项目中的模糊性，并将通过减少错误实现的数量使开发人员和测试人员的工作变得简单。此外，您还可以看到，现在每个需求都记录了应用程序的一个确切行为。这意味着它本身可以被看作是一个需求文档。

 

结论是什么?

好吧，通过上面的例子或练习，我们可以总结如下:

1. 项目中的不同团队需要一种公共语言来表达需求。这种语言应该足够简单，能够被业务团队成员理解，并且应该足够明确，能够消除开发人员和测试人员的大部分歧义。
2. 这种语言应该打开团队成员的思路，以提出更多的场景。当您表达更多的细节时，您会尝试更多地可视化系统，因此您最终会创建更多的用户场景。
3. 这种语言应该足够好，可以用作项目文档。

为了解决这些问题，Gherkin(小黄瓜)应运而生。Gherkin是一种简单、轻量级和结构化的语言，它使用常规的口语来描述需求和场景。我们所说的常规口语指的是英语、法语和大约30多种语言。(包括中文)

 

Gherkin(小黄瓜)的例子

由于Gherkin是一种结构化语言，它遵循一些语法，让我们先来看一个用小黄瓜描述的简单场景。

Feature:为用户搜索功能      （中文：功能）
这个特性非常重要，因为它允许用户过滤产品
Scenario: 当用户搜索库存中的产品名称时，没有拼写错误。应显示所有名称相似的产品   （中文：场景）
Given 用户在www.myshopingsite.com的主页上  （中文：假如）
When 用户搜索笔记本电脑时 （中文：当）
Then 搜索页面应该更新笔记本电脑的列表 （中文：然后）

Gherkin包含一组关键字，这些关键字定义了场景的不同前提。正如我们在上面看到的彩色部分是关键字。我们稍后会详细讨论gherkin测试结构，但需要注意的重点是:

• -测试是用通俗易懂的英语编写的，对您的项目团队的所有领域都是通用的。
• -此测试的结构使其能够以自动方式读取。通过在描述场景的同时创建自动化测试。

 

后续会更新更多文章，上文种可能有些许错误，若有请指正，谢谢