Selenium做功能测试的一点讨论(061102 update)

先后和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解决的比较好。