軟體測試方法的總結
、按是否檢視程式內部結構分為:
(1)黑盒測試(black-box testing):只關心輸入和輸出的結果。
(2)白盒測試(white-box testing):去研究裡面的原始碼和程式結構。
(3)灰盒測試(Gray-box testing)關注輸出對於輸入的正確性,同時也關注內部表現,但這種關注不像“白盒”那樣詳細、完整。
黑盒測試
黑盒測試也稱功能測試或資料驅動測試,它是在已知產品所應具有的功能,通過測試來檢測每個功能是否都能正常使用,在測試時,把測試物件看作看不見內部的黑盒,在完全不考慮程式內部邏輯結構和處理過程的情況下,測試者僅依據程式功能的需求規範考慮確定測試用例和推斷測試結果的正確性,程式是否能適當地接收輸入資料而產生正確的輸出資訊,並且保持外部資訊(如資料庫或檔案)的完整性。
“黑盒”測試意味著要在軟體的介面處進行測試,它著眼於程式外部結構,不考慮內部邏輯結構,主要針對軟體介面和軟體功能進行測試。因此,可以說“黑盒”測試是站在使用軟體和程式的角度,從輸入資料和輸出資料的對應關係出發進行的測試。
黑盒測試方法主要有等價類劃分法、邊界值分析法、因果圖法、錯誤推測法等,主要用於軟體確認測試。“黑盒”法是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用,才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個,人們不僅要測試所有合法的輸入,而且還要對那些不合法但是可能的輸入進行測試。
黑盒測試分為功能測試和效能測試:
1) 功能測試(functiontesting),是黑盒測試的一方面,它檢查實際軟體的功能是否符合使用者的需求。包括
a、邏輯功能測試(logicfunction testing)
b、介面測試(UItesting)UI=User Interface
c、易用性測試(usabilitytesting):是指從軟體使用的合理性和方便性等角度對軟體系統進行檢查,來發現軟體中不方便使用者使用的地方。
d、相容性測試(compatibilitytesting):包括硬體相容性測試和軟體相容性測試
2)效能測試(performancetesting)
軟體的效能主要有時間效能和空間效能兩種,時間效能:主要指軟體的一個具體事務的響應時間(respond time);空間效能:主要指軟體執行時所消耗的系統資源。
軟體效能測試分為:
a、 一般效能測試:指的是讓被測系統在正常的軟硬體環境下執行,不向其施加任何壓力的效能測試。
b、 穩定性測試也叫可靠性測試(reliability testing):是指連續執行被測系統檢查系統執行時的穩定程度。
c、 負載測試(loadtesting):是指讓被測系統在其能忍受的壓力的極限範圍之內連續執行,來測試系統的穩定性。
d、 壓力測試(stresstesting):是指持續不斷的給被測系統增加壓力,直到將被測系統壓垮為止,用來測試系統所能承受的最大壓力。(Validatethe system or software can allowed the biggest stress.)
e、 併發測試:驗證系統的併發處理能力。一般是和伺服器端建立大量的併發連線,通過客戶端的響應時間和伺服器端的效能監測情況來判斷系統是否達到了既定的併發能力指標。負載測試往往就會使用併發來創造負載,之所以把併發測試單獨提出來,是因為併發測試往往涉及伺服器的併發容量,以及多程序/多執行緒協調同步可能帶來的問題。這是要特別注意,必須測試的。
f、 基準測試:當軟體系統中增加一個新的模組的時候,需要做基準測試,以判斷新模組對整個軟體系統的效能影響。按照基準測試的方法,需要開啟/關閉新模組至少各做一次測試。關閉模組之前的系統各個效能指標記下作為基準(Benchmark),然後與開啟模組狀態下的系統性能指標作比較,以判斷模組對系統性能的影響。
g、 可恢復測試:測試系統能否快速地從錯誤狀態中恢復到正常狀態。比如,在一個配有負載均衡的系統中,主機承受了壓力無法正常工作後,備份機是否能夠快速地接管負載。可恢復測試通常結合壓力測試一起來做。
提示:每種測試有其存在的空間和目的。當我們接手一個軟體專案後,在有限的資源條件下,選擇去做哪一種測試,這應該根據當前軟體過程階段和專案的本身特點來做選擇。比如,在整合測試的時候要做基準測試,在軟體產品每個釋出點要做效能測試。
白盒測試
白盒測試也稱結構測試或邏輯驅動測試,是一種按照程式內部邏輯結構和編碼結構設計測試資料並完成測試的測試方法。它是基於一個應用程式碼的內部邏輯知識,測試覆蓋全部程式碼、分支、路徑和條件。它利用檢視程式碼功能和實現方式得到的資訊來確定那些需要測試、哪些不需要測試、如何展開測試。
“白盒”測試一般分為靜態測試和動態測試,靜態測試不實際執行軟體,主要是對軟體的程式設計格式、結構等方面進行評估,採用的是程式碼走查、程式碼審查、程式結構分析、控制流分析、資料流測試及資訊流分析等;而動態測試需要在Host環境或Target環境中實際執行軟體,並使用設計的測試用例去探測軟體缺陷。所採用的設計方法是邏輯覆蓋(包括語句覆蓋、分支覆蓋、條件覆蓋、分支條件覆蓋自己路徑覆蓋)。
它是知道產品內部工作過程,可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行,按照程式內部的結構測試程式,檢驗程式中的每條通路是否都有能按預定要求正確工作,而不顧它的功能,“白盒”測試的主要方法有邏輯驅動、基路測試等,主要用於軟體驗證。
“白盒”法全面瞭解程式內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這一方案時,測試者必須檢查程式的內部結構,從檢查程式的邏輯著手,得出測試資料。貫穿程式的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一,窮舉路徑測試決不能查出程式違反了設計規範,即程式本身是個錯誤的程式。第二,窮舉路徑測試不可能查出程式中因遺漏路徑而出錯。第三,窮舉路徑測試可能發現不了一些與資料相關的錯誤。
黑盒、白盒,動態、靜態測試之間的關係
它們只是一個測試的不同分類角度而已,同一個測試,既有可能屬於黑盒測試,也有可能屬於動態測試;既有可能屬於靜態測試,也有可能屬於白盒測試。而且它們之間還有包括交叉的關係,總結以下4句話:
黑盒測試有可能是動態測試(執行程式,只看輸入和輸出),也有可能是靜態測試(不執行程式,只是檢視介面)
“白盒”測試有可能是動態測試(執行程式,並分析程式碼結構),也有可能是靜態測試(不執行程式,只是靜態檢視程式碼)
動態測試有可能是“黑盒”測試(執行程式,只看輸入和輸出),也有可能是“白盒”測試(執行程式,並分析程式碼結構)
靜態測試有可能是“黑盒”測試(不執行程式,只是檢視介面),也有可能是“白盒”測試(不執行程式,只是靜態檢視程式碼)
灰盒測試
灰盒測試是一種綜合測試法,它將“黑盒”測試、“白盒”測試結合在一起,是基於程式執行時的外部表現又結合程式內部邏輯結構來設計用例,執行程式並採集程式路徑執行資訊和外部使用者介面結果的測試技術。可以這樣理解,“灰盒”測試關注輸出對於輸入的正確性,同時也關注內部表現,但這種關注不像“白盒”那樣詳細、完整,只是通過一些表徵性的現象、事件、標誌來判斷內部的執行狀態,有時候輸出是正確的,但內部其實已經錯誤了,這種情況非常多,如果每次都通過“白盒”測試來操作,效率會很低,因此需要採取這樣的一種灰盒的方法。灰盒測試結合了“白盒”測試和“黑盒”測試的要素.它考慮了使用者端、特定的系統知識和操作環境。它在系統元件的協同性環境中評價應用軟體的設計。
2、按是否執行程式分為:
(1)靜態測試(static testing):是指不實際執行被測軟體,而只是靜態地檢查程式程式碼、介面或文件可能存在的錯誤的過程。
靜態測試包括:
對於程式碼測試,主要是測試程式碼是否符合相應的標準和規範。
對於介面測試,主要測試軟體的實際介面與需求中的說明是否相符。
對於文件測試,主要測試使用者手冊和需求說明是否真正符合使用者的實際需求。
(2)動態測試(dynamic testing),是指實際執行被測程式,輸入相應的測試資料,檢查輸出結果和預期結果是否相符的過程
3、按階段劃分:
(1)單元測試(unit testing),是指對軟體中的最小可測試單元進行檢查和驗證。
樁模組(stud)是指模擬被測模組所呼叫的模組,驅動模組(driver)是指模擬被測模組的上級模組,驅動模組用來接收測試資料,啟動被測模組並輸出結果。
(2)整合測試(integration testing),是的下一階段,是單元測試指將通過測試的單元模組組裝成系統或子系統,再進行測試,重點測試不同模組的介面部門。
整合測試就是用來檢查各個單元模組結合到一起能否協同配合,正常執行。
(3)系統測試(system testing),指的是把整個軟體系統看做一個整體進行測試,包括對功能、效能,以及軟體所執行的軟硬體環境進行測試。
系統測試的主要依據是《系統需求規格說明書》文件。
(4)驗收測試(acceptance testing),指的是在系統測試的後期,以使用者測試為主,或有測試人員等質量保障人員共同參與的測試,它也是軟體正式交給使用者使用的最後一道工序。
驗收測試又分為a測試和beta測試,其中a測試指的是由使用者、 測試人員、開發人員等共同參與的內部測試,而beta測試指的是內測後的公測,即完全交給終端使用者測試。
(5)迴歸測試(regression testing)是指對軟體的新的版本測試時,重複執行上一個版本測試時的用例。
4、按執行時是否需要人工干預劃分
(1)人工測試:人工測試是由測試人員手工逐步執行所有的活動,並觀察每一步是否成功完成。人工測試是任何測試活動的一部分,在開發初始階段軟體及其使用者介面還未足夠穩定時尤其有效,因為這時自動化並不能發揮顯著作用。即使在開發週期很短以及自動化測試驅動的開發過程中,人工測試技術依然具有重要的作用。
(2)自動化測試:使用自動化測試工具來進行測試,這類測試一般不需要人干預,通常在GUI、效能等測試和功能測試中用得較多。通過錄制測試指令碼,然後執行這個測試指令碼來實現測試過程的自動化。自動化測試工具有QTP/UFT、AutoRunner和TAR等。
5、按測試實施的組織劃分
(1)開發方測試:通常也叫“難證測試”或“alpha”。開發方通過檢驗和提供客觀證據,證實軟體的實現是否滿足規定的需求。驗證測試是在軟體開發環境下,由開發者檢測與證實軟體的實現是否滿足軟體設計說明或軟體需求說明的要求。主要是指在軟體開發完成以後,開發方對要提交的軟體進行全面的自我檢查與驗證,可以和軟體的“系統測試”一併進行
(2)使用者測試:是在使用者的應用環境下,使用者通過執行和使用軟體,檢測與核實軟體實現是否符合自己預期的要求。通常情況使用者測試不是指使用者的“驗收測試”,而是指使用者的使用性測試,由使用者找出軟體的應用過程中發現的軟體的缺陷與問題,並對使用質量進行評價。
beta測試通常被看成一種“使用者測試”。beta測試主要是把軟體產品有計劃地免費分發到目標市場,讓使用者大量使用,並評價、檢查軟體。通過使用者各種方式的大量使用,來發現軟體存在的問題與錯誤,把資訊反饋給開發者修改。beta測試中廠商攻取的資訊,可以有助於軟體產品的成功釋出。
(3)第三方測試:介於軟體開發方和使用者方之間的測試組織的測試。第三方測試也稱為獨立測試。軟體質量工程強調開展獨立驗證和確認(IV&V)活動。IV&V是由在技術、管理和財務上與開發組織具有規定程度獨立的組織執行驗證和確認過程。軟體第三方測試也就是由在技術、管理和財務上與開發方和使用者方相對獨立的組織進行的軟體測試。情況下是在模擬使用者真實應用環境下,進行軟體確認測試。
5、其他測試型別:
(1)冒煙測試(smoke testing),是指在對一個新版本進行大規模的測試之前,先驗證一下軟體的基本功能是否實現,是否具備可測性。
(2)隨機測試(random testing),是指測試中所有的輸入資料都是隨機生成的,其目的是模擬使用者的真實操作,並發現一些邊緣性的錯誤。
(3)使用者介面測試(User interfacetesting)簡稱UI測試,測試使用者介面的功能模組的佈局是否合理,整體風格是否一致和各個控制元件的放置位置是否符合客戶使用習慣,更重要的是要符合操作便捷,導航簡單易懂,介面中文字是否正確,命名是否統一,頁面是否美觀,文字、圖片組合是否完美等等
(4)隨機測試(Ad-hoc testing),軟體測試中除了根據測試用例和測試說明書進行測試外,還需要進行隨機測試(Ad-hoc testing),主要是根據測試者的經驗對軟體進行功能和效能抽查,是保證測試覆蓋完整性的有效方式和過程。
(5)本地化測試(Localization testing),本地化就是將軟體版本語言進行更改,比如將英文的windows改成中文的windows就是本地化。本地化測試的物件是軟體的本地化版本。本地化測試的目的是測試特定目標區域設定的軟體本地化質量。本地化測試的環境是在本地化的作業系統上安裝本地化的軟體。從測試方法上可以分為基本功能測試,安裝/解除安裝測試,當地區域的軟硬體相容性測試。測試的內容主要包括軟體本地化後的介面佈局和軟體翻譯的語言質量,包含軟體、文件和聯機幫助等部分。
(6)解除安裝測試(UninstallTesting),解除安裝測試是對軟體的全部、部分或升級解除安裝處理過程的測試。主要是測試軟體能否解除安裝,解除安裝是否乾淨,對系統有無更改,在系統中的殘留與後來的生成檔案如何處理等。還有原來更改的系統值是否修改回去.
(7)安全性測試(Security Testing),安全測試是測試系統在防止非授權的內部或外部使用者的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。安全測試檢查系統對非法侵入的防範能力。安全測試期間,測試人員假扮非法入侵者,採用各種辦法試圖突破防線。
例如:①想方設法擷取或破譯口令;②專門定做軟體破壞系統的保護機制;③故意導致系統失敗,企圖趁恢復之機非法進入;④試圖通過瀏覽非保密資料,推導所需資訊,等等。理論上講,只要有足夠的時間和資源,沒有不可進入的系統。因此係統安全設計的準則是,使非法侵入的代價超過被保護資訊的價值。此時非法侵入者已無利可圖。
安全性一般分為兩個層次,即應用程式級別的安全性和系統級別的安全性,針對不同的安全級別,其測試策略和方法也不相同。
應用程式級別的安全性,包括對資料或業務功能的訪問,在預期的安全性情況下,操作者只能訪問應用程式的特定功能、有限的資料。其測試是核實操作者只能訪問其所屬使用者型別已被授權訪問的那些功能或資料。測試時,確定有不同許可權的使用者型別,建立各使用者型別並用各使用者型別所特有的事務來核實其許可權,最後修改使用者型別併為相同的使用者重新執行測試。
系統級別的安全性,可確保只有具備系統訪問許可權的使用者才能訪問應用程式,而且只能通過相應的閘道器來訪問,它包括對系統的登入或遠端訪問。其測試是核實只有具備系統和應用程式訪問許可權的操作者才能訪問系統和應用程式。
(8)相容性測試(Compatibility Testing),相容測試是測試軟體在一個特定的硬體/軟體/作業系統/網路等環境下的效能如何。向上相容向下相容,軟體相容硬體相容。軟體的相容性有很多需要考慮的地方。