本文主要是介绍Cucumber 黄瓜测试 BDD 从入门到精通,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
1. Cucumber
Cucumber 是 BDD(Behavior-Driven Development,行为驱动开发)的一个自动化测试工具,使用自然语言来描述测试用例,使得 非研发(QA、PM)也可以理解甚至编写 测试用例。
官方表示:应该将 Cucumber 视为一个【文档编写工具】,而非一个单纯的自动化测试工具
- 撰写时,应该要以 PM 也能理解 测试用例 为目标去编写 Cucumber
2. Gherkin
Gherkin 是 Cucumber 用来描述 测试用例 的语言,以下为关键字的用意与关联关系。
以 分享概览 为例
- Given:新增 帐号abc@qq.com 、新增 概览1
- When:将 概览1 分享给 帐号abc@qq.com
- Then:校验 帐号abc@qq.com 是否能查看到 概览1
2.1 Scenario 范例
Feature: 授权功能 Scenario: 帐号 通过绑定 角色 进行授权 Given 新增角色 '分析师',拥有权限 '1001, 1002, 1003' And 新增帐号 'abc@qq.com' When 帐号 'abc@qq.com' 绑定角色 '分析师' Then 鉴权 帐号 'abc@qq.com',有权限 '1001' And 鉴权 帐号 'abc@qq.com',有权限 '1002' But 鉴权 帐号 'abc@qq.com',没有权限 '1005'复制代码
2.2 Background 范例
Feature: 授权功能 Background: Given 新增帐号 'abc@qq.com' Scenario: 帐号 通过绑定 角色 进行授权 Given 新增角色 '分析师',拥有权限 '1001, 1002, 1003' When 帐号 'abc@qq.com' 绑定角色 '分析师' Then 鉴权 帐号 'abc@qq.com',有权限 '1001' And 鉴权 帐号 'abc@qq.com',有权限 '1002' But 鉴权 帐号 'abc@qq.com',没有权限 '1005' Scenario: 帐号 通过绑定 机构 进行授权 Given 新增机构 '北京部门',拥有权限 '2001, 2002, 2003' When 帐号 'abc@qq.com' 绑定机构 '北京部门' Then 鉴权 帐号 'abc@qq.com',有权限 '2001' And 鉴权 帐号 'abc@qq.com',有权限 '2002' But 鉴权 帐号 'abc@qq.com',没有权限 '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 | abc@qq.com | 1001 | | 开发者 | 2001, 2002, 2003 | cde@qq.com | 2001 | | 管理员 | 3001, 3002, 3003 | fgh@qq.com | 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…
- 在 Cucumber 中描述你想要实现的 Scenairo,把所有的 Step 串连起来,
这篇关于Cucumber 黄瓜测试 BDD 从入门到精通的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!