一般而言，我們將測試工具分為白盒測試工具、黑盒測試工具、性能測試工具、測試管理工具幾個大類。
a) 白盒測試工具
白盒測試工具一般是針對代碼進行測試，測試中發現的缺陷可以定位到代碼級，根據測試工具原理的不同，又可以分為靜態測試工具和動態測試工具。
i. 靜態測試工具
靜態測試工具直接對代碼進行分析，不需要運行代碼，也不需要對代碼編譯鏈接，生成可執行文件。靜態測試工具一般是對代碼進行語法掃描，找出不符合編碼規范的地方，根據某種質量模型評價代碼的質量，生成系統的調用關系圖等。
靜態測試工具的代表有Telelogic公司的Logiscope軟件、PR公司的PRQA軟件。
ii. 動態測試工具
動態測試工具與靜態測試工具不同，動態測試工具的一般采用“插樁”的方式，向代碼生成的可執行文件中插入一些監測代碼，用來統計程序運行時的數據。其與靜態測試工具最大的不同就是動態測試工具要求被測系統實際運行。
動態測試工具的代表有Compuware公司的DevPartner軟件、Rational公司的Purify系列。
b) 黑盒測試工具
黑盒測試工具適用于黑盒測試的場合，黑盒測試工具包括功能測試工具和性能測試工具。黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作，然后將被測系統的輸出記錄下來同預先給定的標準結果比較。黑盒測試工具可以大大減輕黑盒測試的工作量，在迭代開發的過程中，能夠很好地進行回歸測試。
黑盒測試工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，專用于性能測試的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。
c) 測試管理工具
測試管理工具用于對測試進行管理。一般而言，測試管理工具對測試計劃、測試用例、測試實施進行管理，并且，測試管理工具還包括對缺陷的跟蹤管理。
測試管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord等軟件。
d) 其他測試工具
除了上述的測試工具外，還有一些專用的測試工具，例如，針對數據庫測試的TestBytes，對應用性能進行優化的EcoScope等工具。
e) 測試工具的選擇
面對如此多的測試工具，對工具的選擇就成了一個比較重要的問題。我們在考慮選用工具的時候，建議從以下幾個方面來權衡和選擇：
i. 功能
功能當然是我們最關注的內容，選擇一個測試工具首先就是看它提供的功能。當然，這并不是說測試工具提供的功能越多就約好，在實際的選擇過程中，適用才是根本�！板X要花在刀刃上”，為不需要的功能花費金錢實在不是明智的行為。事實上，目前市面上同類的軟件測試工具之間的基本功能都是大同小異，各種軟件提供的功能也大致相同，只不過有不同的側重點。例如，同為白盒測試工具的Logiscope和PRQA軟件，他們提供的基本功能大致相同，只是在編碼規則、編碼規則的定制、采用的代碼質量標準方面有不同。
除了基本的功能之外，以下的功能需求也可以作為選擇測試工具的參考：
1) 報表功能；測試工具生成的結果最終要由人進行解釋，而且，查看最終報告的人員不一定對測試很熟悉，因此，測試工具能否生成結果報表，能夠以什么形勢提供報表是需要考慮的因素。
2) 測試工具的集成能力；測試工具的引入是一個長期的過程，應該是伴隨著測試過程改進而進行的一個持續的過程。因此，測試工具的集成能力也是必須考慮的因素，這里的集成包括兩個方面的意思，首先，測試工具能否和開發工具進行良好的集成；其次，測試工具能夠和其他測試工具進行良好的集成。
3) 操作系統和開發工具的兼容性；測試工具可否跨平臺，是否適用于公司目前使用的開發工具，這些問題也是在選擇一個測試工具時必須考慮的問題。
ii. 價格
除了功能之外，價格就應該是最重要的因素了。說句題外話，在論壇上經�？吹接腥苏凑醋韵驳恼f我已經破解了XX測試工具這樣的話，對這種態度我十分不贊成。如果作為軟件從業者的我們都不能尊重別人的勞動，那有怎么能夠指望我們的客戶尊重我們的勞動呢？況且，測試工具的價格并不是真的昂貴到不能承受的程度，例如Numega的DevPartner一個固定license是兩萬多元人民幣，對一個中型的公司來說完全可以承受。
iii. 測試工具引入的目的是測試自動化，引入工具需要考慮工具引入的連續性和一致性
測試工具是測試自動化的一個重要步驟之一，在引入/選擇測試工具時，必須考慮測試工具引入的連續性。也就是說，對測試工具的選擇必須有一個全盤的考慮，分階段、逐步的引入測試工具。
3、 測試工具在測試過程中的應用
前面已經對測試工具的分類、測試工具的選擇進行了一些描述，這里，我還想就測試工具在測試過程中的應用說一點自己的看法。
對測試工具能夠發揮的作用大家都已經了解并認可了，但是很多引入測試軟件的公司并沒有能夠讓測試軟件發揮應有的作用，其主要原因我總結為三個方面：
a) 沒有考慮到公司的實際情況，盲目引入測試工具
首先我們要明確一點，并不是每種測試工具都適合公司目前的實際情況。我見過一些公司懷著美好的愿望花了不小的代價引入測試工具，半年一年以后，測試工具卻成了擺設，成了引入者心頭的痛。究其原因，就是沒有能夠考慮公司的現實情況，不切實際地期望測試工具能夠改變公司的現狀，從而導致了失敗。
例如，如果一個公司所開發的軟件屬于工程性質的軟件，在整個開發過程中需求和用戶界面變動較大，這種情況下就不適合引入黑盒測試軟件，因為黑盒測試軟件的基本原理是錄制/回放，對于不停變化的需求和界面，可能修改和錄制腳本的工作量還大過測試實施，運用測試工具不但不能減輕工作量，反而加重了測試人員的負擔。
我公司引入測試工具時比較成功的（至少從目前來看），針對我公司的應用項目都存在需求、界面變動比較頻繁的情況，我們暫時沒有引入黑盒測試工具，主要依靠白盒測試工具提升代碼質量。目前我們引入的測試工具包括Compuware的DevPartner和Telelogic的Logiscope，這兩個工具在測試階段和維護階段發揮了應有的作用。
b) 沒有形成一個良好的使用測試工具的環境
換句話說，就是沒有能夠形成一種機制讓測試工具真正能夠發揮作用。例如，白盒測試工具的一般使用場合是在單元測試階段，而單元測試是由開發人員完成，如果沒有流程來規范開發人員的行為，在項目進度壓力比較大的情況下，開發人員很可能就會有意識地不使用測試工具，來逃避問題。在這種情況下，就必須形成一種有約束力的機制來強制對測試工具的使用。
將測試工具的使用明確定義進公司的開發流程，我認為是一種比較好的方式。我們目前的做法是在開發流程中明確說明，在項目里程碑提交的文檔中必須包括測試工具生成的報告，該報告中的數據是決定項目是否合格的依據。根據我公司的實際情況，在提交集成測試時需要提交DevPartner工具生成的測試覆蓋率報告、Logiscope生成的代碼質量報告，并且要求單元測試的代碼覆蓋率必須達到80%以上，代碼質量評價必須在Fair以上。
c) 沒有進行有效的測試工具的培訓
測試工具的使用者必須對測試工具非常了解，在這方面，有效的培訓是必不可少的。測試工具的培訓是一個長期的過程，不是通過一兩次講課的形式就能達到良好的效果。而且，在實際的使用測試工具的過程中，測試工具的使用者可能還存在著這樣那樣的問題，這也需要有專人負責解決，否則的話，對于測試工具使用者的積極性是很大的打擊。
我公司在進行測試工具的培訓時，進行了一個系列的培訓和交流，從針對開發高層的《測試工具基本概念培訓》到針對測試工具實際使用者的《測試工具使用培訓》，再到交流性質的《測試工具應用交流研討會》，再到定期發出的《測試工具應用問答》，在這方面下了很大的功夫，目前測試工具的應用已經成為了開發人員和測試人員的基本功
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
