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