EEPW论坛

　　由于存在同源策略的问题，所以在进行测试部署时，必须将所测试程序部署在服务器端。 例如你想采用selenium-core来测试用JavaScript写的www.google.cn,由于不允许向磁盘写数据，所以只能将测试结果发送到另外一台服务器进行保存。

　　Selenium IDE是对浏览器进行扩展，作为FireFox的一个插件。通过监听用户对html页面的操作来录制脚本。 其特点：

　　①非常容易在页面上进行录制和回放

　　②能自动通过id，name和xpath等来定位页面上的元素

　　③自动执行selenium的命令

　　④能够进行编辑、调试和设置断点

　　⑤录制时自动生成脚本，不但能够保存，并且能转化成各种语言(C#、JAVA等)

　　⑥在每个录制的脚本中能够加入断言

　　测试套件Suit

　　要达到对应用程序的完全测试覆盖，通常需要不止一个测试用例。测试套件用于将具有类似功能的一些测试用例编成一组，以便让它们按顺序运行。

　　测试套件和测试用例一样，都是用简单的 HTML 表编写的。但是注意，测试套件使用一个只包含一列的表，表中的每一行指向一个包含某个测试用例的文件，如下例所示：

　　通过以上的分析，我们可以知道10 Selenium比其他的测试工具有着明显的优势，但是其也有一定的限制：

　　①录制脚本可能会带来冗余、公用元素不可调用、脚本调试复杂等问题。专业化的建议是以录制为参考,以编写脚本为主要行为。 当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。

　　②输入数据或测试环境的改变，都会导致测试结果受到影响甚至失败。而如果仅是一个个执行测试用例，也只能被称作是半自动化测试，极大的影响自动化测试的效率。

　　③Selenese 有一些严格的限制，如它没有条件(没有“if”表达式)，没有循环(没有“For”表达式)。这样会使编写复杂的测试变得困难甚至不可能。

　　六、自动化测试的使用范围

　　1) 软件需求变动不频繁

　　不稳定的系统也就意味着测试的不稳定，我们不知道这次的变动是否会影响到系统其他的功能。那么是否需要在每次迭代完以后都需要对系统进行完整的回归测试呢?测试脚本的稳定性决定了自动化测试的维护成本。如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

　　2) 周期足够长的项目

　　自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要时间和精力来完成，这样的过程本身就是一个测试软件的开发过程，需要考虑投入成本的问题。

　　如果项目的周期比较短，没有足够的时间去支持这样一个过程，或者说传统测试所花费的时间和人力资源远小于采用自动化测试的投入，那么自动化测试便成为笑谈。

　　3) 自动化测试脚本可重复使用

　　如果费尽心力开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。

　　七、小结

　　任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台，或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。