Cucumber是如何工作的

Cucumber是一种开源自动化测试框架，最初基于RUBY语言，但后来也支持诸如JAVA，C#等开发语言。Cucumber使用自然语言来编写测试用例（通常是英语，但也可以是其它语言），由Cucumber编写的自动化测试用例可以被团队所有成员读懂，这将大大降低需求转化为实际功能的过程中可能产生的误解，从而提高沟通效率和降低开发成本。

我们来看一个测试用例的例子：

Feature: Sign-up
  Sign-up should be quick and friendly.

  Scenario: Successful sign-up
    New users should get a confirmation email and be greeted
    personally by the site once signed in.

    Given I have chosen to sign up
    When I sign up with valid details
    Then I should receive a confirmation email
    And I should see a personalized greeting message

  Scenario: Duplicate email
    Where someone tries to create an account for an email address that already exists.

    Given I have chosen to sign up
    When I sign up with an email address that has already registered
    Then I should be told that the email is already registered
    And I should be offered the option to recover my password

不难看出，由Cucumber编写的自动化测试用例（基于gherkin语法)：

需求方可以通过该用例很容易地判断出是否满足需求

测试方可以通过该用例很容易判断出是否已经覆盖所需测试的场景

开发方可以通过该用例很容易判断出软件的功能应该完成哪些功能

那么Cucumber自动化测试框架又是如何工作的呢？

 

 

图中面向业务的有三种，分别是Features、Scenarios和Steps。三者之间存在结构关系，最大的是features（通常是一个文件，根据不同情况而定，测试框架中可包含一个或多个.features文件）。一个feature可包含一个或者多个Scenarios，而一个Scenario可包含一个或者多个steps(通常是多个steps）。

面向技术的也有三种，分别是 Step Definitions、Support Code和Automation Library。Cucumber作为一个 自动化测试框架，光有自然语言编写的测试用例，不足以自动测试，还需将这些测试用例和你所测试的软件系统建立联系。

• Step Definitions -> 将Gherkin语言中的步骤（Steps）与实际的代码实现关联起来的定义。每个Gherkin步骤都必须在Step Definitions中找到相应的实现。
• Support Code -> 是一组辅助代码、配置和工具，用于支持Cucumber测试的执行。它包括在测试运行期间使用的各种功能和工具，如配置文件、钩子（Hooks）、辅助方法、环境设置等。其目的是为了方便测试的编写、管理和执行。您可以将常见的配置、通用功能和重复的代码放在Support Code中，并在Step Definitions中调用它们，以提高测试的可维护性和可读性。
• Automation library -> 是用于实现Cucumber测试的具体自动化工具或库。Cucumber本身只是一个行为驱动开发（BDD）的框架，它提供了一种将测试用例和实际代码连接起来的结构。但是，实际的自动化工作通常需要使用具体的自动化库来实现测试步骤的执行和断言。比如Selenium和Appium都是其中一种。

简单来说，就是测试人员通过Gherkin语言编写测试用例，features告诉框架我们想要做什么；然后将测试用例中的步骤与实际的代码进行关联，step definitions告诉框架我们如何来做；而代码会调用自动化测试库的功能以及其它工具和库来解释具体的测试步骤，最后自动化测试库会针对系统完成或者模拟具体的一个个测试步骤。

文中的涉及的一些重要概念：

1. 验收测试(Acceptance Tests) -> 软件开发的最后阶段进行的一系列测试，旨在验证软件系统是否满足事先定义的验收标准和功能要求。

2. 自动化验收测试(Automated Acceptance Tests) -> 即是将验收测试自动化。

3. TDD(Test-driven development) ->  一种敏捷开发方法，其核心思想是在编写实际代码之前，先编写测试用例。TDD遵循以下基本循环：

• 编写测试：首先，开发人员编写一个测试用例，描述代码应该具备的某个特定行为或功能。

• 运行测试：运行测试用例，此时预期测试应该失败，因为尚未编写与测试用例匹配的实际代码。

• 编写代码：根据测试用例编写足够的代码来实现所需的功能或行为。

• 运行测试：再次运行测试用例，预期测试应该通过，如果没有通过，则需要进行代码修正。

• 重构代码：对代码进行重构，以改善其设计、性能或可读性，确保测试仍然通过。

这个循环一遍又一遍地进行，每次迭代都会增加一小部分功能，并且通过测试用例进行验证。TDD的目标是通过快速迭代和频繁测试来提高代码质量、可维护性和可靠性。

4. BDD(Behaviour-driven development) -> BDD是一种软件开发方法，旨在更加强调软件的行为和业务价值。BDD关注于描述系统行为和期望结果，以帮助开发人员、测试人员和非技术人员更好地理解需求，并促进团队之间的协作。

BDD使用自然语言（通常是英语）编写测试用例，以更好地描述系统的行为和预期结果。BDD测试用例通常使用"Given-When-Then"结构，如下所示：

• Given（假设）：描述测试场景的背景和先决条件。
• When（当）：描述要测试的特定行为或事件。
• Then（那么）：描述预期结果和期望的行为。

BDD帮助开发人员和非技术人员更好地理解系统行为，促进团队之间的沟通和协作。

5. Gherkin -> 是一种用于描述软件行为规范的领域特定语言（DSL）。它是Cucumber框架中使用的语言，用于编写测试用例和规范，以促进团队成员之间的沟通和理解。

Gherkin采用自然语言风格的语法，具有简洁和易读的特点。它主要用于描述系统行为和用户故事，以及与之相关的测试场景和步骤。

某种程度上来说，Gherkin也是一种编程语言，其最初的设计目的是让编写出的自动化测试用例像文档一样可读且有意义。

以下是Gherkin语言的关键字：

Feature

Background

Scenario

Given

When

Then

And

But

*

Scenario Outline

Examples