測試工具可以用來支援乙個或多個測試活動。這些工具包括：
• 直接用於測試的工具，如測試執行工具和測試資料準備工具
• 有助於管理需求、測試用例、測試規程、自動化測試指令碼、測試結果、測試資料和缺陷的工具，以及用於報告和監視測試執**況的工具
• 用於調查和評價的工具
• 任何有助於測試的工具（這個意義上電子**也是測試工具）
6.1.1 測試工具分類
測試工具可以根據上下文有以下乙個或多個目的：
• 將重複的任務或者手動測試需要大量資源的任務進行自動化以提高測試活動的效率(例如：測試執行、回歸測試)
• 在整個測試過程中支援手工測試活動，以提高測試活動的效率(見第1.4節)
• 通過更加一致的測試和更高的缺陷重現級別來提高測試活動的質量
• 自動化無法手工執行的活動(例如：大規模效能測試)
• 提高測試的可靠性（例如：通過自動進行大規模資料比較或模擬的行為）
可以根據目的、**定價、許可證發放模式(例如商業**或開放**)和所使用的技術等若干標準對工具進行分類。在本大綱中，工具根據其支援的測試活動進行分類。
有些工具明確只支援或主要支援一項活動；另一些工具可能支援多項活動，但被歸類為與其聯絡最密切的活動。單一**商提供的工具，特別是那些被設計成可以一起工作的工具，可以作為乙個整合套件提供。
某些型別的測試工具可能具有干預性，這意味著它們可能影響測試的實際結果。例如：應用程式的實際響應時間可能因效能測試工具執行的額外指令而不同，或者由於使用覆蓋工具而導致**覆蓋的數量可能被扭曲。使用干預性工具的後果稱為探針效應。
一些工具提供的支援通常更適合開發人員（例如：在元件和整合測試期間使用的工具）。這些工具在以下各節中以"(d)"進行標識。
測試和測試件管理的工具支援
管理工具可適用於整個軟體開發生命週期中的任何測試活動。支援測試和測試件管理的工具的例子包括：
• 測試管理工具和應用生命週期管理工具（alm）
• 需求管理工具（例如：測試物件的可追溯性）
• 缺陷管理工具
• 配置管理工具
• 持續整合工具(d)
靜態測試的工具支援
靜態測試工具與第3章中描述的活動和收益相關聯。這類工具的例子包括：
• 支援評審的工具
• 靜態分析工具(d)
測試設計與實現的工具支援
測試設計工具有助於在測試設計和實現中建立可維護的工作產品，包括測試用例、測試規程和測試資料。這類工具的例子包括：
• 測試設計工具
• 基於模型的測試工具
• 測試資料準備工具
• 驗收測試驅動開發（atdd）和行為驅動開發（bdd）工具
• 測試驅動開發工具(tdd)（d）
在某些情況下，支援測試設計和實現的工具也可能支援測試執行和日誌記錄，或者將其輸出直接提供給支援測試執行和日誌記錄的其他工具。
測試執行與記錄的工具支援
有許多任務具可以支援和增強測試執行和日誌記錄活動。這些工具的例子包括：
• 測試執行工具（例如：執行回歸測試）
• 覆蓋工具(如需求覆蓋、**覆蓋(d))
• 測試用具(d)
• 單元測試框架工具(d)
效能測量和動態分析的工具支援
效能測量和動態分析工具對於支援效能和負載測試活動是必不可少的，因為這些活動不能有效地通過手工完成。這些工具的例子包括：
• 效能測試工具
• 監視工具
• 動態分析工具(d)
特殊測試需要的工具支援
除了支援一般測試過程的工具外，還有許多其他工具支援更具體的測試事件。其中包括側重於以下方面的工具：
• 資料質量評估
• 資料轉換和遷移
• 易用性測試
• 輔助性測試
• 本地化測試
• 安全性測試
• 可移植性測試（例如：在多個支援的平台上測試軟體）
6.1.2 測試自動化的收益與風險
僅僅獲得工具並不能保證成功。每個組織引入新工具都需要投入工作量以實現真正和持久的收益。測試中使用工具有潛在的收益和機會，但也存在風險。這對於測試執行工具（通常稱為測試自動化）尤其如此。
使用工具支援測試執行的潛在收益包括：
• 減少重複的手工工作（例如：執行回歸測試、環境安裝/拆除任務、重新輸入相同的測試資料和檢查程式設計規範），從而節省時間
• 更好的一致性和可重複性(例如：以一致的方式建立測試資料，通過工具以相同頻率相同順序執行測試，使用一致的方式從需求中獲得測試)
• 更客觀的評估(例如：靜態測量、覆蓋率)
• 更容易獲得有關測試的資訊（例如：關於測試進度、缺陷率和效能的統計數字和圖表）
使用工具支援測試的潛在風險包括：
• 對工具不切實際的期望(包括功能性和易用性)
• 低估初次引入工具的時間、成本和工作量(包括培訓和外部專業知識)
• 低估從該工具獲得重大和持續收益所需的時間和工作量(包括需要的測試過程的改變和該工具使用方式的不斷改進)
• 低估維護該工具生成的測試資產所需的工作量
• 過分依賴工具（被看作測試設計或執行的替代，或在使用人工測試更好的情況下切使用自動測試）
• 忽視測試資產的版本控制
• 忽視關鍵工具之間的關係和互操作性問題，例如需求管理工具、配置管理工具、缺陷管理工具和來自多個**商的工具
• 工具**商可能倒閉、工具退役或將工具賣給其他**商
• **商不能及時提供對支援、公升級和缺陷修復的響應
• 開源專案暫停
• 工具不支援新平台或新技術
• 該工具可能沒有明確的責任人(例如：指導、更新等)
6.1.3 測試執行與測試管理工具的特殊考慮
為了順利和成功地實現，在選擇和整合測試執行和測試管理工具到組織中時，有許多事情需要考慮。
測試執行工具
測試執行工具使用自動化測試指令碼執行測試物件。這類工具往往需要付出巨大的工作量，才能取得顯著的收益。
通過記錄手動測試人員的動作來捕獲測試似乎很有吸引力，但是這種方法無法應用到大量測試指令碼的情況。捕獲的指令碼是作為每個指令碼一部分的帶有特定資料和動作的線性表示。當不可預料的事件發生時，這種型別的指令碼是不穩定的。最新一代的工具利用了"智慧型"影象捕捉技術，增強了這類工具的效用，儘管生成的指令碼仍然需要隨著系統使用者介面的發展不斷進行維護。
資料驅動的測試方法將測試輸入和預期結果分離出來，通常放入電子**中，並使用更通用的測試指令碼，通過讀取輸入資料並使用不同的資料執行相同的測試指令碼。不熟悉指令碼語言的測試人員可以為這些預先定義的指令碼建立新的測試資料。
在關鍵字驅動的測試方法中，通用指令碼處理描述要採取的動作的關鍵字（也稱為動作詞），然後呼叫關鍵字指令碼處理相關的測試資料。測試人員（即使他們不熟悉指令碼語言）可以使用關鍵字和相關資料定義測試，這些關鍵字和相關資料可以根據正在測試的應用程式進行裁剪。資料驅動和關鍵字驅動的測試方法的進一步細節和例子，可以參考istqb-tae高階測試自動化工程師大綱，fewster1999和buwalda2001。
上述方法需要有人具備指令碼語言的專門知識（測試人員、開發人員或測試自動化方面的專家）。無論使用何種指令碼技術，每個測試的預期結果都需要與測試的實際結果進行比較，或者是動態的（在測試執行時），或者是儲存供以後（執行後）比較。
基於模型的測試（mbt）工具能夠以模型的形式捕獲功能規格說明，例如活**。此任務通常由系統設計人員執行。mbt工具解釋模型以建立測試用例規格說明，然後儲存在測試管理工具中和/或通過測試執行工具執行（見istqb-mbt基礎級別基於模型的測試大綱）。
測試管理工具
測試管理工具經常由於各種原因需要與其他工具或電子**相互互動，包括：
• 以適合本組織要求的格式提供有用的資訊
• 對需求管理工具中的需求保持一致的可追溯性
• 在配置管理工具中與測試物件版本資訊鏈結
這一點在使用綜合工具（如應用生命週期管理）時尤其重要，該工具包括測試管理模組（可能還有缺陷管理系統），以及其他模組（如專案時間進度和預算資訊），它們會在同乙個組織內的不同團體中使用。
開源的測試工具
文章 七劍下天山，獨領自動化測試技術 介紹了一些開源測試工具，非常有用，所以把它列出來 1 莫問劍 selenium 的 web功能測試，變化無窮 氣勢磅礴。第 3章介紹了 selenium 旗下的四大金剛 selenium ide core remore control 和grid 及其應用，從而...
壓力測試工具
webbench最多可以模擬3萬個併發連線去測試 的負載能力，比apache自帶的ab壓力測試工具好，安裝使用也特別方便。1 適用系統 linux 2 編譯安裝 引用 wget tar zxvf webbench 1.5.tar.gz cd webbench 1.5 make make instal...
http load測試工具
基於linux平台的一種效能測工具。以並行復用的方式執行，用以測試web伺服器的吞吐量與負載，測試web頁面的效能。優點1.基於命令列，簡單 易於上手 2.小巧輕便，解壓縮後不到100k 3.開源，免費 缺點1.僅適用於web頁面的效能測試，不適用於訪問資料庫 2.測試結果分析有限 3.平台依賴li...