这种超级清晰、简短的测试脚本与实际海量的页面源码之间有一条鸿沟，我们可以通过“封装”来屏蔽。下面以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嵌套很多的话，控件的定位会比较麻烦，并且影响展现速度。