軟體專案的進行，可以囫圇吞棗，也可以鉅細彌遺，注意細節。而軟體工程的專業知識，古今中外，老生常談。但聽過是一回事，知道如何去做又是另外一回事。軟體系統不能老是屢做屢敗，而屢敗屢做！除了深耕自己的開發技能專業外，尤須注意專案管理及軟體工程的最佳實務作法。
往往一個軟體專案的失敗，可能決定於一個 bug 的產生。而為了預防這一切的發生，我們需要對軟體進行測試，而軟體就像蓋房子一樣，若蓋歪了需要馬上修正問題，否則遇到一個小小地震，就會造成整個房子倒塌。唯有持續的測試並修正，才能使房子蓋得又高又穩 !
軟體測試方法是指測試軟體性能的方法。隨著軟體測試技術不端的發展，測試方法也越來越多樣化，針對性更強；選擇合適的軟體測試方法可以讓我們事半功倍。
而軟體測試方法有百百種，以下將介紹幾種比較常見的方法。
測試分類
β 測試(Beta testing)：
- β 测试是軟體的多個用戶在一個或多個用戶的實際使用環境下進行地測試。開發者通常不在測試現場，β 測試不能由程式設計師或測試人員完成。
- 當開發和測試要完成所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成，不能由程式設計師或測試人員完成。
α 測試(Alpha testing)：
- α 測試是由一個用戶在開發環境下進行測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，α 測試不能由該系統的程式設計師或測試人員完成。
- 再系統開發接近完成時對應用系統的測試，測試後仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員來完成，不能由程式設計師或測試人員完成。
可移植性測試(Portability testing)：
- 又稱為兼容性測試。
- 可移植性測試是指測試軟體是否可以成功被移植到指定的硬體或軟體平台上。
UI 測試
使用者介面測試(User interface testing)是指使用者介面的風格是否滿足客戶的要求、文字是否正確、畫面是否美觀、文字與圖片組合是否完美，操作性是否良好 ⋯⋯ 等等。UI 測試的目標是確保使用者介面會通過測試對象的功能來為使用者提供相應的訪問或瀏覽功能。確保使用者介面符合公司的標準。包括使用者的互動性、人性化、易操作性的各種測試。
分析軟體使用者介面的設計是否能達到使用者期望或要求。它常常包括 Menu、對話框以及對話框上所有的按鈕、文字、警告提示等方面的測試。
冒煙測試
冒煙測試(Smoke testing)的對象是一個新編譯的需要正視測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。
Example：
於每日構建(Nightly build)，構建伺服器首先從CVS伺服器上，下載最新的源代碼，然後編譯單元測試，運行單元測試通過後，編譯可執行文件，可執行文件若可運行，並能執行最基本的功能，則認為通過了冒煙測試，這時，構建伺服器會把程序打包成安裝文件，然後上傳到內部網站。
第二天一早，測試人員來了以後，會收到構建伺服器發來的郵件提示昨晚是否構建成功。若構建成功，則測試人員進行相關的功能測試。
隨機測試
隨機測試(Ad hoc testing)是指沒有書面資料、測試案例、期望值、檢查點 ⋯⋯ 等的測試；主要是根據使用者的經驗以及相關知識對待測軟體進行功能或效能抽查，有時會包括到一些當前測試案例沒有覆蓋到的部分，另外，也可以針對軟體新增或更新的功能做一些重點測試，如特殊場景、特殊環境，並可以結合回歸測試一起進行。
Example：
- 我來試試看如果當聽音樂時打電話進來會發生什麼事？
- 任意調整視窗大小
白箱測試與黑箱測試
白箱測試
白箱測試(White box testing)也稱為結構性測試(Structural testing)、透明盒測試(Glass box testing)。是以測試的深度為主，可分為資料流程面(Data Flow Coverage)以及控制流程面(Control Flow Coverage)兩個層面：
- 資料流程面：測試資料在程式內所經過的流程。
- 控制流程面：測試程式在執行過程中每個階段的流程。
白箱測試時，測試人員必須掌握程式原始碼，瞭解其內部運作，包含資料流程以及程式控制流程。
黑箱測試
黑箱測試(Black box testing)則不需要對軟體的內部結構有深層的了解，直接就功能面來驗證，所以在程式碼的安全性檢測方面，黑箱測試就是所謂的「動態程式碼安全性檢測」，其中「動態」是指應用程式處於執行期的狀態，黑箱測試的手法則是模擬駭客的攻擊，測試系統有沒有漏洞。而白箱就是「靜態程式碼安全性檢測」，它直接掃描程式寫法。黑箱測試使用已知的攻擊樣板 (Pattern) 進行檢測。
黑箱測試有以下幾個原則：
- 測試應用程式的功能，而不是其內部結構運作。
- 測試者只需要知道什麼是系統應該做的事，即當鍵入一個特定的輸入，可以得到一定的輸出。
- 測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。
白箱與黑箱測試優缺點分析
自動化測試
使用自動化測試工具來進行測試，這類測試一般不需要人來干預，通常在 GUI 測試、效能測試、功能測試中用的較多。透過錄製測試腳本，然後執行這個測試腳本來實現測試過程的自動化。
回歸測試
回歸測試(Regression testing)是指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，軟體產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新版本上再次出現。
驗收測試
驗收測試(Acceptance testing)是指 系統開發生命週期 方法論的一個階段，這時相關的使用者或獨立的測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統使用者決定是否接收系統。它是一項確定產品是否能夠滿足合約或使用者所規定需求的測試。
單元測試
單元測試(Unit testing)是最小規模的測試；以測試某個功能或部分代碼。由程式設計師來進行測試而非測試員來做，因為它需要知道內部程式設計和編碼的細節。
單元測試是最常見的測試，在
Open Source中為最常見的測試項目之一。其驗證開發者的程式碼邏輯及判斷是否正確。
整合測試
整合測試(Integration testing)是單元測試的邏輯延伸。在最簡單的形式中，已經測試完成的兩個單元會結合成一個元件，而且會測試它們之間的介面。在這方面，元件是指多個單元的整合彙總(Aggregate)。在現實狀況下，許多單元會結合成元件，依序再彙總(Aggregate) 成程式中較大的部分。這個想法是測試片段的組合，最後擴展此程序，以測試您的模組與其他群組的模組。最後一起測試構成程序的所有模組。此外，如果程式包含多個程序，就應該成對進行測試，而不是一次完成測試。
整合測試可識別組合單元時所發生的問題。藉由使用需要測試各單元以便在組合各單元之前確定其可行性的測試規劃，可以了解，組合各單元時所發現的任何錯誤都可能與單元之間的介面有關。這個方法可大為減少其可能性，使分析變得比較簡單。
端到端測試
端到端測試(End to End testing)亦可稱為 E2E 測試。簡單來說，是從使用者與應用程式的互動方式來進行測試，因此寫測試時，會從操作的面向來思考測試寫法。而端到端測試包含所有訪問點的功能測試及效能測試。端到端測試實質上是一種「灰盒」測試，一種集合了白盒測試與黑盒測試優點的測試方法。
壓力/負載/效能測試
以下先簡單說明三種測試方法的定義：
- 效能測試：屬於在正常的執行下，確認各個數據有符合期望值；
- 負載測試：在瀕臨上限時還是可以正常執行，目的在測試是否有 memory leak 問題；
- 壓力測試：在超過上限後是否正常執行或 crash 之後是否可以回復之前的狀態。
效能測試
效能測試(Performance testing)的目的不是要找缺陷(bug)，而是要解決瓶頸和替未來的回歸測試(regression testing)建立一個底線。效能測試是為獲取或驗證系統效能指標而進行的測試，多數情況下效能測試會在不同負載情況下進行。
效能測試主要目的在系統的效能是否能符合客戶的需求，因此執行效能測試時，首先需要瞭解客戶的需求為何。
負載測試
負載測試(Load testing)是系統所能承受的條件下，逐漸的增加負載來觀察不同負載下系統的回應時間、數據的吞吐量和系統佔用資源(例如：CPU、記憶體) ⋯⋯ 等等，以檢驗系統的行為和特性，藉此發現系統可能存在的效能瓶頸以及記憶體洩漏 ⋯⋯ 等等。
在測試文獻中，負載測試一詞經常被定義為提供系統所能執行最大工作量下運作測試的流程，負載測試通常被稱為「容量測試」或「壽命(longevity)/耐力(endurance)測試」。
容量測試的例子：
- 藉由修改一個非常大的檔案以測試一個文字處理器。
- 藉由上千位使用者的收件匣以測試一個郵件伺服器。
- 一個容量測試的特定 Case 是 0 容量測試，已確認系統能接受空的工作。
壽命/耐力測試的例子：
- 在 Client 端執行一個 Client-Server 應用程式以考驗伺服器在延長一段時間下的狀況。
壓力測試
壓力測試是對資統資源不斷施加壓力(超出系統資源或拿走系統資源)，觀察系統最後在什麼樣的壓力下或系統哪部分被壓垮，以及當系統被壓垮後是否能平順的結束與恢復，因此主要目的是在確保系統可以平順的結束與恢復。
Ron Ratton 的 《Software Testing》 中對壓力測試的定義為一種破壞性的測試，故意讓系統在比較少的資源環境下執行(例如：較低的記憶體、硬碟空間較少、較高的 CPU 使用率 ⋯⋯ 等等)，執行至系統無法被壓垮後從而發現系統的缺陷。用一句話來比喻就是讓系統載飢餓的狀態下執行。
壓力測試又可以分為以下兩種：
- 穩定壓力測試：在特定壓力下，長時間一直進行，查看是否有
OOM(out of memory)或是系統會不會反應越來越慢； - 破壞性壓力測試：透過不斷的加壓可以讓原本穩定壓力測試的問題更快的發生。
而壓力測試可以分為以下三種方向：
- Spike Testing：短時間的極端負載測試。例如：在搶購江蕙演唱會門票的時候，在某個時間突然湧入大量用戶搶購；
- Extreme testing：在過量用戶下的負載測試。例如：某網站最多只允許 100 人同時上現操作，卻給它 110 人；
- Hammer testing：連續執行所有能做的操作。
邊界值分析
邊界值分析(Boundary Value Analysis, BVA)從過往經驗來看，許多問題都發生在輸入或輸出範圍的邊界值上，而不是在輸入範圍內，因此，我們必須小心去分析邊界值條件，針對邊界值去設計測試案例，以免忽略邊界值的錯誤。
BVA 是一種黑箱測試的方法。特別適用偵測以下幾種錯誤：
- 人為造成的錯誤資料型態
- 指定錯誤關係運算子
- 資料型態的封裝
- 迴圈結構的問題
- 差一錯誤 (off-by-one-errors)
隱藏的邊界值：
並不是所有的邊界值都可以用數值表示，或是直接讓使用者觀察到，像是程式中會有許多迴圈，或是一些資料型態，也都存在邊界值的問題。
Example：
輸入一位學生軟體工程成績，成績範圍：0 ~ 100(可輸入最小值為0，可輸入最大值為100)。
所以根據邊界值分析，我們會取-1, 0, 1, 99, 100, 101 來做邊界值測試，之後會再取範圍內的任一值(假設我們取 60)當作確認輸入範圍內的直也為正常。
結果如下：
| No. | 成績 | 預期輸出 |
|---|---|---|
| 1 | -1 | 跳出錯誤訊息 |
| 2 | 0 | 成績數值正常 |
| 3 | 1 | 成績數值正常 |
| 4 | 99 | 成績數值正常 |
| 5 | 100 | 成績數值正常 |
| 6 | 101 | 成績數值正常 |
| 7 | [0-100] | 成績數值正常 |
總結
測試的方法不勝枚舉，而以上都是我目前從專案中學習到的一些測試方法。或許許多人都會覺得測試是讓費時間，如果你不想要遇到軟體給廠商後發現一堆問題，才開始後悔當初應該好好做測試這類情況發生的話，就開始動手學習如何測試吧！