转 敏捷自动化测试（2）——像用户使用软件一样享受自动化测试B
这种超级清晰、简短的测试脚本与实际海量的页面源码之间有一条鸿沟，我们可以通过“封装”来屏蔽。下面以ExtJS的Button控件为例来示意如何完成这种封装：
● Button的界面展现如下：
● 实际生成的页面源码DOM结构如下（省略部分非关键属性）：
| <div id="button-1032" class="x-btn x-box-item x-btn-default-small x-noicon x-btn-noicon > <em id="button-1032-btnWrap"> <button id="button-1032-btnEl" class="x-btn-center" autocomplete="off" role="button"> <span id="button-1032-btnInnerEl">Cancel <span id="button-1032-btnIconEl" class="x-btn-icon "/> </button> </em> </div> |
我们封装所要做的主要工作就是解析出测试脚本中定义的关键信息（button、保存、click），结合对应页面源码的DOM结构，翻译成W3C标准的定位方式（如，XPath）。通过XPath就可以定位到页面上的任何控件。
对于测试脚本（<event id="[button]Cancel" name="click"/>），翻译后的XPath可以是（//button/span[text()='Cancel']）。
同理，其它测试脚本还可以包括：
● 树节点展开/关闭
| <event id="[treeNode]部门" name="open"/> <event id="[treeNode]部门" name="close"/> |
● Grid翻页
| <event id="[grid]人员列表" name="nextPage"/> |
它们的封装实现比Button稍微复杂一些，但原理是一样的。
（三）增强测试脚本浏览器兼容性的实现思路
这个就比较简单了，只要选用标准化程度高、厂商支持度高、扩展性强的第三方底层实现即可，笔者推荐采用Selenium WebDriver。
通过上面的介绍，有些读者或许会有个疑问：“如果一个Web应用没有采用任何UI框架、而且编码又极为不规范，那么你这种方案岂不就不适用了？”
答案是肯定的。但笔者认为此类Web应用如果想要发展下去，其瓶颈还停留在开发环节，对其进行自动化回归测试的投入产出比不是很大。
此外，为了进一步提高Web应用的可测试性，笔者在实际工作中总结了一些前台页面开发的最佳实践，供大家参考：
● 页面采用单帧实现
如果页面上的frame/iframe嵌套很多的话，控件的定位会比较麻烦，并且影响展现速度。
● 兼容Firefox
Firefox有很多强大插件，如Firebug、FirePath，非常有助于在开发、测试过程中的调试问题。
● 采用统一的UI框架开发复杂控件
对于复杂控件，比如Tree、Grid，如果不基于统一的UI框架实现，开发、测试工作量都会很大。
● 对于需要设置ID的控件，一定要设置唯一、并且有业务意义的ID
当然对于一般不需要设置ID的控件（如，div）或者控件ID由UI框架自动生成的情况除外。
● 对于Form中最常见的label+input组合，尽量让label和input有逻辑对应关系
推荐为label设置for属性，属性值等于input的id，这样对最终用户也比较友好：双击label的时候，鼠标焦点能定位到对应的input中。
● 页面设计时考虑用户体验，往往用户使用方便的时候，自动化测试也会方便
比如，一个页面上不要有多个同名的按钮、通过点击上下微调按钮（箭头）改变输入域值的控件也支持直接输入值、日期选择控件支持用户直接输入、下拉列表控件支持输入过滤，等等
对以上几点最佳实践有如下补充说明：
1、这些最佳实践不仅能提高Web UI的可测试性，也非常有助于提升用户体验；
2、这些最佳实践如果能满足更好，即使不能全部满足，也可以开展自动化测试；
按照本文给出的方案，前文“我们的测试为什么不够敏捷”中用到的“用户管理（增加、删除）”功能的自动化测试脚本就可以改造为如下样式（示意代码）：
| <event id="[button]新增" name="click"/> <event id="[input]帐号" name="setValue" value="${account}"/> <event id="[input]密码" name="setValue" value="1"/> <event id="[input]姓名" name="setValue" value="${accountName}"/> <event id="[input]性别" name="select" value="女"/> <event id="[input]生日" name="setDate" value="1980-01-01"/> <event id="[input ]国籍" name="select" value="中国"/> <event id="[button]保存" name="click"/> <event id="[gridRow]${account}" name="assertExist"/> <event id="[gridRow]${account}" name="check"/> <event id="[button]删除" name="click"/> <event id="[ gridRow]${ account }" name="assertNotExist"/> |
以上测试脚本完全基于界面上“可见”的内容进行编写，大家应该不需要看下面的解读，也能明白脚本的意思：
● 第1、8、11行表示点击“新增”、“保存”、“删除”按钮；
● 第2~7行表示为输入域赋值，赋值方式有输入文本、输入日期、选择下拉选项；
● 第10行表示选中表格中的指定行，即，选中指定行前面的Radio按钮；
● 第9、12行表示断言表格中指定的行“存在”或“不存在”；
● ${ account }表示使用外部的变量account；
自动化测试中最关键的两部分是“脚本”和“断言”。至此，自动化测试脚本的编写、维护以及执行已经可以跟上敏捷开发的步伐了。本系列的下一篇文章会就“如何让断言不再成为自动化测试的负担”这个话题来分享一些实践经验，敬请关注！
TAG:
