一般公司常用的軟件測試工具有哪些？

1、靜態測試工具：直接對代碼進行分析，生成可執行文件。靜態測試工具一般是對代碼進行語法掃描，根據某種質量模型評價代碼的質量，生成系統的調用關系圖等。靜態測試工具的代表有：Telelogic公司的Logiscope軟件；PR公司的PRQA軟件。

2、動態測試工具：動態測試工具的一般采用"插樁"的方式，向代碼生成的可執行文件中插入一些監測代碼，用來統計程序運行時的數據。動態測試工具的代表有：Compuware公司的軟件;Rational公司的Purify系列等。

3、黑盒測試工具

黑盒測試工具的一般原理是利用腳本的錄制(Record)/回放(Playback)，模擬用戶的操作。黑盒測試工具的代表有：Rational公司的TeamTest、Robot;Compuware公司的QACenter。

4、性能測試工具

的是一種適用于各種體系架構的自動負載測試工具，它能預測系統行為并優化系統性能。的測試對象是整個企業的系統，它通過模擬實際用戶的操作行為和實行實時性能監測，來幫助您更快的查找和發現問題。

5、測試管理工具

測試管理工具對測試計劃、測試用例、測試實施進行管理，并且，測試管理工具還包括對缺陷的跟蹤管理。測試管理工具的代表有：Rational公司的；公司的；公司的等軟件。

參考資料：百度百科-軟件測試（第二版）

軟件測試工具有哪些？

1、禪道測試管理工具是功能比較全面的測試管理工具，功能涵蓋軟件研發的全部生命周期，為軟件測試和產品研發提供一體化的解決方案，是一款十分優秀的國產開源測試管理工具。

2、是一種預測系統行為和性能的工業標準級負載測試工具。通過模擬上千萬用戶實施并發負載及實時性能監測的方式來確認和查找問題，它能夠對整個企業架構進行測試。通過，企業能*限度地縮短測試時間，優化性能和加速應用系統的發布周期。它是一種適用于各種體系架構的自動負載測試工具，它能預測系統行為并優化系統性能。的測試對象是整個企業的系統，它通過模擬實際用戶的操作行為和實時性能監測，來幫助更快地查找和發現問題。

3、QTP是一個B/S系統的自動化功能測試的利器,軟件程序測試工具。Mercury的自動化功能測試軟件，可以覆蓋絕大多數的軟件開發技術，簡單高效，并具備測試用例可重用的特點。是一款先進的自動化測試解決方案，用于創建功能和回歸測試。它自動捕獲、驗證和重放用戶的交互行為。為每一個重要軟件應用和環境提供功能和回歸測試自動化的行業*解決方案。

4、Selenium是為正在蓬勃發展的web應用開發的一套完整的測試系統。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。它的主要功能包括：測試與瀏覽器的兼容性——測試你的應用程序是否能夠很好的在不同瀏覽器和操作系統上工作。測試系統功能——創建衰退測試檢驗軟件功能和用戶需求。支持自動錄制動作和自動生成。Selenium的核心基于JsUnit，完全由編寫，因此可運行于任何支持的瀏覽器上，包括IE、、Chrome、Safari等。

軟件測試一般都用到哪些工具

1、企業級自動化測試工具WinRunner，用于檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，能夠幫助測試人員對復雜的企業級應用的不同發布版進行測試，確保跨平臺的、復雜的企業級應用無故障發布及長期穩定運行。

2、工業標準級負載測試工具，是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施并發負載及實時性能監測的方式來確認和查找問題，能夠對整個企業架構進行測試。企業能*限度地縮短測試時間，優化性能和加速應用系統的發布周期。

3、功能測試工具Rational Robot，可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational 上，測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。

4、功能測試工具SilkTest，是Borland公司所提出軟件質量管理解決方案的套件之一。這個工具采用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，并分析功能錯誤。

5、全球測試管理系統，是基于Web的測試管理系統，可以在公司內部或外部進行全球范圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，極大地加速了測試過程。

擴展資料：

WinRunner可以通過Function Generator增加測試的功能。使用Function Generator可以從目錄列表中選擇一個功能增加到測試中以提高測試能力。

針對相當數量的企業應用里非標準對象，WinRunner提供了Virtual Object Wizard來識別以前未知的對象。使用Virtual Object Wizard，可以選擇未知對象的類型，設定標識和命名。在錄制使用該對象的測試時，WinRunner會自動對應它的名字，從而提高測試腳本的可讀性和測試質量。

常用的軟件測試工具有哪些?

在測試工作中，需要接觸到各種類型的測試工具。一般來說，有以下一些類型的工具：
測試管理工具：可以幫助完成測試計劃、跟蹤測試運行結果等的工具。這類工具還包括有助于需求、設計、編碼測試及缺陷跟蹤的工具；
靜態分析工具：分析代碼而不執行代碼。這種工具檢測某些缺陷比用其它方法更有效，開銷也更小。這種工具一般可以度量代碼的各種指標，如McCabe測定復雜度，Logiscope度量代碼和規范的復合度等等；
覆蓋率工具：這種工具評估通過一系列測試后，軟件被執行的程度。這種工具大量的被應用于單元測試中，如、、Logiscope等；
動態分析工具：這種工具評估正在運行的系統。例如，檢查系統運行過程中的內存使用情況，是否有內存越界、內存泄露等等，這類工具有Purify、等；
測試執行工具：這類工具可使測試能夠自動化進行，并且各個層次（單元測試、集成測試、系統測試）的執行工具都有。例如系統測試階段有功能測試自動化工具，如Robot、Winrunner、SilkTest等；還有性能測試工具，如、等。
白盒測試工具主要有：
內存資源泄漏檢查：Numega中的,Rational的Purify
代碼覆蓋率檢查：Numega中的,Rational的，Telelogic公司的logiscope,Macabe公司的Macabe
代碼性能檢查：Numega中的truetime,Rational的Quantify
代碼靜態度量分析質量檢查工具：logiscope和Macabe
黑盒測試工具主要有：
客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的robot
服務器端壓力性能測試：MI公司的winload,compuware的qaload,Rational的SQAload等等
Web測試工具：MI公司的Astra系列，rsw公司的e-testsuite
測試管理工具：rational的,compuware的等
缺陷跟蹤工具：，Testtrack
單元測試工具：
測試框架：++cppunit

黑盒測試需要掌握哪些工具，技能？

軟件測試要求知識面廣，但不一定精，編程語言的話，*是什么都學過，至少幾種主流的程序語言要學過，如java、.net、C++。還有會一些腳本語言vba（vb）、sql、 C等。
網絡的話：TCP/IP協議，局域網廣域網相關知識等
數據庫：當前主流的mysql、ms-sql、oracle
常用測試工具：HP的三劍客首當其沖了：QTP（自動化功能測試工具）、（自動化性能測試工具）、QC（TD前身，測試管理追蹤工具）。當然這些都是收費產品。網上有破解版的可供學習。（一套）
開源免費的測試工具：QTP（自動化功能測試工具，破解版的可以滿足絕大部分測試需求）、jmeter（自動化性能測試工具）、bugzilla（測試管理追蹤工具）。

軟件測試中什么是白盒測試 黑盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。
這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。
采用什么方法對軟件進行測試呢？常用的軟件測試方法有兩大類：靜態測試方法和動態測試方法。其中軟件的靜態測試不要求在計算機上實際執行所測程序，主要以一些人工的模擬技術對軟件進行分析和測試；而軟件的動態測試是通過輸入一組預先按照一定的測試準則構造的實例數據來動態運行程序，而達到發現程序錯誤的過程。
白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。
白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
六種覆蓋標準：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋發現錯誤的能力呈由弱至強的變化。語句覆蓋每條語句至少執行一次。判定覆蓋每個判定的每個分支至少執行一次。條件覆蓋每個判定的每個條件應取到各種可能的值。判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。路徑覆蓋使程序中每一條可能的路徑至少執行一次。
"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。*，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
如何挑選白盒測試工具
白盒測試目前主要用在具有高可靠性要求的軟件領域，例如：軍工軟件、航天航空軟件、工業控制軟件等等。白盒測試工具在選購時應當主要是對開發語言的支持、代碼覆蓋的深度、嵌入式軟件的測試、測試的可視化等。
對開發語言的支持：白盒測試工具是對源代碼進行的測試，測試的主要內容包括詞法分析與語法分析、靜態錯誤分析、動態檢測等。但是對于不同的開發語言，測試工具實現的方式和內容差別是較大的。目前測試工具主要支持的開發語言包括：標準C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
代碼的覆蓋深度：從覆蓋源程序語句的詳盡程度分析，邏輯覆蓋標準包括以下不同的覆蓋標準：語句覆蓋、判定覆蓋、條件覆蓋、條件判定組合覆蓋、多條件覆蓋和修正判定條件覆蓋。
·語句覆蓋 為了暴露程序中的錯誤，程序中的每條語句至少應該執行一次。因此語句覆蓋（Statement Coverage）的含義是：選擇足夠多的測試數據，使被測程序中每條語句至少執行一次。語句覆蓋是很弱的邏輯覆蓋。
·判定覆蓋 比語句覆蓋稍強的覆蓋標準是判定覆蓋（Decision Coverage）。判定覆蓋的含義是：設計足夠的測試用例，使得程序中的每個判定至少都獲得一次“真值”或“假值”，或者說使得程序中的每一個取“真”分支和取“假”分支至少經歷一次，因此判定覆蓋又稱為分支覆蓋。
·條件覆蓋 在設計程序中，一個判定語句是由多個條件組合而成的復合判定。為了更徹底地實現邏輯覆蓋，可以采用條件覆蓋（Condition Coverage）的標準。條件覆蓋的含義是：構造一組測試用例，使得每一判定語句中每個邏輯條件的可能值至少滿足一次。
·多條件覆蓋 多條件覆蓋也稱條件組合覆蓋，它的含義是：設計足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
·修正條件判定覆蓋 修正條件判定覆蓋是由歐美的航空/航天制造廠商和使用單位聯合制定的“航空運輸和裝備系統軟件認證標準”，目前在國外的國防、航空航天領域應用廣泛。這個覆蓋度量需要足夠的測試用例來確定各個條件能夠影響到包含的判定的結果。它要求滿足兩個條件：首先，每一個程序模塊的入口和出口點都要考慮至少要被調用一次，每個程序的判定到所有可能的結果值要至少轉換一次；其次，程序的判定被分解為通過邏輯操作符（and、or）連接的布爾條件，每個條件對于判定的結果值是獨立的。
不同的測試工具對于代碼的覆蓋能力也是不同的，通常能夠支持修正條件判定覆蓋的測試工具價格是極其昂貴的。
嵌入式軟件的測試：對于嵌入式軟件的測試，我們還需要一方面進一步考慮測試工具對于嵌入式操作系統的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等；另一方面還需要考慮測試工具對于硬件平臺的支持能力，包括是否支持所有64/32/16位CPU 和 MCU，是否可以支持 PCI/VME/CPCI 總線。
測試的可視化：白盒測試是工作量巨大并且枯燥的工作，可視化的設計對于測試來說是十分重要的。在選購白盒測試工具時，應當考慮該款測試工具的可視化是否良好，例如：測試過程中是否可以顯示覆蓋率的函數分布圖和上升趨勢圖，是否使用不同的顏色區分已執行和未執行的代碼段顯示分配內存情況實時圖表等，這些對于測試效率和測試質量的提高是具有很大的作用的。
白盒測試之基本路徑測試法
白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。
其中運用最為廣泛的是基本路徑測試法。
基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。
設計出的測試用例要保證在測試中程序的每個可執行語句至少執行一次。
在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下4個步驟和一個工具方法：
1. 程序的控制流圖：描述程序控制流的一種圖示方法。
2. 程序圈復雜度：McCabe復雜性度量。從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。
3. 導出測試用例：根據圈復雜度和程序結構設計用例數據輸入和預期結果。
4. 準備測試用例：確保基本路徑集中的每一條路徑的執行。
工具方法：
圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。
程序的控制流圖：描述程序控制流的一種圖示方法。
圓圈稱為控制流圖的一個結點，表示一個或多個無分支的語句或源程序語句
流圖只有二種圖形符號：
圖中的每一個圓稱為流圖的結點，代表一條或多條語句。
流圖中的箭頭稱為邊或連接，代表控制流
任何過程設計都要被翻譯成控制流圖。
如何根據程序流程圖畫出控制流程圖?
在將程序流程圖簡化成控制流圖時，應注意：
在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
邊和結點圈定的區域叫做區域，當對區域計數時，圖形外的區域也應記為一個區域。
基本路徑測試法的步驟：
*步：畫出控制流圖
流程圖用來描述程序控制結構。可將流程圖映射到一個相應的流圖(假設流程圖的菱形決定框中不包含復合條件)。在流圖中，每一個圓，稱為流圖的結點，代表一個或多個語句。一個處理方框序列和一個菱形決測框可被映射為一個結點，流圖中的箭頭，稱為邊或連接，代表控制流，類似于流程圖中的箭頭。一條邊必須終止于一個結點，即使該結點并不代表任何語句(例如：if-else-then結構)。由邊和結點限定的范圍稱為區域。計算區域時應包括圖外部的范圍。
第二步：計算圈復雜度
圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用于計算程序的基本的獨立路徑數目，為確保所有語句至少執行一次的測試數量的上界。獨立路徑必須包含一條在定義之前不曾用到的邊。
有以下三種方法計算圈復雜度：
流圖中區域的數量對應于環型的復雜性;
給定流圖G的圈復雜度V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量;
給定流圖G的圈復雜度V(G)，定義為V(G)=P+1，P是流圖G中判定結點的數量。
第三步：導出測試用例 根據上面的計算方法，可得出四個獨立的路徑。(一條獨立路徑是指，和其他的獨立路徑相比，至少引入一個新處理語句或一個新判斷的程序通路。V(G)值正好等于該程序的獨立路徑的條數。)
路徑1：4-14
路徑2：4-6-7-14
路徑3：4-6-8-10-13-4-14
路徑4：4-6-8-11-13-4-14
根據上面的獨立路徑，去設計輸入數據，使程序分別執行到上面四條路徑。
白盒測試三步法
1） 根據代碼的功能，人工設計測試用例進行基本功能測試；
2） 統計白盒覆蓋率，為未覆蓋的白盒單位設計測試用例，實現完整的白盒覆蓋，比較理想的覆蓋率是實現*語句、條件、分支、路徑覆蓋；
3） 自動生成大量的測試用例，捕捉"程序員未處理某些特殊輸入"形成的錯誤。

第1步的測試用例通常是現成的，因為詳細設計文檔會規定程序的基本功能，沒有文檔的，程序員在編程時也要想清楚程序的功能，這些基本功能就是基本測試用例；
第2步是在第1步的基礎上，檢查未覆蓋的白盒單位，由于未覆蓋的邏輯單位通常對應未測試的等價類，因此第2步可以找出第1步所遺漏的測試用例；
第3步用自動動態測試彌補第2步的固有缺陷。
"三步法"盡量避免重復工作，白盒方法和黑盒方法相結合，人工方法和自動方法相補充，如果第2步的覆蓋率比較理想，那么基本上可以保證找出所有等價類。在開發過程允許的限度內，"三步法"已接近極限，當得起"徹底測試"四個字。
黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試地，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關系出發進行測試的。很明顯，如果外部特性本身有問題或規格說明的規定有誤，用墨盒測試方法是發現不了的。
黑盒測試法注重于測試軟件的功能需求，主要試圖發現下列幾類錯誤。
功能不正確或遺漏；
界面錯誤；
數據庫訪問錯誤；
性能錯誤；
初始化和終止錯誤等。
從理論上講，黑盒測試只有采用窮舉輸入測試，把所有可能的輸入都作為測試情況考慮，才能查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但可能的輸入進行測試。這樣看來，完全測試是不可能的，所以我們要進行有針對性的測試，通過制定測試案例指導測試的實施，保證軟件測試有組織、按步驟，以及有計劃地進行。黑盒測試行為必須能夠加以量化，才能真正保證軟件質量，而測試用例就是將測試行為具體量化的方法之一。具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。
等價類劃分的辦法是把程序的輸入域劃分成若干部分（子集），然后從每個部分中選取少數代表性數據作為測試用例。每一類的代表性數據在測試中的作用等價于這一類中的其他值。該方法是一種重要的,常用的黑盒測試用例設計方法。
1) 劃分等價類: 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的，并合理地假定：測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
有效等價類:是指對于程序的規格說明來說是合理的,有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能.
無效等價類:與有效等價類的定義恰巧相反.
設計測試用例時,要同時考慮這兩種等價類.因為,軟件不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性.
2）劃分等價類的方法:下面給出六條確定等價類的原則.
①在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.
②在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下,可確立一個有效等價類和一個無效等價類.
③在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.
④在規定了輸入數據的一組值（假定n個）,并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.
⑤在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）.
⑥在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.
3）設計測試用例:在確立了等價類后,可建立等價類表,列出所有劃分出的等價類:
輸入條件 有效等價類 無效等價類
... ... ...
... ... ...
然后從劃分出的等價類中按以下三個原則設計測試用例:
①為每一個等價類規定一個*的編號.
②設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步.直到所有的有效等價類都被覆蓋為止.
③設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步.直到所有的無效等價類都被覆蓋為止.
邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類劃分方法的補充.
（1）邊界值分析方法的考慮:
長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.
（2）基于邊界值分析方法選擇測試用例的原則:
1）如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據.
2）如果輸入條件規定了值的個數,則用*個數,最小個數,比最小個數少一,比*個數多一的數作為測試數據.
3）根據規格說明的每個輸出條件,使用前面的原則1）.
4）根據規格說明的每個輸出條件,應用前面的原則2）.
5）如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的*個元素和*一個元素作為測試用例.
6）如果程序中使用了一個內部數據結構,則應當選擇這個內部數據結構的邊界上的值作為測試用例.
7）分析規格說明,找出其它可能的邊界條件.
錯誤推測法是基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
因果圖法：
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）.
因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.
利用因果圖生成測試用例的基本步驟:
(1) 分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 并給每個原因和結果賦予一個標識符.
(2) 分析軟件規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.
(3) 由于語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.
(4) 把因果圖轉換為判定表.
(5) 把判定表的每一列拿出來作為依據,設計測試用例.
從因果圖生成的測試用例（局部,組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線性地增加.
前面因果圖方法中已經用到了判定表.判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期,判定表就已被當作編寫程序的輔助工具了.由于它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.
判定表通常由四個部分組成.
條件樁（Condition Stub）:列出了問題得所有條件.通常認為列出得條件的次序無關緊要.
動作樁（Action Stub）:列出了問題規定可能采取的操作.這些操作的排列順序沒有約束.
條件項（Condition Entry）:列出針對它左列條件的取值.在所有可能情況下的真假值.
動作項（Action Entry）:列出在條件項的各種取值情況下應該采取的動作.
規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.
判定表的建立步驟:（根據軟件規格說明）
①確定規則的個數.假如有n個條件.每個條件有兩個取值（0,1）,故有 種規則.
②列出所有的條件樁和動作樁.
③填入條件項.
④填入動作項.等到初始判定表.
⑤簡化.合并相似規則（相同動作）.
B. Beizer 指出了適合使用判定表設計測試用例的條件:
①規格說明以判定表形式給出,或很容易轉換成判定表.
②條件的排列順序不會也不影響執行哪些操作.
③規則的排列順序不會也不影響執行哪些操作.
④每當某一規則的條件已經滿足,并確定要執行的操作后,不必檢驗別的規則.
⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.
正交試驗設計法，就是使用已經造好了的正交表格來安排試驗并進行數據分析的一種方法，目的是用最少的測試用例達到*的測試覆蓋率。
黑盒測試的優點
1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了
2. 設計完測試例之后，下來的工作就是爽了，當然更苦悶的是確定crash原因
黑盒測試的缺點
1. 結果取決于測試例的設計，測試例的設計部分來勢來源于經驗，OUSPG的東西很值得借鑒
2. 沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作
3. 就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。
黑盒測試（功能測試）工具的選擇
那么，如何高效地完成功能測試？選擇一款合適的功能測試工具并培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不采用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。
目前，用于功能測試的工具軟件有很多，針對不同架構軟件的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。
WinRunner是一種用于檢驗應用程序能否如期運行的企業級軟件功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟件功能缺陷，從而確保那些跨越了多個功能點和數據庫的應用程序在發布時盡量不出現功能性故障。
WinRunner的特點在于: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用; 它針對于大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基于Windows平臺的應用程序實施功能測試而言帶來了極大的便利。
WinRunner的工作流程大致可以分為以下六個步驟:
1．識別應用程序的GUI
在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別后，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其*區別是后者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、加載，推薦初學者選用這種模式。但是，這種模式不易于描述對象的改變，其效率比較低，因此對于一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。
2．建立測試腳本
在建立測試腳本時，一般先進行錄制，然后在錄制形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄制腳本有兩種模式: Context Sensitive和Analog，選擇依據主要在于是否對鼠標軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。
只要看看現代軟件的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。
3．對測試腳本除錯(debug)
在WinRunner中有專門一個Debug Toolbar用于測試腳本除錯。可以使用step、pause、等來控制和跟蹤測試腳本和查看各種變量值。
4．在新版應用程序執行測試腳本
當應用程序有新版本發布時，我們會對應用程序的各種功能包括新增功能進行測試，這時當然不可能再來重新錄制和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作。可以使用一個call命令來加載各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。
5．分析測試結果
分析測試結果在整個測試過程中最重要，通過分析可以發現應用程序的各種功能性缺陷。當運行完某個測試腳本后，會產生一個測試報告，從這個測試報告中我們能發現應用程序的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。
6．回報缺陷（defect）
在分析完測試報告后，按照測試流程要回報應用程序的各種缺陷，然后將這些缺陷發給指定人，以便進行修改和維護。
常用的功能測試方法
功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。

*的軟件測試方法有哪些?

隨著軟件測試技術的不斷發展，測試方法也越來越多樣化，針對性更強；選擇合適的軟件測試方法可以讓我們事半功倍。以下是一些常用的軟件測試方法：
β測試_Beta測試
β測試，英文是Beta testing。又稱Beta測試，用戶驗收測試（UAT）。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。
當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。
α測試_Alpha測試
α測試，英文是Alpha testing。又稱Alpha測試.
Alpha測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由該系統的程序員或測試員完成。
在系統開發接近完成時對應用系統的測試;測試后，仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。
可移植性測試
可移植性測試，英文是 testing。又稱兼容性測試。
可移植性測試是指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。
用戶界面測試-UI測試
用戶界面測試，英文是User interface testing。又稱UI測試。
用戶界面，英文是User interface。是指軟件中的可見外觀及其底層與用戶交互的部分（菜單、對話框、窗口和其它控件）。
用戶界面測試是指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操作性測試。
用戶界面測試用戶分析軟件用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息 (Menu 和Help content)等方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息內容和字體大小，工具欄位置/圖標等等。
冒煙測試
冒煙測試，英文是Smoke testing。
冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路板功基本功能檢查。任何新電路板焊好后，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。
冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行后續的正式測試工作。冒煙測試的執行者是版本編譯人員。
隨機測試
隨機測試，英文是Ad hoc testing。
隨機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。
隨機測試主要是對被測軟件的一些重要功能進行復測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、并發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合回歸測試 ( testing)一起進行。
本地化測試
本地化測試，英文是 testing。
本地化就是將軟件版本語言進行更改，比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目標區域設置的軟件本地化質量。本地化測試的環境是在本地化的操作系統上安裝本地化的軟件。從測試方法上可以分為基本功能測試，安裝/卸載測試，當地區域的軟硬件兼容性測試。測試的內容主要包括軟件本地化后的界面布局和軟件翻譯的語言質量，包含軟件、文檔和聯機幫助等部分。
本地化能力測試
本地化能力測試，英文是 testing。
本地化能力測試是指不需要重新設計或修改代碼，將程序的用戶界面翻譯成任何目標語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力側是通常在軟件的偽本地化版本上進行。
本地化能力測試中發現的典型錯誤包括：字符的硬編碼（即軟件中需要本地化的字符寫在了代碼內部），對需要本地化的字符長度設置了固定值，在軟件運行時以控件位置定位，圖標和位圖中包含了需要本地化的文本，軟件的用戶界面與文檔術語不一致等。
國際化測試
國際化測試，英文是 testing。又稱國際化支持測試。
國際化測試的目的是測試軟件的國際化支持能力，發現軟件的國際化的潛在問題，保證軟件在世界不同區域都能正常運行。國際化測試使用每種可能的國際輸入類型，針對任何區域性或區域設置檢查產品的功能是否正常，軟件國際化測試的重點在于執行國際字符串的輸入/輸出功能。國際化測試數據必須包含東亞語言、德語、復雜腳本字符和英語（可選）的混合字符。
國際化支持測試是指驗證軟件程序在不同*或區域的平臺上也能夠如預期的那樣運行，而且還可以按照原設計尊重和支持使用當地常用的日期，字體，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如，日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執行國際化支持測試的測試人員往往需要基本上了解這些*或地區的語言要求和期望行為是什么。
安裝測試
安裝測試，英文是 testing。
安裝測試是確保軟件在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創建權限等場景。核實軟件在安裝后可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝，安裝代碼提供安裝一些程序能夠運行的基礎數據。
白盒測試-結構測試-邏輯驅動測試
白盒測試，英文是White Box Testing。又稱結構測試或者邏輯驅動測試。
白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動態測試時，需要測試軟件產品的內部結構和處理過程，不需測試軟件產品的功能。
白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
白盒測試是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。
白盒測試常用工具有：Jtest、VcSmith、Jcontract、C++ Test、、logiscope。
黑盒測試-功能測試-數據驅動測試
黑盒測試，英文是Black Box Testing。又稱功能測試或者數據驅動測試。
黑盒測試是根據軟件的規格對軟件進行的測試，這類測試不考慮軟件內部的運作原理，因此軟件對用戶來說就像一個黑盒子。
軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結果來發現軟件存在的缺陷，而不關心程序具體如何實現的一種軟件測試方法。
黑盒測試常用工具有：、winrunner、。
自動化測試
自動化測試，英文是Automated Testing。
使用自動化測試工具來進行測試，這類測試一般不需要人干預，通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本，然后執行這個測試腳本來實現測試過程的自動化。國內領先的自動化測試服務提供商是澤眾軟件。自動化測試工具有和TAR等。
回歸測試
回歸測試，英文是 testing。
回歸測試是指在發生修改之后重新測試先前的測試以保證修改的正確性。理論上，軟件產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新軟件版本上再次出現。
根據修復好了的缺陷再重新進行測試。回歸測試的目的在于驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的，特別當臨近產品發布日期時。因為為了修正某缺陷時必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化測試。
驗收測試
驗收測試，英文是 testing。
驗收測試是指系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。
驗收測試一般有三種策略：正式驗收、非正式驗收或Alpha 測試、Beta 測試。
動態測試
動態測試，英文是Moment Testing。
動態測試是指通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。
根據動態測試在軟件開發過程中所處的階段和作用，動態測試可分為如下幾個步驟：
1、單元測試
2、集成測試
3、系統測試
4、驗收測試
5、回歸測試
探索測試
探索測試，英文是 Testing。
探索測試是指通常用于沒有產品說明書的測試，這需要把軟件當作產品說明書來看待，分步驟逐項探索軟件特性，記錄軟件執行情況，詳細描述功能，綜合利用靜態和動態技術來進行測試。探索測試人員只靠智能、洞察力和經驗來對bug的位置進行判斷,所以探索測試又被稱為自由形式測試。
單元測試
單元測試，英文是Unit Testing。
單元測試是最微小規模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因為它需要知道內部程序設計和編碼的細節知識。這個工作不容易做好，除非應用系統有一個設計很好的體系結構; 還可能需要開發測試驅動器模塊或測試套具。
集成測試
集成測試，英文是 Testing。
集成測試是指一個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試尤其與客戶服務器和分布式系統有關。一般集成測試以前，單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。*，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元，并確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法將可能發生的情況數量減少到更簡單的分析級別
系統測試
系統測試，英文是System Testing。
系統測試是基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。
系統測試的對象不僅僅包括需要測試的產品系統的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等。因此，必須將系統中的軟件與各種依賴的資源結合起來，在系統實際運行環境下來進行測試。
端到端測試
端到端測試，英文是End to End Testing。
端到端測試類似于系統測試，測試級的“宏大”的端點，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。例如與數據庫對話，用網絡通訊，或與外部硬件、應用系統或適當的系統對話。端到端架構測試包含所有訪問點的功能測試及性能測試。端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的優點的測試方法。
健全測試
健全測試，英文是Sanity testing。
健全測試是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執行下一步大的測試能力。例如，如果一個新版軟件每5分鐘與系統沖突，使系統陷于泥潭，說明該軟件不夠“健全”，目前不具備進一步測試的條件。
衰竭測試
衰竭測試，英文是Failure Testing。
衰竭測試是指軟件或環境的修復或更正后的“再測試”。可能很難確定需要多少遍再次測試。尤其在接近開發周期結束時。自動測試工具對這類測試尤其有用。
接受測試
接受測試，英文是Accept Testing。
接受測試是基于客戶或最終用戶的規格書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。一般從功能、用戶界面、性能、業務關聯性進行測試。
負載測試
負載測試，英文是Load testing。
負載測試是測試一個應用在重負荷下的表現。例如測試一個 Web 站點在大量的負荷下，何時系統的響應會退化或失敗，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。
負載測試的目標是確定并確保系統在超出*預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。
強迫測試
強迫測試，英文是Force Testing。
強迫測試是在交替進行負荷和性能測試時常用的術語。也用于描述象在異乎尋常的重載下的系統功能測試之類的測試，如某個動作或輸入大量的重復，大量數據的輸入，對一個數據庫系統大量的復雜查詢等。
壓力測試
壓力測試，英文是Stress Testing。和負載測試差不多。
壓力測試是一種基本的質量保證行為，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規條件下運行手動或自動測試，而是在計算機數量較少或系統資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內部內存、CPU 可用性、磁盤空間和網絡帶寬等。一般用并發來做壓力測試。
性能測試
性能測試，英文是 Testing。
性能測試是在交替進行負荷和強迫測試時常用的術語。理想的“性能測試”(和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。
通常驗證軟件的性能在正常環境和系統條件下重復使用是否還能滿足性能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會流失(memory leak)。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。
可用性測試
可用性測試，英文是Practical Usability Testing。
可用性測試是對“用戶友好性”的測試。顯然這是主觀的，且將取決于目標最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其他一些技術都可使用。程序員和測試員通常都不宜作可用性測試員。
卸載測試
卸載測試，英文是Uninstall Testing。
卸載測試是對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸載，卸載是否干凈，對系統有無更改，在系統中的殘留與后來的生成文件如何處理等。還有原來更改的系統值是否修改回去
恢復測試
恢復測試，英文是Recovery testing。
恢復測試是測試一個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬件損壞或其他災難性問題。恢復測試指通過人為的讓軟件（或者硬件）出現故障來檢測系統是否能正確的恢復，通常關注恢復所需的時間以及恢復的程度。
恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統。恢復測試首先要采用各種辦法強迫系統失敗，然后驗證系統是否能盡快恢復。對于自動恢復需驗證重新初始化（）、檢查點( )、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性；對于人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。
安全測試
安全測試，英文是Security Testing。
安全測試是測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復雜的測試技術。安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：
①想方設法截取或破譯口令；
②專門定做軟件破壞系統的保護機制；
③故意導致系統失敗，企圖趁恢復之機非法進入；
④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
兼容性測試
兼容測試，英文是 Testing。
兼容測試是測試軟件在一個特定的硬件/軟件/操作系統/網絡等環境下的性能如何。向上兼容向下兼容，軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。
比較測試
比較測試，英文是Compare Testing。
比較測試是指與競爭伙伴的產品的比較測試，如軟件的弱點、優點或實力。來取長補短，以增強產品的競爭力。
可接受性測試
可接受性測試，英文是 Testing。
可接受性測試是在把測試的版本交付測試*大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試*大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩定。必須滿足一些*要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應該阻攔測試*花時間在該測試版本上測試。同時還要找到造成該版本不穩定的主要缺陷并督促盡快加以修正
邊界條件測試
邊界條件測試，英文是Boudary Testing。又稱邊界值測試。
一種黑盒測試方法，適度等價類分析方法的一種補充,由長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
邊界條件測試是環繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理*值，最小值或者所設計軟件能夠處理的最長的字符串等等。
強力測試
強力測試，英文是 Testing。
強力測試通常驗證軟件的性能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟件的性能在各種極端環境和系統條件下的承受能力。比如，在*的硬盤驅動器空間或系統記憶容量條件下，驗證程序重復執行打開和保存一個巨大的文件1000次后也不會崩潰或死機。
裝配/安裝/配置測試
裝配/安裝/配置測試是驗證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺上，和不同方式安裝的軟件都能夠如預期的那樣正確運行。比如，把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上，再驗證所有功能都正常運行。
靜態測試
靜態測試，英文是Static Testing。
靜態測試指測試不運行的部分，例如測試產品說明書，對此進行檢查和審閱.。靜態方法是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結構、過程、接口等來檢查程序的正確性。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態測試結果可用于進一步的查錯，并為測試用例選取提供指導。
靜態測試常用工具有：Logiscope、PRQA；
隱藏數據測試
隱藏數據測試在軟件驗收和確認階段是十分必要和重要的一部分。程序的質量不僅僅通過用戶界面的可視化數據來驗證，而且必須包括遍歷系統的所有數據。
假設一個應用程序要求用戶兩條信息-----用戶名和密碼來創建帳戶。這個用戶輸入這兩條數據后保存。*，一個確認窗口將通過數據庫中找到這條數據來顯示用戶名和密碼給用戶。為了驗證所有的數據保存是否正確，一個QA測試人員會在這個確認窗口簡單的查看下用戶名和密碼。如果他們成功了？假設數據庫記錄了第三條信息----創建日期，它可能不會出現在確認窗口，而只在存檔中才出現。如果創建日期保留的不正確，而QA測試人員只驗證屏幕上的數據，那么這個問題就不可能被發現。創建日期可能就是一個bug，由于一個用戶帳戶保存了一個錯誤的日期到數據庫中，這個問題也不可能會被引起注意，因為它被用戶界面所隱藏。這只是一個簡單的例子，但是它卻演化出了一點：隱藏數據測試的重要性。
等價劃分測試
等價劃分測試的英文是 partition testing。
等價劃分測試是根據等價類設計測試用例的一種技術。是黑盒測試的典型方法之一，通過把被測試程序所有可能的輸入數據域劃分成若干部分。從每一部分中選取少數有代表性的數據作為測試用例，可有效減少測試次數，極大提高軟件測試效率，縮短軟件開發周期．等價類劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的數據得到比較好的測試效果。有效等價類盒無效等價類。有效等價類中的數據代表的是一組符合需求文檔的正確的有意義數據。無效等價類則正相反。
判定表
判定表的英文是decision table，是指一個表格，用于顯示條件和條件導致動作的集合。
定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
判定表的優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合于處理這類問題
深度測試
深度測試的英文Depth test ，是指執行一個產品的一個特性的所有細節，但不測試所有特性。
當比較函數返回真的時候才顯示出效果來。必須啟用“#深度測試”，才能執行測試。不使用的時候需要關閉。
基于設計的測試
基于設計的測試的英文是design-based testing，是根據軟件的構架或詳細設計引出測試用例的一種方法。
一種基于設計模型的測試方法(Model Based TestIng System,MATIS).該方法利用用戶界面自動生成方法,把設計模型中的類屬性定義和實現中的控件屬性組織在一起,構建描述界面的邏輯對照表,輔助測試腳本引擎執行自動測試腳本.借助設計模型中擴展的類定義,MATIS方法可以自動生成測試用例和測試數據。
文檔測試

軟件測試的方法有哪些？

測試的有2種方法

答：黑盒測試和白盒測試

黑盒：這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。

黑盒測試又叫做功能測試或數據驅動測試。

白盒：此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。

通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。

軟件測試按過程分為三個步驟

答：單元測試：單元測試又稱模塊測試，是針對軟件設計的最小單位—程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。

單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。

集成測試：在運行（可能是不完整）的應用中保證軟件單元被結合后能正常操作的測試執行的階段

系統測試：當應用作為整體運行時的測試執行階段

軟件測試的步驟是什么？

1)測試過程按4個步驟進行，即單元測試（）、集成測試（）、確認測試（）和系統測試（）及發版測試。

2)開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。

3)集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。

4)確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。

應該考慮進行如何測試的測試方法

黑盒測試()——不考慮內部設計和代碼，根據需求和功能進行測試。

白盒測試()——根據應用軟件的代碼的內部邏輯，按照代碼的語句、分支、路徑和條件進行測試。

功能測試（）——對一個應用軟件的功能模塊進行黑盒測試。這種測試應當由測試人員進行。但這并不意味著程序員在推出軟件之前不進行代碼檢查。（這一原則適用于所有的測試階段。）

系統測試——針對全部需求說明進行黑盒測試，包括系統中所有的部件。

回歸測試()——每當軟件經過了整理、修改、或者其環境發生變化，都重復進行測試。很難說需要進行多少次回歸測試，特別是是到了開發周期的*階段。進行此種測試，特別適于使用自動測試工具。

負荷試驗()——在大負荷條件下對應用軟件進行測試。例如測試一個網站在不同負荷情況下的狀況，以確定在什么情況下系統響應速度下降或是出現故障。

壓力測試()——經常可以與“負荷測試”或“性能測試”相互代替。這種測試是用來檢查系統在下列條件下的情況：在非正常的巨大負荷下、某些動作和輸入大量重復、輸入大數、對數據庫進行非常復雜的查詢，等等。

性能測試()——經常可以與“壓力測試”或“負荷測試”相互代替。理想的“性能測試”(也包括其他任何類型的測試)都應在質量保障和測試計劃的文檔終予以規定。

可用性測試()——是專為“對用戶友好”的特性進行測試。這是一種主觀的感覺，取決于最終用戶或顧客。可以進行用戶會見、檢查、對用戶會議錄像、或者使用其他技術。程序員和測試人員通常不參加可用性測試。

安裝/卸載測試(install/)——對安裝/卸載進行測試(包括全部、部分、升級操作)。

安全測試()——測試系統在應付非授權的內部/外部訪問、故意的損壞時的防護情況。這需要精密復雜的測試技術。

兼容性測試()——測試在特殊的硬件/軟件/操作系統/網絡環境下的軟件表現。

α測試()——在開發一個應用軟件即將完成時所進行的測試。此時還允許有較小的設計修改。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。

β測試()——當開發和測試已基本完成，需要在正式發行之前*尋找毛病而進行的測試。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。