2、用户怎么用我们的SDK？是调用接口，跟CORE面对的问题相似

　　估计由于经常跟XML打交道，所以VI的自动化测试用到很多XML文件作为配置。由于隔行如隔山，所以没有看懂里面的一些玄机，总的来说是跟我们CORE有点相似。

　　我们CORE和VI一样，这些工具如果跳出了这个公司，基本上不能应用到其他地方，这也是对整个系统来说的底层部分做自动化测试的特点：高度定制化，通用性低，自己开发居多

　　后是UI的介绍，终于等到一个看得懂的啦。

　　UI那边是大量使用开源工具，这个也是很有道理的

　　1、UI的自动化测试实施难度比后台程序的自动化要大

　　2、现有的UI自动化测试非常丰富

　　那我们的UI是怎么做的呢？首先UI的同事用了一个持续集成的工具hudson作为一个颗粒度比较粗的测试用例管理工具，hudson作为自动化测试的主心骨，QA们可以在hudson上触发自动化测试的运行，运行完了以后可以看到测试结果，并且，利用了hudson的分布式结构，由多个测试机来执行测试，达到了很好的资源调配。对浏览器的控制方面，用了Selenium，会上没有问UI是否利用了Selenium的多浏览器支持，从演示上来看应该只做的Firefox的。他们的分工很明确，分了专门做功能测试的QA和专门做自动化测试工具开发的SDET，SDET主要是负责写RUBY代码，封装并且暴露了一些通用的方法给QA使用，并且同时使用了Cucumber作为一个DSL，QA是用Cucumber来做自动化测试的一些描述，Cucumber的作用是对功能测试的QA屏蔽了底层RUBY脚本，对上是“翻译”功能测试QA的意图，“翻译”成RUBY。说一下我觉得的优点：

　　1、分开了自动化测试工具开发和自动化测试实施

　　2、使用了大量开源工具，提高效率

　　3、而且都是业界常用工具，对以后跳槽帮助不小（嘿嘿）

　　4、One click automation (只需要点一下hudson）

　　一些工具带来的制约：

　　1、一次只能运行一批测试，不能重跑单个测试

　　2、个人觉得使用XPATH作为对象的识别并不是一个好的选择

　　总得来说大家都各有特色，并且都做得挺好，并且都有不少可以提高的空间。多点交流的确能带来不少灵感。