正式开始写Web自动化测试吧。
Xebium脚本分为2部分，一部分为Scenario部分，其作用是把页面操作步骤变为测试场景，具体写法为：
| scenario | 主页元素展示验证 |
| do | open | on | /index.html |
| ensure | do | waitForElementPresent | on | //h2 |
| check | is | verifyText | on | //h2 | 畅销产品 |
在页面上就渲染为：
但是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等。
在源码中，相对应的方法参数如下：
通常来说，这个命令直接放入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后可以运行，运行结果如下：
自己总结的一些测试经验和思想：
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用途呢？我们在下一章阐述。
