軟體測試

一、概述

程式+文件+資料=軟體

狹義的軟體測試定義：為發現軟體缺陷而執行程式或系統的過程

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

為什麼要做軟體測試

• 發現軟體缺陷
  軟體質量高低：是否符合使用者習慣、符合使用者需求
  • 功能錯
  • 功能遺漏
  • 超出需求部分（畫蛇添足）
  • 效能不符合要求

測試的任務

• 找出
• 定位
• 修改
• 修改後要做迴歸測試，對已修改的部分進行再次的測試，避免引入新的錯誤

測試用例的定義和組成部分

• 測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果。測試用例是執行的最小實體。簡單地說，測試用例就是設計一個場景，使軟體程式在這種場景下，必須能夠正常執行並且達到程式所設計的執行結果。
• 包含
  
  • 用例ID
  • 用例名稱
  • 測試目的
  • 測試環境
  • 前提條件
  • 測試步驟
  • 預期結果
  • 其他資訊

一個好的高質量的測試用例在於能發現至今未發現的錯誤，一個成功的測試是發現了至今未發現的錯誤的測試

兩個方向

• 找錯誤，反向思維。
• 證明能正常工作，正向思維。
• 目前的方法出發點一般是“找錯誤”，因為沒法證明軟體是正確的。

使用者需求

什麼時候停止測試

• 繼續測試沒有產生新的失效
• 繼續測試沒有發現新缺陷
• 回報很小
• 以達到要求的覆蓋
• 無法考慮新的測試用例（若已遵循測試規則和指導方針，則可以選擇）

測試過程模型

缺陷具有放大的特點，隨著階段的推進發現bug的成本會指數型上升，所以並不是程式碼級的測試才叫測試，而是開發過程各個階段越早開始測試越好。

• 瀑布模型：需求分析->設計（概要、詳細）->程式設計->測試（單元、整合、系統）->維護
• V模型（瀑布-改）：在軟體開發的生存期，開發活動和測試活動幾乎同時的開始，如概要設計階段結束後集成測試的測試用例就出來了、詳細設計階段結束後單元測試的測試用例也就出來了等
• W模型（V模型更加細化、每步都加測試，邊造軟體邊進行測試）：需求分析加了需求測試、概要設計加了功能測試、詳細設計加了設計測試、編碼加了單元測試、整合加了整合測試、確認加了確認測試、驗收加了系統測試
• H模型：無實際意義，僅說明可以獨立測試

軟體測試的原則

• 所有的測試都應追溯到使用者的需求
• 儘早地和不斷地進行軟體測試（缺陷具有放大的特點，測試成本隨階段深入而上升）
• 8-2原則
  軟體缺陷的寄生蟲性：找到的缺陷越多說明軟體遺留的缺陷越多
  • 測試中發現的錯誤80%很可能起源於程式中的20%
  • 提前測試可發現80%，系統測試找出剩餘bug的80%（總體的16%），最後的4%可能只有使用者大範圍長時間使用後才暴露出來
  • 80%的工程用在20%的需求上（即關鍵需求）
  • …
• 避免自己測試自己的程式
• 迴歸測試：避免引入新的錯誤

軟體測試流程

制定測試計劃->測試設計->測試開發->測試執行->評估測試

注意

• 測試不是開發後期的一個階段
• 測試入門其實稍容易，但要求技術一樣高
• 測試多數情況下不能覆蓋所有輸入
• 不要“有時間多測，沒時間少測”
• 軟體測試不止是測試人員的事，也是開發人員的事
• 除錯和測試不一樣
• 測試絕非只執行一下軟體看結果對不對

黑盒測試

等價類劃分與邊界值分析

如何劃分有效和無效等價類（一些常用原則）

• 如果一個變數在某一個範圍內，給它一個有效等價類兩個無效等價類
• 如果一個變數取值在某一個集合範圍內，可在集合內取一個有效等價類在集合外取一個無效等價類
• 如果一個變數的條件是“必須怎樣”、“一定會是怎樣”則去一個值滿足“必須要”的條件再取多個不滿足的從多個角度去違背這個條件
• 如果一個變數是布林型別，則取一個對的一個錯的

在找到有效等價類和無效等價類後如何找測試資料

• 有效等價類：要儘可能多的覆蓋有效等價類
• 無效等價類：每找到一組資料要至少覆蓋一組無效等價類

如果功能模組的輸入是多個，多個自變數放在一起如何找有效等價類、無效等價類、測試資料，4鍾方法：

以一個具有自變數X1、X2的函式F為例，X1取值範圍為[a, b)、[b, c)、[c, d]；X2取值範圍為[e, f)、[f, g]。僅考慮有標記的方塊內為一般等價類測試（不處理無效資料的測試）、所有方塊都考慮為健壯等價類測試（進行無效資料處理的測試）

g |_______|_______|_______|_______|_______|
f |_______|///|///|///|_______|
e |_______|///|///|///|_______|
  |_______|_______|_______|_______|_______|
          a       b       c       d

• 弱一般等價類
  • 有假設前提：是單缺陷的，即假設系統出現的缺陷很少是由兩個及以上的輸入變數共同出現缺陷而引起的。
  • 選取的測試用例覆蓋所有的有效等價類
    
    • 對於X1（橫軸）：[a, b)、[b, c)、[c, d]都需要覆蓋到；對於X2（縱軸）：[e, f)、[f, g]都需要覆蓋到。保證了這兩點的情況下，就可以任意取點了

g |_______|_______|_______|_______|_______|
f |_______|_______|____x__|_______|_______|
e |_______|___x___|_______|___x___|_______|
  |_______|_______|_______|_______|_______|
          a       b       c       d

• 強一般等價類
  • 基於多缺陷假設
  • 選取的測試用例覆蓋所有的有效等價類的笛卡爾積（集合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

• 弱健壯等價類
  
  • 有假設前提：是單缺陷的，即假設系統出現的缺陷很少是由兩個及以上的輸入變數共同出現缺陷而引起的。
  • 考慮無效值，對有效輸入，測試用例的設計等同於弱一般等價類；對無效輸入，測試用例需要保證擁有一個無效值（比如某一變數的有效類的取值範圍為x、y、z，則無效類為x-和z+，加起來取值範圍一共：x-、x、y、z、z+），並保持其餘的值都是有效的。

所以如下圖，在保證弱一般等價類的取點後，還需要分別保證X1、X2中有1個屬於無效輸入的兩個額外的取值範圍，另一個屬於有效輸入的原本取值範圍（如X1取無效X2取有效或X1取有效X2取無效，並全部覆蓋無效範圍）

g |_______|_______|_______|___O___|_______|
f |_______|_______|___x___|_______|___O___|
e |___O___|___x___|_______|___x___|_______|
  |_______|___O___|_______|_______|_______|
          a       b       c       d

• 強健壯等價類
• 基於多缺陷假設
• 所有的取值範圍取笛卡爾積（比如某一變數的有效類的取值範圍為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

在找測試資料時

• 對於單缺陷的，即只有一個輸入變數是處於無效等價類，其他所有輸入變數都處在有效等價類中。包含：
  
  • 單缺陷有效值
  • 單缺陷無效值
• 對於多缺陷的，即多個輸入變數同時出現錯誤引起的。包含：
  
  • 有效值
  • 無效值

與等價類劃分密切相關的就是邊界值分析。先劃分等價類，再結合邊界值產生測試用例。邊界值分析中也有假設前提：單缺陷。包含4種設計測試用例的方法：

• 一般的邊界值分析
• 有效範圍：最小的、比最小大一點的、正常值、比最大小一點、最大值
• 無效範圍：比最小更小、比最大更大
• 共7個，再分單缺陷和多缺陷，這樣設計測試用例的個數就會指數上升

常見的邊界值

• 16bit整數32767～-32768
• 報表第一行和最後一行
• 螢幕游標最左上和最右下
• 陣列的第一個和最後一個
• 迴圈的第0、1、倒數第一、倒數第二次

決策表

適合於問題有多個條件，條件有多種組合執行不同操作（有很多if、else if、else），不能表達迴圈結構

最嚴格、最具有邏輯性

判定表
| 條件樁 | 條件項 | ... | 動作項 |
| 動作樁 | 動作項 | ... | 動作項 |

規則：條件的任意組合，判定表中的一列（貫穿條件項和動作項）。判定表有多少列就代表有多少條規則。

規則的化簡：有的規則相互包含，可以化簡

因果圖

找出所有的原因，找出結果，可能還有中間結果的產生，在畫因果圖時注意。

• 從輸入考慮
  
  • I：連虛線出去，如連到ab，表示ab中至少有一個必須成立
  • E：連虛線出去，如連到ab，表示ab不能同時成立
  • R：如處於a指向b的虛線三角箭頭上，表示a出現時b也必須出現，不可能一個出現一個不出現
• 從輸出考慮
  連線：恆等
  • M：如處於a指向b的虛線三角箭頭上，表示a為1時b必須為0，a為0時b值不定
• ～：非
• ∨：或
• ∧：且
• ci：原因
• ei：結果

畫出因果圖後，根據圖得到決策表從而得到相應的測試資料：原因節點+中間節點為條件樁，結果結點為動作樁

白盒測試

邏輯覆蓋

語句覆蓋->判定覆蓋->判定/條件覆蓋->條件組合覆蓋->路徑覆蓋
      \_條件覆蓋/

• 語句覆蓋：每條語句執行一次
• 判定覆蓋：每個判定分支至少執行一次
• 條件覆蓋：每個判定條件應取到各種可能的值
• 判定/條件覆蓋：同時滿足判定和條件
• 條件組合覆蓋：每個判定條件的每一種組合各出現一次
• 路徑覆蓋：每一條可能的路徑至少執行一次

關係：

• 條件組合覆蓋＞判定覆蓋＞語句覆蓋(即如果達到條件組合覆蓋，就達到判定覆蓋和語句覆蓋：如果達到判定覆蓋，就達到語句覆蓋，下面類似理解)。
• 條件組合覆蓋＞條件覆蓋。
• 條件覆蓋不一定包含判定覆蓋、語句覆蓋。
• 判定覆蓋不一定包含條件覆蓋。
• 路徑覆蓋，判定覆蓋＞語句覆蓋。

基本路徑測試

基於程式圈複雜度產生的測試方法，畫出控制流程圖，算圈複雜度，找到獨立路徑並壓縮為基本路徑集合，根據集合中每條路徑設計用例。把複合邏輯表示式拆成單個表示式

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

• 圈複雜的V(G) = e - n + 2p【邊-節點+2*連線區域數，連線區域p通常為1】=P+1【判定節點數+1】
• 一般來說，一個單元模組的最大複雜度V(G)<10

如果把覆蓋的路徑數壓縮到一定限度內，例如程式中的迴圈體只執行0次和1次，就成為基本路徑測試，通過匯出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次

基於資料流的測試

基於真的資料定義到資料的使用來進行測試，需要找到定義的節點（包括賦值的和比較的）和使用的節點

• 定義節點DEF：輸入語句、賦值語句、迴圈語句和過程呼叫；變數的值會發生變化的語句
• 使用節點USE：數出語句、賦值語句、條件語句、迴圈控制語句、過程呼叫

需要找到所有這段功能程式碼從哪裡開始定義，到哪裡開始執行，把路徑找出來。什麼是定義使用路徑（某一變數在最初節點定義到最終節點被使用）、定義清除路徑（某一個變數從它的定義節點到使用節點這個過程中沒有對這個變數進行二次定義）

迴圈測試

前提是程式是結構化的。

簡單迴圈測試

• 0次通過迴圈
• 1次通過迴圈
• 2次通過迴圈
• m次通過迴圈（m<=迴圈最大次數）
• m-1，m，m+1次通過迴圈

測試的過程

單元測試

單元測試的內容：5點（簡答題）

• 模組介面的測試
• 區域性資料結構的測試
• 獨立路徑測試
• 錯誤處理測試
• 邊界測試

單元測試的模組

• 被測模組：被測試的程式的模組
• 驅動模組：用來模擬測試模組的上一級模組，相當於被測模組的主程式
• 樁模組：用來模擬被測模組工作過程中所呼叫的模組

單元測試的工具：Junit相關的概念：以插入斷言的方式進行測試（類似黑盒測試）

• 針對被測程式碼或者被測的功能點先建立測試類，然後在類裡面建立一個個測試方法。通過例項化物件呼叫被測方法，用斷言進行實際值預期值比較。

單元測試的方法

• 以白盒測試法為主（覆蓋），先靜態檢查程式碼是否符合規範，再動態執行程式碼，檢查結果。除了需要驗證結果是否正確，還需要檢查程式的容錯能力、邊界值處理等問題。

整合測試

• 一次性的整合big-bang：把所有通過了單元測試的模組按設計要求一次全部組裝起來，然後進行整體測試。時間隨變短了但急於求成。
• 漸進地整合
  
  • 自上而下：從主程式模組開始按深度或廣度優先策略邊組裝邊測試
  • 自下而上：從最底層模組開始組裝和整合測試
  • 漢堡包：兩者進行結合，樹狀圖每層畫線，頂層採用自頂向下，底層採用自底向上
    相鄰的整合：上下三層進行整合
    成對整合：先成對再相鄰
    基於MM路徑的整合：MM路徑不是可執行路徑，描述單元之間的控制轉移。

最終得到呼叫圖，然後就會到基本路徑測試，找複雜度，找路徑，得到測試用例的套路

系統測試

黑盒為主

對哪些內容進行系統測試（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
  
  • 寫指令碼或者錄製指令碼
  • 使用使用者自定義引數
  • 場景設計
  • 產生虛擬使用者的機制：使用控制器，來控制模擬多少使用者。
  • 使用監聽器，檢視測試結果

若是對你有幫助~點贊關注~　持續分享，加入我們，642830685。群內免費領取最新軟體測試大廠面試資料和Python自動化、介面、框架搭建學習資料！技術大牛解惑答疑，同行一起交流。