zzzmmmkkk的专栏

IE DriverIE 是一个很有意思的浏览器，它是由一些协同工作的COM接口构建成的，这一直延伸到Javascript引擎，常见的Javascript变量实际参考了隐含的COM实例。Javascript窗口是一个IHTML窗口，文档是一个COM接口IHTML文档的实例。微软已经做了非常出色的工作通过增强浏览器来维护现有的行为。这意味着如果一个应用程序如果支持IE6的COM类，它仍可以支持IE

布局和Javascript浏览器自动化工具基本上由三部分构成：· 与DOM交互的方法· 执行Javascript的机制· 一些模拟用户输入的办法本节重点介绍第一部分：提供与DOM交互的机制。浏览器的办法是通过Javascript，所以看起来与DOM交互的理想语言也是它。虽然这种选择似乎显而易见，但是在考虑Javascript时需要平衡一些有趣的挑战和需求。

上一篇文章介绍了Selenium1.0的历史及工作原理， 现在，接着上一次的内容说2.0的由来及设计架构。就在Selenium1.0处于开发阶段的同时，另一款浏览器自动化框架WebDriver也正在ThoughtWorks公司的酝酿之中。WebDriver项目的初衷是把端对端测试与底层测试工具隔离开。通常情况下，这种隔离手段通过适配器（Adapter）模式完成。WebDriver正是来源于

当你看到这篇文章时一定会诧异，2.0都广泛使用了，为何还要了解1.0的内容呢？1.0的确已经慢慢的成为历史，那我们就先通过历史来认识一下selenium的发展吧。Jason Huggins在2004年发起了Selenium项目，当时他在ThoughtWorks公司开发内部的时间和费用（Time and Expenses）系统，该应用使用了大量的JavaScript。虽然IE在当

前阵子因为要进行支持多浏览器的自动化测试，原来selenium1.0仅支持到firefox3.6，IE8，chrome4的版本，而公司GA数据显示用户多使用IE9，Firefox20，chrome26，很显然selenium1.0已不再满足当前也业务需求，为了更好进行兼容性测试，升级selenium已经迫在眉睫。(PS.这篇文章重点讲的是selenium1.0升级到2.0的内容，关于如何使用sel

在我刚入职时候，部门的组织架构还是分功能测试组和自动化组，每个组的负责人都向CTO汇报，功能测试组都是做纯功能测试的，而自动化组包括测试环境的搭建维护，自动化框架开发，自动化用例编写及性能测试，当然不同的负责人之间的知识共享也并不是很多，所以也就造成了功能测试组对技术研究的并不是很多，多专注于业务相关的技术上，自动化及性能相关的也多是停留在知识分享及培训上，也许个别同学有下来自己研究并尝试实践，但

前面说到在实施冒烟测试自动化时候，当时使用的selenium1.0所支持的浏览器版本太低，无法满足我们的需求，面对这个问题，唯有升级我们的框架，可是面前有1千多条自动化用例等着，的确需要花费很大的人力和时间来完成。当时后台组也已有人研究过Webdriver，在其中一个产品中用起来了，但是并没有对原来的东西全部升级，不过至少证明了它的实用价值。当时我跟我老大说我研究下Webdriver，OK的话要不

不知不觉已经写了8个关于我在兰亭这三年的主题，其实在刚开始起草的时候就已经想好了写哪些内容，预告一下总共有10个主题，这是倒数第二个。我在前面也讲过两则关于自动化的主题，其实之前的实践还远远不止这些，今天接着聊那些年我们追过的自动化。在当时做一个项目时，因为需要保持前后台数据库的一致性，把共用的表结构进行了统一，同时进行了分库操作，代码相应的需要做调整，但是重点验证两点：一是数据源获取正确，二