HtmlUnit使用体会

    HtmlUnit测试工具的推出，创意非常好。是一款给java开发用的browser。说它是browser，其实它是对html建模并且提供API来访问页面，点击链接等等的java类库。
    这样的测试工具有这样几个优点：

1. 运行起来没有界面，速度非常快。
2. 由于是java类库，有无限扩展的可能，可以构造各种功能强大的工具。包括本地化测试，多种数据源输入数据。
3. 跨平台，跨浏览器。java本身就有跨平台的特性，浏览器，只要简单的设定一个参数就可以轻易模仿想要的浏览器了。
4. 转化为性能测试，非常简单，可以共享同一脚本。

    基于HtmlUnit基础之上的还有两个测试工具，Conoon WebTest和JWebUnit两个工具。有如此之多的好处，这样的测试工具可真是稀有的宝贝。实际上用起来却有几个很大的缺点，让人感到非常可惜。
    现在说说使用的体会，如果参照HtmlUnit的javadoc api和测试的例子，感觉工具的作者把现在的页面开发状况想的太好了，按照作者的意思，页面上的element都可以用getHtmlElementByID,byName就可以获取了。而我遇到的页面却写的很糟糕，页面上的element100个里面能有一二个有ID或是Name的就很不错了。
    不过还好，HtmlUnit还提供了其他丰富命令来获取element。最差的可以用xpath去抓取。但是抓到的element还要显式地声明这个element的类型是什么。这个步骤很麻烦，要费很多的精力来分清楚到底是什么类型的element。写五个不算复杂的页面的操作，耗了两天时间。（这和刚刚上手，不熟悉也有关系）
    其次HtmlUnit对javascript的支持还是不算太好，如果有用javascript动态画出来的菜单，HtmlUnit好像就没有办法去找到对应的element了。HtmlUnit依靠的是Mozila的Rihno做的javascript引擎做解析的，出了错，debug起来都很困难。（需要花功夫，深入学习）
    TestGen4Web在前几天推出了新版本的recorder，其中提供了可以将录制脚本用HtmlUnit来运行的解释器。解释器对HtmlUnit的理解和运用显出高超的技巧和功力，值得好好看看。其中通过record录制脚本，对javascript生成的菜单，识别成一个xpath表达式，在run的时候还是无法识别到。这个是致命的问题，也许是自己对工具掌握程度不够，用到这里怎么也进行不下去了。
    JWebUnit也试用了一下，感觉是HtmlUnit的简化版，使用上简单很多，但和jUnit绑的太紧，要整合到其他工具里的话，十分不便。
    Conoo WebTest没有专门用，在它的网站上介绍看看就够了，用法和JWebUnit差不多，但自己说对javascript的支持不好，最适合测静态页面。
    说几句题外话，如果TestGen4Web和HtmlUnit这条路可以走通的话，这对web测试是一个非常大的提高。这不仅是从具体技术角度看。从使用者角度来看，QA可以直接拿着脚本在浏览器里run case，用于检查核对case的内容。而测试自动化的人员可以用同样的脚本来高效率地执行case。跨平台，本地化都很方便。这样普通的测试和自动化测试可以进行无缝的对接。
    无界面browser测试工具的前景非常好，只是还有很长的路要走。

     补充：人多力量大，这是开源软件的优点。在HtmlUnit的Bug Tracker里找到了我遇到的问题，别人老早就遇到了，bug