自动化测试框架更多的是流程与工具的结合，缺一不可。

　　如果只是简单的将selenium/webdriver，watir等工具进行串联，那么基本也是去了自动化的意义。

　　自动化测试的基本思想为持续改进提供自动化的解决方案，那么我们在持续改进方案中真正需要的数据是什么?

　　1.自动化测试覆盖率：

　　衡量自动化的一个客观标准。(emma)

　　2.自动化测试用例re-product的概率及工作量

　　这是使用selenium等框架必须考虑的部分，重用率，面对web应用动辄80%以上的页面重构，re-product的概率及工作量将会决定框架的好坏。

　　3.自动化测试BUG发现率

　　这是判断自动化测试效率的指数，如何更好的设计自动哈测试用例将与用例的效率息息相关。

　　4.自动化测试与BUG管理工具的关系

　　这是由工具框架向流程转变的一个重要指标。

　　5.自动化测试的优化

　　这里之前jason已经提到了，通过各种优化，针对测试类的提取，针对java设计模式的扩展，针对测试工具的优化。优化会提高第7项的效率及自动化执行的效率。

　　6.自动化case的成本

　　这个指标区分与第2项指标，更多的是完成一个case需要的成本(学习成本，coding成本)。

　　7.持续集成中自动化的应用

　　这个需要和第4项结合起来一起实现。

　　自动化测试必须由数据来支持，没有数据支持的自动化是没有说服力的。自动化测试需要将业务，流程从各种角度进行可重组的自动化，不仅仅涉及SCM，QA也涉及到持续集成及流程管理，自动化测试框架从一开始设计决定了框架的优劣，所以设计好的框架更多的需要从逻辑上自动化，而不是简单的将工具进行整合。这也催生了新的测试管理系统，统筹规划自动化测试，并统一报表显示。

　　自动化测试工具对于公司来说一般都是unique的但可借鉴的 ，集各家之所长。