軟件測試-測試分類

軟件測試-測試分類
1、按軟件測試階段：
a. 單元測試
b. 集成測試
c. 系統測試
d. 驗收測試
一、單元測試
單元測試的原則：
一、儘量保證部沒測測試用例相互獨立
二、通常由代碼的編寫人員來實施

單元測試的優勢：
一、能儘早發現缺陷
二、有利於重構
三、能夠簡化集成

單元測試的缺陷
一、不可能窮盡測試，即測試用例不可能覆蓋全部的執行路徑，不可能捕捉到全部的錯誤
二、每一行代碼須要3-5行測試代碼來完成測試

單元測試框架
xUnit，好比：JUnit
例：eclipse->new->Java project->(finish)->右鍵項目->properties->Java Build Path->Add library->選擇JUnit->next->選擇Junit版本->finish
選中須要測試的類，在上右鍵->new->junit test case(勾選setUp()和tearDown() )->next( 選擇須要測試類中待測試的方法 ) -> finish()

二、集成測試
在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規格說明的要求組裝成模塊，子系統或者系統的過程當中各部分工做是否達到或者實現相應3技術指標及要求的活動。

集成測試實施方案
一、BIg Bang（一次性集成/大爆炸）：把大部分開發模塊耦合起來，造成一個完整的軟件系統，或者系統的主要組成部分，把它們拿來作測試。
二、自頂向下：遞增組裝軟件結構的方法，從主程序開始，沿控制層，逐層向下來集成，
三、自底向上（經常使用）：從程序模塊最底層模塊開始，逐層向上組裝，逐層測試。優勢是能比較好的鎖定軟件故障的所在位置。
四、核心系統集成：將核心軟件挑選出來，對這些部件進行集成測試，在測試經過的基礎上，再逐步擴展到外圍部件。
五、高頻集成測試：持續集成就是高頻次的不斷進行集成測試。

核心集成和高頻集成的結合通常是如今敏捷開發比較經常使用的集成測試方式，而自頂向下和自底向上是傳統瀑布模式主要採用的集成測試方式。

單元測試和集成測試的不一樣
一、測試對象不一樣：單元測試針對軟件的基本單元，而集成測試主要針對軟件的模塊或者子系統，主要測試模塊之間接口的關係。
二、測試的依據不一樣：單元測試主要是針對軟件的詳細設計，測試用例設計的主要依據就是詳細設計文檔，而集成測試主要是針對軟件的概要設計進行測試，測試用例的主要依據是概要。
三、測試的方法不一樣：集成測試主要關注模塊之間接口的集成，而單元測試只關心在單元的類。

三、系統測試（測試主要階段）
系統測試是將通過集成測試的軟件，做爲計算機系統的一個 部分，與系統中其餘部分結合起來，在實際運行環境下對計算機系統進行一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統的正常運行。

單元測試和集成測試不少地方會採用模擬的方式來作測試，而系統測試更多的是用真實的運行環境，來系統的對軟件進行測試。

系統測試通常要進行功能測試，性能測試，穩定性測試等多種測試類型。

系統測試主要關注系統自己的使用（功能上使用的問題），與其餘相關係統的關聯性連通性，關注系統不一樣使用壓力下的表現，關注系統在真實環境下的表現。

系統測試和集成測試的不一樣
一、測試對象不一樣：集成測試是由經過了單元測試的各個模塊所集成起來的構件，系統測試是除軟件以外，還包括計算機硬件及相關的外圍設備、數據採集的傳輸機構，支持軟件部、系統操做人員等整個系統。
二、測試時間不一樣：集成測試介於單元測試和系統測試之間，系統測試在集成測試以後
三、測試內容不一樣：集成測試主要測試各個單元模塊之間的接口，系統測試則是測試整個系統的功能和性能
四、測試角度不一樣：集成測試偏於技術角度的驗證，系統測試偏於業務角度的驗證

四、驗收測試（交付測試）
針對用戶需求，業務流程的正式測試。肯定系統是否知足驗收的標準，由用戶、客戶或者其餘受權機構決定是否接受系統。

驗收測試分爲：
用戶驗收測試
運行驗收測試
合同和規範驗收測試
alpha測試：在開發者所提供的場所和環境中運行
Bata測試：徹底脫離開發者，在用戶提供的環境中運行

2、按軟件測試手段：
a. 黑盒測試
b. 白盒測試
c. 靜態測試
d. 動態測試
e. 手工測試
f. 自動化測試
一、黑盒測試（功能測試）
只檢查程序的功能是否可以按照咱們需求規格說明的規定可以正常使用，程序可否正常的接受數據，併產生合理的輸出
黑盒測試主要經過用戶的視角，對軟件進行測試

黑盒測試的優缺點：
優勢：容易實施，不須要考慮內部實現，更貼近用戶的角度
缺點：測試覆蓋率低，通常只能覆蓋到代碼量的不到40% ，針對黑盒自動化測試，複用率較低，維護成本高

黑盒測試的主要內容
一、是否有不正確或者功能遺漏
二、在接口上，輸入是否能正確的接受，可否輸出正確的結果
三、是否有數據結構錯誤（例如數據文件）訪問錯誤
四、性能上是否能知足要求

黑盒測試的主要設計方法
一、等價類劃分：針對程序的輸入條件，將全部輸入中，等價的歸爲一類，這樣就造成若干典型的表明性的輸入，經過典型的數據進行測試用例的設計，這樣的方法稱爲等價類劃分法。
二、邊界值分析法：實際上是一種特殊的等價類，關注
三、因果圖+斷定表
四、錯誤推測法：基於經驗或者直覺，判斷程序中可能出現的錯誤，進而針對性設計測試用例的方法
五、流程圖分析法
六、正交實驗分析法:主要用於
七、狀態遷移圖法

二、白盒測試（結構化測試）
白盒測試中測試人員要對內部結構是很是瞭解，白盒測試是對程序的邏輯結構來設計測試用例，用邏輯的覆蓋率來衡量測試的完整性。

邏輯單位有：語句，條件，條件組合，分支，路徑
對應的測試覆蓋方法有：語句覆蓋，條件覆蓋，條件組合覆蓋，分支覆蓋（斷定覆蓋），路徑覆蓋，斷定和條件的組合覆蓋

白盒測試的優缺點：
優勢：迫使測試人員去仔細思考軟件的實現，理解原理。能夠檢測帶代碼中的每條分支和路徑。揭示隱藏在代碼中的錯誤，對代碼的測試比較完全。
缺點：成本高。沒法檢測代碼中遺漏的路徑和敏感性錯誤。不能直接驗證需求的正確性。

白盒測試的主要測試方法
一、代碼檢測法
二、靜態結構分析法
三、靜態質量度量法
四、邏輯覆蓋法（主要）
五、基本路徑測試法（主要）

三、灰盒測試
介於黑盒和白盒測試之間的，關注輸出對於輸入的正確性，同事也關注內部表現

四、靜態測試
靜態測試是指無需執行被測程序，而是經過評審軟件文檔或者代碼，度量程序靜態複雜度，檢查軟件是否符合編程標準，藉以發現編寫的程序的不足之處，減小錯誤出現的機率。

靜態測試的特色是程序不被運行。

靜態測試的方式有：
一、互審
二、走查
三、會議

五、動態測試
動態測試是指經過運行被測程序，檢查運行結果與預期結果的差別，並分析運行效率、正確性和健壯性。

黑盒測試中相關的方法主要是動態測試，而白盒測試中一些測試方法主要是靜態測試方法。

六、手工測試
指由專門的測試人員從用戶視角來驗證軟件是否知足設計要求的行爲，更適用針對深度的測試和強調主管判斷的測試，如衆包測試、探索式測試

七、自動化測試
使用單獨的測試工具軟件控制測試的自動化執行以及對預期和結果進行自動檢查。單元測試、接口測試、性能測試更多的是用自動化測試。

手工測試和自動化測試的比較
手工測試易發現缺陷，容易實施，創造性和靈活性。可是手工測試覆蓋量化難，重複測試效率低，不一致性、可靠性低，人力資源的依賴。
自動化測試高效率、速度快，高複用性，覆蓋使用容易度量，準確。可靠，不知疲勞。可是機械，發現缺陷率低，一次性投入較大。

3、按測試類型：
a. 功能測試
b. 性能測試
c. 安全測試
d. 兼容性測試
一、功能測試
根據產品的特性，操做描述和用戶反感，測試一個產品的特性和可操做行爲以肯定它們知足設計需求。

針對問題：
功能錯誤或遺漏，界面問題，性能錯誤（通常指軟件自己的性能錯誤），數據及訪問錯誤，初始化及終止錯誤。

測試工具（自動化）
QTP（基於關鍵字驅動，web應用）、winrunner（桌面軟件）、silkTEST、Rationalrobot；selenium、Watir、Sikuli

二、性能測試
驗證軟件系統的性能可否知足需求規格給定的指標要求。

性能測試點：
性能測試通常包括負載測試、壓力測試、穩定性測試。
性能指標：併發用戶數、每秒事務數TPS、系統響應時間、設備性能
測試工具：LoadRunner、Sillperformer、Jmeter、WebLoad、Apache Bench、LoadUI
靜態性能評估：YSlow、PageSpeed（均爲瀏覽器插件）

三、安全測試
安全測試：對軟件產品進行測試以確保產品安全需求和質量標準。
滲透測試：經過模擬對軟件系統的惡意攻擊行爲來評估系統安全性的一種測試。

滲透測試和安全測試
滲透測試的側重點是攻，安全測試的側重點是防。滲透測試和安全測試是點到面的過程。
OWASP：Open Web Application Security Project
OWASP Top十、 Test Guide

安全測試工具：
一、Appscan（針對web應用的漏洞掃描工具）
二、Webinspect（和Appscan功能上相似）
三、Nessus（針對服務器主機類漏洞檢查工具）
四、Nmap（端口show探工具）
五、MetaSploit（攻擊框架，包含大量插件，作滲透測試）
六、WebScarab（基於代理劫持的分析，來進行攻擊路徑的檢測）
七、Fortify（白盒測試工具，靜態分析代碼中可能出現的問題）
八、W3AF（針對web應用）

四、兼容性測試
驗證被測對象在不一樣的操做系統、硬件信息等環境下的運行狀況

3、按測試模式
a. 瀑布模型
b. 敏捷測試
c. 基於腳本的測試
d. 基於風險的測試
e. 探索式測試等
一、傳統的瀑布模型
項目測試階段：
項目計劃->需求分析->軟件設計->程序開發->軟件測試->集成維護

各階段對應輸出：
項目計劃書->需求說明書->概要設計/詳細設計說明書->產品版本->測試報告

瀑布模型每個階段都是以上一個階段的輸出做爲下一個階段的輸入。

瀑布模型優缺點
強調需求、設計的做用，前一階段完成後，只須要關注後續階段，爲項目提供了按階段劃分的檢查點，里程碑清晰，文檔規範
難以適應需求的頻繁變化，項目週期後端才能看到成果，強制的里程碑、完成時間點，文檔工做量大

從測試角度，瀑布模型並無體現軟件測試的地位和價值

二、V模型（目前使用較普遍的模型）
項目測試階段：
需求分析->概要設計->詳細設計->軟件編碼->（V轉折點）->單元測試->集成測試->系統測試->驗收測試

V模型中，強調軟件開發的協做，反映測試活動和設計分析的關係，而且將軟件的實現和驗證有機地結合了起來。

W模型（雙V模型）

X模型

H模型

三、敏捷測試（Agile Testing）
敏捷測試更加的擁抱變化

敏捷測試的特色：
強調從客戶的視角進行測試，重點關注迭代測試新功能，再也不其強調測試階段，儘早測試，不間斷測試，具有條件即測試，強調持續反饋，預防缺陷重於發現缺陷

傳統測試與敏捷測試比較

傳統測試 敏捷測試
測試是質量的最後保護着 開發和測試人員是緊密合做，你們都有責任對軟件負責
嚴格的變動管理 變動是可接受的，擁抱變動
預先的計劃和細節的準備 計劃隨着進展時常調整
重量級文檔 只須要絕對必要的文檔
各階段測試嚴格的入口和出口標準 各迭代之間已經沒有明顯的入口和出口標準
更多的在早會測試時進行重量級的自動化測試 全部階段都須要早自動化測試，每一個人都須要作，是項目集成的一部分
嚴格依賴流程執行 流程再也不須要嚴格執行
測試團隊和開發團隊是相互獨立的 團隊合做是無縫隙合做，沒有明確區分
四、基於腳本的測試
Script-based Testing SBT
Scripted Testing （ST）
Exploratory Testing（ET 探索式測試）

ET：徹底拋開測試腳本的測試

文檔測試
針對軟件產品的交付品，配套的文檔類部件的測試。如用戶手冊，使用說明，用戶幫助文檔等。

文檔測試關注點：
完整性，正確性，一致性，易理解性，易瀏覽性

可靠性測試
軟件的可靠性測試
硬件的可靠性測試

易用性測試
是指測試用戶使用軟件時是否以爲方便，是否能保證用戶使用體驗的測試類型

本地化測試
針對軟件的本地實施的針對性測試
主要測試內容：語言，書寫習慣，時區，日期格式，貨幣類型，當地風俗，法律法規，政治敏感內容

部署測試（安裝測試）
主要驗證系統部署過程，並確保軟件通過安裝測試後能夠正常使用
主要測試內容：在不一樣環境下的部署驗證，參照部署文檔執行，過程的合理、正確性，基礎數據

無障礙測試（訪問性測試）
是指軟件須要提供便於特殊人羣使用的功能，如視障8，聽障，老人，身體殘疾用戶等。

迴歸測試
軟件功能修改後，對軟件進行從新測試以確認修改沒有引入新的錯誤或致使其餘部分產生錯誤。
迴歸測試的重心在關鍵模塊和終點功能組件。
軟件研發週期中會進行屢次迴歸測試，且儘可能實現自動化。

Monkey測試（搞怪測試）
用一些隨機、稀奇古怪的方式來操做軟件，以測試系統的健壯性和穩定性

貓眼測試
來自於硬件板卡驗證術語，軟件上則用於確認代碼中的更改會按預期運行，且不會破壞整個版本的穩定性。

A/B測試
多用於互聯網行業，經過頁面提供2個版本給用戶使用並記錄相關的用戶行爲數據，來肯定更優化設計的一種測試方案。

測試實施要點
一、多個方案並行
二、每次測試僅改動一個變量
三、按照某種規則進行優勝劣汰

測試工具 Google Analytics Content Experiments，Visual Website Optimizer--------------------- 版權聲明：本文爲CSDN博主「??_zero」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/zero_201605/article/details/81902357