Robot Framework与Web界面自动化测试：简单例子

假设环境已经搭建好了。这里用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界面自动化测试上的基本应用。虽然比较简单，但已经把用例编写最核心的概念和步骤做了介绍。其它功能的用例与之区别在于用例的复杂程度区别（比如准备测试条件、用例执行步骤、结果验证的复杂性、用例执行影响的清理）。