軟體測試

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

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

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

測試的程序

1.1 Alpha 測試

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

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

1.2 Beta 測試

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

1.2.1 封測與公測

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

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

1.3 Gamma 測試

Gamma 測試是一個很少被提及的非正式測試階段，該測試階段對應的是對 “存在缺陷” 產品的測試。考慮到任何產品都可以被稱為 “存在缺陷” 的產品（測試只能發現產品中存在的問題，不能說明產品不存在問題），因此這個概念存在一定的不確定性。

對 Alpha 和 Beta 測試常見的一個誤解是「Beta 測試＝黑盒測試」。實際上，Alpha 和 Beta 測試對應在軟體產品釋出之前的 Alpha 和 Beta 階段，而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述，不應該將這兩部分概念混淆。

測試的方法

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

2.1 黑盒測試

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

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

2.2 白盒測試

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

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

測試的型別

3.1 壓力測試與效能測試

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

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

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

測試的階段

4.1 單元測試

單元測試是對軟體組成單元進行測試，其目的是檢驗軟體基本組成單位的正確性，測試的物件是軟體設計的最小單位：函式。

並且使用假資料測試不同狀況下功能使用情況，單元測試還有助於開發人員編寫更好的程式碼。

單元測試是基於 code 的：可讀性、可測試性，它們與開發程式碼的構建方式密切相關。因此開發人員最清楚哪些測試最有意義。

4.2 整合測試

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

4.3 系統測試

系統測試主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。

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

4.4 迴歸測試

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

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

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

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

測試過程示例

6.1 軟體測試活動

驗收測試
系統測試
整合測試
單元測試
迴歸測試
效能測試
壓力測試
安全測試
安裝測試
可用性測試
穩定性測試
易用性測試
移植測試

程式碼覆蓋率

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

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

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

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

自動化的測試

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