为什么是Gauge?

开发人员和商业利益相关者之间的沟通障碍是软件开发的常见风险。Gauge是一种高级自动化工具,可以使项目的所有角色都能够理解需求,并帮助弥补差距。

Gauge的一些主要功能使得它独特包括:

  • 基于markdown的丰富标记;
  • 简单、灵活且丰富的语法;
  • 商业化语言测试:支持文档可执行的概念;
  • 一致的跨平台/语言支持来编写测试代码,目前为止支持的 语言
  • 开源,它可以免费分享且更好的被改善;
  • 具有插件支持的模块化架构;
  • 通过插件可扩展;
  • 支持外部数据源;
  • 帮助您创建可维护和易于理解的测试套件;
  • IDE支持

Gauge语法

Specifications(spec)

它们是业务层测试用例,也可以做为您的功能文档。它们是用业务语言编写,通常spec或者specification描述了被测应用的特定特征。

  • 它们编写在.spec后缀的文件内。Gauge也支持.md文件格式。
  • Specification文件的标记是基于markdown语法。

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Search Specification
=====================
The admin user must be able to search for available products on the search page.
Tags: search, admin

* User must be logged in as "admin"
* Open the product search page

Successful search
--------------------
Tags: successful
For an existing product name, the search result will contain the product name.

* Search for product "Die Hard"
* "Die Hard11 should show up in the search results

Unsuccessful search
---------------------
On an unknown product name search the search results will be empty
* Search for product "unknown"
* The search results will be empty

specification 标题

Spec文件必须以spec标题开始,且一个spec文件只能包含一个spec标题。它是以< H1 >的markdown语法编写,可以使用以下两种形式:

Spec Heading
===============

或者

# Spec Heading

  • 每个spec必须包含一个或者多个Scenarios;
  • 每个spec可以使用Tags标记。

Scenarios(场景)

每个场景代表特定spec中的单个流。Spec必须包含至少一个scenario。
一个场景在场景标题或者场景名后开始。场景标题以< H2>的markdown语法编写,可以使用以下两种形式:

Scenario heading
-----------

或者

## Scenario heading

  • 一个场景包含一个或者更多步骤在scenario名的下面
  • 可以使用标签来标记场景

示例

1
2
3
4
5
6
7
8
9
10
Configuration
================
The admin user should be able to switch permissions for other user.

Admin Login
-----------
* User must login as "admin"
* Navigate to the configuration page
* Change permissions for user "john" to "admin"
* User "john" should have admin permissions

Steps(步骤)

steps是您的spec内的可执行组件,它们被写为无序列表项(项目符号)。

它们写在spec中作为:

  • 上下文步骤
  • tear down步骤
  • 在scenario中的步骤或者concept中的步骤
    每一个步骤都有一个使用编程语言的底层代码实现。当spec内的步骤执行时被执行。参阅不同语言下的 步骤实现

示例

  • Login into my app
  • Search for “gauge”
  • Search for “gauge-java”

以引号表示的值是作为语言特定结构传递到基础步骤实现的参数。注意:下面的字符是为参数保留的,它们不可以使用在step内。

  • <
  • >

参数

可以定义步骤以将值作为参数 ,以便可以使用不同的参数值来重新使用。

1
2
* Check "product 1" exists
* Check "product 2" exists

在代码里的底层步骤实现里,必须和步骤传递来的参数数量一致。传递给步骤的参数是下列类型:

简单参数

它们是以双引号引入到步骤里的值。

1
2
* Create a “gauge-java” project
* Write “100” line specification

备注:
重命名参数将不会改变方法中的用法。根据设计,重命名的参数被认为是一个新的参数。因此,必须手动修改旧参数(如果有的话)的使用以解决相应的编译问题。

动态参数

动态参数作为值的占位符。
语法<dynamic_param>
动态参数主要使用在当数据驱动引用表列的值被执行时,或者将值传递给concepts时。

示例

example.cpt

1
2
# A sample concept that takes a <parameter>
* And used the <parameter> in a step.

上述concept可以被调用,并且可以在调用时将值传递给针对<parameter>的concept.

1
* A sample concept that takes a "dummy value"

备注:有关如何使用动态参数引用表格单元格值的说明,请参阅本 示例

表格参数

表格参数可以在以下两种方式使用:

  • 当要针对多组数据执行spec中的场景或者多个场景时,可以使用数据驱动执行
  • 表或者内联表可以作为参数传递给步骤

数据表的值在内联表内

数据表内的动态值也可以参考传递给步骤的表格参数

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Create projects
=================
|id|name|
|--|----|
|1 |john|
|2 |mike|

First scenario
------------------

* Create the following projects

|project name|username|
|------------|--------|
|gauge java |<name> |
|gauge ruby |<name> |

在上述的示例,表格参数使用数据表格内的动态值。

特殊参数

特殊参数提供了将更大更丰富的数据作为参数传递到步骤的能力。

  • 它们在步骤中以尖括号 <> 输入
  • 它们包含两个由冒号分割的部分:

<prefix:value>

Prefix :定义特殊参数的类型,比如:file,table
Value :定义特殊参数的值
有两种特殊类型:

  1. File
  2. CSV

特殊参数:文件

这是通过读取文件然后将文件内容作为字符串参数传给底层步骤。
语法 : <file:[value]> [value]是指文件的路径

[value]可以是相对或者绝对路径。相对路径相对于 GAUGE_PROJECT_ROOT 来解析。

示例:

1
2
* 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 来解析。

示例

1
2
* 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 specificationSuccessful login scenario 场景都有标签。

1
2
3
4
5
6
7
Login specification
===================
Tags: login, admin, user-abc

Successful login scenario
--------------------------
Tags: login-success, admin

应用在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
1
2
3
4
5
# 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功能。

  • 任何常规步骤可以作为上下文
  • 上下文在执行场景前被执行
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Delete project
=================

* Sign up for user "mike"
* Log in as "mike"

Delete single project
-----------------
* Delete the "example" project
* Ensure "example" project has been deleted

Delete multiple projects
------------------
* Delete all the projects in the list
* Ensure project list is eapty

在上面的示例spec中, User is logged in as MikeNavigate to the project page是上下文步骤,它们在任意场景前被定义。这些步骤在每个场景 Delete single projectDelete multiple projects 执行之前被执行。

Spec执行过程应该是:

  1. 上下文执行
  2. Delete single project 场景执行
  3. 上下文执行
  4. Delete multiple projects 场景执行

Tear Down步骤

Tear Down步骤在最后一个场景后被定义在spec内的步骤。它们允许你在每个场景执行后指定一系列清理步骤。它们被用来完成tear down功能。

  • 任何常规的步骤可以作为tear down步骤
  • tear down步骤在每个spec内的场景执行后被执行

语法

___ :三个或者更多的连续下划线指示tear down的开始。编写在tear down内(在三个或者更多联系的下划线之后)的步骤将被认为是tear down步骤。

1
2
3
4
___
* tear down step 1
* tear down step 2
* tear down step 3

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Delete project
=================

* Sign up for user "mike"
* Log in as "mike"

Delete single project
-----------------
* Delete the "example" project
* Ensure "example" project has been deleted

Delete multiple projects
------------------
* Delete all the projects in the list
* Ensure project list is eapty

_____________
These are teardown steps
* Logout user "mike"
* Delete user "mike"

在上述示例spec中, Logout user "mike"Delete user "mike" 是tear down步骤,它们在三个或者更多连续下划线后被定义。Spec执行过程应该是:

  1. 上下文执行
  2. Delete single project 场景执行
  3. Tear down步骤执行
  4. 上下文执行
  5. Delete multiple projects 场景执行
  6. Tear down步骤执行