編輯&整理：Xu An

一、基本概念

1、軟件=程序+文檔+數據+服務

2、軟件的特點：依托具體的硬件設備運行

3、軟件測試定義：確保被測系統滿足要求

4、測試目的：不是發現缺陷，而是滿足用戶需求

5、軟件測試過程（流程） 計例搭測評

（1）制定測試計劃

（2）設計和生成測試用例（編寫測試用例的過程中是沒有源代碼的，根據需求寫）

（3）搭建測試環境

（4）執行測試

（5）測試總結與評估

6、 （1）測試工作應該具備的素質：細心，耐心，溝通，能力，編程基礎

（2）原則：

從需求階段盡早介入

貫穿於整個聲明周期

標準是用戶需求

測試前準備好試數據和結果

包含合理輸入與不合理輸入

程序提交測試後，由專門的測試人員進行測試

嚴格執行測試計劃，排除隨意性

對每一個測試做全面的檢查

註意測試中的群體現象

（3）誤區：

測試等於調試

軟件需求規格說明詳細包含所有用戶需求

軟件測試可以提高軟件質量

7、測試分類

（1）執行時是否需要人工幹預

人工測試

自動化測試（性能測試，測並發）：通過測試工具、測試腳本手段對軟件產品進行自動測試，適用於長期的項目，需求穩定，對測試人員有編碼能力的要求

a、自動化可以處理：單元測試（CodeReview，數據處理層）、服務測試（模塊接口測試，web接口測試，業務邏輯層）、UI測試（功能，性能，安全，UI界面層）

b、自動化測試適用場合：回歸測試、頻繁測試、跨平臺測試、測試過程和驗證點比較穩定的 c、不適用的場合：隨機測試、時間短、一次性項目、需求變化多的項目，軟件版本不穩定、涉及與物理設備交互

（2）是否看代碼（關心內部結構）

黑盒測試：功能測試

白盒測試：邏輯驅動測試

灰盒測試：接口測試

（3）測試對象不同（軟件開發過程）

單元測試

集成測試

系統測試

驗收測試

（4）實施方不同

開發測試：自己測

用戶測試：用戶測

第三方測試：別人測

（5）是否運行被測試程序

靜態測試：不運行程序

動態測試：需要運行程序

7、測試用例

（1）定義：一組測試輸入、執行條件和預期結果，目的是滿足一個特定目標（輸入+預期輸出+測試環境）

（2）測試環境：真實、幹凈、獨立、無毒

（3）用例設計：正常數據、錯誤數據、邊界數據

（4）基本原則：數量少，典型性高，對缺陷定位強

二、黑盒測試

1、等價類（分為無效等價類、有效等價類）輸入輸出可以用等價類思想

（1）產生的原因

對系統進行窮盡測試是不可能的，所以使用少量有限的測試用例進行測試以達到完備和沒有冗余的測試

（2）基本原理：等價劃分（約束：分而不交，合而不變，類內等價）：根據需求對輸入/輸出的範圍進行細分，然後分出每一個區域沒選取一個有代表性的測試數據開展測試。

（3）等價類的分類

<1>有效等價類：輸入域中一組合理、有意義（符合需求說明）的數據集合，用於檢驗特定功能和性能是否能正確實現

<2>無效等價類：輸入域中一組不合理、無意義（不符合需求說明）的數據集合，用來檢驗系統容錯性

（4）等價類劃分的原則

<1>如果規定了範圍，且趨勢範圍上下限之間數據有意義，則：

有效等價類1：取值範圍內

無效等價類1：小於下限

無效等價類2: 大於上限

<2>輸入條件規定“必須如何”，則：

有效等價類1：滿足必須條件

無效等價類1：其他數據

<3>輸入條件規定布爾量：

有效等價類1：真值

無效等價類1：假值

<4>輸入條件是邏輯量（即規定了輸入數據是一組值，且系統分別要對每個量進行處理）

有效等價類*n：每一個輸入值n

無效等價類1：所有不允許輸入的值的集合

<5>用戶需求規定必須遵守某種規則

有效等價類1：滿足用戶規則

無效等價類*n:不同角度違反規則

（5）設計等價類測試用例的步驟

<1>按照常用方法劃分等價類

<2>為等價類表中的每一個等價類分別規定一個唯一編號

<3>設計一個新用例，使它能夠盡可能 多的覆蓋尚未覆蓋的有效等價類，重復該步驟，直到所有有效等價類用例均被覆蓋

<4>設計一個新用例，使它僅能覆蓋一個尚未覆蓋的無效等價類，重復該步驟，直到所有的無效等價類用例均被覆蓋。

（6）輸出域等價類測試的流程

確定有幾類輸出結果

劃分每類輸出結果的等價類

設計測試用例

2、邊界值（邊界值關鍵：剛好等於、剛好大於、剛好小於）

（1）產生的原因：在輸入域的邊界或邊界附近，會有大量的缺陷。所以選擇系統邊界或者邊界附近的數據來設計測試用例

（2）邊界值的確定：

<1>規定了值的範圍：選取剛達到這個範圍的邊界值、剛剛超過這個範圍的邊界值

<2>規定了值的個數：選取最大個數、最小個數、比最大個數多一個、比最小個數少一個

<3>給出輸入域和輸出域的有序集合（有序表、順序文件）：選擇第一個或最後一個

<4>使用內部數據結構:選取這個內部數據結構邊界值上的值

3、決策表（判定表）：輸入輸出的依賴關系。如果動作項和條件項只用一個不同，可以合並

（1）基本原理：分析和表達多種邏輯條件下執行不同操作情況的工具。

（2）適用問題：對不同的邏輯條件的組合值，分別執行不同的操作

（3）決策表的4部分組成

<1>條件樁：列出問題的所有條件（與次序無關）

<2>動作樁：列出問題可能采取的操作（操作排列順序無關）

<3>條件值：條件項的各種取值情況下采取的動作

<4>規則：任何一個條件組合的特定取值及其相應之星的操作

條件樁

條件項1 規則

條件項2

...

動作樁

動作項1 規則

動作項2

...

（4）決策表的分類

有限條目決策表：所有條件都是二叉條件（T/F）

擴展條目決策表：條件可以有多個

（5）決策表的使用範圍

<1>規格說明書以決策表形式給出，或者容易轉化為決策表

<2>條件、規則的排列順序不會執行操作

<3>當某規則的條件已經滿足，並確定要執行的操作後，不必檢驗別的規則

<4>若某一規則要執行多個操作，這些執行順序無關

（6）建立決策表的步驟

<1>確定規則的個數，若有n個條件，每個條件有兩個取值(T/F)，則有2^n種規則

<2>列出所有的條件樁、動作樁

<3>填入條件項和動作項

<4>化簡，合並相似規則或相似動作

（7）特點

<1>最嚴格、最有邏輯性的測試方法

<2>輸入輸出多、且相互制約條件多，使用決策表合適

<3>不是專門用於測試用例的設計方法，也可用在需求分析等方面

（8）優缺點

優點：復雜的問題按照各種情況一一列舉，簡明易於理解，可避免疏漏

缺點：不能表達重復執行的動作，如循環結構

4、因果圖：輸入（出）與輸出（入）的約束，輸出與輸入的依賴關系，符合表示得到決策表

（1）產生背景：等價類和邊界值都著重輸入條件，沒有開率輸入條件的各種組合、輸入條件之間的互相制約關系，多個輸入條件組合起來可能出錯

（2）概念：利用圖解發分析輸入的各種組合情況，適用於檢查程序中輸入條件的各種組合情況

（3）優點：將自然語言轉化為形式語言規格說明的一種嚴格方法，可以指出規格說明存在的不完整性和二義性。

缺點:測試用例數目過大，不利於維護

（4）因果圖的4中基本關系

在基本符號中，左節點ci表示輸入狀態（原因），右節點表示輸出狀態（結果），ci與ei取值為0或者1，0表示狀態不出現，1表示狀態出現

<1>恒等（沒有標記）：若 c1 是1，則 e1 也為1，否則 e1 為0

<2>非（~）：若c1是1，則e1為0，否則e1為1

<3>或（∨）：若 c1 或 c2 或 c3 是1，則 e1 為1，否則 e1 為0

<4>與（∧）：若 c1 和 c2 都是1，則 e1 為1，否則 e1 為0

（5）因果圖中的約束

輸入狀態相互之間，輸出狀態相互之間存在某些依賴關系，對於輸入狀態有E、I、O、R四種約束，對於輸出條件只有M約束

<1>E約束（exclusive OR，異或）a,b不能同時為1

<2>I約束（In,或）a,b,c不能同時為0

<3>O約束（Only，唯一）a和b必須有一個且僅有一個為1

<4>R約束（recommand，要求）a為1時，b不能為0

<5>M約束（must，強制）若結果a為1，則結果b強制為0。

（6）因果圖是決策表的前置過程，步驟為

<1>根據需求，列出輸入和輸出

<2>找出輸入和輸出的關系

<3>用約束表明輸入和輸出關系

<4>轉化為決策表

<5>為每一列設計一條測試用例

5、正交實驗：有效縮減測試用例的方法

查詢、配置測試（硬件）

兼容性測試（軟件）

（1）產生原因：決策表得到的測試數目大，利用正交實驗可以減少測試用例。

（2）基本原理：從全面實驗中挑選部分具有代表性的實驗點，求出最佳工藝參數和工藝條件

（3）特性：均勻分散，整齊可比

直觀印象：數據點均勻分布，每個面3個點，每條線1個點

（4）正交表的結構

L（n）（q^s）

n:實際測試用例的個數，對應正交表的行數

q：每個輸入條件取測試數據的個數，對應正交表中每個 輸入條件的取值個數

s：輸入條件的總個數，對應正交表的列數

q^s:理論上全組合方式的測試用例個數，基於正交表的測試效率為n與q^s的比值

（5）等水平正交表的特點

<1>表中任一列，不同的數字出現的次數相同

<2>表中任意兩列，各種同行數字對（水平搭配）出現的次數相同

（6）常用的標準表（相同水平正交表）

2水平：L4(23）,L8 (27）,L16 (215），…

3水平：L9 (34），L27（313），L81(340），…

4水平：L16 (45）,L64 (421）,L256 (485），…

5水平：L25（56）,L125(531）,L625 (5156），

各列中出現的最大數字相同 的正交表稱為相同水平正交表

（7）混合水平正交表的性質

<1>表中任一列，不同數字出現次數相同

<2>每兩列，同行兩個數字逐層的各種不同水平搭配出現的次數是相同的，單不同列間組成的水平搭配種類和出現次數是不完全相同的

（8）正交表測試用例的步驟

<1>分析需求，找出相應的因子和水平

<2>選擇合適的正交表

<3>把變量映射到表中

<4>加上可疑且沒有在表中出現的組合

<5>正交表的每行作為一條測試用例

（9）全面實驗和正交實驗設計

全面實驗：每個因素的每個水平都相互搭配進行實驗（e.g 3因素4水平實驗次數為4^3=64）

正交實驗設計：利用正交表安排，（e.g 3因素4水平實驗次數為16）

（10）選擇正交表

<1>考慮變量的個數

<2>考慮變量取值的個數

<3>考慮正交表的行數

<4>取行數最少的一個，但不應小於最少測試用例數量

最少測試用例數量=∑（每列水平數-1）+1（e.g. 5個3水平的因子和一個2水平因子，表示為3^5*2^1，實驗次數為5*（3-1）+1*（2-1）+1=12）

<5>因素數（變量），水平數（變量值）相符，因素數不相同，水平數不相同

（11）設計正交表的情況

因素數不同：在正交表公式中找到包含該情況的公式，如果有N個符合條件的公式，則選取行數最少的公式

水平數不相同：采取包含和組合的反射光hi選取合適的正交表

6、場景法：適合流程類的軟件（ATM）基本流只有一個，備選流有多個

（1）基本思想

通過分析同一事件的不同觸發順序和處理結果，構成各個事件流，並基於這些時間的觸發控制業務流程，形成多個不同場景，最終基於場景設計測試用例

（2）基本流和備選流

基本流:從系統的某個狀態開始，經過一些列的狀態變化後達到終止狀態過程的最主要的一個業務流程

備選流：以基本流為基礎，經過基本流的每個判定節點（包括條件判定和循環判定）÷滿足不同的觸發條件，導致的其他事件流（業務流程中的錯誤輸入操作，可選的備選流）

（3）使用步驟

<1>根據業務流程創建基本流和備選流

<2>基於這些事件流構建場景，以滿足測試完備和無冗余的要求

<3>根據場景設計測試用例

（4）基本流和備選流的對比

基本流 備選流

數目 1 1或多

初始節點位置 系統初始狀態 基本流或其他備選流

結束節點位置 系統默認終止狀態 基本流或系統其他終止狀態

是否完整業務流 是 否，是執行片段

（5）場景設計的基本原則

1、最少的場景數等於事件流的總數（基本流+備選流）

2、基本流唯一

3、對應某個備選流，至少應該有一個場景覆蓋，且在場景中應該避免覆蓋其他備選流

7、狀態遷移圖：多個狀態的場景（e.g. 電商訂單）

（1）定義：一種基於產品規格分析，對系統的每個狀態與狀態相關的函數進行測試，通過不同的狀態驗證程序的邏輯流程。測試對象的輸出和行為方式不僅手當前輸入數據的影響，同時與測試對象之前執行情況或之前的輸入數據或事件有關。一個系統，如果對同一個輸入根據狀態不同可以得到不同的輸出，就是一個有限狀態系統

（2）有限狀態機

表示有限個狀態以及在這些狀態之家的轉移和動作等行為的數學模型，可以用狀態圖，狀態表，狀態樹表示

（3）狀態遷移使用的場合：多狀態的變化

（4）狀態圖的使用步驟

<1>根據需求得到主要的狀態

<2>繪制狀態遷移圖

<3>畫出狀態遷移樹

根據分支抽取規則，每個葉子節點形成一條測試用例

<4>抽取測試用例規則（每個狀態至少到達一次）

（e.g.1.網上訂票，此時訂單處於“待支付”

2.顧客付款後，訂單處於“已支付”

3.火車站取票後，訂單處於“已出票”

4.檢票後，訂單處於“已使用”

5.上車前任何時間都可以取消自己的訂票信息，如果已經支付了車票的費用，則可以退款，訂單處於“已取消”）

8、錯誤猜測（探索性測試）

（1）概念：基於經驗和直覺推測成語中存在的錯誤，從而針對性的設計測試用例

（2）基本思想：列舉出程序中說有可能的錯誤和容易發生錯誤的特殊情況，選擇測試用例。（比如：以前產品測試中曾經發現的錯誤，輸入數據和輸出數據為0的情況、輸入表格為空格、輸入表格只有一行等）

（3）錯誤猜測舉例：輸入字符文本框空格是否過濾，區分全角半角空格，html標簽是否轉換，需要二次密碼驗證時粘貼，密碼加密顯示，數據庫中插入相同的記錄是否有提示

（4）隨機測試

測試中所有輸入數據都是隨機產生的，目的是模擬用戶的真實操作，並發現一些邊緣性的錯誤

（5）探索性測試

強調測試人員的主管能動性，拋棄繁雜的測試計劃和測試用例，在碰到問題時及時改變測試策略

9、總結

（1）等價類：任何情況都要使用，可以對輸入域或者輸出域等價劃分，盡量保證測試的完備性和無冗余性

（2）邊界值:等價類測試的有效補充

（3）場景法：業務流程清晰的系統

（4）正交實驗法：參數配置，兼容性測試，輸入輸出條件過多，減少測試用例的恕不，保證測試的均勻分布

（5）因果圖、決策表：輸入輸出組合條件

（6）因果圖：多狀態變化

（7）錯誤推斷法：後期追加測試用例

三、白盒測試——使用源代碼做判定

（一）白盒測試概述

（1）白盒測試關註的對象

<1>源代碼:直接查看源代碼的規範性，並對照函數功能查找代碼的邏輯缺陷，內存管理缺陷、數據定義和使用缺陷

<2>程序結構：通過函數調用圖、算法流程圖等找到程序設計的缺陷，或評價程序的的執行效率，以利於程序結構的優化

（2）優勢

<1>針對性強，便於快速定位缺陷

<2>有助於代碼優化和缺陷預防

<3>測試效率高，通過不同的白盒覆蓋指標有助於衡量被測對象的覆蓋程度

<4>在函數級別開始測試工作，缺陷修復成本低

（3）局限性

<1>對測試人員的技術要求高，需要有一定的編碼能力

<2>成本高，白盒測試準備時間長

（4）適用階段

<1>當被測對象為函數時

a.完成對函數代碼的結構測試

b.主要關註函數源代碼是否符合功能要求，是否有典型的編程缺陷，或優化的角度分析是否過於復雜

c.對應單元測試階段，主要由開發人員完成測試工作

<2>被測對象為功能時

a.完成對業務流程的覆蓋測試

b.對應集成測試或系統測試階段，主要由測試人員完成測試工作

（5）測試方法的評價

<1>關註源代碼中不同類型的結構，側重點不同，對應原碼覆蓋程度也不同

<2>引入白盒測試覆蓋指標來評估黑盒測試方法的測試覆蓋率

（二）靜態測試（不需要設計測試用例）

1、代碼檢查

2、靜態結構分析

（1）基本原理

通過引入多種形式的圖表（函數調用關系圖、模塊控制流圖）幫助人們更好了解程序結構，找到優化方向

（2）函數調用關系圖

<1>測試重點

函數之間調用關系是否符合要求

是否存在遞歸調用

函數調用層次是否太深

是否存在孤立的函數

<2>一般原則

優先測試根節點、葉子節點、接口數量多的節點

（3）函數控制流圖

<1>測試重點

是否存在多出口情況

是否存在孤立語句

環復雜度是否太大

是否存在非結構化設計

3、代碼質量度量

（1）模型:外部質量和內部質量模型

4、靜態結構分析特點

（1）在原代碼的條件下對程序進行分析

（2）通過代碼評審、後續動態白盒測試來進一步對源代碼進行測試覆蓋，來找到更多潛伏的軟件缺陷

（三）動態測試（需要測試用例）

1、基於判定的覆蓋：

（1）語句覆蓋（條件最弱）

<1>保證程序的每一條可執行語句至少執行一次（對程序流程圖所有節點都進行覆蓋）

<2>局限性：關註語句而非判定表達式，對隱式分支無效

（2）判定覆蓋（分支覆蓋）

<1>保證程序中每個判定節點的真假分支至少執行一次

<2>局限性：沒有徹底分析每個簡單判定條件的取值情況，會導致部分缺陷遺漏

（3）條件覆蓋

<1>保證測試用例的每個符合判定表達式中每個簡單判定 條件取真和取假的情況至少執行一次

<2>局限性：條件覆蓋不能保證100%的判定覆蓋

區分：判定覆蓋和條件覆蓋

判定覆蓋只關心判定表達式的值（真/假），而條件覆蓋涉及到判定表達式的每個條件的值（真/假）

（4）判定條件覆蓋

<1>測試用例滿足判定節點的真假至少執行一次，且每個簡單判定條件的取真假至少執行一次，既滿足判定覆蓋+條件覆蓋

<2>局限性:沒有考慮條件組合的情況

（5）條件組合覆蓋

<1>滿足每個判定節點中所有的簡單判定條件的所有可能的取值組合情況至少執行一次

<2>實質：通過列出真值表的方式來的到完全的覆蓋，以冗余換取方法的簡單性

<3>局限性：當判定表達式復雜卻存在多個判定 節點串聯，覆蓋的測試用例規模大

（6）修正條件/判定覆蓋

<1>在滿足判定/條件覆蓋的基礎上每個簡單判定條件都應獨立底影響到整個判斷表達式的取值

<2>實質：利用簡單判定條件的獨立影響性消除測試用例的冗余

（7）測試用例優化

盡量選擇邊界測試數據、盡量避免與或關系的屏蔽現象

2、基於路徑的覆蓋（獨立路徑覆蓋）：控制流圖（唯一的入口、唯一的出口，保證每個判定節點的出度為2）

（1）程序圖

<1>壓縮的控制流圖

剔除註釋語句

剔除數據變量的聲明語句

所有連續的串行語句壓縮為一個節點

所有循環次數壓縮為一次循環

（2）計算環路復雜度（程序的環路復雜度應該不超過10）：

<1>封閉的區域+1

<2>邊數-節點數+2（e-n+2）

<3>獨立判定節點（兩分支的判定）+1

（a.符合條件表達式需要轉換為單個條件表達式

b.如果判定節點是n分支（n>2）,則該判定節點視為（n-1）個獨立判定節點

c.若判斷中條件表達式是由邏輯運算符(or,and)連接的符合條件表達式，則需要改為只有單條件嵌套的判斷）

（3）基本復雜度

<1>概念：對程序圖中的結構化設計節點進行不斷壓縮後得到一個無法壓縮的程序圖，該圖的還復雜度 稱為基本復雜度

<2>關註點：程序中所有非結構化的設計代碼，包含測試優化的設計思想

<3>即使程序的環復雜度高，但是基本復雜度不高，說明程序多為結構化的設計，設計優，缺陷風險度低

（4）測試用例設計

<1>難點：確定獨立測試路徑集合的規模

從整個路徑集合中抽取獨立路徑集合，以確保路徑的獨立性和獨立路徑集合的完備性

確保每條獨立路徑的可行性

從獨立路徑設計測試用例

<2>獨立路徑集合規模的確定

對路徑的測試中所需獨立路徑結合大小等於程序圖的環復雜度

<3>獨立路徑的抽取

a.確定主路徑：包含盡可能多的判定節點、包含盡可能復雜的判定表達式、盡可能高執行概率、包含盡可能多語句

b.根據基礎路徑抽取其他獨立路徑

<4>不可行路徑的處理（程序設計缺陷）

原因：構成判定表達式的多個簡單判定條件之間存在一定關聯，體現在多個簡單判定 條件的取值互相約束，從而使得部分路徑不可行。如果完全根據程序設計圖來進行測試用例設計，會發現不可行路徑，從而導致測試失敗。

<5>測試用例設計

a.根據源代碼生成程序圖

b.計算程序圖的環復雜度，確定獨立路徑集合的大小

c.一將最復雜的路徑作為基礎路徑，通過覆蓋所有判斷分支確定其他路徑，抽取獨立路徑集合

d.剔除不可行路徑，必要時補充其他重要路徑

e.根據得到的路徑集合設計對應的測試用例

<6>測試分析

<1>獨立路徑測試保證了測試的完備性和無冗余性

<2>適用於多個判定節點串聯和存在循環的情況

<3>避免引入不可行的節點

<4>基於程序圖和環復雜度的獨立路徑測試僅關註測試的覆蓋

（5）總結

對路徑的測試可以用於任何動態模型

單元測試階段：對程序源代碼的執行測試

集成測試&系統測試：對業務流、頁面跳轉等動態執行路徑的測試

3、基於循環的測試：

（1）基本原理

重點關註循環過程的正確性，在循環的邊界和運行界限內對循環體之星過程的測試

（2）循環結構的分類

循環的串聯、循環的嵌套、非結構化的循環

（3）難點

單個循環節點->循環次數的邊界，保證循環的完整性

串聯的循環節點->測試的全面性

非結構化循環->進行測試

（4）單個循環節點循環次數的測試

0次，1次，2次，正常次數（通常為最大次數的一半），n-1次，n次

（5）單個循環節點循環過程的測試

初始化、叠代、終止

（6）多個循環結構的測試

節點的串聯

節點的嵌套：內min\max，外min\max

非結構化的循環

（7）總結

<1>循環測試一方面是對過程的靜態檢查，另一方面是對控制循環邊界來觀察執行結構是否與預期保持一致

<2>重點在於觀察循環過程是否符合設計，並不考慮循環體所涉及的相關變量有何實際意義。

單個循環（0，1，2，···m(中間值)····n，n+1）

多個循環：串聯、嵌套、非結構化循環

基於變量的測試：靜態測試方法

四、單元測試：又稱模塊測試，主要是白盒的方法

（一）重點內容

1、主要依據：詳細設計說明書

2、五個方面（靜態&動態）

3、驅動模塊和樁模塊

4、單元測試自動化測試，需要單元測試框架

（二）概述

1、定義：對軟件中最小可測試單元或基本組成 單元進行檢查和認證

2、單元選取的原則

（1）面向過程的開發語言：一個函數或子過程

（2）面向對象：一個類

（3）圖形化：一個窗口或一個菜單

（三）測試的內容

1、靜態測試：走查、審查等會議方式，看代碼是否符合要求

2、動態測試：模塊接口、模塊邊界條件、模塊獨立路徑和錯誤處理

<1>模塊接口測試：考慮數據是否可以正確輸入輸出（主要關註單元中的輸入和輸出）

輸入的實參形參在個數、屬性等是否匹配

被測模塊調用其他模塊時，傳遞的參數屬性是否匹配

是否存在當前入口點無關的參數引用

是否修改了只讀形參

全局變量在各模塊中的定義是否一致

<2>模塊邊界條件測試：在被測模塊的輸入/輸出域邊界或其附近設計測試用例

<3>獨立路徑測試：主要關註程序的邏輯分支問題

<4>所有錯誤處理路徑：主要關註程序的邏輯分支問題。

3、驅動模塊和樁模塊的設計

（1）驅動模塊（Driver）：模擬被測單元的上級模塊，用於接收測試數據、啟動被測模塊和輸出結果

（2）樁模塊（Sub）模擬被測單元所調用的模塊，有時需要使用子模塊的接口，才能做少量的數據操作，並驗證和打印入口出的信息，然後返回。樁模塊不包含原模塊的所有細節。

（3）適用條件：被測單元所調用的模塊簡單，不需要專門設計樁模塊，直接與被測單元放在一起執行測試

（4）設計原則

<1>測試用例執行滿足所有的環境因素

<2>使驅動模塊和樁模塊盡量能不經修改直接使用，提高重用性，提高回歸測試效率

其體現在：結合已有的測試用例設計測試數據、驅動被測單元，將測試數據和測試腳本分離

（5）驅動模塊的功能要求

<1>利用已有的測試用例接收測試的輸入數據

<2>將測試數據傳送給被測單元

<3>輸出測試用例的相關結果，判斷失敗還是通過

<4>通過測試日誌文件記錄過程 ，便於後續數據的保存和分析

（6）樁模塊的功能要求

<1>在特定 的條件下完成原單元測基本功能

<2>能夠被正確調用

<3>有返回值

<4>不包含原單元的所有細節

4、測試需求分析

（1）測試需求是系統需求和測試用例之間的橋梁 系統需求->測試需求->細化的測試需求?->測試用例

（2）測試需求的屬性

ID、所屬功能模塊、評審狀態、重要性、穩定性、工作量、優先級、需求版本、功能點描述、業務規則描述、創建人、創建日期

（3）測試需求的分析

用戶定義業務需求

系統分析師提取系統需求

測試人員提取測試需求

測試工程師設計測試用例

（4）測試需求：測試分析活動的產物

可測試性需求：需求分析活動的產物

（5）單元測試過程

計劃（重在計劃，不在於文檔，即使更新）、設計（進度、測試粒度、測試密度）、實施階段->執行階段->評估階段

5、日創建：自動完整的構建整個代碼庫的代碼，在構建的同時完成單元測試執行的軟件研發工作模式

優勢：進度可見、可控、適用於多環境下的團隊研發、便於盡早發現、修復和驗證缺陷、增量測試

五、集成測試：又稱組裝測試，主要是黑盒+白盒測試

（一）概述

1、主要依據：概要設計說明書

單個集成測試用例設計

成對集成、鄰居集成、獨立測試路徑集成

2、集成測試的遍歷順序

大爆炸集成，自頂向下，自底向上，三明治集成

3、集成測試是在單元測試的基礎上，將所有已經通過的單元測試模塊按照概要設計說明書的要求組裝為子系統或系統，並進行測試的過程

4、集成測試的目的：確保各個單元模塊組合在一起後能夠按照既定的意圖協作運行，並確保增量的行為正確

（二）集成測試的內容

1、將各個具有相互調用關系的模塊組合起來，檢查穿越模塊接口的數據是否丟失

2、判斷各個子功能組合起來是否可以達到預期的父功能

3、檢查一個模塊的功能時候會對其他模塊的功能產生不利影響

4、檢查全面數據結構是否正確，和在完成模塊功能的過程中是否會被異常修改

5、單個模塊的誤差累積起來是否會放大到不可接受的程度

（三）集成測試的評價

1、單個集成測試用例設計

（1）成對集成思想：將每個集成 測試用例限定在一對調用單元上，每個集成測試用例 都是最小的集成單元，僅涉及一對接口的調用

優點：便於缺陷定位

（2）鄰居集成思想：將每個集成 測試用例限定在某個節點的鄰居上，針對某個模塊的集成測試用例同時應該包括該模塊和其鄰居

（鄰居：某個指定模塊及其所有直接調用該模塊的上層模塊和下層模塊）

（3）基於獨立路徑的集成：將函數調用圖看作程序的控制流圖或程序圖，每個從根節點到葉子節點的調用形成了路徑，每條獨立路徑即可構成一個集成測試用例

2、集成測試遍歷順序的設計

（1）大爆炸集成：將所有經過單元測試的模塊一次性組裝到被測系統中進行測試，不考慮模塊之間的依賴性和可能的風險

（2）自頂向下的集成：從主控模塊（主程序即根節點）開始，按照系統程序結構，按照控制層次從上而下，逐漸將各模塊組裝起來

優勢：避免主控程序缺陷，確保開發進度

單個測試用例包含多個模塊，可從整體上降低測試用例規模

采用遞增方式展開測試，每個新的測試用例僅能增加一個新的模塊，便於缺陷定位

不足：樁模塊的開發和維護的工作量大

難以發現底層模塊中復雜的算法缺陷

不利於測試的並行

（3）自底向上的集成：從底層模塊（葉子節點）開始，按照調用圖的結構，從下而上，逐層調用模塊。

優勢：從葉子節點開始測試有利於提前發現算法錯誤，降低了測試用例的規模，並行行好

缺點：驅動模塊的開發維護工作量大，難以發現早期上層模塊的邏輯控制缺陷，知道最後一個模塊加入才能看到整個系統框架，難以早期發現時序問題和資源競爭問題

（4）三明治集成：將自頂向下和自底向上集成方法結合起來的集成策略。在調用圖上按照一定的策略，分別自頂向下和自底向上展開集成，並在子樹上進行大爆炸集成

<策略1>將系統劃分為三層，中間層為目標層，測試時對目標層上面的層使用自頂向下的集成策略，對目標層下面的層使用自底向上的集成策略。

<策略2>基於策略1並對目標層采用獨立測試策略，確保目標層模塊在集成測試之前得到充分的測試

<策略3>對包含讀操作的子系統自底向上集成測試直至根節點，然後對包含寫操作的子系統自頂向下集成測試直至葉子節點

優勢：結合了自頂向下和自底向上的集成的優勢

不足：中間的目標層可能得不到充分的測試，需要同時開發樁模塊和驅動模塊，任務量大，子樹進行大爆炸集成時當接口多時難以進行缺陷定位

六、系統測試：主要是黑盒測試

（一）概述

1、主要依據：需求說明書

2、測試方法：功能測試：對功能控件的測試

性能測試

安全測試

界面測試：統一性

安裝測試：易用性測試、文檔測試

3、概念：將經過良好集成測試的軟件系統作為計算機系統的一部分，與硬件、外部設備、支持軟件、數據和人員等其他系統元素結合在一起，在實際環境中對計算機系統進行一系列的嚴格測試。

4、系統測試與集成（單元）測試的區別：系統測試不僅限於軟件，且系統測試不能夠省略

（二）功能測試（系統測試中最基本的測試）

1、主要針對系統的功能需求，確認系統是否滿足用戶的使用要求

2、設計測試用例：系統輸入、系統內部處理、系統輸出

3、以數據為中心的系統，其核心是數據處理（從實體關系模型（1對1，1對多。。）、對數據的操作（增加、刪除、查找、修改））結合黑盒（考慮所有輸入輸出的覆蓋測試）、白盒的設計思想（有線狀態機、由主業務所得到的業務流程圖）

4、以活動為中心的系統，核心是活動序列（系統輸入、輸出、狀態、出發狀態的變遷事件）

（三）性能測試

1、對軟件性能指標進行測試，判斷系統集成使用環境知否穩定

2、主要考慮系統的時間（具體事物 相應時間）和空間性能（運行時消耗的系統資源）

3、主要內容：常規性能測試、壓力測試（最大壓力）、負載測試（側重壓力持續時間）、可靠性測試（平均 錯誤時間間隔越大，系統越穩定）、大數據量測試

（四）安全性測試

用於檢驗系統對非法侵入的防範能力

（五）兼容性測試 檢驗被測軟件與其他軟、硬件相互是否能夠正確交互和實現信息共享

七、驗收測試（交付測試）

（一）

1、主要依據：用戶需求

2、測試方：用戶

3、測試階段

ahpha測試：請用戶到公司內測試

beta測試：大規模不受控制測試

4、概念：在產品完成系統測試之後、產品發布之前所進行的軟件測試活動，它是技術測試的最後一個手段

5、目的：確保產品準備就緒，並且可以讓最終用戶將其用於執行產品的既定功能和任務。

6、常用策略：

<1>項目軟件的驗收

<2>產品軟件的驗收

7、alpha（內部）測試

（1）軟件開發公司組織內部人員模擬各類用戶對即將面世的軟件產品（稱為α版本）進行測試，試圖發現錯誤。由用戶、測試人員、開發人員等共同參與的內部測試。

（2）關鍵：盡可能逼真模擬實際運行環境和用戶對軟件產品的操作，盡最大努力涵蓋所有用戶操作。

8、beta（公測）

完全交給最終用戶測試。軟件開發公司組織各方面的典型用戶在日常生活中實際使用β版本，並要求用戶報告異常情況、提出批評意見。然後軟件開發公司再對β版本進行改錯和完善。

9、常用技術：黑盒測試、易用性測試、靜態測試

八、測試管理

1、開發模型

（1）開發模型：軟件開發的任務結構框架，給出了各個階段之間的關系（從構思到公開發行）

（2）分類：

<1>軟件需求完全確定為前提的第一代過程模型

<2>在開始階段只提供基本需求的漸進式模型

<3>以體系結構為基礎基於構建組裝的開發模型

（3）常見開發模型

<1>大棒開發

優點：思路簡單，通常可能是開發者的“突發奇想”

缺點：開發過程是非工程化的，隨意性大，結果不可預知

測試：開發任務完成後，修復較困難

<2>邊寫邊改法

優點：簡單考慮到了軟件的需求，產品周期短

缺點：沒有計劃和文檔的編制

測試工作： 由於新的版本不斷產生，測試工作長期循環

<3>快速原型法

根據客戶需求在較短的時間內解決用戶最迫切解決的問題。在得到用戶的更加明確的需求之後，原型將丟棄。

（4）瀑布開發模型（適用於需求明確的軟件，如操作系統、數據庫管理軟件）

<1>流程:如同瀑布流水，逐級下落

需求分析（需求說明書）

系統設計（系統設計書）

程序設計（程序設計書）

編碼（程序清單）

測試（測試報告）

運行和維護（維護報告，改進的系統）

<2>特點：將軟件生存周期各活動規定為線性順序連接的若幹階段模型

<3>優點：易理解、階段性、強盜需求分析、明確測試階段、提供模板（文檔驅動）

<4>缺點：

線性嚴格——成果晚出——風險

階段固定——反復&叠代——靈活性

單次需求——需求變更——適應性

測試滯後——缺陷晚查——代價

（5）螺旋模型

每個開發階段包括5個步驟

確定目標，選擇方案

評估方案，解決風險

本階段的開發和測試

計劃下一階段

確定下階段方法

優點：嚴格的全過程風險管理；強調各開發階段的質量；提供機會評估項目是否有價值繼續下去。(發現問題早)

（6）敏捷開發

以人為核心、叠代、循序漸進的開發方法

2、測試模型

（1）測試的基本流程

制定測試計劃：測試工作的整體規劃

設計和生成測試用例：生成測試用例文檔（測試輸入、測試步驟、預期結果等內容）

搭建測試環境：真實、無毒、獨立、幹凈

實施測試（提交缺陷報告）：初測、細測、回歸期（復查已知錯誤的糾正情況）

測試評估和總結

（2）測試過程模型

<1>V模型：動態測試行為與開發行為對應，每個測試階段的基礎是對應開發階段的提交物，通過低層測試確保源代碼正確，滿足整個系統的需求。（開發過程自頂向下，測試過程自頂向上）

局限性：測試滯後，測試與開發文檔難以一一對應，缺少靜態測試

<2>W模型：靜態測試和動態測試伴隨整個開發過程，並與開發行為對應，有助於早期發現缺陷/了解項目難度/評估測試風險

局限性：串行活動、不支持叠×××發、不具有測試流程的完整性

<3>H模型：測試流程獨立於其他流程，與其他流程並發進行，只要測試準備工作完成就可以進行測試

<4>X模型：清晰地體現了單元測試→集成測試→系統測試的過程，該模型還能處理開發中包括交接、頻繁重復的集成等工作，更加貼合實際的項目開發流程

<5>綜合策略：

宏觀:W模型（開發測試並行過程）

微觀：H模型（獨立測試）

存在不確定因素：X模型（分離編碼與測試）

3、用例管理

（1）用例報告的書寫

標題、優先級、輸入、操作步驟、輸出預期、測試環境

根據需求來寫用例，沒有代碼

（2）測試結果

Pass、Fail、Warning、block、skip

（3）測試用例的組織和跟蹤

整理模塊需求、撰寫測試計劃、設計測試思路、編寫測試用例、評審測試用例、修改更新測試用例、執行測試用例、分析評估測試用例質量

（4）測試用例更改更新策略

<1>若新版本特性無變化，只是出現缺陷被用戶發現的情況，此時可以修改測試用例，並給出變更記錄。且當前修改的測試用例，對目前和以前的版本都有效 <2>若新版本中原有的功能取消，此時需在新版本上將對應測試用例設置為無效 <3>若新版本中原有的產品特性發生變化，但屬於功能增強，則原有測試用例僅對原版本有效，此時不能修改測試用例，只能增加新的測試用例，新增測試用例僅對當前版本有效

4、測試管理工具：bugfree

5、缺陷管理

（1）定義（5個）

<1>出現未達到需求規格說明書中指明的功能

<2>出現需求規格說明書中指明不會出現的錯誤

<3>功能超出規格說明書的範圍

<4>未達到規格說明書中沒要求但應該達到的要求

<5>測試人員認為軟件難以理解、不易使用、運行速度慢、用戶體驗不佳。

（2）缺陷報告組成

優先級、指派、嚴重程度、可重現性

（3）註意事項：保證重現

（4）缺陷報告的生命周期（流程）

（測試人員、項目經理、程序員）

提交測試報告 測試人員

|

處理缺陷報告 開發人員

|

返測？ 測試人員

|

關閉測試報告

九、冒煙測試和回歸測試（兩者都在新版本發布之前進行）

冒煙測試：主要測試功能（在回歸測試之前完成）

回歸測試：任何階段都會有，新版本發布時做

十、測試文檔

測試計劃

測試用例

缺陷報告

測試總結報告

十一、測試能力

1、軟件測試的發展階段（TMM(Testing Maturity Model)，測試成熟度模型）：

第一階段：初始階段

措施：測試是完全混亂無序的，測試等同與調試，編碼完成後隨意測試調試，目標是表明軟件奏效的。

優勢：省力

弊端：開發出的產品沒有質量保證，存在很多弊端

第二階段：定義階段

措施：測試不同於調試，將測試定義為編碼後的階段和工作，所有測試都是依賴於代碼的執行，只有當編碼完成後才進行測試

優勢:掌握了一定的測試技術和方法，可以取得一定的效果

弊端：在需求和設計中沒有測試，大量缺陷擴散到代碼中，開發出的產品依然會有較多的缺陷

第三階段：集成階段

措施：將測試集成到整個軟件的生存周期，開始考慮客戶和用戶的需求來建立測試目標，將測試看做專業化的活動，成立專門的測試組織，有基本的測試工具

優勢：基於技術的測試，效果更好

弊端：在整個軟件生存周期中沒有建立正式的評審程序，沒有開展評審活動，測試組應付

第四階段：管理、測量

措施：測試成為一個可以測量和量化的過程，開發過程引入評審機制，測試用例過程被管理起來

優勢：基於規範的測試，擁有流程控制，出現質量管理活動

弊端：缺陷尋找過於被動

第五階段：最佳化

措施：建立缺陷預防的思想，通過統計抽樣的方式不斷改進測試，自動工具完全支持

優勢：機制完善，不斷改進測試，可以度量和優化產品質量

2、CMM：能力成熟度模型 (Capability Maturity Model)

是對於軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。

五級模型：

（1）初始級

特點是軟件過程無秩序，有時甚至是混亂的。軟件過程定義幾乎沒有章法和步驟可循，軟件產品所取得的成功往往依賴極個別人的努力和機遇

（2）可重復級

已建立了基本的項目管理過程，可用於對成本，進度和功能特性進行跟蹤。對類似的應用項目，有章可循，並能重復以往所取得的成功。

（3）定義級 （標誌著軟件能力“成熟”）

用於管理的、工程的軟件過程均已實現文檔化、標準化，並形成了整個軟件組織的標準軟件過程。全部項目均已采用與實際情況相吻合的、適當修改的標準軟件過程來進行。

（4）定量管理級（有明確的度量指標）

軟件過程和產品質量有詳細的度量標準，軟件過程和產品質量得到了定量的認證和控制。

（5）優化級

通過對來自過程、新概念和新技術等方面各種有用信息的定量分析，能夠不斷地、持續性的對過程進行改進。

十二、軟件測試停止的依據

（一）缺陷修復率標準

一、二級：100%

三、四級：80%

五級以上：60%

（二）覆蓋率

語句覆蓋率大於80%

用例執行覆蓋率100%

需求執行覆蓋率100%

參考資料： [1]Paul Ammann，軟件測試基礎[M]，機械工業出版社，2017.1

【軟件測試】軟件測試基礎 復習筆記