【軟體測試基礎】軟體測試階段
阿新 • • 發佈:2018-12-17
1.軟體測試的分類
按測試階段分類:單元測試、整合測試、系統測試、驗收測試
2.單元測試
- 定義:對軟體中的最小可測試單元進行檢查和驗證。
- 單元:人為規定的可測試的最小模組。比如C語言中,可看作各個函式;Java這種面嚮物件語言中,可看做每一個類;針對有介面的功能軟體,單元可看做具體的功能項,比如選單項,一個子視窗的具體的功能。
單元測試的原則:
- 儘可能保證各個測試用例是互相獨立的。
- 一般由程式碼的開發人員來實施,用以檢驗所開發的程式碼功能符合自己的設計要求。
單元測試的益處:
- 能儘早發現缺陷。單元測試處於前期,可以發現更多的缺陷。
- 有利於重構。有了完善的單元測試,可以在重構時,就可以快速地識別出重構時出現問題的點。
- 簡化整合。只有充分的單元測試,整合測試才能更加聚焦在模組之間的關係上,而不用再花精力到單元內部的邏輯上。
- 減少文件。現在的敏捷研發,提倡程式碼級文件,即儘可能地減少文件。如果單元測試比較規範,通過對單元測試程式碼的閱讀,就可以基本地理解模組的特性。很大程度上可以減少文件的工作。
- 用於設計。通過編寫單元測試,是可以把設計思路體現在單元測試的組織上。設計的本身可以用來驗證設計。
注:
TDD:測試驅動開發,先編寫單元測試,再編寫功能的程式碼,並保證這些程式碼能使單元測試通過。
單元測試的限制:
- 不可能覆蓋所有的執行路徑,所以不可能保證捕捉到所有路徑的錯誤。
- 每一行程式碼,一般需要3~5行測試程式碼才能完成單元測試。所以存在投入和產出的一個平衡。
單元測試框架:
- Xunit
- JUnit: 針對java
- nunit:針對.net
- PHPUnit:針對PHP
- CppUnit:針對C++
3.整合測試:
定義:是在單元測試的基礎上,測試在將所有的軟體單元按照概要設計規格說明的要求組裝成模組、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。
整合測試的主要實施方案:
- Big Bang:一次性整合,把大部分的開發模組都耦合起來,形成一個完整的軟體系統或系統的主要的組成部分,然後再來做整合測試。
- 自頂向下:從主程式開始,沿控制層逐層向下地測試,以覆蓋到所有的模組。
- 自底向上:從程式模組的最底層的模組開始,逐層地向上組裝,逐層地測試。針對已經整合的或已經組裝過的,可以不需要對上一層組裝模組。它是最常用的整合方法。
- 核心系統整合:先把核心的軟體部分挑選出來,並對這些部件進行整合測試。在測試通過的基礎上,再逐步地擴充套件到外圍的部件,直到最後形成穩定的軟體產品。
- 高頻整合:高頻次地、不斷地進行整合。
核心系統整合和高頻整合是很常用的整合方式,自頂向下和自底向上在傳統的瀑布軟體研發模型中比較常用。
整合測試&單元測試的區別:
- 測試的物件不同:單元測試針對的是最小的單元,整合測試則是以模組和子系統為單元,它主要測試的是模組和模組之間的關係。
- 測試的依據不同:單元測試主要針對的是軟體的詳細設計,整合測試則主要針對軟體的概要設計來測試的。
- 測試的方法不同:整合測試關注的是介面之間的整合,單元測試只關心單元的內部。
4.系統測試:
定義:是將經過整合測試的軟體,作為計算機系統的一個部分,與系統中其他部分結合起來,在實際執行環境下對計算機系統進行的一系列嚴格有效地測試,以發現軟體潛在的問題,保證系統的正常執行。
系統測試的關注點:
- 關注系統本身的使用
- 關注系統與其他系統間的連通
- 關注系統在不同使用壓力下的表現
- 關注系統在真實使用環境下的表現
系統測試&整合測試的不同:
測試物件:
- 整合測試:由通過了單元測試的各個模組所整合起來的構件
- 系統測試:除了軟體以外,還包括計算機硬體及相關的外圍裝置、資料採集和傳輸機構、支援軟體、系統操作人員等整個系統。
測試時間:
- 整合測試介於單元測試和系統測試之間測試
- 系統測試是在整合測試之後
測試內容:
- 整合測試: 各個單元模組之間的介面
- 系統測試:整個系統的功能和效能
測試角度:
- 整合測試:偏於技術角度的驗證
- 系統測試:偏於業務角度的驗證
5.驗收測試:
定義:也稱交付測試。針對使用者需求、業務流程的正式的測試,確定系統是否滿足驗收標準,由使用者、客戶或其他授權機構決定是否接受系統。
細分:
- 使用者驗收測試
- 執行驗收測試
- 合同和規範驗收測試
- alpha測試:開發者所提供的的環境中,由使用者完成。
- Beta測試:完全脫離了開發者環境,在使用者環境下測試。