转自：http://blog.csdn.net/tulituqi/article/details/7906130

在我们做自动化案例的时候，用的最多的主要是用户关键字。说到关键字，大体上可以分为测试库关键字（或叫系统关键字）和用户关键字，前者一般都是通过加载Library得到的，而用户关键字一般都是通过加载Resouce得到的。

以之前的这个case为例：

图中的Import Variables和log都是测试库关键字，而搜索测试这个就是用户关键字，只要RIDE的版本高一些，就能看出他们的颜色是有区别的。

接下来，我们新建一个案例，并针对用户关键字的用法进行介绍。

1、先新建一个用户关键字，不用带arguments。

在Setting下面的这些呢，Documentation就不多说了。主要看下面4个设置，其实前面的文章里也简单介绍过，这里再说一下。

Arguments: 设置传入参数

Teardown: 设置完成时的动作，比如写上Close All Browsers，表示在这个用户关键字执行完成之后会执行什么关键字。

Timeout: 设置超时时间，如写上1min，表示1分钟超时，如果这个关键字执行超过1分钟则认为失败。

Return Value: 设置返回值

一直以来我都觉得用户关键字就像一个函数一样，有传入参数Arguments，有返回值Return Value，而且还可以用Teardown作为函数完成后的清理动作。

所以我们也要像函数一样来使用User Keyword。

2、传入参数Arguments

前面在做案例分层的时候其实已经用到了一些参数设置了，可以看看前面2篇文章。这里提一下多参数及可选参数的设置。

0）变量类型

顺带提一下变量的类型，RF里的变量分两种，一种是Scalar，可以理解为单值变量，一种是List Variable，list型变量，或者可以理解为数组变量。Scalar型变量用$符号开头，List型变量用@符号开头。这里只是简单介绍，后面会专门写一篇两种变量关系的。

1）必填参数

给我们的关键字先添加4个参数，参数之间使用 | 进行分隔。（如果想在默认值里使用 | 作为一个值而不是分隔符，那么就要使用 \| 来表示|的值。

如果是这样添加参数呢，表示这些参数都是必填的，我们建一个case3，并调用关键字测试看一下，这里的关键字测试后面的4个格子都是红色，提示参数必填。

2）选填参数

假设我们想把其中第2个参数设成选填参数，选填参数就是给参数加上默认值，默认值使用 = 加上值，如果想默认为空，只写等号就行了。

（默认值的意思不需要细讲了哈，就是如果你在调用这个关键字的时候，如果不给这个选填参数传值，那么就使用默认值作为参数的值）

如果我们直接这样加的话，点击OK就会报错。意思是说必填参数不允许在选填参数后面。

也就是说如果某一个参数设置成了选填参数，那么他后面的参数都必须是选填参数，不能是必填参数。

在我们这里就是第2个参数如果要可选，要么把3、4参数也都设置上默认值，要么就把第2个参数调整到最后去。我先调整成下面这样，就不会报错了。

3）List变量参数

List变量也是可以作为参数，但是List变量只能放在最后一位。如果放在前面，就会报错。

我把arg4改成了@{arg4}这样的List变量，保存时就会提示List变量只能作为最后一个参数。

为啥只能是最后一个呢？从英文的角度看是the last argument，没有s。。。。

如果一定要试试最后2个都放list变量呢，也是会报错的。

这是为什么呢？首先，List变量本来来说，他是一个可变的，即List的成员数量不确定。而List作为参数的话，有几个成员就是相当于几个单值参数，他实际上是提供了一种参数个数可变的方式。那么既然可变，如果放在前面的话（见第一个例子的图），他就没法确定传入的参数到底哪些是给arg4的，哪个是给arg2的了；同理，如果放2个List也是不行的（见第二个例子的图），因为也是无法区分传入的参数到底哪些是给arg4，哪些是给arg2。

而且2个可变和1个可变没什么差别滴，所以最终限定是只能有1个List参数，并且必须放在最后。

注意一下：变量名和等号间不能有空格，如果有空格系统会报参数语法错误。

最后看一下List参数的实例，其他几种实例应该没什么复杂的，大家自己练习一下即可。

为了看的方便，我把参数数量减少点，只放2个参数，${arg1} | @{arg2}，然后用了个Fail，目的是想把值打印在运行界面上。

然后我们在case3里给他传几个值。

我特意把关键字的说明也截图下来，大家可以看到agr2前面有个*，表示他可以接受任意个参数，Python里其实也是这样处理多参数的。

运行一下案例，看一下打印出来的内容。

继续介绍User Keyword里面的Teardown和Return Value的内容

3、Teardown测试完成回收清理

如果有用过Junit的朋友应该记得Junit的案例一般都是有一个Setup、一个Test、一个Teardown的，同样我们的TestCase也是有这2个的，大家可以自己看一下case的Setting。

那么这个User Keyword的Teardown，作用都是差不多的，如果是Case的Teardown，那么是案例结束的时候做回收清理；而User Keyword的Teardown就是用在调用User Keyword完成之后才会做的数据回收清理。

当然，用于什么可以根据你自己的需求自己调整，并不一定是数据回收清理，是系统关键字或者用户关键字都可以。总之可以理解为关键字完成后还要调一个关键字。参数要用 | 分隔。

我这里改造一下上一篇写的关键字测试，以便于演示Teardown的作用。

改完的效果是先把arg1的值赋给temp，然后把arg2的列表第三项值赋给arg1（这里算个小bug，如果传的参数少于3个就会报错了，这里只是演示，请忽略），然后log打印出arg1和arg2的值。

在Teardown这里我使用了Set Suite Variable方法，把temp的值覆盖arg1，并把arg1设为Suite级别的变量，然后我再case3里调用完关键字测试后又用log打印出arg1的值。（也可以用Set Global Variable，如果不用这2个的话，在case3里是找不到arg1这个变量的）