Cucumber 黄瓜测试 BDD 从入门到精通

1. Cucumber

Cucumber 是 BDD（Behavior-Driven Development，行为驱动开发）的一个自动化测试工具，使用自然语言来描述测试用例，使得 非研发（QA、PM）也可以理解甚至编写 测试用例。

官方表示：应该将 Cucumber 视为一个【文档编写工具】，而非一个单纯的自动化测试工具

• 撰写时，应该要以 PM 也能理解 测试用例 为目标去编写 Cucumber

2. Gherkin

Gherkin 是 Cucumber 用来描述 测试用例 的语言，以下为关键字的用意与关联关系。

以 分享概览 为例

• Given：新增 帐号[email protected] 、新增 概览1
• When：将 概览1 分享给 帐号[email protected]
• Then：校验 帐号[email protected] 是否能查看到 概览1

2.1 Scenario 范例

Feature: 授权功能  
  
  Scenario: 帐号 通过绑定 角色 进行授权  
  
    Given 新增角色 '分析师'，拥有权限 '1001, 1002, 1003'  
    And 新增帐号 '[email protected]'  
  
    When 帐号 '[email protected]' 绑定角色 '分析师'  
  
    Then 鉴权 帐号 '[email protected]'，有权限 '1001'  
    And  鉴权 帐号 '[email protected]'，有权限 '1002'  
    But  鉴权 帐号 '[email protected]'，没有权限 '1005'

复制代码

2.2 Background 范例

Feature: 授权功能  

  Background:   
    Given 新增帐号 '[email protected]'  


  Scenario: 帐号 通过绑定 角色 进行授权  
  
    Given 新增角色 '分析师'，拥有权限 '1001, 1002, 1003'  
  
    When 帐号 '[email protected]' 绑定角色 '分析师'  
  
    Then 鉴权 帐号 '[email protected]'，有权限 '1001'  
    And  鉴权 帐号 '[email protected]'，有权限 '1002'  
    But  鉴权 帐号 '[email protected]'，没有权限 '1005'  
  
  
  Scenario: 帐号 通过绑定 机构 进行授权  
  
    Given 新增机构 '北京部门'，拥有权限 '2001, 2002, 2003'  
  
    When 帐号 '[email protected]' 绑定机构 '北京部门'  
  
    Then 鉴权 帐号 '[email protected]'，有权限 '2001'  
    And  鉴权 帐号 '[email protected]'，有权限 '2002'  
    But  鉴权 帐号 '[email protected]'，没有权限 '2005'

复制代码

2.3 Scenario Outline 范例

可以在多个 Step 上共用同一个 "简单" 参数，且每一个 Example 都视为一个 Scenario

Feature: 授权功能  
  
  Scenario Outline: 帐号 通过绑定 角色 进行授权  
  
    Given 新增角色 <role>，拥有权限 <permissions>  
    
    When 新增帐号 <account>  
    
    Then 帐号 <account> 绑定角色 <role>  
    And  鉴权 帐号 <account>，有权限 <has_permission>  
  
    Examples:  
	    | role   | permissions      | account    | has_permission |  
	    | 分析师  | 1001, 1002, 1003 | [email protected] | 1001           |  
	    | 开发者  | 2001, 2002, 2003 | [email protected] | 2001           |  
	    | 管理员  | 3001, 3002, 3003 | [email protected] | 3001           |
复制代码

3. 基本概念

3.1 文件结构

• Gherkin 写在 .feature 文件中
• Step 对应的逻辑 写在 .java 文件中

3.2 Step 映射

通过 Gherkin 语法上的描述，找到与 注解 value 值匹配的 Java 方法，将 Gherkin 与 Java 代码关联起来。

3.3 Scenario 独立

• 当同时执行多个 Scenario 时，执行每个 Scenario 对应的 Java 文件都会被重新创建。
• 不同的 Scenario 之间，不应该存在数据依赖（MySQL），如果存在依赖，将会使 Scenario 变得脆弱
  • 可以在 Backgroud，进行数据清理，来保证测试结果的正确性

二、最佳实践

1. 撰写 Scenairo 原则 - BRIEF

school.cucumber.io/courses/tak…

B：Business Language。

• Scenairo 中使用的词语应该使用【业务团队成员】能够理解的词语，否则将无法与业务团队成员互动。

R：Real Data。

• Scenairo 中应该使用 具体、真实 的数据（不要用 1、2、3、A、B、C），有助于让场景变得生动，并及早揭示边界条件与基本假设。

I：Intention Revealing。

• Scenairo 应该描述试图实现的意图，而不是描述程式将如何实现它的机制。
• 确保每一行 Step 描述的是 意图 而非 机制。 （比如：创建帐号，就不要写成 "将帐号数据写入 user 表，并在 account_project 表绑定帐号与项目的关联"）

E：Essential。

• Scenairo 应该只保留必要的 Step，不直接促成结果的场景都应该被删除。
• 任何不能增加读者对预期行为理解的场景，都不應該出现在文档中。

F：Focus。

• 多数的 Scenairo 应该只专注于单一职责。

BRIEF

• 建议将大多数的 Scenairo 限制在五行或更少，这将使它们更易于阅读与推理，并有助于避免 同时测试多个规则 或 增加额外细节。

2. 保证 Scenairo 可读性好处

school.cucumber.io/courses/tak…

• 随时获得 你做的事情是否正确 的反馈
• 你的 Feature 可以变成描述你 系统功能 的 线上文档
• Scenairo 将会引导你的技术设计

3. 开发流程推荐

school.cucumber.io/courses/tak…

1. 在 Cucumber 中描述你想要实现的 Scenairo，把所有的 Step 串连起来，