6.3 測試

05-01

定義：為了發現程序中的錯誤而執行程序的過程。

測試決不能證明程序是正確的。即使經過了最嚴格的測試，程序中仍然可能藏有未被發現的錯誤。

軟體測試準則

以用戶需求為依據；
在測試開始之前制定測試計劃；
窮舉測試是不可能的——不要妄圖測試所有的情況；
為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。

關於「第三方從事測試工作」，不一定是專門的「測試人員」，即使是大公司，也可能沒有專門的測試人員；開發人員互測也算「第三方」。

測試發現的80%的Bug 可能是由程序中20%的錯誤代碼造成的。

測試方法

黑盒測試·Black-Box Testing（功能測試）

把程序看作黑盒子，完全不考慮程序的內部結構和處理過程。

黑盒測試只檢查程序功能是否能按照規格說明書的規定正常使用，輸出結果是否正確，是否能否保持外部信息（例如資料庫或文件）的完整性。

白盒測試·White-Box Testing（結構測試）

是把程序看成裝在一個透明的白盒子里，測試者完全知道程序的內部結構。

這種方法按照程序內部的邏輯測試程序，檢測程序中的主要執行通路是否都能按預定要求正確工作。

測試用例

目標明確：測試之前要對測試計划進行定製

測試用例包括輸入數據、預期輸出數據

包括正確數據（正常系）、不合理數據（異常系）

比如，測試年齡【0~99】：
正常系
>輸入數據：0/1/99/98

>預期輸出結果：true
異常系
>輸入數據：-1/100
>預期輸出結果：false

TDD·測試驅動開發

Test-Driven Development，一種設計方法論

原理：編碼之前先編寫單元測試用例代碼，以測試代碼確定產品代碼

單元測試·Unit Testing

書上叫「模塊測試」

對軟體中的最小可測試單元進行測試

C語言中是對函數進行測試
Java中是對類進行測試

單元測試和編碼是同一階段的事情，測試依據一般是詳細設計文檔，往往採用白盒測試的形式進行。

單元測試用於發現：

錯誤的賦值
錯誤的計算
不正確的比較
不適當的控制流程（if，while，for等）。

單元測試的現狀

經常寫單元測試：不到20%
偶爾寫單元測試：超過50%
應付檢查寫單元測試，不保證通過：將近10%
從不寫單元測試：將近20%

集成測試·Integration Testing

在單元測試的基礎上，將多個模塊按照設計要求組裝成為子系統進行測試。

實踐表明：
一些模塊雖然能夠單獨地工作，但並不能保證連接起來也能正常的工作。
一些局部反映不出來的問題，在全局上很可能暴露出來。

系統測試·System Testing

將已經確認的軟體、硬體、外設、網路等元素結合在一起，針對整個產品系統進行確認測試

系統測試是黑盒類測試，依據是《需求說明書》。

系統測試的目的是驗證系統是否滿足了「需求說明書」的定義，而不是滿足「用戶需求」，因為可能需求分析就做錯了，但系統測試只對需求分析的結果負責。

壓力測試·Stress Testing

壓力測試可以算做系統測試的一部分，也叫負載測試。

壓力測試指長時間、超大負荷地運行測試軟體，驗證軟體的性能、可靠性、穩定性等。

2009年9月7日下午，移動公司開商務車裝載200多部電信手機，在溫州某大學邊上不停撥打，導致電信網路癱瘓。電信發現後連車帶人押送到公安局，在公安局，移動自稱沒有違法，只是幫電信做壓力測試。

驗收測試

驗收測試也叫確認測試，是在用戶參與下進行的系統測試，使用實際數據進行。

驗收測試的目的是驗證系統確實能夠滿足用戶的需要，在這個測試步驟中發現的往往是需求說明書中的錯誤。

Alpha和Beta測試

Alpha測試：用戶在開發者對用戶的「指導」下進行測試。開發者負責記錄發現的錯誤和使用中遇到的問題。

Beta測試：由軟體的最終用戶在實際使用場所進行,沒有開發者在場。

平行運行測試

關係重大的軟體在驗收之後往往並不立即投入運行，而是經過一段平行運行的測試。

平行運行指同時運行新系統和舊系統，以便比較新舊兩個系統的處理結果。

目的：

(1)在准生產環境中運行新系統而又不冒風險。
(2)用戶能有一段熟悉新系統的時間。
(3)可以驗證用戶指南和使用手冊之類的文檔。
(4)能夠以准生產模式對新系統進行全負荷測試，可以用測試結果驗證性能指標。

回歸測試·Regression Testing

系統測試、維護升級等階段，修改代碼之後，重新進行的測試叫回歸測試。

回歸測試用以確認代碼的修改沒有引入新的錯誤。

如果修改了舊代碼，引入了新錯誤，會導致軟體「退步（Regression ）」，所以叫「回歸測試」，雖然這個名詞很不恰當