一、商業工具：
1、kylinTOP:
這是一款國產的自動化測試工具，支持Web和APP的自動化測試，其中元素智能定位是這款自動化軟件主要特點，是設計理念比較超前的測試工具，算是國內眾多自動化測試工具中，做的比較突出的一款。與傳統的RFT和UFT相比，的確有過人之處，算是后起之秀吧。
2、RFT
Rational Functional Tester 的基礎是針對於java、.NET的對象技術和基於 Web 應用程序的錄制、回放功能。工具為測試者的活動提供的自動化的幫助，如數據驅動測試。
IBM RFT是一個用於功能和回歸測試的數據驅動的測試平台。它支持大范圍的應用，例如.Net、Java、SAP、Flex和Ajax。RFT使用Visual Basic。Net和Java作為腳本語言。RFT有一個獨特的功能，稱為 Storyboard 測試，用戶的動作被記錄下來，並通過應用截圖在 Storyboard 格式中可視化。
RFT的另一個有趣特性是它與IBM Jazz應用生命周期管理系統（如IBM Rational Team Concert和Rational Quality Manager）的集成。
3、UFT：
UFT(別名：QuickTest Professional簡稱)QTP是一種自動化測試工具，以VBScirpt為內嵌語言,其前身是QTP。UFT支持功能測試和回歸測試自動化，可用於軟件應用程序和環境的測試。UFT自動化測試的基本功能包括：創建測試、檢驗數據、增強測試、運行測試腳本、分析測試結果、維護測試；UFT支持兩種視圖，一種是Keyword View(關鍵字視圖)，另一種是Expert View(專家視圖)。是一款老牌的自動化測試工具。
4、SilkTest：
這個也是比較相對著名的工具，不過同樣還是沒有了解過，對於商業的工具，因為其占地面積大，還要破解等麻煩事，最關鍵的是使用的公司少，所以只使用過QTP，其它的一概未了解過。
二、開源工具：
1、Selenium：
這個應該大多數人都知道的，現在也是大多數互聯網公司在使用的測試框架；
Selenium僅支持Web的UI級別測試，但是其優點在於：
-
支持多種語言編寫測試腳本，比如：java、python、ruby、perl等；同時也就意味着其后的支持類庫也是很多的
-
支持多瀏覽器，如：ie，ff，safari、chrome等
-
支持多平台，如：windows、linux、MAC、android、iphone等
-
支持分布式執行，一套測試用例可以同時分布到不同的測試機上執行，而且還可以進行任務細化，比如：針對liunx執行系統只分配linux下需要執行的用例
此外還有錄制工具支持，簡單也說，Web類測試基本上是首選，不過對flash的支持好像不是太好。
其主要分2個版本：1.X版本是以js驅動來進行自動化實現的；2.X重新開發了webdriver來代替js驅動，直接調用瀏覽器底層接口來完成自動化實現的
前提：如果使用remote或者RC功能，需安裝jre
2、EFT【easy function testing】：
這個是在.net3.0 的UIAutomatuon的基礎上封裝的一個dll文件，同樣還封裝了部分windows api以實現鼠標和鍵盤事件。所以這個只能叫測試類庫，且僅支持windows程序，而且同樣支持uiautomain所支持的WPF程序的測試。
前提：安裝了.net3.0
使用：引入該文件，uiautomation 相關dll，VS環境下編寫測試用例
3、UIAutomation：
這個是微軟提供的UI自動化框架，當然它的初衷並不僅僅是為自動化測試而產生的，它的任務是給更多的開發或者應用去調用windows的UI控件，不過還是可以用於自動化測試的；因為之前微軟就有類似的工具，而這個是重新設計的ui操作類框架，其目的是為了兼容支持windows系列操作系統的UI自動化操作【xp，vista，server2003】，還有就是天然支持WPF。當然其設計與通常的自動化工具就不一樣了，比如：沒有把控件支持的方法綁定在控件對象本身，沒有提供專門的鼠標/鍵盤事件，但是卻提供了特定控件對象的事件響應監聽及處理方法的定制。
其工作流程大概是這樣的：
-
先獲取特定的元素對象，有多種方法。如：句柄，屬性值
-
獲取這個元素對象的模式。模式是這個框架的設計的獨具之處，成就了它的靈活性，統一性
-
通過這個模式在進行具體的方法調用，屬性值獲取等
-
監聽指定對象的特定事件，一旦發生則執行指定的事件處理函數
4、Robot Framework
Robot Framework是一個完全基於關鍵字測試驅動的框架，它即能夠基於它的一定規則，導入你需要的測試庫（例如：其集成了selenium的測試庫，即可以理解為操作web控件的測試底層庫），然后基於這些測試庫，你能應用HTML、TXT等文檔形式編寫自己的關鍵字（這些關鍵字即你的庫組成），之后，再編寫測試用例（測試用例由測試關鍵字組成）進行測試。例如：一個簡單的登陸測試由 登陸+輸入密碼+登出 三個關鍵字組成，也可以由一個關鍵字登陸組成，關鍵字顆粒的大小可以自行定制。
三、總結
最后才是干貨，掌握和了解這么工具為嘛使，不能總是為了好玩，而是為了能在以后的自動化實施過程中用於支持策略的制定；
比如新接收了一個測試項目需要進行自動化實施，那么需要考慮哪些點？使用哪個工具，有哪些工具可以作為備選？那么自然就要對常用自動化工具有一個初步的了解，同時對影響自動化過程的其它元素也要有一定的掌握，不過這里可以跳過，這里只是說與工具相關的因素的抉擇。
大體可以分為如下來考慮：
1. 考慮被測試產品的類型，B/S,，C/S，web service，SOAP，SDK或者API；過濾支持某類功能測試的工具
2. 考慮是否支持錄制，可以錄制就相對於說開發效率有較大的提高
3. 考慮工具的價格，通常首選開源或免費產品
4. 考慮工具擴展性，可能某類工具可以支持現在的業務需求，但日后需求有變化的話，是否有很好的擴展性，支持被測產品的新特性，如flex，flash，wpf等
5. 考慮工具的支持性，即后期的升級及版本更新的特性，不要選用即將不再支持的工具
6. 考慮工具的廣泛性，即這個工具在外部的流行程度，這樣以后招人容易，有問題也有較活躍的社區可以求助
7. 考慮工具的成熟性，即這個工具不能還在beta版本，需要有一個較穩定的版本，而且估計較長時間內不會有大版本的更迭
8. 考慮工具的可開發性，即工具是否提供插件接口，用於可以自定義自己的基礎類庫和識別機制
9. 考慮工具的易用性，即是否有強大的后台支持，如windows、.net、java類庫支持
10. 考慮工具的適應性，即是否容易被封裝，可以很容易被嵌入或引入到其它的框架中，比如：功能框架被引入到執行框架中
11. 考慮工具的針對性，即如果有專門的針對性工具可選，自然比那些綜合性很強的工具其適用性要高的多了