軟件測試

軟件測試[編輯]

 
 
軟件開發
軟件開發步驟
需求分析 | 軟件架構 | 軟件設計 |軟件編程 | 軟件測試 | 軟件部署 |軟件維護
軟件開發模式
敏捷開發 | 無塵室 | 迭代式開發 |RAD | 統一過程 | 螺旋模型 | 瀑布模型 | 極限編程 | Scrum
軟件開發輔助領域
配置管理 | 文檔編寫 | 質量管理 |項目管理 | 用戶經驗設計
軟件開發工具
編譯器 | 除錯器 | 性能分析 | GUI設計 | 集成開發環境

軟件測試英語software testing),描述一種用來促進鑑定軟件正確性完整性安全性質量的過程。據此,您可能會想,軟件測試永遠不可能完整的確立任意電腦軟件的正確性。然而,在可計算理論(計算機科學的一個支派)一個簡單的數學證實推斷出下列結果:不可能徹底解決所謂「死機」,指任意電腦程序是否會進入死循環,或者罷工併產生輸出問題。換句話說,軟件測試是一種實際輸出與預期輸出間的審覈或者比較過程。php

軟件測試的經典定義是:在規定的條件下對程序進行操做,以發現程序錯誤,衡量軟件質量,並對其是否能知足設計要求進行評估的過程。web

軟件測試有許多方法,但對複雜的產品運行有效測試不只僅是研究過程,更是創造並嚴格遵照某些呆板步驟的大事。測試的其中一個定義:爲了評估而質疑產品的過程;這裏的「質疑」是測試員試着對產品作的事,而產品以測試者腳本行爲反應做爲回答。雖然大部分測試的智力過程不外乎回顧、檢查,然而「測試」這個辭意味着產品動態分析──讓產品流暢運行。程序質量可能,並且一般會,隨系統不一樣而有差別;不過某些公認特性是共通的:可靠性穩定性輕便性易於維護、以及實用性。請引用至ISO標準ISO 9126有更詳盡的說明。編程

 

 

§軟件測試介紹[編輯]

軟件測試一度被認爲是編程能力偏低的員工的工做,直到今天,仍然有許多公司把優秀的人才放在編碼上,也有更多公司讓優秀的人才進行設計,但是不多公司讓優秀的人才進行測試工做。實際的軟件工程實踐證實,讓對軟件思想有深入理解的工程師進行軟件測試的,能夠大幅度的提升軟件質量。安全

§測試的進程[編輯]

§Alpha測試[編輯]

Alpha測試一般是階段性的開發完成後所開始進行,一直持續到進入Beta測試階段前的階段。Alpha測試是一種驗證測試,在模擬的環境中以模擬的數據來運行。網絡

在這個階段中,一般是在開發單位由開發人員與測試的測試人員,以模擬或實際操做性的方式進行驗證測試。架構

§Beta測試[編輯]

在系統測試中一般先進行Alpha測試以驗證信息系統符合用戶以及設計需求所指望的功能。當Alpha階段完成後,開發過程進入到Beta階段,由公衆參與的測試的階段。Beta測試可稱爲確認測試,在一個真實的環境中以實際的數據來運行測試,以確認性能,系統運行有效率,系統撤消與備份做業正常,經過測試讓信息系統往後能夠更趨完善。編程語言

§封測與公測[編輯]

封閉測試(Closed Beta,常簡做封測CB)是軟件服務等產品在開發完成後、將公開上市前的測試過程。相對於公開測試,封閉測試的主要用途是測試軟件的功能和檢查程序錯誤等等,所以一般只提供給少數人進行測試。有些公司會要求參與測試者簽署保密協議,以免測試的產品提早外流。MMORPG的封測退出以後,遊戲公司常會將角色數據刪除,但也有少數不刪的。ide

公開測試(Open Beta,常簡做公測OB),通常常指軟件服務等產品在正式上市前開放給不特定人試用,雖然原意是但願試用者可以提報bug,但並非把試用者當作真正的驗證人員。因爲一般爲免費性質,故經常可以吸引到大批的試用者參與,可視爲另外一種營銷策略。另外一方面也節省下測試人員的成本,和驗證穩定度(對於多人使用的帶寬及機器是否能負載,又稱壓力測試)的時間。svg

§Gamma測試[編輯]

Gamma測試是一個不多被說起的非正式測試階段,該測試階段對應的是對「存在缺陷」產品的測試。考慮到任何產品均可以被稱爲「存在缺陷」的產品(測試只能發現產品中存在的問題,不能說明產品不存在問題),所以這個概念存在必定的不肯定性。 對Alpha和Beta測試常見的一個誤解是「Beta測試=黑盒測試」。實際上,Alpha和Beta測試對應在軟件產品發佈以前的Alpha和Beta階段,而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述,不該該將這兩部分概念混淆。函數

§測試的方法[編輯]

軟件測試通常分爲白箱測試和黑箱測試。

§黑箱測試[編輯]

黑箱測試(black-box testing),也稱黑盒測試,是軟件測試方法,測試應用程序的功能,而不是其內部結構或運做。測試者不需具有應用程序的代碼、內部結構和編程語言的專門知識。測試者只需知道什麼是系統應該作的事,即當鍵入一個特定的輸入,可獲得必定的輸出。測試案例是依應用系統應該作的功能,照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。

此測試方法可適合大部分的軟件測試,例如單元測試(unit testing)、集成測試(integration testing)以及系統測試(system testing)。

§白箱測試[編輯]

白箱測試(white-box testing,又稱透明盒測試glass box testing、結構測試structural testing等)是一個測試軟件的方法,測試應用程序的內部結構或運做,而不是測試應用程序的功能(即黑箱測試)。在白箱測試時,以編程語言的角度來設計測試案例。測試者輸入數據驗證數據流在程序中的流動路徑,並肯定適當的輸出,相似測試電路中的節點。

白箱測試能夠應用於單元測試(unit testing)、集成測試(integration testing)和系統的軟件測試流程,可測試在集成過程當中每一單元之間的路徑,或者主系統跟子系統中的測試。儘管這種測試的方法能夠發現許多的錯誤或問題,它可能沒法檢測未使用部分的規範。

§測試的類型[編輯]

功能測試 按照測試軟件的各個功能劃分進行有條理的測試,在功能測試部分要保證測試項覆蓋全部功能和各類功能條件組合。
系統測試 對一個完整的軟件以用戶的角度來進行測試,系統測試和功能測試的區別是,系統測試利用的全部測試數據和測試的方法都要模擬成和用戶的實際使用環境徹底同樣,測試的軟件也是通過系統集成之後的完整軟件系統,而不是在功能測試階段利用的每一個功能模塊單獨編譯後生成的可執行程序。
極限值測試 對軟件在各類特殊條件,特殊環境下可否正常運行和軟件的性能進行測試。 特殊條件通常指的是軟件規定的最大值,最小值,以及在超過最大、最小值條件下的測試。 特殊環境通常指的是軟件運行的機器處於CPU高負荷,或是網絡高負荷狀態下的測試,根據軟件的不一樣,特殊環境也有過不一樣。
性能測試 性能測試是對軟件性能的評價。簡單的說,軟件性能衡量的是軟件具備的響應及時度能力。所以,性能測試是採用測試手段對軟件的響應及時性進行評價的一種方式。根據軟件的不一樣類型,性能測試的側重點也不一樣。

§壓力測試與性能測試[編輯]

壓力測試經常和性能測試相混淆。它們主要不一樣點是,壓力測試要求進行超過規定性能指標的測試。例如一個網站設計容量是100我的同時點擊,壓力測試就要是採用120個同時點擊的條件測試。

壓力測試的一般判斷準則:

  1. 系統可以恢復。
  2. 壓力過程當中不要有明顯性能降低。

§測試的階段[編輯]

§單元測試[編輯]

單元測試是對軟件組成單元進行測試,其目的是檢驗軟件基本組成單位的正確性,測試的對象是軟件設計的最小單位:模塊。

§集成測試[編輯]

集成測試也稱綜合測試、組裝測試、聯合測試,將程序模塊採用適當的集成策略組裝起來,對系統的接口及集成後的功能進行正確性檢測的測試工做。其主要目的是檢查軟件單位之間的接口是否正確,集成測試的對象是已經通過單元測試的模塊。

§系統測試[編輯]

系統測試主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現程度(功能流程&業務流程、數據處理&業務數據處理)方面測試。

§迴歸測試[編輯]

迴歸測試指在軟件維護階段,爲了檢測代碼修改而引入的錯誤所進行的測試活動。迴歸測試是軟件維護階段的重要工做,有研究代表,迴歸測試帶來的耗費佔軟件生命週期的1/3總費用以上。

與普通的測試不一樣,在迴歸測試過程開始的時候,測試者有一個完整的測試用例集可供使用,所以,如何根據代碼的修改狀況對已有測試用例集進行有效的複用是迴歸測試研究的重要方向,此外,迴歸測試的研究方向還涉及自動化工具,面向對象迴歸測試,測試用例優先級,迴歸測試用例補充生成等。

§測試用例、測試腳本和測試場景[編輯]

§測試過程示例[編輯]

§軟件測試活動[編輯]

§代碼覆蓋率[編輯]

代碼覆蓋率本來是種白箱測試活動。目標軟件經過特殊選項或者函數館編譯而且/或者在特殊環境(程序裏每一個函數都被映射回源代碼裏函數起點)下運行。這個過程容許開發員與品管員查看系統中在正常狀況下極少或從未被讀寫的部分(例如:異常處理之類)而且幫助測試員確認最重要的狀況(函數點)都被測過了。

測試員可查看代碼覆蓋率測試結果來設計測試個案、相對應的輸入或者設置組以增長重要函數的代碼覆蓋率。兩種測試員經常使用的代碼覆蓋率形式:陳述式覆蓋率(或稱行覆蓋率)以及路徑覆蓋率(或稱邊覆蓋率)。行覆蓋率回報到測試完成時,運行過哪些行,或者存儲器大小。邊覆蓋率回報到測試完成時,哪些分支,或者程序決定點被運行過。正如覆蓋率的「率」字所言,這兩個都以百分比爲單位。

一般代碼覆蓋率的工具與函數館要求的性能、存儲器、或者其餘資源開銷不爲正常的軟件營運接受。所以它們一般只存在實驗室裏。又,你可能會想到軟件裏的許多類沒法一一經過這些代碼覆蓋率測試,雖然代碼覆蓋程度可經過分析但不是直接測試。

有些瑕疵也會受這些工具的影響。個別來講某些競態條件(race condition)或者相似的對實時(real time)敏感度高的操做幾乎不可能在代碼覆蓋率測試環境下偵知;相反的這類的瑕疵只會帶來更多的測試碼開銷。

§自動化的測試[編輯]

使用軟件工具和既定程序,對軟件所進行的測試活動。

相關文章
相關標籤/搜索