軟件測試

概述
程序+文檔+數據=軟件

狹義的軟件測試定義：爲發現軟件缺陷而執行程序或系統的過程

廣義的軟件測試定義：人工或自動地運行或測定某系統的過程，目的在於檢驗它是否知足規定的需求或弄清預期結果和實際結果間的差異

爲何要作軟件測試

發現軟件缺陷
功能錯
功能遺漏
超出需求部分（多此一舉）
性能不符合要求
軟件質量高低：是否符合用戶習慣、符合用戶需求
測試的任務

找出
定位
修改
修改後要作迴歸測試，對已修改的部分進行再次的測試，避免引入新的錯誤
測試用例的定義和組成部分

測試用例是爲特定的目的而設計的一組測試輸入、執行條件和預期的結果。測試用例是執行的最小實體。簡單地說，測試用例就是設計一個場景，使軟件程序在這種場景下，必須可以正常運行而且達到程序所設計的執行結果。
包含
用例ID
用例名稱
測試目的
測試環境
前提條件
測試步驟
預期結果
其餘信息
一個好的高質量的測試用例在於能發現至今未發現的錯誤，一個成功的測試是發現了至今未發現的錯誤的測試(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

兩個方向

找錯誤，反向思惟。
證實能正常工做，正向思惟。
目前的方法出發點通常是「找錯誤」，由於無法證實軟件是正確的。
用戶需求

要求（用戶想要） 需求（用戶目的） 須要（用戶內在慾望）
牙膏 清潔牙齒 我的魅力（我的外表整潔）
何時中止測試

繼續測試沒有產生新的失效
繼續測試沒有發現新缺陷
回報很小
以達到要求的覆蓋
沒法考慮新的測試用例（若已遵循測試規則和指導方針，則能夠選擇）
測試過程模型
缺陷具備放大的特色，隨着階段的推動發現bug的成本會指數型上升，因此並非代碼級的測試才叫測試，而是開發過程各個階段越早開始測試越好。

瀑布模型：需求分析->設計（概要、詳細）->編程->測試（單元、集成、系統）->維護
V模型（瀑布-改）：在軟件開發的生存期，開發活動和測試活動幾乎同時的開始，如概要設計階段結束後集成測試的測試用例就出來了、詳細設計階段結束後單元測試的測試用例也就出來了等
W模型（V模型更加細化、每步都加測試，邊造軟件邊進行測試）：需求分析加了需求測試、概要設計加了功能測試、詳細設計加了設計測試、編碼加了單元測試、集成加了集成測試、確認加了確認測試、驗收加了系統測試
H模型：無實際意義，僅說明能夠獨立測試
軟件測試的原則
全部的測試都應追溯到用戶的需求
儘早地和不斷地進行軟件測試（缺陷具備放大的特色，測試成本隨階段深刻而上升）
8-2原則
測試中發現的錯誤80%極可能起源於程序中的20%
提早測試可發現80%，系統測試找出剩餘bug的80%（整體的16%），最後的4%可能只有用戶大範圍長時間使用後才暴露出來
80%的工程用在20%的需求上（即關鍵需求）
…
軟件缺陷的寄生蟲性：找到的缺陷越多說明軟件遺留的缺陷越多
避免本身測試本身的程序
迴歸測試：避免引入新的錯誤
軟件測試流程
制定測試計劃->測試設計->測試開發->測試執行->評估測試

注意

測試不是開發後期的一個階段
測試入門其實稍容易，但要求技術同樣高
測試多數狀況下不能覆蓋全部輸入
不要「有時間多測，沒時間少測」
軟件測試不止是測試人員的事，也是開發人員的事
調試和測試不同
測試絕非只運行一下軟件看結果對不對
L10N：本地化測試

I18N：國際化測試

黑盒測試
等價類劃分與邊界值分析
如何劃分有效和無效等價類（一些經常使用原則）

若是一個變量在某一個範圍內，給它一個有效等價類兩個無效等價類
若是一個變量取值在某一個集合範圍內，可在集合內取一個有效等價類在集合外取一個無效等價類
若是一個變量的條件是「必須怎樣」、「必定會是怎樣」則去一個值知足「必需要」的條件再取多個不知足的從多個角度去違背這個條件
若是一個變量是布爾類型，則取一個對的一個錯的
在找到有效等價類和無效等價類後如何找測試數據

有效等價類：要儘量多的覆蓋有效等價類
無效等價類：每找到一組數據要至少覆蓋一組無效等價類
若是功能模塊的輸入是多個，多個自變量放在一塊兒如何找有效等價類、無效等價類、測試數據，4鍾方法：

以一個具備自變量X一、X2的函數F爲例，X1取值範圍爲[a, b)、[b, c)、[c, d]；X2取值範圍爲[e, f)、[f, g]。僅考慮有標記的方塊內爲通常等價類測試（不處理無效數據的測試）、全部方塊都考慮爲健壯等價類測試（進行無效數據處理的測試）

g |_______|_______|_______|_______|_______|
f |_______|///////|///////|///////|_______|
e |_______|///////|///////|///////|_______|
|_______|_______|_______|_______|_______|
a b c d
1
2
3
4
5
弱通常等價類
有假設前提：是單缺陷的，即假設系統出現的缺陷不多是由兩個及以上的輸入變量共同出現缺陷而引發的。
選取的測試用例覆蓋全部的有效等價類
對於X1（橫軸）：[a, b)、[b, c)、[c, d]都須要覆蓋到；對於X2（縱軸）：[e, f)、[f, g]都須要覆蓋到。保證了這兩點的狀況下，就能夠任意取點了
g |_______|_______|_______|_______|_______|
f |_______|_______|____x__|_______|_______|
e |_______|___x___|_______|___x___|_______|
|_______|_______|_______|_______|_______|
a b c d
1
2
3
4
5
強通常等價類
基於多缺陷假設
選取的測試用例覆蓋全部的有效等價類的笛卡爾積（集合A{a1,a2,a3} 集合B{b1,b2} 他們的 笛卡爾積 是 A*B ={(a1,b1),(a1,b2),(a2,b1),(a2,b2),(a3,b1),(a3,b2)} ）
對於X1（橫軸）：[a, b)、[b, c)、[c, d]；X2（縱軸）：[e, f)、[f, g]，笛卡爾積的結果就是全部的格子，因此必須全部格子都取點
g |_______|_______|_______|_______|_______|
f |_______|___x___|___x___|___x___|_______|
e |_______|___x___|___x___|___x___|_______|
|_______|_______|_______|_______|_______|
a b c d
1
2
3
4
5
弱健壯等價類
有假設前提：是單缺陷的，即假設系統出現的缺陷不多是由兩個及以上的輸入變量共同出現缺陷而引發的。
考慮無效值，對有效輸入，測試用例的設計等同於弱通常等價類；對無效輸入，測試用例須要保證擁有一個無效值（好比某一變量的有效類的取值範圍爲x、y、z，則無效類爲x-和z+，加起來取值範圍一共：x-、x、y、z、z+），並保持其他的值都是有效的。
因此以下圖，在保證弱通常等價類的取點後，還須要分別保證X一、X2中有1個屬於無效輸入的兩個額外的取值範圍，另外一個屬於有效輸入的本來取值範圍（如X1取無效X2取有效或X1取有效X2取無效，並所有覆蓋無效範圍）

g |_______|_______|_______|___O___|_______|
f |_______|_______|___x___|_______|___O___|
e |___O___|___x___|_______|___x___|_______|
|_______|___O___|_______|_______|_______|
a b c d
1
2
3
4
5
強健壯等價類
基於多缺陷假設
全部的取值範圍取笛卡爾積（好比某一變量的有效類的取值範圍爲x、y、z，則無效類爲x-和z+，加起來取值範圍一共：x-、x、y、z、z+，再與另外一變量的取值範圍取笛卡爾積）
g |___O___|___O___|___O___|___O___|___O___|
f |___O___|___x___|___x___|___x___|___O___|
e |___O___|___x___|___x___|___x___|___O___|
|___O___|___O___|___O___|___O___|___O___|
a b c d
1
2
3
4
5
在找測試數據時(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

對於單缺陷的，即只有一個輸入變量是處於無效等價類，其餘全部輸入變量都處在有效等價類中。包含：
單缺陷有效值
單缺陷無效值
對於多缺陷的，即多個輸入變量同時出現錯誤引發的。包含：
有效值
無效值
與等價類劃分密切相關的就是邊界值分析。先劃分等價類，再結合邊界值產生測試用例。邊界值分析中也有假設前提：單缺陷。包含4種設計測試用例的方法：

通常的邊界值分析
有效範圍：最小的、比最小大一點的、正常值、比最大小一點、最大值
無效範圍：比最小更小、比最大更大
共7個，再分單缺陷和多缺陷，這樣設計測試用例的個數就會指數上升
- 單變量假設 多變量假設
有效值 **通常邊界值**5n-(n-1)【n-1個變量取正常值】=4n+1【僅考慮有效區間單個變量邊界值（通常邊界值）：用最小值、略高於最小值、正常值、略低於最大值和最大值。】 **通常最壞狀況邊界值**5^n【僅考慮有效區間多個變量邊界值同時做用（通常最壞狀況邊界值）：用各個變量最小值、略高於最小值、正常值、略低於最大值和最大值的笛卡爾積。】
無效值 **健壯性邊界值**7n-(n-1)=6n+1【 同時考慮有效區間和無效區間單個變量邊界值（健壯邊界值）：除了最小值、略高於最小值、正常值、略低於最大值、最大值，還要有略超過最大值和略小於最小值的值。】 **健壯最壞狀況邊界值**7^n【同時考慮有效區間和無效區間多個變量邊界值同時做用（健壯最壞狀況邊界值）：用各個變量最小值、略高於最小值、正常值、略低於最大值、最大值、略超過最大值和略小於最小值的笛卡爾積。】
常見的邊界值

16bit整數32767～-32768
報表第一行和最後一行
屏幕光標最左上和最右下
數組的第一個和最後一個
循環的第0、一、倒數第1、倒數第二次
決策表
適合於問題有多個條件，條件有多種組合執行不一樣操做（有不少if、else if、else），不能表達循環結構

最嚴格、最具備邏輯性

斷定表
| 條件樁 | 條件項 | ... | 動做項 |
| 動做樁 | 動做項 | ... | 動做項 |
1
2
3
規則：條件的任意組合，斷定表中的一列（貫穿條件項和動做項）。斷定表有多少列就表明有多少條規則。

規則的化簡：有的規則相互包含，能夠化簡

因果圖
找出全部的緣由，找出結果，可能還有中間結果的產生，在畫因果圖時注意。

從輸入考慮
I：連虛線出去，如連到ab，表示ab中至少有一個必須成立
E：連虛線出去，如連到ab，表示ab不能同時成立
R：如處於a指向b的虛線三角箭頭上，表示a出現時b也必須出現，不可能一個出現一個不出現
從輸出考慮
M：如處於a指向b的虛線三角箭頭上，表示a爲1時b必須爲0，a爲0時b值不定
連線：恆等
～：非
∨：或
∧：且
ci：緣由
ei：結果
畫出因果圖後，根據圖獲得決策表從而獲得相應的測試數據：緣由節點+中間節點爲條件樁，結果結點爲動做樁

白盒測試
邏輯覆蓋
語句覆蓋->斷定覆蓋->斷定/條件覆蓋->條件組合覆蓋->路徑覆蓋
\_條件覆蓋/
1
2
語句覆蓋：每條語句執行一次
斷定覆蓋：每一個斷定分支至少執行一次
條件覆蓋：每一個斷定條件應取到各類可能的值
斷定/條件覆蓋：同時知足斷定和條件
條件組合覆蓋：每一個斷定條件的每一種組合各出現一次
路徑覆蓋：每一條可能的路徑至少執行一次
關係：

條件組合覆蓋＞斷定覆蓋＞語句覆蓋(即若是達到條件組合覆蓋，就達到斷定覆蓋和語句覆蓋：若是達到斷定覆蓋，就達到語句覆蓋，下面相似理解)。
條件組合覆蓋＞條件覆蓋。
條件覆蓋不必定包含斷定覆蓋、語句覆蓋。
斷定覆蓋不必定包含條件覆蓋。
路徑覆蓋，斷定覆蓋＞語句覆蓋。
基本路徑測試
基於程序圈複雜度產生的測試方法，畫出控制流程圖，算圈複雜度，找到獨立路徑並壓縮爲基本路徑集合，根據集合中每條路徑設計用例。把複合邏輯表達式拆成單個表達式

圈複雜度用於計算程序的基本的獨立路徑數目（每條新的獨立路徑都必須包含一條新的有向邊，從入口到出口互不相同的路徑數）

圈複雜的V(G) = e - n + 2p【邊-節點+2*鏈接區域數，鏈接區域p一般爲1】=P+1【斷定節點數+1】
通常來講，一個單元模塊的最大複雜度V(G)<10
若是把覆蓋的路徑數壓縮到必定限度內，例如程序中的循環體只執行0次和1次，就成爲基本路徑測試，經過導出基本路徑集合，從而設計測試用例，保證這些路徑至少經過一次

基於數據流的測試
基於真的數據定義到數據的使用來進行測試，須要找到定義的節點（包括賦值的和比較的）和使用的節點(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

定義節點DEF：輸入語句、賦值語句、循環語句和過程調用；變量的值會發生變化的語句
使用節點USE：數出語句、賦值語句、條件語句、循環控制語句、過程調用
須要找到全部這段功能代碼從哪裏開始定義，到哪裏開始執行，把路徑找出來。什麼是定義使用路徑（某一變量在最初節點定義到最終節點被使用）、定義清除路徑（某一個變量從它的定義節點到使用節點這個過程當中沒有對這個變量進行二次定義）

循環測試
前提是程序是結構化的。

簡單循環測試

0次經過循環
1次經過循環
2次經過循環
m次經過循環（m<=循環最大次數）
m-1，m，m+1次經過循環
測試的過程
單元測試
單元測試的內容：5點（簡答題）

模塊接口的測試
局部數據結構的測試
獨立路徑測試
錯誤處理測試
邊界測試
單元測試的模塊

被測模塊：被測試的程序的模塊
驅動模塊：用來模擬測試模塊的上一級模塊，至關於被測模塊的主程序
樁模塊：用來模擬被測模塊工做過程當中所調用的模塊
單元測試的工具：Junit相關的概念：以插入斷言的方式進行測試（相似黑盒測試）

針對被測代碼或者被測的功能點先建立測試類，而後在類裏面建立一個個測試方法。經過實例化對象調用被測方法，用斷言進行實際值預期值比較。
單元測試的方法

以白盒測試法爲主（覆蓋），先靜態檢查代碼是否符合規範，再動態運行代碼，檢查結果。除了須要驗證結果是否正確，還須要檢查程序的容錯能力、邊界值處理等問題。
集成測試
一次性的集成big-bang：把全部經過了單元測試的模塊按設計要求一次所有組裝起來，而後進行總體測試。時間隨變短了但急於求成。
漸進地集成
自上而下：從主程序模塊開始按深度或廣度優先策略邊組裝邊測試
自下而上：從最底層模塊開始組裝和集成測試
漢堡包：二者進行結合，樹狀圖每層畫線，頂層採用自頂向下，底層採用自底向上
相鄰的集成：上下三層進行集成
成對集成：先成對再相鄰
基於MM路徑的集成：MM路徑不是可執行路徑，描述單元之間的控制轉移。
最終獲得調用圖，而後就會到基本路徑測試，找複雜度，找路徑，獲得測試用例的套路

系統測試
黑盒爲主(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

對哪些內容進行系統測試（9個）：易用性、國際化本地化、性能、功能、界面、兼容性、安全性、文檔、安裝

Web系統測試
具體到如Web系統測試中的功能測試包含哪些內容、對cookies裏面的內容進行測試屬於Web系統測試裏面的哪一項的測試（屬於功能測試）

功能測試
頁面內容測試
頁面連接測試
表單測試
Cookies測試、Session測試
設計語言測試
數據庫測試
性能測試（負載/壓力）
鏈接速度測試
測試工具 LoadRunner
負載測試
壓力測試
網頁性能Firefox插件：Yslow，Findbug，PageSpeed
Dynatrace檢查網頁性能
可靠性測試：不間斷測試，看多久不出錯
用戶界面測試/易用性測試
導航測試
圖形測試
內容測試
總體界面測試
安全性測試
兼容性測試
接口測試
服務器接口
外部接口
錯誤處理
主要講了性能測試的含義和怎麼作，如所涵蓋的含義如壓力測試怎麼作、負載測試怎麼作等

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。
時間性能：軟件的一個具體事務的響應時間
空間性能：軟件運行時所消耗的系統資源
我讓你背1袋米(輕鬆)
我讓你背1袋米，但讓你去操場上跑圈，看多久累倒（吃力）
我讓你背3袋米去操場跑圈，看多久累倒（極限）
我讓你背1袋、2袋、3袋、4袋…發現最多背3袋
負載測試讓被測系統在其能忍受的壓力的極限範圍以內連續運行，來測試系統的可靠性。
系統可否處理某個時刻同時訪問Web系統/某個頁面的用戶數量
超過了這個數量，會出現什麼現象？
在線數據處理的數量
負載/壓力測試關注什麼？
驗證系統可否同一時間響應大量的用戶，用戶傳送大量數據時可否響應，系統可否長時間運行。
瞬間訪問高峯
每一個用戶傳送大量數據
長時間使用
LoadRunner性能測試工具原理：錄製+回放模擬用戶實際操做場景，監控並分析運行結果。
自動化測試
錄製+回放+腳本 是主要的方式

經常使用的自動化測試的工具，哪些種類，每種有什麼工具

功能測試工具：QTP性能測試工具：LoadRunner 寫腳本或者錄製腳本使用用戶自定義參數場景設計產生虛擬用戶的機制：使用控制器，來控制模擬多少用戶。使用監聽器，查看測試結果--------------------- 做者：sgyzetrov 來源：CSDN 原文：https://blog.csdn.net/S_gy_Zetrov/article/details/80879773