淺談軟體測試方法

標籤：

      軟體測試已然成為生產高品質軟體必不可少的一個工程實踐活動，其中軟體測試方法更是種類繁多，對於初學者而言，記憶起來比較困難。因而我通過課上聽講及查閱資料加以簡單地整理總結，方便大家有個整體的瞭解。

從測試設計方法分類                                                        

測試名稱	測試內容
Black Box Testing黑箱測試	黑箱測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程式看作一個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入資料而產生正確的輸出資訊。黑箱測試著眼於程式外部結構，不考慮內部邏輯結構，主要針對軟體介面和軟體功能進行測試。
White Box Testing白盒測試	白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試案例設計方法，盒子指的是被測試的軟體，白盒指的是盒子是可視的，你清楚盒子內部的東西以及裡面是如何運作的。"白盒"法全面瞭解程式內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程式的內部結構，從檢查程式的邏輯著手，得出測試資料。
Gray Box Testing灰盒測試	灰盒測試，是介於白盒測試與黑箱測試之間的，可以這樣理解，灰盒測試關注輸出對於輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表徵性的現象、事件、標誌來判斷內部的運行狀態，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要採取這樣的一種灰盒的方法。

  其中黑箱測試和白盒測試尤為常見，兩者之間的比較如下：                                      從是否執行程式的角度分類                                               

測試名稱	測試內容
靜態測試Static Test	靜態方法是指不運行被測程式本身，僅通過分析或檢查來源程式的文法、結構、過程、介面等來檢查程式的正確性。對需求規格說明書、軟體設計說明書、來源程式做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程式靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的迴圈嵌套和分支嵌套、不允許的遞迴、未使用過的變數、null 指標的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試案例選取提供指導。
動態測試  Dynamic Test	動態測試方法是指通過運行被測程式，檢查運行結果與預期效果的差異，並分析運行效率、正確性和健壯性等效能。這種方法由三部分組成：構造測試案例、執行程式、剖析器的輸出結果。

　　

     靜態測試包括對軟體產品的設計規格說明書的審查，對程式碼的閱讀、審查等。靜態分析的查錯和分析功能是其他方法所不能替代的．已被當做一種自動化的代碼校正方法。

　　動態測試是通過觀察代碼運行時的動作，來提供執行跟蹤、時間分析，以及測試覆蓋度方面的資訊。動態測試通過真正運行程式發現錯誤。通過有效測試案例，對應的輸入腳出關係來分析被測程式的運行情況。

     不同的測試方法各自的目標和側重點不一樣，在實際工作中。應將這兩種方法結合起來運用，以達到更完美的效果。

從測試是否手動分類                                                        

 

測試名稱	測試內容
Manual Test 手動測試	測試人員用滑鼠去手動測試 （測試GUI），或者進行手動演算
Automation 自動化測試	用程式測試程式 （測試API）

      無論是自動化測試還是手工測試，其核心永遠是測試案例。無效的用例，用任何方法去測試，都不會達到良好的測試目的。目前大部分的項目組都是手動測試和自動化測試相結合。因為很多測試無法做成自動化，很多複雜的商務邏輯也很難自動化， 所以自動化測試無法取代手動測試。當然自動化測試的目的是節約人力成本及時間成本，把枯燥的迴歸測試自動化起來，縮短項目周期，而這也恰恰是手動測試無法比擬的，手動測試最大的缺點就是技術含量低，單調乏味。

     總而言之，手工測試勝在測試商務邏輯，而自動化測試勝在測試底層架構。

 

從軟體開發的過程按階段劃分分類                                         

測試名稱	測試內容
單元測試	單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java裡單元指一個類，圖形化的軟體中可以指一個視窗或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模組。單元測試是在軟體開發過程中要進行的最低層級的測試活動，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試。
整合測試	整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求（如根據結構圖）組裝成為子系統或系統，進行整合測試
確認測試	確認測試的目的是向未來的使用者表明系統能夠像預定要求那樣工作。經整合測試後，已經按照設計把所有的模組組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是確認測試的任務，即軟體的功能和效能如同使用者所合理期待的那樣。
系統測試	系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。系統測試發現問題之後要經過調試找出錯誤原因和位置，然後進行改正。是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的組件。對象不僅僅包括需測試的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等。
驗收測試	驗收測試是部署軟體之前的最後一個測試操作。在軟體產品完成了單元測試、整合測試和系統測試之後，產品發布之前所進行的軟體測試活動。它是技術測試的最後一個階段，也稱為交付測試。驗收測試的目的是確保軟體準備就緒，並且可以讓終端使用者將其用於執行軟體的既定功能和任務。
迴歸測試	迴歸測試是指修改了舊代碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。迴歸測試作為軟體生命週期的一個組成部分，在整個軟體測試過程中佔有很大的工作量比重，軟體開發的各個階段都會進行多次迴歸測試。在漸進和快速反覆式開發法中，新版本的連續發布使迴歸測試進行的更加頻繁，而在極端編程方法中，更是要求每天都進行若干次迴歸測試。因此，通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是非常有意義的。
Alpha測試	Alpha測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在類比實際作業環境下進行的測試。Alpha測試的目的是評價軟體產品的FLURPS(即功能、局域化、可使用性、可靠性、效能和支援)。尤其注重產品的介面和特色。Alpha測試可以從軟體產品編碼結束之時開始，或在模組(子系統)測試完成之後開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之後再開始。
Beta測試	Beta測試由軟體的終端使用者們在一個或多個客房場所進行。與 Alpha測試不同，開發人員通常不在Beta測試的現場，因Beta測試是 軟體在開發人員不能控制的環境中的“真實”應用。使用者Beta測試中遇到的一切問題（真實在或想像的），並且定期把這些問題報告給開發人員。接收到在Beta測試期間報告的問題之後，開發人員對軟體產品進行必要的修改，並準備向全體客戶發布最終的軟體產品

從測試的目的分類                                                            

測試名稱	測試內容
功能測試	功能測試檢查實際的功能是否符合使用者的需求。測試的大部分工作也是圍繞軟體的功能進行，設計軟體的目的也就是滿足客戶對其功能的需求。如果偏離的這個目的任何測試工作都是沒有意義的。 功能測試又可可以細分為很多種：邏輯功能測試、介面測試、易用性測試、安裝測試、相容性測試等
非功能測試	一個軟體除了準系統之外，還有很多功能之外的特性，這些叫“Quality of Service requirement”服務品質需求。沒有軟體的功能，這些特性都無從表現出來，因此，我們要在軟體開發的適當階段-準系統完成後做這些測試。
效能測試	能測試是通過自動化的測試載入器類比多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。 　　軟體的效能包括很多方面，主要有時間效能和空間效能兩種。 　　時間效能：主要是指軟體的一個具體的回應時間。比如一個登入所需要的時間，一個證券交易所需要的時間等。當然，拋開具體的測試環境，來分析一次事務的回應時間是沒有任何意義的。需要搭建一個具體且獨立的測試環境。 　　空間效能：主要指軟體運行時所消耗的系統資源，比如硬體資源，CPU、記憶體，網路頻寬消耗等。
安全性測試	安全性測試是在IT軟體產品的生命週期中，特別是產品開發基本完成到發布階段，對產品進行檢驗以驗證產品符合安全需求定義和產品品質標準的過程

 

 

淺談軟體測試方法