模板
教程
環境
性能
功能
管理
軟件測試術語解析
一.從測試設計的方法來看，我們知道有兩類方法： Black box ( 黑箱 ) White box ( 白箱 ) 二. 功能測試 在下表所列的測試中，測試的范圍有小到大，測試者也由內到外， 從程序開發人員（單元測試）到 測試人員 ，到一般用戶（ Alpha/Beta 測試）。 測試名稱
一.從測試設計的方法來看，我們知道有兩類方法：
Black box (黑箱)
White box (白箱)
二.功能測試
|
測試名稱 |
測試內容 |
|
單元測試 – 在最低的功能/參數上驗證程序的正確性 | |
|
Functional Test |
功能測試 – 驗證模塊的功能 |
|
Integration Test |
集成測試 – 驗證幾個互相有依賴關系的模塊的功能 |
|
Scenario Test |
場景測試 – 驗證幾個模塊是否能夠完成一個用戶場景 |
|
System Test |
系統測試 – 對于整個系統功能的測試 |
|
Alpha/Beta Test |
三.非功能測試
|
測試名稱 |
測試內容 |
|
Stress/load test |
測試軟件在負載情況下能否正常工作 |
|
Performance test |
測試軟件的效能 |
|
Aclearcase/" target="_blank" >ccessibility test |
測試軟件輔助功能測試 – 測試軟件是否向殘疾用戶提供足夠的輔助功能 |
|
Localization/Globalization Test |
|
|
Compatibility Test |
|
|
Configuration Test |
配置測試 – 測試軟件在各種配置下能否正常工作 |
|
Usability Test |
可用性測試 – 測試軟件是否好用 |
|
Security Test |
軟件安全性測試 |
四.Ad hoc Test, Exploratory Test “探索式”的測試
“ad hoc”測試的測試流程是不可重復的，因為它的測試都是“特定”測試，沒法重復。由于這一原因，“ad hoc”測試不能自動化，就這一點而言，還達不到CMM的第二級 – 可重復級。
五.Regression Test回歸測試
Regress的英語定義是：return to a worse or less developed state. 是倒退，退化，退步的意思。
在軟件工程中，如果一個模塊或功能以前是正常工作的，但是在一個新的構建中出了問題，那這個模塊就出現了一個“退步”- regression, 從正常工作的穩定狀態退化到不正常工作的不穩定狀態。
在某某版本，某某模塊的某某測試用例是通過的！
如果測試人員發現了在新的構建版本某個測試用例失敗了，這就是一個“倒退”，在新版本上運行所有已通過的測試用例以驗證沒有“退化”情況發生，這個過程就是一個“regression test”. 如果這樣的“倒退”是由于模塊的功能發生了正常變化（由于設計變更的原因），那么測試用例的基準就要修改，以和新的功能保持一致。
針對一個bug fixed，我們也要作Regression Test，
a) 驗證新的代碼的確把缺陷改正了，
b) 同時要驗證新的代碼沒有把模塊的現有功能破壞，沒有regression。
回歸測試最好要自動化，因為對于每一個構建都要運行所有回歸測試，以保證盡早發現問題。
就是“退化測試嗎”?
六.Scenario/integration/System Test 場景/集成/系統測試
在軟件開發的一定階段，我們要對一個軟件進行全面和系統的測試，以保證軟件的各個模塊都能共同工作，在各方面都能滿足用戶的要求。
七.Performance Test 效能測試
八.Stress Test壓力測試
壓力測試嚴格地說不屬于效能測試。壓力測試要驗證的問題是：
軟件在超過設計負載的情況在仍能夠返回正常結果，而沒有產生嚴重的副作用或崩潰。
九.Alpha Test, Beta Test
在開發軟件的過程中，開發團隊希望讓用戶直接接觸到最新版本的軟件，以便從用戶那里收集反饋，這時開發團隊會在開發過程中讓特定的用戶（alpha/beta用戶）使用正處于開發過程中的版本，用戶會用特定的反饋渠道（email, BBS）與開發者討論使用中發現的問題。
......
補充一些測試類型名詞:
| 測試種類 | 解釋 |
| 黑盒測試 | 不基于內部設計和代碼的任何知識，而是基于需求和功能性。 |
| 白盒測試 | 基于一個應用代碼的內部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件。 |
| 單元測試 | 最微小規模的測試，以測試某個功能或代碼塊。典型的由程序而非測試員來做，因為它需要知道內部程序設計和編碼的細節知識。 |
| 累積綜合測試 | 當一個新功能增加后，對應用系統所做的連續測試。它要求應用系統的不同形態的功能能夠足夠獨立以便在全部系統完成前能分別工作，這種測試可由程序員或測試員來做。 |
| 集成測試 | 一個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試主要與客戶服務器和分布式系統有關。 |
| 功能測試 | 用于測試應用系統的功能需求的黑盒測試方法。 |
| 系統測試 | 基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。 |
| 端到端測試 | 類似于系統測試，測試級的“宏大”的端點，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。例如與數據庫對話，用網絡通訊，或與外部硬件、應用系統或適當的系統對話。 |
| 健全測試 | 典型的是指一個初始化的測試工作，以決定一個新軟件版本測試是否足以執行下一步的測試。 |
| 衰竭測試 | 軟件或環境的修復或更正后的“再測試”，可能很難確定需要多少遍再次測試，尤其在接近開發周期結束時，自動測試工具對這類測試尤其有用。 |
| 接受測試 | 基于客戶或最終用戶的規格書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。 |
| 負載測試 | 測試一個應用在重負荷下的表現，例如測試一個web站點在大量的負荷下，何時系統的響應會退化或失敗。 |
| 強迫測試 | 在交替進行負荷和性能測試時常用的術語。也用于描述象在異乎尋常的重載下的系統功能測試之類的測試，如某個動作或輸入大量的重復、大量數據的輸入，對一個數據庫系統大量的復雜的查詢。 |
| 性能測試 | 在交替進行負荷和強迫測試時常用的術語，應在需求文檔或質量保證、測試計劃中定義。 |
| 可用性測試 | 對“用戶友好性”測試，顯然這是主觀的，且將取決于目標最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其它一些技術都可使用。程序員和測試員通常都不宜作可用性測試。 |
| 安裝/卸載測試 | 對軟件的全部、部分或升級安裝或卸載處理過程的測試。 |
| 恢復測試 | 測試一個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬件損壞或其它災難性問題。 |
| 安全測試 | 測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復雜的測試技術。 |
| 兼容測試 | 測試軟件在一個特定的硬件/軟件/操作系統/網絡等環境下的性能如何。 |
| 比較測試 | 與競爭伙伴的產品的比較測試，如軟件的弱點、優點或實力。 |
| Alpha測試 | 在系統開發接近完成時對應用系統的測試；測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成，不能由程序或測試員完成。 |
| Beta測試 | 當開發和測試根本完成時所做的測試，最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程序員或測試員完成。 |
