文章目录
Cucumber简明教程
入门篇
简单介绍
- 用途:BDD(行为驱动开发)自动化测试产品,可以和目前很多语言结合在一起。
- 有明确的可执行规范,自动化测试,记录系统的实际行为
- 特点:它使用自然语言来描述测试,使得非程序员可以理解他们
- 官方安装地址:https://cucumber.io/docs/installation/
- 依赖包:
dependencies {
testCompile 'io.cucumber:cucumber-java8:4.3.1'
testCompile 'io.cucumber:cucumber-junit:4.3.1'
testCompile 'info.cukes: cucumber-java:1.2.5' //2016年之前的包
}
- 如果你用的是IEAD可以检查是否自动安装了该插件:Cucumber for Java plugin,如果没有自己手动安装下
Gherkin语法部分
概念介绍
- Feature:一个测试用例集
- SCENARIOS:类似一个具体测试用例或场景
- STEPS:测试步骤,每个SCENARIOS包含多个STEPS,STEPS可以使用如下关键词:Gievn,When,Then,But,And等
- Given:创建测试环境需要的前提条件
- When:触发某个业务事件
- Then:验证事件产生的结果
- And:多个前提条件时使用,连接前一个条件,作为正向条件
- But:多个前提条件时使用,连接前一个条件,作为反向条件
- Background:执行SCENARIOS之前会执行Bankground,在一个Feature里只能有一个,作用上有点SCENARIOS,作为公共的步骤
- arguments:步骤中传入参数,支持单个参数和复杂参数datatable
- SCENARIOS Outline:重复场景数据
基本原理
对国家语言支持
- 支持40多种语言
- https://github.com/cucumber/cucumber/blob/master/gherkin/gherkin-languages.json
几个feature文件的例子
- 一个加减法的例子
Feature: Basic Add Test
Background: give x and y value
Given x and y value
Scenario: Addition
Given x is 4 and y is 5
When invoke add Method
Then the result is 9
Scenario: autoX
Given x is 1
When invoke autoX Method
Then the result is 2
Scenario: Sub
And sub operation
When invoke calculate button
Then the result is x-y
- 一个复杂参数例子
Feature: Complex data type
Scenario: multiple then keywords
Given the user account infomation
Then we can found user "hzqiuxm", with password "123456", phone "13989461462"
Then we can found user "linjiangxian", with password "123456", phone "13989461462"
Then we can found user "queqiaoxian", with password "123456", phone "13989461462"
Scenario:
Given use complex data
Then 验证下面的一些用户账号信息
| name | password | phone |
| hzqiuxm | 123456 | 13989461462 |
| linjiangxian | 123456 | 13989461462 |
| queqiaoxian | 123456 | 13989461462 |
- 一个公共场景和中文支持的例子
Feature: With Scentrio Outline
Background: 公共的登录操作
Given 进行用户登录来测试Scentrio Outline
Scenario Outline: 用户名或密码错误
When 使用错误用户名 "<UserName>" 和密码 "<Password>" 来登录
Then 不正确的用户名或密码
Examples:
| UserName | Password |
| hzqiuxm | 123321 |
| simon | 123321 |
Scenario: 正确的用户名密码登录测试
When 使用正确用户名 "hzqiuxm", 密码 "123456" 来登录
Then 用户名密码正确,登录成功
操作步骤详情部分
Step Definitions
- 不要定义重复的或模棱两可(正则匹配多个符合)的steps
- 正则表达式的使用(参数要使用是小括号分组,字符串要用双引号)
- 想多种情况下匹配又不想抓取参数时,使用?:正则表达式来进行说明
- DataTable数据格式:dataTable类型,用户自定义类型(https://github.com/cucumber/cucumber/tree/master/datatable),list map类型,list list类型
- DataTable的compare来做一些结果对比,用于CURD或其它操作结果的一些检测
Tagging
- 可以按照标签来执行场景用例,使用"@"符号,例子:@v1.0.0 @hzqiuxm
- 使用~ 取反,放在一个不同""里表示and关系,放在同一个""里表示or关系
tags = {"@v1.0.0","not @santai"} //执行v1.0.0标签并且不包含santai标签的场景用例
Hooks
- 类似Junit中的before,after作用,执行顺序:Before Hook, Background,Scenario,After Hook
- @Before代表之前,@After代表之后
- 多个Before后After可以使用Order属性值来控制,默认是按照代码中顺序来执行
- Before和After可以结合tag属性,控制其作用范围,默认情况下是所有feature都有效的,tag属性也只是and和or的关系
Options
- 作用在启动类上,用来控制测试报告report输出、plugin插件、标签Tag选择、环境配置、Feature文件选择、严格模式等
@CucumberOptions(plugin = {"pretty","json:target/cucumber-report3.json"},tags = {"@v1.0.0","~@santai"})
- Feature:只执行指定路径下的feature
- gule:指定feature对应的测试类路径
- tags:指定执行的标签规范
- dryRun:不会真正的去执行steps,但会检查哪个feature没被实现
- strict:严格模式下出现未实现的steps或断言失败就会失败报错
- monochrome:影响控制台输出的样式效果
- 支持的输出格式:html:target/Cucumber;json:target_json/Cucumber.json;junit:target_json/Cucumber_junit.xml
第三方整合
- Jenkins整合,在Jenkins中安装cucumber 插件
自动构建后就会生产相关的报告
- 结合Assured进行RESTful API测试
http://rest-assured.io/
https://www.baeldung.com/rest-assured-tutorial/
- 结合selenium进行自动化测试
// https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java
compile group: 'org.seleniumhq.selenium', name: 'selenium-java', version: '3.14.0'
几个gradle下的cucumber插件
- https://github.com/samueltbrown/gradle-cucumber-plugin
- https://plugins.gradle.org/plugin/se.thinkcode.cucumber-runner
- https://plugins.gradle.org/plugin/com.github.spacialcircumstances.gradle-cucumber-reporting
- https://github.com/awbdallas/gradle-cucumber-jvm-plugin
个人总结
- cucumber是敏捷开发团队常用的一种测试框架,它鼓励了系统开发环节中各个参与者来进行协作,其中也包括非技术人员
- cucumber中的测试场景一般由纯自然语言来进行描述,很易懂,因此,非技术人员也可以来编写测试用例,然后通过技术人员来进行实现它。
- Cucumber可以让人们用近似自然的语言去描述Feature和场景,根据Feature驱动开发。用作软件技术人员和非技术之间验收测试的桥梁。
- 如果刚开始践行BDD,通常最好让开发人员编写
- 如果只是用作测试自动化工具,可以由测试人员和开发人员编写
- 特性(Feature)文件应该描述特性,而不是应用程序的组成部分,每个特性文件应有一个好的命名,并保持特性的专注
- 避免特性与领域逻辑的不一致性,确保使用客户的领域语言。这一活动的最佳做法是让客户也参与编写故事。
- 用组织代码的思想来组织你的特性与场景(Scenary)
- 灵活使用标签Tag
- 您的方案应该描述系统的预期行为,而不是实现。换句话说,它应该描述什么,而不是如何描述