最新翻译(2020/12/1)已更新在个人博客:https://www.nothinghere.cn/gauge/overview/
为什么是Gauge?
开发人员和商业利益相关者之间的沟通障碍是软件开发的常见风险。Gauge是一种高级自动化工具,可以使项目的所有角色都能够理解需求,并帮助弥补差距。
Gauge的一些主要功能使得它独特包括:
- 基于markdown的丰富标记;
- 简单、灵活且丰富的语法;
- 商业化语言测试:支持文档可执行的概念;
- 一致的跨平台/语言支持来编写测试代码,目前为止支持的语言。
- 开源,它可以免费分享且更好的被改善;
- 具有插件支持的模块化架构;
- 通过插件可扩展;
- 支持外部数据源;
- 帮助您创建可维护和易于理解的测试套件;
- IDE支持。
Gauge语法
Specifications(spec)
它们是业务层测试用例,也可以做为您的功能文档。它们是用业务语言编写,通常spec或者specification描述了被测应用的特定特征。
- 它们编写在.spec后缀的文件内。Gauge也支持.md文件格式。
- Specification文件的标记是基于markdown语法。
示例
specification标题
Spec文件必须以spec标题开始,且一个spec文件只能包含一个spec标题。
它是以< H1 >的markdown语法编写,可以使用以下两种形式:
Spec Heading
===============
或者
Spec Heading
- 每个spec必须包含一个或者多个Scenarios;
- 每个spec可以使用Tags标记。
Scenarios(场景)
每个场景代表特定spec中的单个流。Spec必须包含至少一个scenario。
一个场景在场景标题或者场景名后开始。场景标题以< H2>的markdown语法编写,可以使用以下两种形式:
Scenario heading
————
(译者注:这里其实是“—”虚线的形式,因为使用的csdn的markdown语法编辑器会自动把虚线给转换成分隔符)
或者
Scenario heading
- 一个场景包含一个或者更多步骤在scenario名的下面
- 可以使用标签来标记场景
示例
Steps(步骤)
steps是您的spec内的可执行组件,它们被写为无序列表项(项目符号)。
它们写在spec中作为:
- 上下文步骤
- tear down步骤
- 在scenario中的步骤或者concept中的步骤
每一个步骤都有一个使用编程语言的底层代码实现。当spec内的步骤执行时被执行。
参阅不同语言下的步骤实现。
示例
- Login into my app
- Search for "gauge"
- Search for "gauge-java"
以引号表示的值是作为语言特定结构传递到基础步骤实现的参数。
注意:下面的字符是为参数保留的,它们不可以使用在step内。
- "
- <
参数
可以定义步骤以将值作为参数 ,以便可以使用不同的参数值来重新使用。
* Check "product 1" exists
* Check "product 2" exists
在代码里的底层步骤实现里,必须和步骤传递来的参数数量一致。
传递给步骤的参数是下列类型:
简单参数
它们是以双引号引入到步骤里的值。
* Create a “gauge-java” project
* Write “100” line specification
备注:
重命名参数将不会改变方法中的用法。根据设计,重命名的参数被认为是一个新的参数。因此,必须手动修改旧参数(如果有的话)的使用以解决相应的编译问题。
动态参数
动态参数作为值的占位符。
语法:< dynamic_param >
动态参数主要使用在当数据驱动引用表列的值被执行时,或者将值传递给concepts时。
示例
example.cpt
# A sample concept that takes a <parameter>
* And used the <parameter> in a step.
上述concept可以被调用,并且可以在调用时将值传递给针对< parameter>的concept.
* A sample concept that takes a "dummy value"
备注:
有关如何使用动态参数引用表格单元格值的说明,请参阅本示例。
表格参数
表格参数可以在以下两种方式使用
- 当要针对多组数据执行spec中的场景或者多个场景时,可以使用数据驱动执行
- 表或者内联表可以作为参数传递给步骤
数据表的值在内联表内
数据表内的动态值也可以参考传递给步骤的表格参数
示例
在上述的示例,表格参数使用数据表格内的动态值。
特殊参数
特殊参数提供了将更大更丰富的数据作为参数传递到步骤的能力。
- 它们在步骤中以尖括号 -<> 输入
- 它们包含两个由冒号分割的部分 :
< prefix:value>
Prefix:定义特殊参数的类型,比如:file,table
Value:定义特殊参数的值
有两种特殊类型:
特殊参数:文件
这是通过读取文件然后将文件内容作为字符串参数传给底层步骤。
语法:< file:[value]> [value]是指文件的路径
备注
[value]可以是相对或者绝对路径。相对路径相对于GAUGE_PROJECT_ROOT来解析。
示例
* Verify email text is <file:email.txt>
* Check if <file:/work/content.txt> is visible
文件的路径可以是相对Gague项目路径的相对路径或者文件的绝对路径。
特殊参数:CSV
表格通常用于从外部csv文件读取再传递表格值给steps。步骤中的参数文本包含前缀表和csv文件的路径。
语法:< table:[value]> [value]是指csv文件的路径。
备注:
[value]可以是相对或者绝对路径。相对路径相对于GAUGE_PROJECT_ROOT来解析。
示例
* Step that takes a table <table:data.csv>
* Check if the following users exist <table:/Users/john/work/users.csv>
简单的csv文件
Id,Name
1,The Way to Go On
2,Ivo Jay Balbaert
第一行被视为表头,后面的行视为列的值。
标签
Tags用于将标签与sepc或者scenarios关联。标签用前缀Tags:和逗号分割值写成。
- Spec和scenarios可以单独标记
- 只能将一组标签添加到单个spec或者scenario中
它们有助于基于使用标签的标签来过滤spec或者scenario。
示例
在下面的例子里Login specification
和Successful login scenario
场景都有标签。
应用在spec的标签自动应用在场景里。
Concepts
Concepts提供将步骤中的重复使用的逻辑组组合到一个单元中的能力。它通过组合步骤来提供更高层次的业务意图抽象。
它们在项目中specs文件夹的.cpt格式文件内被定义。它们也可以保存在specs文件夹的子目录内。
- Concepts在spec的使用就象其他步骤一样,将适当的参数传递给它们。
- Concepts下的所有步骤都按照定义的顺序执行。
备注:一个.cpt文件可以包含多个concept定义
concept定义
使用concept定义在sepcs文件夹内创建一个.cpt文件。Concept定义包含两部分:
Concept标题
concept标题定义concept的名字和它将使用的参数。它写成markdown H1
格式。
- 所有的参数被定义在角括号
<>
- 一个concept的定义必须包含concept标题
# Concept name with <param0> and <param1>
步骤
concept里的步骤紧跟concept标题。它们以常用的步骤结构定义。
- 所有从concept标题使用的参数在
<>
内 - 固定的静态参数用
""
括起来 - concept定义也可以调用其他concept
# Login as user <username> and create project <project_name>
* Login as user <username> and "password"
* Navigate to project page
* Create a project <project_name>
在上面的示例:
- 第一行是concept标题
- 下面三行是在concept中的抽象
上下文
上下文或者上下文步骤是在任何场景之前被定义在spec的步骤。
它们允许您指定必须用来执行spec步骤的条件集合。上下文步骤可以用来在执行场景前初始化数据。它们也可以完成setup或者tear down功能。
- 任何常规步骤可以作为上下文
- 上下文在执行场景前被执行
在上面的示例spec中,User is logged in as Mike
和 Navigate to the project page
是上下文步骤,它们在任意场景前被定义。这些步骤在每个场景Delete single project
和Delete multiple projects
执行之前被执行。
Spec执行过程应该是:
- 上下文执行
Delete single project
场景执行- 上下文执行
Delete multiple projects
场景执行
Tear Down步骤
Tear Down步骤在最后一个场景后被定义在spec内的步骤。它们允许你在每个场景执行后指定一系列清理步骤。它们被用来完成tear down功能。
- 任何常规的步骤可以作为tear down步骤
- tear down步骤在每个spec内的场景执行后被执行
语法
___
:三个或者更多的连续下划线指示tear down的开始。编写在tear down内(在三个或者更多联系的下划线之后)的步骤将被认为是tear down步骤。
示例
在上述示例spec中,Logout user "mike"
和 Delete user "mike"
是tear down步骤,它们在三个或者更多连续下划线后被定义。
Spec执行过程应该是:
- 上下文执行
Delete single project
场景执行- Tear down步骤执行
- 上下文执行
Delete multiple projects
场景执行- Tear down步骤执行