在Xebium目录结构和页面类型中，提到每个测试脚本（Wiki页）都是文件夹里的目录，用例集也就是目录下有各个用例（目录）的父目录。那么，如果我们创建文件或者目录的软链接会发生什么，如何利用这个特性来应用到测试用例的组织中去呢？

    如果接触过Linux系统，那么一定对软链接（Symbolic Links）的创建很熟了；对于windows用户来说，则相当于建立一个目录或者文件的快捷图标（.lnk）文件。现在越来越多的人都不再接触console的命令行界面了，反而很多人熟悉于桌面图标，但从编程领域来说，接触并了解命令行模式才能对系统有更深入的了解：）。

    先来说说Xebium如何创建软链接（Symbolic Links）吧。

    1. 假设我们有一个TestSuite-A（地址为：.testEntry.TestSuite-A），已经完成了相关脚本的编写，另外我们创建了一个TestSuite-B，还没有为TestSuite-B写任何脚本，如图：

测试集目录结构

    2. 发觉TestSuite-B可以完全重用TestSuite-A的用例集，虽然我们用copy的方式，可以完全实现该目的，但是会有如下情况：a) 我们要修改相关测试脚本，需要同时修改2份文件；b）文件占用硬盘的容量翻倍。当发现确实有以上的烦恼，那么可以创建软链接（Symbolic Links）。我们进入到TestSuite-B，点导航栏菜单项Tools->Properties，进入文件属性设置界面，设置“Symbolic Links”部分，如图：

进入文件属性页

在“Symbolic Links”部分，Name随意，Path to Page需要填入其他测试用例集（或者测试用例）的地址，点Create按钮即可，如图：

软链接设置

显示结果如下:

软链接创建结果

测试集后面的">"号，用来表明这是Symbolic Link，下方列出的是被引用的测试集下的所有用例（或者说子目录），但实际的文件目录下却没有相关的文件。

    为什么这里重点以一章的重点来说呢？因为，利用这个特性，我们可以准备一套用例和不同的配置文件（用到变量的传递）来实现多个环境下的回归测试。

    来看看官方给出的示意图：

Symbolic Link使用示意图

看这图不太容易理解，我们来举个例来说：

首先我们有测试用例TestCaseA，脚本如下：

| script |

| start browser | ${BROWSER} | on url | ${url} |

| scenario | 登录测试系统 |

| do | open | on | / |

| do | windowMaximizeAndWait | on |  |

| ensure | do | waitForPageToLoad | on | 1000 |

| ensure | do | type | on | !-//input[@type='text']-! | with | ${user} |

| ensure | do | type | on | !-//input[@type='password']-! | with | ${password} |

| ensure | do | clickAndWait | on | id=btn-login |

| script |

| 登录测试系统 |

以上wiki脚本用于实现打开${BROWSER}变量定义的浏览器，代开${URL}定义的地址，然后输入${user}（用户名）和${password}（密码），并点击登录按钮进行登录。

那么问题来了，如果我在测试环境和生产环境都想用这套脚本，只是不同的地址，用户名，密码，那我是否还需要复制一套并定义变量？答案当然是不需要，我们只要定义一个空的TestSuite（测试环境），然后增加SuiteSetUp（测试环境数据准备），用于自己定义以上变量${BROWSER}，${URL}，${user}和${password}，然后添加Symbolic Link，为TestCaseA添加软链接，这样，就可以实现为特定的环境设置需要的变量，并采用同一套测试脚本的目的。

同样的，如果为生产环境，那么再定义一个TestSuite（生产环境），在SuiteSetUp中把生产环境的值赋给以上四个变量，并用Symbolic Link，执行特定环境配置的相同脚本。

一旦控件或者空间属性发生变化，需要维护脚本，那么以上2个环境也只需要维护TestCaseA的脚本，那么以上2个环境都会同时生效。是不是更为易用，减少的维护脚本的消耗？其实这种实现，也算是数据驱动测试方法的一种。