6. Web自动化测试

正式开始写Web自动化测试吧。

Xebium脚本分为2部分，一部分为Scenario部分，其作用是把页面操作步骤变为测试场景，具体写法为：

| scenario | 主页元素展示验证 |

| do | open | on | /index.html |

| ensure | do | waitForElementPresent | on | //h2 |

| check | is | verifyText | on | //h2 | 畅销产品 |

在页面上就渲染为：

wiki脚本的页面展示

但是scenario并不是执行的部分（可以点击页面导航栏内的“Test”按钮执行用例），具体的测试部分是用如下脚本来实现的：

| script |

| 主页元素展示验证 |

| scenario2 |

|...... |

script 表格才是真正执行的部分。当然，如果script表格中也用scenario表的执行步骤来写也是可以的，Xebium并不限制你的写法。但scenario和script分离的好处就是我可以在script中重复执行scenario。比如我定义了一个search控件的搜索，包括输入和点击搜索控件操作（前提是search控件在不同页面间都能用某种方式定位），那么给这些步骤一个scenario名称，那么在不同用例的script表格部分加入这个scenario名称，就达到了步骤复用的目的，是不是更加省力呢？

---

我们再深入下去，我们会看到每一个步骤的第一列都是一个关键词来驱动的，那么有多少关键词达到驱动的目的呢？

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

这句脚本用来启动浏览器，${BROWSER} 是Xebium独特的变量调用方法，用!define BROWSER {firefox}来定义即可，熟悉英文的话，这句话就变的很容易理解。浏览器只要按selnium的webdriver设置，可以用iexplore，chrome，opera，opera-mobile-phone等。

在源码中，相对应的方法参数如下：

启动浏览器，打开url页面

通常来说，这个命令直接放入script在测试用例的SetUp或者测试集的SuiteSetUp内写入，启动待测试页，等待之后的用例执行。

2. | stop browser | 

相对于启动浏览器，关闭浏览器就方便多了，一般就把行直接放在测试用例的TearDown或者测试集的SuiteTearDown内写入。

3. | do | open | on | / |  或者  | ensure | do | click | on | id=kw |

其实两者都是用于执行某个selenium命令操作，区别在于do开头的不做任何检验，只是要求Xebium去执行命令，ensure开头表示做这件事后判断是否执行完成，ensure根据返回值是否符合给定的值来判断是否正确，这里最后一个单元格校验数据不给的情况下，执行成功就是pass。

那么可执行的selenium命令有哪些呢？

"addSelection"

"altKeyDown"

"altKeyUp"

"assignId"

"attachFile"

"click"

"check"

"chooseCancelOnNextConfirmation"

"chooseOkOnNextConfirmation"

"close"

"createCookie"

"controlKeyDown"

"controlKeyUp"

"deleteAllVisibleCookies"

"deleteCookie"

"doubleClick"

"dragdrop"

"dragAndDrop"

"dragAndDropToObject"

"fireEvent"

"focus"

"goBack"

"highlight"

"keyDown"

"keyPress"

"keyUp"

"metaKeyDown"

"metaKeyUp"

"mouseOver"

"mouseOut"

"mouseDown"

"mouseDownAt"

"mouseMove"

"mouseMoveAt"

"mouseUp"

"mouseUpAt"

"open"

"openWindow"

"refresh"

"removeAllSelections"

"removeSelection"

"runScript"

"select"

"selectFrame"

"selectWindow"

"shiftKeyDown"

"shiftKeyUp"

"submit"

"type"

"typeKeys"

"uncheck"

"waitForFrameToLoad"

"waitForPageToLoad"

"waitForPopUp"

"windowFocus"

"windowMaximize"

....................... 

还有很多命令不一一列举了，可以说囊括了所有网页上支持的操作命令(可以查看源码：ExtendedSeleniumCommand.java)。

4. | check | is | assertTitle | test_百度搜索 |

check检查返回值是否是true或者false，如果是true则pass；reject则相反，返回false为pass，selenium的assert基本用check/reject来判断检查结果。

---

测试脚本如下：

测试脚本

点Test后可以运行，运行结果如下：

Xebium运行结果

---

自己总结的一些测试经验和思想：

1. 是否这样写太累了，有没有更简便的工具呢？答案是有的，很多人在写前都会用firefox的selenium ide来录制回放，其实只要安装Selenium Xebium Formatter的firefox插件就可以把录制回放结果直接转换成Xebium格式，这样写起来就更得心应手了。

2. selenium测试回放时会出现很多控件未找到的错误，如何解决呢？首先，我们把执行步骤的间隔时间调大，还记得之前一章提到的

|set step delay to|slow | 

这个命令，主要就是把间隔时间调大，当页面全部加载完再去操作可以避免很多问题。另外，如果能和开发沟通，尽量有唯一不变的id或固定的xpath和properties来标识控件，这样也可以避免在不断迭代期间，控件位置的变化而导致无法识别，减少脚本修改的花费。

3. 减少自动化测试消耗的另一个原则是，尽量保持scenario的短小精悍，不要面面俱到的测试，不要把所有测试用例都自动化，不要在web设计都没有定的情况下开始自动化，不要在没有任何数据准备的情况下开发大量脚本，在开发期也尽量少用当某个控件waitForElementPresent来判断（很多时候，控件定位就发生了变化，这个判断会失效）。一个web自动化测试用例，用于regression测试，一般保证页面导航、搜索、或者主流程能正常走通即可，花最少的人力物力情况下把产出最大化。

---

Web自动化测试介绍到这，大家心里应该有底了，那么如何再进一步开发自己的测试套件来扩展Xebium用途呢？我们在下一章阐述。