軟體測試

軟體測試（英語：software testing），描述一種用來促進鑑定軟體的正確性、完整性、安全性和品質的過程。依照可計算理論（電腦科學的一個支派）一個簡單的數學證明推斷出下列結果：不可能完全解決所謂「當機」，指任意電腦程式是否會進入無窮迴圈，或者罷工並產生輸出問題。換句話說，軟體測試是一種實際輸出與預期輸出間的稽核或者比較過程。

軟體測試的經典定義是：在規定的條件下對程式進行操作，以發現程式錯誤，衡量軟體品質，並對其是否能滿足設計要求進行評估的過程。

軟體測試有許多方法，但對複雜的產品執行有效測試不僅僅是研究過程，更是創造並嚴格遵守某些呆板步驟的大事。測試的其中一個定義：為了評估而質疑產品的過程；這裡的「質疑」是測試員試著對產品做的事，而產品以測試者指令碼行為反應作為回答。雖然大部分測試的質疑過程不外乎回顧、檢查，然而「測試」這個詞意味著產品動態分析──讓產品流暢運行。程式品質可能，而且通常會，隨系統不同而有差異；不過某些公認特性是共通的：可靠性、穩定性、輕便性、易於維護、以及實用性。請參照至ISO標準ISO 9126有更詳盡的說明。

測試的進程

Alpha測試

Alpha測試通常是階段性的開發完成後所開始進行，一直持續到進入Beta測試階段前的階段。Alpha測試是一種驗證測試，在類比的環境中以類比的資料來執行。

在這個階段中，通常是在開發單位由開發人員與測試的測試人員，以類比或實際操作性的方式進行驗證測試。

Beta測試

在系統測試中通常先進行Alpha測試以驗證資訊系統符合使用者以及設計需求所期望的功能。當Alpha階段完成後，開發過程進入到Beta階段，由公眾參與的測試的階段。Beta測試可稱為確認測試，在一個真實的環境中以實際的資料來執行測試，以確認效能，系統執行有效率，系統復原與備份作業正常，透過測試讓資訊系統日後可以更趨完善。

封測與公測

封閉測試（Closed Beta，常簡作封測或CB）是軟體或服務等產品在開發完成後、將公開上市前的測試過程。相對於公開測試，封閉測試的主要用途是測試軟體的功能和檢查程式錯誤等等，因此通常只提供給少數人進行測試。有些公司會要求參與測試者簽署保密協定，以避免測試的產品提前外流。MMORPG的封測結束之後，遊戲公司常會將角色資料刪除，但也有少數不會刪除。

公開測試（Open Beta，常簡作公測或OB），一般常指軟體或服務等產品在正式上市前開放給不特定人試用，雖然原意是希望試用者能夠提報bug，但並不是把試用者當做真正的驗證人員。由於通常為免費性質，故常常能夠吸引到大批的試用者參與，可視為另一種行銷策略。另一方面也節省下測試人員的成本，和驗證穩定度（對於多人使用的頻寬及機器是否能負載，又稱壓力測試）的時間。

Gamma測試

Gamma測試是一個很少被提及的非正式測試階段，該測試階段對應的是對「存在缺陷」產品的測試。考慮到任何產品都可以被稱為「存在缺陷」的產品（測試只能發現產品中存在的問題，不能說明產品不存在問題），因此這個概念存在一定的不確定性。對Alpha和Beta測試常見的一個誤解是「Beta測試＝黑箱測試」。實際上，Alpha和Beta測試對應在軟體產品發布之前的Alpha和Beta階段，而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述，不應該將這兩部分概念混淆。

測試的方法

軟體測試一般分為黑箱測試和白盒測試。

黑箱測試

黑盒測試（black-box testing），也稱黑箱測試，是軟體測試方法，測試應用程式的功能，而不是其內部結構或運作。測試者不需具備應用程式的程式碼、內部結構和程式語言的專門知識。測試者只需知道什麼是系統應該做的事，即當鍵入一個特定的輸入，可得到一定的輸出。測試案例是依應用系統應該做的功能，照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。

此測試方法可適合大部分的軟體測試，例如整合測試（integration testing）以及系統測試（system testing）。

白盒測試

白盒測試（white-box testing，又稱透明盒測試glass box testing、結構測試structural testing等）是一個測試軟體的方法，測試應用程式的內部結構或運作，而不是測試應用程式的功能（即黑箱測試）。在白盒測試時，以程式語言的角度來設計測試案例。測試者輸入資料驗證資料流在程式中的流動路徑，並確定適當的輸出，類似測試電路中的節點。

白箱測試可以應用於單元測試（unit testing）、整合測試（integration testing）和系統的軟體測試流程，可測試在整合過程中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規範。

測試的類型

功能測試	按照測試軟體的各個功能劃分進行有條理的測試，在功能測試部分要保證測試項覆蓋所有功能和各種功能條件組合。
系統測試	對一個完整的軟體以使用者的角度來進行測試，系統測試和功能測試的區別是，系統測試利用的所有測試資料和測試的方法都要類比成和使用者的實際使用環境完全一樣，測試的軟體也是經過系統整合以後的完整軟體系統，而不是在功能測試階段利用的每個功能模組單獨編譯後生成的可執行程式。
極限值測試	對軟體在各種特殊條件，特殊環境下能否正常執行和軟體的效能進行測試。特殊條件一般指的是軟體規定的最大值，最小值，以及在超過最大、最小值條件下的測試。特殊環境一般指的是軟體執行的機器處於CPU高負荷，或是網路高負荷狀態下的測試，根據軟體的不同，特殊環境也有過不同。
效能測試	效能測試是對軟體效能的評價。簡單的說，軟體效能衡量的是軟體具有的回應及時度能力。因此，效能測試是採用測試手段對軟體的回應及時性進行評價的一種方式。根據軟體的不同類型，效能測試的側重點也不同。

壓力測試與效能測試

壓力測試常常和效能測試相混淆。它們主要不同點是，壓力測試要求進行超過規定效能指標的測試。例如一個網站設計容量是100個人同時點擊，壓力測試就要是採用120個同時點擊的條件測試。

壓力測試的通常判斷準則：

系統能夠恢復。
壓力過程中不要有明顯效能下降。

測試的階段

單元測試

單元測試是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性，測試的對象是軟體設計的最小單位：函式。
並且使用假資料測試不同狀況下功能使用情況，單元測試還有助於開發人員編寫更好的代碼。
單元測試是基於code的:可讀性、可測試性，它們與開發代碼的構建方式密切相關。因此開發人員最清楚哪些測試最有意義。

整合測試

整合測試也稱綜合測試、組裝測試、聯合測試，將程式模組採用適當的整合策略組裝起來，對系統的介面及整合後的功能進行正確性檢測的測試工作。其主要目的是檢查軟體單位之間的介面是否正確，整合測試的對象是已經經過單元測試的模組。

系統測試

系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、資料處理&業務資料處理）方面測試。

回歸測試

回歸測試(regression test)指在軟體維護階段，為了檢測代碼修改而引入的錯誤所進行的測試活動。回歸測試是軟體維護階段的重要工作，有研究表明，回歸測試帶來的耗費占軟體生命周期的1/3總費用以上。

與普通的測試不同，在回歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據代碼的修改情況對已有測試用例集進行有效的復用是回歸測試研究的重要方向，此外，回歸測試的研究方向還涉及自動化工具，物件導向回歸測試，測試用例優先級，回歸測試用例補充生成等。

測試原有功能
測試新加入的功能是否有side effect

測試用例、測試指令碼和測試場景

測試過程範例

軟體測試活動

代碼覆蓋率

代碼覆蓋率原本是種白箱測試活動。目標軟體通過特殊選項或者函式館編譯並且/或者在特殊環境（程式裡每個函式都被對映回原始碼裡函式起點）下執行。這個過程允許開發員與品管員檢視系統中在正常情況下極少或從未被讀寫的部分（例如：例外處理之類）並且幫助測試員確認最重要的情況（函式點）都被測過了。

測試員可檢視代碼覆蓋率測試結果來設計測試個案、相對應的輸入或者設定組以增加重要函式的代碼覆蓋率。兩種測試員常用的代碼覆蓋率形式：語句覆蓋率（或稱行覆蓋率）以及路徑覆蓋率（或稱邊覆蓋率）。行覆蓋率回報到測試完成時，執行過哪些行，或者記憶體大小。邊覆蓋率回報到測試完成時，哪些分支，或者程式決定點被執行過。正如覆蓋率的「率」字所言，這兩個都以百分比為單位。

通常代碼覆蓋率的工具與函式館要求的效能、記憶體、或者其他資源開銷不為正常的軟體營運接受。因此它們通常只存在實驗室裡。又，你可能會想到軟體裡的許多類無法一一通過這些代碼覆蓋率測試，雖然代碼覆蓋程度可通過分析但不是直接測試。

有些瑕疵也會受這些工具的影響。個別來說某些競態條件（race condition）或者類似的對即時（real time）敏感度高的操作幾乎不可能在代碼覆蓋率測試環境下偵知；相反的這類的瑕疵只會帶來更多的測試碼開銷。

自動化的測試

自動化測試是使用軟體工具和既定程式，對軟體所進行的測試活動。

參考文獻

鄭人傑，《计算机軟體測試技術》，清華大學出版社