假设环境已经搭建好了。这里用RIDE（ Robot Framework Test Data Editor）工具来编写用例。下面我们对Robot Framework简称rf。
我们先考虑下一个最基本的登录功能的测试用例。
一、自动化测试 与 人工测试
在开始编写用例之前，我们先来思考下自动化测试和人工测试的区别。对于web页面的人工测试，我们想下，如果去测试，怎么操作呢？不外乎如下的基本动作：
1）打开浏览器
2）输入url （前提web服务器要正常启动运行着）
3）等待页面显示出来
4）用眼睛看页面显示的内容是否与自己想象的一致，如果一致，认为功能正常，否则，会认为程序有问题。
5）通过鼠标、键盘执行相关的操作，通过页面的变化和内容显示继续进行检查功能是否正常。
那么什么是自动化测试呢？其本质就是将人的操作过程（打开浏览器、输入url、鼠标点击、键盘输入等）以及验收标准（在人脑中验收）转换为测试代码。
有了测试代码，就可以让其自动运行了。
二、登录用例设计
一个登录功能，想象下如果是人工测试，那基本的测试过程一般如下：
1）打开浏览器、输入登录url
2）输入用户名、密码（也许还有别的输入项，如验证码，则取决于程序本身），点击登录按钮
3）如果是正确的用户名密码，应该出来相应的页面；如果是错误的，应该出来错误页面或错误提示信息。
那我们看看利用Robot Framework怎么写用例。
三、 用例编写
1、成功登陆的用例1
successLogin
open browser http://localhost/nau/login ff
input text id=userid xxx
input password id=password yyy
click button id=loginBtn
Wait Until Element Is Visible id=userid
close browser
下面我们看下上面代码的含义
1）successLogin是用例名，是自己取的
2）后面的语句，每句都是 “关键字+参数（0个或多个）”的格式，其中蓝色的词组就是关键字。这个例子的关键字是rf框架中的内置关键字。
用户可以定义自己的关键字。
open browser http://localhost/nau/login ff
这句代码的含义，其实看上去就能理解。open browser是关键字，表示打开浏览器；http://localhost/nau/login 是第一个参数，是要打开的页面url；ff是第二个参数，代表要用的浏览器类型，其中ff表示是firefox浏览器，gc表示是chrome浏览器，ie表示是Internet Explorer浏览器。这里我们用的是firefox浏览器。
input text id=userid xxx
这句代码，input text 是关键字，表示要在html组件（如文本框）中输入信息， id=userid 是 第一个参数，用于定位用来输入的html组件，这里的id表示通过元素的id来定位，userid就是元素的id值。如果页面中存在一个id为userid的输入框，则就能找到。 xxx是第二个参数，表示要输入的值。想象下，如果是人工操作，就是在界面中找到这个输入框，敲击键盘输入xxxx这几个字符。
看到这里，我们可以把关键字当作一个函数（其实它本质上就是一个函数），后面跟的是函数参数，有的关键字有参数，有的没有。
input password id=password yyy
这句代码，也非常好理解了，就是在密码框中输入密码了。其中input password为关键字。
click button id=loginBtn
这句代码，看上去也明白了，click button 是关键字，表示点击按钮；id=loginBtn是第一个参数，用于定位要点击的按钮，这里也是用id来定位的。
Wait Until Element Is Visible id=userid
前面的几句代码，进行的相关的操作，这句代码就是检查操作结果。如果登录成功，会出现新的页面，并且页面上应该有个元素会显示用户的登录名。
这里的Wait Until Element Is Visible 是关键字，顾名思义，就是等待元素可见； id=userid就是要显示的元素，这里同样是通过id定位。
实际上这个检查是不完善的，这里只是检查了是否有id为userid的元素，但元素的内容呢（正常内容应该是xxx），没有检查。这点我么在下个用例介绍。
close browser
上面是这个用例的最后一个语句。这很好理解了，就是关闭浏览器。close browser是关键字，该关键字没有参数。
执行该用例。如果系统存在用户名为xxx和密码为yyy的用户，则该用例就会成功。
2、成功登陆用例2
上面是一个最基本的用例。上面用例存在一个问题，就是检查用例成功的标准是看希望的html元素是否存在。但很多时候不仅需要判断希望的元素是否存在，还需要判断元素的内容是否符合预期。就上面这个用例，希望 id为userid的元素的内容是xxx。那用例应该如何写呢？
successLogin2
open browser http://localhost/nau/login ff
input text id=userid xxx
input password id=password yyy
click button id=loginBtn
${value} get text id=userid
Should Be Equal ${value} xxx
close browser
和上个用例相比，区别就是检查语句（上面红色的2行）。
其中${value} get text id=userid的含义是 利用关键字 get text 获取id为userid元素的内容放到变量${value}中。
而 Should Be Equal ${value} xxx 语句，Should Be Equal 是关键字，用来断言两个参数的值是否相等，如果不等，则表示失败。
3、失败登录用例
上面是验证成功登录的用例。那应该也有验证登录失败的用例。其思路差不多，就是当登录失败后的页面是啥。通过代码来进行检查。
我们假设登录失败后会出现一个新的页面，页面中有文本 “用户名或密码错误”字样。那么用例就可以这么写。
errorLogin
open browser http://localhost/nau/login ff
input text id=userid xxx
input password id=password yyy123
click button id=loginBtn
Wait Until Page Contains 用户名或密码错误
close browser
相比前面的用例，区别还是验收语句。上面的验收语句一看就明白，Wait Until Page Contains 是关键字，用于检查页面中是否包含预期的信息。
4、自定义关键字
可以看出，上面3个用例，前面的4个语句，区别只是输入的参数 用户名和密码的值区别，我们自然会想到，可以把这4个语句封装成一个关键字，包含两个参数用户名和密码。
关键字定义如下：
login
[Arguments] ${username} ${password}
open browser http://localhost/boot/login ff
input text id=userid ${username}
input password id=password ${password}
click button id=loginBtn
使用该关键字的用例如下
loginSuccessWithKeywords
login xxx yyy
${value} get text id=userid
Should Be Equal ${value} xxx
close browser
loginErrorWithKeywords
login xxx yyy123
Wait Until Page Contains 用户名或密码错误
close browser
5、用例的setup和teardown
每个用例，从整个实现讲。一般包括如下三大部分：
1）执行条件设置部分(setup部分)：因为用例的执行，通常需要一些条件。如前面的登录成功用例，需要用户已经存在。
2）用例执行部分：包括该用例进行的操作，对结果的验证
3）清理部分（teardown部分）：在自动化测试中，我们希望用例执行后，对当前环境不会有任何破坏。因此一般需要做些清理工作，包括第一部分条件设置对系统造成的影响和用例执行过程中对系统造成的影响。
rf对这也提供了支持，可以把一个用例分成三部分。虽然我们写成一部分，从最终效果上讲没区别。但分开了，会更加符合逻辑，用例也非常清楚。
对于我们这个登录用例，可以看出，每个用例完成的最后一步都要关闭浏览器，这里用的是close browser。
因为各个用例都是公共的，我们可以把这放到用例包的teardown中。
*** Settings ***
Test Teardown close browser
这样每个用例的最后语句close browser都不需要了。
把一些语句放到teardown中，还有一个好处是，无论用例执行部分出现什么问题，最后的teardown都会保证被执行。
三、小结
本篇文章，我们通过一个登录例子来介绍了rf在web界面自动化测试上的基本应用。虽然比较简单，但已经把用例编写最核心的概念和步骤做了介绍。其它功能的用例与之区别在于用例的复杂程度区别（比如准备测试条件、用例执行步骤、结果验证的复杂性、用例执行影响的清理）。