敏捷自动化测试(2)——像用户使用软件一样享受自动化测试(2)

　　“账号”输入***、“密码”输入***、“姓名”输入***、“性别”选择***、“生日”输入***、“国籍”选择***，点击“保存”按钮。

　　这就可以理解为“根据界面编写的测试脚本”。

　　我们在使用Web应用时，心里常常默念的还包括：“展开/收拢/选中”树(Tree)的某个节点、数据表格(Grid)的下一页/上一页、选中数据表格(Grid)的某一行、点击/关闭某个Tab页，等等。

　　很多人在与笔者交流的过程中都会问“为什么还要手工编写脚本，怎么不提供脚本录制工具呢?”

　　因此在这里想澄清一下大家对“编写”脚本的误解，与传统自动化测试工具相比，“此脚本”非“彼脚本”。

　　传统的测试脚本是给特定测试工具执行时使用的，对人类而言可读性极差，更别谈手工编写了，因此“录制/回放”工具往往都是必备组件。即便如此，此类“录制/回放”工具的实际使用效果，也是不尽如人意的。

　　从这种角度来看，“录制”脚本是“下策”，“上策”应该是让测试脚本大幅简化，并且具备良好的可读性和可维护性，以达到人工编写很容易的程度。

　　——以上只是笔者的一点差异化见解，对业界优秀的测试工具没有任何冒犯之意!

　　(二)降低测试脚本对技术实现依赖度的实现思路

　　Web页面开发中的技术实现细节主要包括UI框架的选择及版本升级、页面样式设计、页面布局设计，因此我们的主要目标就是降低测试脚本对这些因素的依赖。

　　为了便于测试脚本的解析和组织管理，目前还不能直接写形如“点击(保存)按钮”这样的纯自然语言，但可以设计成接近自然语言的领域专用语言(DSL:Domain Specific Language)，本文采用XML来实现这种DSL。比如：

　　这种超级清晰、简短的测试脚本与实际海量的页面源码之间有一条鸿沟，我们可以通过“封装”来屏蔽。下面以ExtJS的Button控件为例来示意如何完成这种封装：

　　Button的界面展现如下：

　　实际生成的页面源码DOM结构如下(省略部分非关键属性)：

　　我们封装所要做的主要工作就是解析出测试脚本中定义的关键信息(button、保存、click)，结合对应页面源码的DOM结构，翻译成W3C标准的定位方式(如，XPath)。通过XPath就可以定位到页面上的任何控件。

　　对于测试脚本()，翻译后的XPath可以是(//button/span[text()='Cancel'])。

　　同理，其它测试脚本还可以包括：

　　树节点展开/关闭

　　Grid翻页

　　它们的封装实现比Button稍微复杂一些，但原理是一样的。

　　(三)增强测试脚本浏览器兼容性的实现思路

　　这个就比较简单了，只要选用标准化程度高、厂商支持度高、扩展性强的第三方底层实现即可，笔者推荐采用Selenium WebDriver。

　　通过上面的介绍，有些读者或许会有个疑问：“如果一个Web应用没有采用任何UI框架、而且编码又极为不规范，那么你这种方案岂不就不适用了?”

　　答案是肯定的。但笔者认为此类Web应用如果想要发展下去，其瓶颈还停留在开发环节，对其进行自动化回归测试的投入产出比不是很大。

　　此外，为了进一步提高Web应用的可测试性，笔者在实际工作中总结了一些前台页面开发的最佳实践，供大家参考：

　　页面采用单帧实现

　　如果页面上的frame/iframe嵌套很多的话，控件的定位会比较麻烦，并且影响展现速度。

　　兼容Firefox

　　Firefox有很多强大插件，如Firebug、FirePath，非常有助于在开发、测试过程中的调试问题。

原文转自：http://www.infoq.com/cn/articles/Agile-test-automation-2