先后和nemo、limo、raimudox、nicholas讨论:
selenium的Remote Control比较适合在需求阶段就撰写(当然Fit方式也可以先于实现写),作为验收的测试。好处是RC对重构支持相对好一些,而且你可以换Agent,也可以做浏览器兼容测试。(但是由于RC的限制,兼容侧试兼容性并不好:)
按照raimudox所说RC是更加Pragmatic的实践,更能体现敏捷软件开发的测试先行的特性。功能测试可以说是沟通用户与开发者的最佳契约。
Selenium IDE录制script适合作为基线保留(指先实现需求,后录制测试这样的顺序),作为某次重构之前的样本。或者说,如果觉得手写测试脚本太麻烦,而喜欢本末倒置(没有贬义,纯技术上)的人设计的。更现实的说,这很有用,比如一个项目从一半开始敏捷改造,引入功能测试、单元测试,对以后的迭代进行基线的衡量,给新引入的CI(持续集成)一个更有实际意义的测试保障,用Selenium IDE帮助生成一下Script,然后再使用RC或者直接用Core执行一下都是不错的实践。而Fit方式(这里指先于应用实现就写出来的基于html/table的Fit式测试),相对吸引力差一些,因为工作量与RC相仿,重构支持比较差,而且没有DSL风格的封装,读起来相对费解一些。
还有,据Nicholas同学实践,Selenium IDE所录制的script在IDE中执行比RC方式兼容性要好,尤其对于跨域的情况,RC很有可能是无法工作的。还有一个问题,就是Selenium实际上是ThoughtWorks和BEA牵头的项目,TW负责Core,目前Core的代码发展的必较快,而RC由BEA负责,发展比较缓慢,所以,有些时候选择也就成为无奈了。
061102补充:
1、Selenium目前有做不到的地方:例如<input type="file"/>的情况,由于安全问题,浏览器是不允许通过javascript置里面的value的,所以selenium在此时会处于无能为力的情况。比较郁闷。虽然强行修改如Mozzila的安全属性可以办,但那不是好办法。
2、对于拥有复杂的Ajax widget的应用测试可能会非常麻烦,因为需要写很多javascript api在测试里面,对重构支持差(如api发生变化修改unit test很麻烦,而且可能出现需要对你的测试进行测试的尴尬情况)。当然对于大部分的ajax应用Selenium都是很好的选择。
3、大家都很看好的Remote Control方式发展比较慢,API还不够友好(经常抛出奇怪的异常),Bug还是比较多。所以还需要耐心等待,要多些像我们这样的小白鼠:D
推荐大家看看我的同事nicholas的这篇: 用 Selenium 进行功能测试
浓缩一下:
1、何时、何目的来用Selenium选择不同。RC、Fit适合从需求阶段就开始写。而IDE录制则适合后补。
2、重构支持。RC重构友好一些。Fit重构不友好。
3、IDE目前限定于FF,做跨浏览器RC比较好。但是IDE录制后的代码很方便转为RC方式。
4、跨域兼容性问题,IDE解决的比较好。
selenium的Remote Control比较适合在需求阶段就撰写(当然Fit方式也可以先于实现写),作为验收的测试。好处是RC对重构支持相对好一些,而且你可以换Agent,也可以做浏览器兼容测试。(但是由于RC的限制,兼容侧试兼容性并不好:)
按照raimudox所说RC是更加Pragmatic的实践,更能体现敏捷软件开发的测试先行的特性。功能测试可以说是沟通用户与开发者的最佳契约。
Selenium IDE录制script适合作为基线保留(指先实现需求,后录制测试这样的顺序),作为某次重构之前的样本。或者说,如果觉得手写测试脚本太麻烦,而喜欢本末倒置(没有贬义,纯技术上)的人设计的。更现实的说,这很有用,比如一个项目从一半开始敏捷改造,引入功能测试、单元测试,对以后的迭代进行基线的衡量,给新引入的CI(持续集成)一个更有实际意义的测试保障,用Selenium IDE帮助生成一下Script,然后再使用RC或者直接用Core执行一下都是不错的实践。而Fit方式(这里指先于应用实现就写出来的基于html/table的Fit式测试),相对吸引力差一些,因为工作量与RC相仿,重构支持比较差,而且没有DSL风格的封装,读起来相对费解一些。
还有,据Nicholas同学实践,Selenium IDE所录制的script在IDE中执行比RC方式兼容性要好,尤其对于跨域的情况,RC很有可能是无法工作的。还有一个问题,就是Selenium实际上是ThoughtWorks和BEA牵头的项目,TW负责Core,目前Core的代码发展的必较快,而RC由BEA负责,发展比较缓慢,所以,有些时候选择也就成为无奈了。
061102补充:
1、Selenium目前有做不到的地方:例如<input type="file"/>的情况,由于安全问题,浏览器是不允许通过javascript置里面的value的,所以selenium在此时会处于无能为力的情况。比较郁闷。虽然强行修改如Mozzila的安全属性可以办,但那不是好办法。
2、对于拥有复杂的Ajax widget的应用测试可能会非常麻烦,因为需要写很多javascript api在测试里面,对重构支持差(如api发生变化修改unit test很麻烦,而且可能出现需要对你的测试进行测试的尴尬情况)。当然对于大部分的ajax应用Selenium都是很好的选择。
3、大家都很看好的Remote Control方式发展比较慢,API还不够友好(经常抛出奇怪的异常),Bug还是比较多。所以还需要耐心等待,要多些像我们这样的小白鼠:D
推荐大家看看我的同事nicholas的这篇: 用 Selenium 进行功能测试
浓缩一下:
1、何时、何目的来用Selenium选择不同。RC、Fit适合从需求阶段就开始写。而IDE录制则适合后补。
2、重构支持。RC重构友好一些。Fit重构不友好。
3、IDE目前限定于FF,做跨浏览器RC比较好。但是IDE录制后的代码很方便转为RC方式。
4、跨域兼容性问题,IDE解决的比较好。