The primary keywords are:

• Feature
• Rule (as of Gherkin 6)
• Scenario (or Example)
• Given, When, Then, And, But (steps)
• Background
• Scenario Outline (or Scenario Template)
• Examples (or Scenarios)

There are a few secondary keywords as well:

• """ (Doc Strings)
• | (Data Tables)
• @ (Tags)
• # (Comments)

举例

Feature: Some terse yet descriptive text of what is desired
  In order to realize a named business value
  As an explicit system actor
  I want to gain some beneficial outcome which furthers the goal

  Scenario: Some determinable business situation
    Given some precondition
      And some other precondition
     When some action by the actor
      And some other action
      And yet another action
     Then some testable outcome is achieved
      And something else we can check happens too

  Scenario: A different situation
      ...

And/But作为Given/When/Then的同义词使用，

如Given x, And y 这里的And等同于之前的Given，以增加可读性。

Feature: Multiple site support
  Only blog owners can post to a blog, except administrators,
  who can post to all blogs.

  Background:
    Given a global administrator named "Greg"
    And a blog named "Greg's anti-tax rants"
    And a customer named "Dr. Bill"
    And a blog named "Expensive Therapy" owned by "Dr. Bill"

  Scenario: Dr. Bill posts to his own blog
    Given I am logged in as Dr. Bill
    When I try to post to "Expensive Therapy"
    Then I should see "Your article was published."

  Scenario: Dr. Bill tries to post to somebody else's blog, and fails
    Given I am logged in as Dr. Bill
    When I try to post to "Greg's anti-tax rants"
    Then I should see "Hey! That's not your blog!"

  Scenario: Greg posts to a client's blog
    Given I am logged in as Greg
    When I try to post to "Expensive Therapy"
    Then I should see "Your article was published."

Tips for using Background

• Don’t use Background to set up complicated states, unless that state is actually something the client needs to know.

  • For example, if the user and site names don’t matter to the client, use a higher-level step such as Given I am logged in as a site owner.

• Keep your Background section short.

  • The client needs to actually remember this stuff when reading the scenarios. If the Background is more than 4 lines long, consider moving some of the irrelevant details into higher-level steps.

• Make your Background section vivid.

  • Use colourful names, and try to tell a story. The human brain keeps track of stories much better than it keeps track of names like "User A", "User B", "Site 1", and so on.

• Keep your scenarios short, and don’t have too many.

  • If the Background section has scrolled off the screen, the reader no longer has a full overview of whats happening. Think about using higher-level steps, or splitting the *.feature file.

The keyword Scenario Template is a synonym of the keyword Scenario Outline.

A Scenario Outline must contain an Examples (or Scenarios) section.

Scenario Outline: eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |    12 |   5 |    7 |
    |    20 |   5 |   15 |

https://cucumber.io/docs/gherkin/reference/