軟件測試工具有哪些？
開源測試管理工具：Bugfree、Bugzilla、TestLink、mantis 開源功能自動化測試工具：Watir、Selenium、MaxQ、WebInject
開源性能自動化測試工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Load Simulator
[]：企業(yè)級測試管理工具，也是業(yè)界*個基于Web的測試管理系統(tǒng)。
[Quality Center]：基于Web的測試管理工具，可以組織和管理應(yīng)用程序測試流程的所有階段，包括指定測試需求、計劃測試、執(zhí)行測試和跟蹤缺陷。
[QuickTest ]：用于創(chuàng)建功能和回歸測試。
[]：預(yù)測系統(tǒng)行為和性能的負載測試工具。
其他工具與自動化測試框架：Rational Tester、Borland Silk系列工具、WinRunner、Robot等。
軟件測試一般都用到哪些工具
常用的軟件測試工具一般是：QTP++QC
軟件測試中還需的工具如下：
功能測試工具：QTP（HP），WinRunner（MI），Robort（IBM），QARun（Compuware）
性能測試工具：（HP），WAS（MS），Robort（IBM）【必須下載相應(yīng)的插件才支持性能方面的測試】，QALoad（Compuware）
測試管理工具：/Quarlity Center【這兩個工具一個橫版一個豎版，功能完全一樣】，Rational
缺陷跟蹤工具：Bugzilla、Mantis
其他：Rational Purify、Rational
一般測試流程：
需求分析階段：只要就是對業(yè)務(wù)的學(xué)習(xí)，分析需求點。
測試計劃階段：測試組長就要根據(jù)SOW開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風(fēng)險識別等內(nèi)容。
測試設(shè)計階段：測試方案一般由對需求很熟的高資深的測試工程師設(shè)計，測試方案要求根據(jù)《SRS》上的每個需求點設(shè)計出包括需求點簡介，測試思路和詳細測試方法三部分的方案?！稖y試方案》編寫完成后也需要進行評審。
測試方案階段：主要是對測試用例和規(guī)程的設(shè)計。測試用例是根據(jù)《測試方案》來編寫的，通過《測試方案》階段，測試人員對整個系統(tǒng)需求有了詳細的理解。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預(yù)置條件，操作步驟和預(yù)期結(jié)果。其中操作步驟和預(yù)期結(jié)果需要編寫詳細和明確。測試用例應(yīng)該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。
測試執(zhí)行階段：執(zhí)行測試用例，及時提交有質(zhì)量的Bug和測試日報，測試報告等相關(guān)文檔
測試軟件的常用的工具軟件有哪些
在測試工作中，需要接觸到各種類型的測試工具。一般來說，有以下一些類型的工具：
測試管理工具：可以幫助完成測試計劃、跟蹤測試運行結(jié)果等的工具。這類工具還包括有助于需求、設(shè)計、編碼測試及缺陷跟蹤的工具；
靜態(tài)分析工具：分析代碼而不執(zhí)行代碼。這種工具檢測某些缺陷比用其它方法更有效，開銷也更小。這種工具一般可以度量代碼的各種指標，如McCabe測定復(fù)雜度，Logiscope度量代碼和規(guī)范的復(fù)合度等等；
覆蓋率工具：這種工具評估通過一系列測試后，軟件被執(zhí)行的程度。這種工具大量的被應(yīng)用于單元測試中，如、、Logiscope等；
動態(tài)分析工具：這種工具評估正在運行的系統(tǒng)。例如，檢查系統(tǒng)運行過程中的內(nèi)存使用情況，是否有內(nèi)存越界、內(nèi)存泄露等等，這類工具有Purify、等；
測試執(zhí)行工具：這類工具可使測試能夠自動化進行，并且各個層次（單元測試、集成測試、系統(tǒng)測試）的執(zhí)行工具都有。例如系統(tǒng)測試階段有功能測試自動化工具，如Robot、Winrunner、SilkTest等；還有性能測試工具，如、等。
白盒測試工具主要有：
內(nèi)存資源泄漏檢查：Numega中的,Rational的Purify
代碼覆蓋率檢查：Numega中的,Rational的，Telelogic公司的logiscope,Macabe公司的Macabe
代碼性能檢查：Numega中的truetime,Rational的Quantify
代碼靜態(tài)度量分析質(zhì)量檢查工具：logiscope和Macabe
黑盒測試工具主要有：
客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的robot
服務(wù)器端壓力性能測試：MI公司的winload,compuware的qaload,Rational的SQAload等等
Web測試工具：MI公司的Astra系列，rsw公司的e-testsuite
測試管理工具：rational的,compuware的等
缺陷跟蹤工具：，Testtrack
單元測試工具：
測試框架：++cppunit
一般公司常用的軟件測試工具有哪些？
1、靜態(tài)測試工具：直接對代碼進行分析，生成可執(zhí)行文件。靜態(tài)測試工具一般是對代碼進行語法掃描，根據(jù)某種質(zhì)量模型評價代碼的質(zhì)量，生成系統(tǒng)的調(diào)用關(guān)系圖等。靜態(tài)測試工具的代表有：Telelogic公司的Logiscope軟件；PR公司的PRQA軟件。
2、動態(tài)測試工具：動態(tài)測試工具的一般采用"插樁"的方式，向代碼生成的可執(zhí)行文件中插入一些監(jiān)測代碼，用來統(tǒng)計程序運行時的數(shù)據(jù)。動態(tài)測試工具的代表有：Compuware公司的軟件;Rational公司的Purify系列等。
3、黑盒測試工具
黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作。黑盒測試工具的代表有：Rational公司的TeamTest、Robot;Compuware公司的QACenter。
4、性能測試工具
的是一種適用于各種體系架構(gòu)的自動負載測試工具，它能預(yù)測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。的測試對象是整個企業(yè)的系統(tǒng)，它通過模擬實際用戶的操作行為和實行實時性能監(jiān)測，來幫助您更快的查找和發(fā)現(xiàn)問題。
5、測試管理工具
測試管理工具對測試計劃、測試用例、測試實施進行管理，并且，測試管理工具還包括對缺陷的跟蹤管理。測試管理工具的代表有：Rational公司的；公司的；Mercury 公司的等軟件。
參考資料：百度百科-軟件測試（第二版）
常用的軟件測試方法和工具
工業(yè)標準級負載測試工具 是一種預(yù)測系統(tǒng)行為和性能的負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題， 能夠?qū)φ麄€企業(yè)架構(gòu)進行測試。通過使用 ，企業(yè)能*限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。自動化功能測試工具是黑盒測試工具，可以用來完成功能測試、回歸測試、每日構(gòu)建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調(diào)試功能的、支持IE測試和Windows native測試的自動化測試工具，是目前國內(nèi)*的銀行業(yè)務(wù)測試工具。全球測試管理系統(tǒng) 是業(yè)界*個基于Web的測試管理系統(tǒng)，它可以在您公司內(nèi)部或外部進行全球范圍內(nèi)測試的管理。通過在一個整體的應(yīng)用系統(tǒng)中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執(zhí)行以及錯誤跟蹤等功能，極大地加速了測試過程。測試用例管理工具是一款功能強大測試管理工具，它實現(xiàn)了測試需求管理、測試用例管理、測試業(yè)務(wù)組件管理、測試計劃管理、測試執(zhí)行、測試結(jié)果日志察看、測試結(jié)果分析、缺陷管理，并且支持測試需求和測試用例之間的關(guān)聯(lián)關(guān)系，可以通過測試需求索引測試用例。終端自動化測試工具TARTAR適用于VT100、VT220等標準的應(yīng)用系統(tǒng)，支持命令行模式和窗口模式（使用Cursors編寫的應(yīng)用程序）。 支持針對終端應(yīng)用的自動錄制。支持連續(xù)錄制和單獨的窗口錄制。支持的窗口組件：欄位、表格、對話框、窗口等。功能測試工具Rational SilkTest 2006屬于軟件功能測試工具，是Borland公司所提出軟件質(zhì)量管理解決方案的套件之一。這個工具采用精靈設(shè)定與自動化執(zhí)行測試，無論是程序設(shè)計新手或資深的專家都能快速建立功能測試，并分析功能錯誤。 性能測試工具 Web Stress Tool 是由微軟的網(wǎng)站測試人員所開發(fā)，專門用來進行實際網(wǎng)站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機仿真大量用戶上線對網(wǎng)站服務(wù)所可能造成的影響。自動化白盒測試工具是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現(xiàn)java的單元測試和代碼標準校驗，來提高代碼的可靠性。parasoft同時出品的還有C++ test，是一款C/C++白盒測試工具。功能和性能測試的工具是Apache組織的開放源代碼項目，它是功能和性能測試的工具，*的用java實現(xiàn)。性能測試和分析工具是RadView公司推出的一個性能測試和分析工具，它讓web應(yīng)用程序開發(fā)者自動執(zhí)行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。企業(yè)級自動化測試工具 公司的WinRunner是一種企業(yè)級的功能測試工具，用于檢測應(yīng)用程序是否能夠達到預(yù)期的功能及正常運行。通過自動錄制、檢測和回放用戶的應(yīng)用操作，WinRunner能夠有效地幫助測試人員對復(fù)雜的企業(yè)級應(yīng)用的不同發(fā)布版進行測試，提高測試人員的工作效率和質(zhì)量，確?？缙脚_的、復(fù)雜的企業(yè)級應(yīng)用無故障發(fā)布及長期穩(wěn)定運行。
測試經(jīng)理和PM對TC進行Review：
敏捷測試流程總結(jié)：
在敏捷方法中，XP方法強調(diào)測試在整個項目開發(fā)過程中的重要性。針對敏捷開發(fā)方法的敏捷測試不同于以往針對傳統(tǒng)開發(fā)模式的測試,在敏捷團隊中,測試是整個項目組的“車頭燈”，它告訴大家現(xiàn)在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基于這些可靠的信息作出正確的決定。不僅是測試員要保證質(zhì)量，而是整個項目組的每一個人都要對質(zhì)量負責。測試員不跟開發(fā)人員糾纏錯誤，而是幫助他們找到目標,共同為達到項目的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態(tài)調(diào)整測試計劃、測試的執(zhí)行。并且，敏捷測試人員參與到了更多的敏捷生產(chǎn)活動中，積極的影響了團隊做出的決定和計劃。
根據(jù)公司項目目前采用的敏捷開發(fā)模式，相應(yīng)的敏捷測試建議采用以下流程：
1. 驗證需求和設(shè)計
需求和設(shè)計具體來說一般包括：(1)由項目經(jīng)理根據(jù)需求文本而編寫的功能設(shè)計文本( Design );(2)由開發(fā)人員根據(jù)功能文本而編寫的實施設(shè)計文本( Design )包括( Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設(shè)計的可測性.
在測試初期，測試人員要學(xué)會做靜態(tài)測試，做好需求分析，做好對設(shè)計邏輯的分析。測試人員要更多的思考需求的可實現(xiàn)性，將自身作為*用戶積極參與項目和系統(tǒng)的需求分析，設(shè)計和開發(fā)。積極地參與前期工作，并迅速反饋給設(shè)計和開發(fā)其靜態(tài)測試結(jié)果。要盡早的開始測試，不要等待到功能完全做好才開始。
產(chǎn)出物:測試需要提交評審結(jié)果文檔,可以讓測試更多的參與DB Design,框架的評審中來
2. 測試計劃，測試用例
2.1 編寫計劃、測試用例
在敏捷開發(fā)的過程中由于是根據(jù)每個user story來估算時間的。開發(fā)人員將對本次迭代所需要的完成的user story進行評估。開發(fā)人員可以和客戶直接溝通，來確定每個user story的優(yōu)先級。
好處：
客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優(yōu)先級。
問題：
在user story的時間估算上，開發(fā)人員常會估算過少。引起版本無法按時發(fā)布或者必須進行加班才能進行發(fā)布。
分析：
由于版本更新很快，任務(wù)的時間都是以小時來進行估算的。開發(fā)人員一般會忽略掉開發(fā)以外的時間，比如開發(fā)中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。
舉個例子：
開發(fā)人員估算某個user story編碼的時間需要1.5天，開發(fā)人員自己估算了其他時間為半天。于是開發(fā)人員給的估算時間是2天。開發(fā)階段實際的花費時間如下，每天花費開例會的時間。在例會中項目的其他成員需要技術(shù)上的支持。于是發(fā)費了3個小時進行幫助。在開發(fā)的過程中遇到了一些沒有預(yù)見到的問題，結(jié)果解決問題花費了4個小時。(也許更多)。需要處理一些公司突發(fā)性的事務(wù)等等。所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本XP相關(guān)的書上寫到，在時間估算上*的時間是編碼時間的2-3倍。聽起來很嚇人，但是實際的過程中，的確需要這么多的時間。
測試人員根據(jù)已審核通過的需求和設(shè)計編制測試計劃，設(shè)計測試用例。在前面提到的三種文本中，功能設(shè)計文本是主要依據(jù)。測試的這兩個文本也要被項目經(jīng)理和開發(fā)人員審核。
2.2 測試用例的審核
為使開發(fā)人員能參與到Test Case的Review中來，以保證TC的質(zhì)量和可行性，確保測試工作的順利進行，讓開發(fā)人員迅速地了解測試的重點并給出相應(yīng)的意見和建議，測試人員在出 TC的同時，應(yīng)出一份TC_Matrix(Test Case跟蹤矩陣)，其中注明TC已覆蓋了哪些Features，具體每個Features對應(yīng)的TC的編號，這樣在測試經(jīng)理和PM對TC進行 Review的時候，能夠?qū)C的覆蓋率一目了然，對覆蓋率不足(如某個重點Feature的Test Case不夠)的地方能夠及時給出意見。
另外，在每天早上的Morning Meeting上，測試人員可以簡潔地講述一下當天測試的重點部分，以及項目中存在哪些嚴重的bug，讓開發(fā)人員了解當天測試的重點是什么，怎樣進行測試，并提出自己的意見和建議。這樣做加強了開發(fā)與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。
在迭代后期測試要抽時間更新test case。
3. 實施運行測試
在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發(fā)人員來完成的，接收測試是由客戶代表來完成。
由于我們客戶無法在現(xiàn)場，我們采取了，開發(fā)人員做單元測試，測試人員做驗證測試，*由客戶進行接收測試。在每個版本發(fā)布給客戶之前必須由測試人員進行測試，發(fā)布版本之后由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下一個發(fā)布完成。
?? 單元測試
在daily build版本給測試前，開發(fā)首先要做單元測試，提前告知軟件中的薄弱環(huán)節(jié)，幫助測試人員調(diào)整測試重點。Unit test
做單元測試的好處是可以提高版本質(zhì)量，減輕測試的工作量，減少淺層次的bug的發(fā)生率，使測試人員能夠?qū)⒏嗟木ν度氲綄ふ疑顚哟蔚腷ug上面。
?? 驗證測試
測試人員的驗證測試從總體上說就是將上一步設(shè)計的測試用例按計劃付諸實施的過程。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現(xiàn)在開發(fā)和測試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項目的總體計劃共同推進。從測試的過程來看，測試執(zhí)行的一開始可以是針對部分功能的，之后可以逐步擴展。接著開始采用迭代的過程完成測試任務(wù)，即將測試任務(wù)劃分為多個周期，一開始可以做些關(guān)鍵的功能性測試，可以對代碼中的可復(fù)用部分(組件，構(gòu)件)做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，*的幾個迭代應(yīng)該用于回歸測試，和關(guān)鍵的性能和穩(wěn)定性測試。
3.1 每日提供bug趨勢
為方便衡量項目的進度，測試可每天測試完畢后提供測試的bug趨勢，即將每天新生成的Bug數(shù)和每天被解決的Bug數(shù)標成一個趨勢圖表。一般在項目的開始階段新生Bug數(shù)曲線會呈上升趨勢，到項目中后期被解決Bug數(shù)曲線會趨于上升，而新生Bug數(shù)曲線應(yīng)下降，到項目*，兩條曲線都趨向于零。PM會持續(xù)觀察這張圖表，確保項目健康發(fā)展，同時通過分析預(yù)測項目Bug，
對于每個版本的bug，開發(fā)都應(yīng)該想想為什么會出現(xiàn)這樣的問題，特別是很低級的bug，對于同類的bug，是否可以避免。
測試需要考慮:探索性測試用例的編寫
3.2 測試用例的維護
在執(zhí)行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對于當初測試設(shè)計不周全的領(lǐng)域，二是對于外部的Bug(比如從Beta客戶報告來的)，沒有被現(xiàn)有測試用例所覆蓋。當產(chǎn)品的功能設(shè)計出現(xiàn)更改時(敏捷項目中功能設(shè)計的更改頻繁)，所涉及的測試用例也要相應(yīng)地修改，使測試用例保持和現(xiàn)有的功能需求同步。
3.3 根據(jù)項目不斷補充Common Sense
在項目進行過程中，測試人員需要不斷積累經(jīng)驗，不斷補充、完善各類目的Common Sense標準。例如，由CTTS項目總結(jié)出的Common Sense for USA標準，在以后的美國項目中要嚴格按照它來執(zhí)行測試，保證以前出現(xiàn)過的失誤在以后的項目測試中不會再出現(xiàn)。在保證項目質(zhì)量的同時，不斷積累新的經(jīng)驗。
3.4 控制中間版本
為更好地保證軟件質(zhì)量，規(guī)避風(fēng)險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三一定要提交一個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到后期最緊急的時候去完成。以前的項目中出現(xiàn)過項目前期很輕松，到后期bug越來越多，開發(fā)人員和測試人員都異常忙碌，經(jīng)常加班的情況。為減少后期工作量，規(guī)避風(fēng)險，建議開發(fā)進行Daliy Build，或者按照完成一個feature就進行一次build，針對這個feature進行測試，這樣就可以有效避免后期bug越來越多的狀況發(fā)生，后期工作量也就會相應(yīng)減少，項目的質(zhì)量也會更有保證。
3.5 發(fā)布版本前編寫Release Note
在每次發(fā)布版本之前，測試人員要根據(jù)待發(fā)布的版本情況編寫Release Note，使客戶對發(fā)布的版本情況一目了然。Release Note主要包括三方面的內(nèi)容：Fixed，New Features，Known Problems。其中，F(xiàn)ixed部分寫明此版本修復(fù)了上個版本中存在的的哪些比較大的bug;New Features部分寫明此版本新增加了哪些功能;Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善;或者列出需求不太明確的地方，有待客戶給出明確答復(fù)意見，在下個版本中完成。
4. 需求管理
采用敏捷開發(fā)模式的項目中，客戶對于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應(yīng)的歷史記錄，方便后期的管理和維護工作?？蓪⒚看蔚淖兏碛涗浀叫枨蟾櫸臋n中，并使該文檔始終保持*更新的狀態(tài)，與需求的變化保持同步。
問題：
客戶可能會在一個功能點上來回修改他們的需求，也許開始需要某個功能，結(jié)果做完以后又覺得不好，于是讓去掉這個功能。后來又由于一些原因，有需要加上。在整個過程中可能來回修改了很多次。那一定要記錄下變更的內(nèi)容和日期。可能后期客戶會覺得一個功能怎么會花那么多的時間，不是以前很早就做過了嗎?這時這些記錄才是解決客戶疑慮的*證明。說白了，是有證據(jù)證明我們做了很多的變更。大家可能覺得，怎么會有這個問題。其實當一個項目長達半年以上，也許大家的記憶力都不可靠了(:p)
建議：
目前采用的是vss工具，對每天的Email中提到的需求變更做一次backup，文檔以當天收到Email的日期命名
5. 項目開發(fā)末期開展“bug大掃除”
在項目開發(fā)的末期，可以開展“bug大掃除”活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：
(1)盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經(jīng)理，開發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動員。目的是要集思廣益;(2)要鼓勵各*，領(lǐng)域交叉搜索，因為新的思路和視角通常有助于發(fā)現(xiàn)更多的Bug;(3)為調(diào)動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結(jié)束時，評出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴重Bug的個人，給以物質(zhì)和精神獎勵。(4)可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。
