Gauge中文文档(3)—深入开始

为什么是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中的步骤或者概念
  每一个步骤都有一个使用的编程语言的底层代码实现。当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：定义特殊参数的值
有两种特殊类型：

1. File
2. CSV

特殊参数:文件

这是通过读取文件然后将文件内容作为字符串参数传给底层步骤。
语法：< 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或者trar down功能。

• 任何常规步骤可以作为上下文
• 上下文在执行场景前被执行
  

在上面的示例spec中，User is logged in as Mike 和 Navigate to the project page是上下文步骤，它们在任意场景前被定义。这些步骤在每个场景Delete single project和Delete 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步骤。

示例

在上述示例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步骤执行