淺談軟件測試方法

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

從測試設計方法分類                                                        

測試名稱                                 測試內容
Black Box Testing黑盒測試 黑盒測試也稱功能測試,它是經過測試來檢測每一個功能是否都能正常使用。在測試中,把程序看做一個不能打開的黑盒子,在徹底不考慮程序內部結構和內部特性的狀況下,在程序接口進行測試,它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進行測試。
White Box Testing白盒測試 白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒測試是一種測試用例設計方法,盒子指的是被測試的軟件,白盒指的是盒子是可視的,你清楚盒子內部的東西以及裏面是如何運做的。"白盒"法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時,測試者必須檢查程序的內部結構,從檢查程序的邏輯着手,得出測試數據。

Gray Box Testing灰盒測試安全

灰盒測試,是介於白盒測試與黑盒測試之間的,能夠這樣理解,灰盒測試關注輸出對於輸入的正確性,同時也關注內部表現,但這種關注不象白盒那樣詳細、完整,只是經過一些表徵性的現象、事件、標誌來判斷內部的運行狀態,有時候輸出是正確的,但內部其實已經錯誤了,這種狀況很是多,若是每次都經過白盒測試來操做,效率會很低,所以須要採起這樣的一種灰盒的方法。
 
 
其中黑盒測試和白盒測試尤其常見,二者之間的比較以下:
                                     

從是否執行程序的角度分類                                               

測試名稱 測試內容
靜態測試Static Test 靜態方法是指不運行被測程序自己,僅經過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。對需求規格說明書、軟件設計說明書、源程序作結構分析、流程圖分析、符號執行來找錯。靜態方法經過程序靜態特性的分析,找出欠缺和可疑之處,例如不匹配的參數、不適當的循環嵌套和分支嵌套、不容許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態測試結果可用於進一步的查錯,併爲測試用例選取提供指導。

動態測試 網絡

Dynamic Test架構

動態測試方法是指經過運行被測程序,檢查運行結果與預期效果的差別,並分析運行效率、正確性和健壯性等性能。這種方法由三部分組成:構造測試用例、執行程序、分析程序的輸出結果。

  

     靜態測試包括對軟件產品的設計規格說明書的審查,對程序代碼的閱讀、審查等。靜態分析的查錯和分析功能是其餘方法所不能替代的.已被當作一種自動化的代碼校驗方法。函數

  動態測試是經過觀察代碼運行時的動做,來提供執行跟蹤、時間分析,以及測試覆蓋度方面的信息。動態測試經過真正運行程序發現錯誤。經過有效的測試用例,對應的輸入腳出關系來分析被測程序的運行狀況。工具

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

從測試是否手動分類                                                        

 

測試名稱單元測試

測試內容測試

Manual Test 手動測試ui

測試人員用鼠標去手動測試 (測試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軟件產品的生命週期中,特別是產品開發基本完成到發佈階段,對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程 
相關文章
相關標籤/搜索