先后和nemo、limo、raimudox、nicholas討論：
selenium的Remote Control比較適合在需求階段就撰寫（當(dāng)然Fit方式也可以先于實現(xiàn)寫），作為驗收的測試。好處是RC對重構(gòu)支持相對好一些，而且你可以換Agent，也可以做瀏覽器兼容測試。（但是由于RC的限制，兼容側(cè)試兼容性并不好：）
按照raimudox所說RC是更加Pragmatic的實踐，更能體現(xiàn)敏捷軟件開發(fā)的測試先行的特性。功能測試可以說是溝通用戶與開發(fā)者的最佳契約。
Selenium IDE錄制script適合作為基線保留（指先實現(xiàn)需求，后錄制測試這樣的順序），作為某次重構(gòu)之前的樣本。或者說，如果覺得手寫測試腳本太麻煩，而喜歡本末倒置（沒有貶義，純技術(shù)上）的人設(shè)計的。更現(xiàn)實的說，這很有用，比如一個項目從一半開始敏捷改造，引入功能測試、單元測試，對以后的迭代進行基線的衡量，給新引入的CI（持續(xù)集成）一個更有實際意義的測試保障，用Selenium IDE幫助生成一下Script，然后再使用RC或者直接用Core執(zhí)行一下都是不錯的實踐。而Fit方式（這里指先于應(yīng)用實現(xiàn)就寫出來的基于html/table的Fit式測試），相對吸引力差一些，因為工作量與RC相仿，重構(gòu)支持比較差，而且沒有DSL風(fēng)格的封裝，讀起來相對費解一些。
還有，據(jù)Nicholas同學(xué)實踐，Selenium IDE所錄制的script在IDE中執(zhí)行比RC方式兼容性要好，尤其對于跨域的情況，RC很有可能是無法工作的。還有一個問題，就是Selenium實際上是ThoughtWorks和BEA牽頭的項目，TW負責(zé)Core，目前Core的代碼發(fā)展的必較快，而RC由BEA負責(zé)，發(fā)展比較緩慢，所以，有些時候選擇也就成為無奈了。
061102補充：
1、Selenium目前有做不到的地方：例如<input type="file"/>的情況，由于安全問題，瀏覽器是不允許通過javascript置里面的value的，所以selenium在此時會處于無能為力的情況。比較郁悶。雖然強行修改如Mozzila的安全屬性可以辦，但那不是好辦法。
2、對于擁有復(fù)雜的Ajax widget的應(yīng)用測試可能會非常麻煩，因為需要寫很多javascript api在測試?yán)锩妫瑢χ貥?gòu)支持差（如api發(fā)生變化修改unit test很麻煩，而且可能出現(xiàn)需要對你的測試進行測試的尷尬情況）。當(dāng)然對于大部分的ajax應(yīng)用Selenium都是很好的選擇。
3、大家都很看好的Remote Control方式發(fā)展比較慢，API還不夠友好（經(jīng)常拋出奇怪的異常），Bug還是比較多。所以還需要耐心等待，要多些像我們這樣的小白鼠:D
推薦大家看看我的同事nicholas的這篇：用 Selenium 進行功能測試濃縮一下：
1、何時、何目的來用Selenium選擇不同。RC、Fit適合從需求階段就開始寫。而IDE錄制則適合后補。
2、重構(gòu)支持。RC重構(gòu)友好一些。Fit重構(gòu)不友好。
3、IDE目前限定于FF，做跨瀏覽器RC比較好。但是IDE錄制后的代碼很方便轉(zhuǎn)為RC方式。
4、跨域兼容性問題，IDE解決的比較好。