軟體測試基礎

TIP：

A:掌握，知識理解無偏差，熟練應用

B:理解，可以講出來

C:瞭解，瞭解相關知識

目錄

• 軟體測試基礎
  • 1. 軟體缺陷的定義(C)
  • 2. 軟體測試的目的（C）
  • 3. 軟體生命週期（B）
    • 3.1 開發模型（C）
      • 3.1.1 邊做邊改模型（Build-and-Fix Model）：
      • 3.1.2 瀑布模型（Waterfall Model）
      • 3.1.3 快速原型模型（Rapid Prototype Model）
      • 3.1.4 增量模型（Incremental Model）
      • 3.1.5 螺旋模型（Spiral Model）
      • 3.1.6 演化模型(evolution model)
      • 3.1.7 噴泉模型(fountain model)
      • 3.1.8 智慧模型(四代技術（4GL）)
      • 3.1.9 混合模型（hybrid model）
      • 3.1.10 RAD模型
  • 4. 軟體的測試原則（C）
  • 5. 軟體測試流程（B）
    • 5.1 軟體測試常見模型（C）
      • 5.1.1 V模型
      • 5.1.2 W模型（B）
      • 5.1.3 H模型
      • 5.1.4 X模型
  • 6. 軟體測試分類（B）
    • 6.1 按照開發階段劃分
    • 6.2 按照程式碼執行劃分
    • 6.3 按照軟體特性劃分
    • 6.4 按照測試技術劃分
    • 6.5 按照測試主體劃分
    • 6.6 其他測試
  • 7. 測試用例（A）
    • 7.1 測試用例的屬性
    • 7.2 測試用例的設計方法
      • 7.2.1 等價類
      • 7.2.2 邊界值
      • 7.2.3 判定表
      • 7.2.4 因果圖
      • 7.2.5 正交表
      • 7.2.6 狀態遷移
      • 7.2.7 其他方法（C）
    • 7.3 測試用例設計的原則（C）
  • 8. 缺陷（A）
    • 8.1 缺陷屬性
    • 8.2 缺陷型別
    • 8.3 缺陷的劃分
      • 8.3.1 優先順序
      • 8.3.2 嚴重程度
    • 8.3 缺陷的生命週期
  • 9.其他相關

1. 軟體缺陷的定義(C)

• 軟體未實現產品說明書要求的功能
• 軟體出現了產品說明書指明不應該出現的功能
• 軟體實現了產品說明書未提到的功能
• 軟體未實現產品說明書雖未明確提及但應該實現的目標
• 軟體難以理解、不易使用、執行緩慢（從測試的角度看）終端使用者會認為不好

TIP：

所有不滿足需求或超出需求的都是缺陷

沒有不存在缺陷的軟體，只有迄今為止尚未被發現的缺陷

2. 軟體測試的目的（C）

• 以最少的人力、物力、和時間找出軟體中潛伏在的各種潛在的錯誤和缺陷，保證各種錯誤和缺陷得以修復，避免軟體釋出後由於潛在的軟體錯誤和缺陷造成的隱患所帶來的商業風險
• 同時利用測試過程中得到的測試結果和測試資訊，作為後續專案開發和測試過程改進的重要輸入，避免在將來的專案開發和測試中重複同樣的錯誤
• 採用更加高效的測試管理手段，提高軟體測試的效率和軟體產品的質量

3. 軟體生命週期（B）

3.1 開發模型（C）

3.1.1 邊做邊改模型（Build-and-Fix Model）：

3.1.2 瀑布模型（Waterfall Model）

3.1.3 快速原型模型（Rapid Prototype Model）

3.1.4 增量模型（Incremental Model）

3.1.5 螺旋模型（Spiral Model）

3.1.6 演化模型(evolution model)

3.1.7 噴泉模型(fountain model)

3.1.8 智慧模型(四代技術（4GL）)

3.1.9 混合模型（hybrid model）

3.1.10 RAD模型

參考資料：軟體開發模型

4. 軟體的測試原則（C）

• 所有測試的標準都是建立在使用者需求之上
• 軟體測試必須基於“質量第一”的思想去展開各項工作。當時間和質量衝突時，時間要服從質量
• 事先定義好產品的質量標準，只有有了質量標準，才能根據測試的結果，對產品的質量進行分析和評估
• 軟體專案一啟動，軟體測試也就是開始，而不是等程式寫完，才開始進行測試
• 窮舉測試是不可能的
• 第三方進行測試會更客觀，更有效
• 軟體測試計劃是做好軟體測試工作的前提
• 測試用例是設計出來的，不是寫出來的，所以要根據測試的目的，採用相應的方法去設計測試用例，從而提高測試效率，更多的發現錯誤，提高程式的可靠性

5. 軟體測試流程（B）

需求測試--單元測試--整合測試--系統測試--驗收測試--alpha測試-（內）--beta測試（外）--UAT測試（使用者接受度）--迴歸測試

5.1 軟體測試常見模型（C）

5.1.1 V模型

需求規格說明書（SRS）-->概要設計（HLD:high level design） -->詳細設計（LLD:low level design 偽碼）--> 編碼（Coding）

優點：

揭示了開發過程與測試過程中各階段的對應關係

侷限性：

• 在需求分析、系統設計、及編碼之後的一個階段，忽視了測試對需求分析、系統設計的驗證
• 需求的滿足情況一直到後期的驗收測試才被驗證
• 沒有體現出“儘早和不斷地進行軟體測試”的原則

5.1.2 W模型（B）

優點：

• 測試的活動與軟體開發同步進行
• 測試物件不僅僅是程式，包括需求和設計
• 今早發現軟體缺陷可降低軟體開發的成本

侷限性：

在W模型中，需求、設計、編碼等活動被視為序列的，這樣就無法支援靈活的迭代。

5.1.3 H模型

1. H模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執行活動清晰的體現出來

2. H模型揭示了一個原理：軟體測試是一個獨立的流程！

3. H模型指出軟體測試要儘早準備，儘早執行，只要某個測試達到準備就緒點，測試執行活動就可以開展，並且不同的測試活動可按照某個次序先後進行，也可以反覆進行

5.1.4 X模型

X模型也是對V模型的改進，X模型提出針對單獨的程式片段進行相互分離的編碼和測試，以後通過頻繁的交接，通過整合最終合成為可執行的程式

X模型還定位了探索性測試，這是不進行事先計劃的特殊型別的測試，這以方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤

6. 軟體測試分類（B）

6.1 按照開發階段劃分

單元測試（模組測試）

單元測試又稱模組測試，是針對軟體設計的最小單位--程式模組進行正確性檢驗的測試工作。其目的在於檢查每個程式單元能否正確實現詳細設計說明中的模組功能、效能、介面和設計約束等要求，發現各模組內部可能存在的各種錯誤。單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試

單元測試一般要讀程式和程式碼，大多數時候，都是由開發人員自己去完成（交叉，但是一般又不認為是在做測試），測試人員為什麼不做單元測試？（大家不懂程式碼和演算法）

整合測試（組裝測試）

整合測試也叫做組裝測試。通常在單元測試的基礎上，將所有的程式模組進行有序的、遞增測試。整合測試是檢驗程式單元或部件的介面關係，逐步整合為符合概要設計要求的程式部件或整個系統

比較多的涉及到介面測試（介面測試工具和方法專門學習）

確認測試（有效性測試、冒煙測試）

確認測試也叫有效性測試。是在模擬的環境下，驗證軟體的所有功能和效能及其他特性是否與使用者的預期要求一致。通過了確認測試後的軟體，才具備了進入系統測試的資質

確認測試（功能是否實現），一般都是正向的測試，不作為正式的測試環節

系統測試

系統測試是在真實的系統執行的環境下，檢查完整的程式系統是否和系統（包括硬體、外設、網路和系統軟體、支援平臺等）正確的配置、連線，並最終滿足使用者的所有需求

驗收測試

是軟體產品檢驗的最後一個環節。按照專案任務書或合同、僅需雙方約定的驗收依據文件進行的對整個系統的測試與評審，決定是否接收或拒收系統。

供求雙方，一般有三種驗收測試的主體：

α測試：軟體開發商交付前自己進行的測試

β測試：軟體需求方自己進行的測試

γ測試：第三方的軟體測試

6.2 按照程式碼執行劃分

靜態測試：指不實際執行被測物件，而只是靜態的檢驗程式程式碼、介面或文件中可能存在錯誤的過程

程式碼測試：主要測試程式碼是否符合相應的標準和規範

介面測試：主要測試軟體的實際介面與需求中的說明是否相符

文件測試：主要測試使用者手冊和需求說明是否真正符合使用者的實際需求

動態測試：指實際執行被測物件，輸入相應的測試資料，檢查實際輸出結果和預期結果是否相符的過程。所以我們判斷一個測試屬於動態測試還是靜態測試，唯一的標準是看是否執行程式

6.3 按照軟體特性劃分

功能測試：是黑盒測試的一方面，它檢查實際軟體的功能是否符合使用者的需求

效能測試：功能的另一個指標，主要關注軟體中的某一功能在指定的時間、空間條件下，是否使用正常

軟體的效能包括很多方面，主要有時間效能和空間效能兩種

安全性測試：驗證安裝在系統內的保護機制是否能在實際應用中對系統進行保護，使之不被非法入侵，不受各種因素干擾

邏輯功能測試

介面測試

易用性測試

安裝/解除安裝測試

相容性測試

6.4 按照測試技術劃分

黑盒測試

通過軟體的外部表現來發現其他缺陷和錯誤。黑盒測試把測試物件看成一個黑盒子，完全不考慮程式內部結構和處理過程。黑盒測試是在程式介面處進行測試，它只是檢查程式是否按照需求規格說明書的規定正常實現

白盒測試

通過對程式內部結構的分析、檢測來尋找問題。白盒測試可以把程式看成裝載一個透明的盒子裡，檢查是否所有的結構及路徑都是正確的，檢測軟體內部動作是否按照設計說明的規定正常進行。白盒測試又稱結構測試

灰盒測試

介於白盒測試和黑盒測試之間的測試。灰盒測試關注輸入的正確性，同時也關注內部表現，但這種關注不像白盒測試那樣詳細、完整，只是通過一些象徵性的現象、事件、標誌來判斷內部的執行狀態

6.5 按照測試主體劃分

手工測試（功能測試）：點點點

自動化測試：利用工具軟體或是編寫程式碼的方式測試被測的軟體系統

6.6 其他測試

迴歸測試

是指對軟體的新版本測試時，重複執行之前某一個重要版本所有測試用例

目的：

1. 驗證之前版本產生的所有缺陷已全部被修復

2. 確認修復這些缺陷沒有引發新的缺陷

冒煙測試

是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性，也叫可測性測試

隨機測試

是指測試人員基於經驗和直覺的測試，發現一些邊緣性的錯誤

猴子測試

把自己當成不懂產品的小動物，隨便亂點，沒有任何的主觀意識和想法參與進來，讓一些意想不到的操作造成錯誤的結果

7. 測試用例（A）

7.1 測試用例的屬性

用例編號、用例標題、所屬模組、測試等級、預置條件、測試資料、操作步驟、預期結果、編寫人員、編寫時間、用例型別、備註、測試環境

測試用例示例

7.2 測試用例的設計方法

等價類、邊界值、判定表、因果圖、正交表、場景圖（流程圖法）、錯誤猜測法、狀態遷移。

7.2.1 等價類

窮舉（不可取）-->等價類（有效資料和無效資料）

取值規範：

當我的輸入或者輸出是一定範圍的時候，取一個有效和兩個無效的

當我的輸入或者輸出是布林值的時候，取一個有效和一個無效

當我的輸入或者輸出是集合的時候，取一個有效和一個無效

當我的輸入或者輸出是一定規則的時候，取一個有效和n個無效

當我的輸入或者輸出是不同條件得到不同結果的時候，進行細分

設計用例思路

1. 給需求進行分類

2. 每個分類找出有效和無效

3. 給有效和無效進行編號

4. 設計一條用例,使其儘可能覆蓋所有的有效編號

   再設計一條用例,使其儘可能覆蓋所有剩下的的有效編號

   ...

5. 設計用例,一個無效寫一條用例,確保其他資料有效

   再設計用例,一個無效寫一條用例,確保其他資料有效

   ...

7.2.2 邊界值

等價類的補充,補充等價類中,可度量的情況下,用邊界值用例設計方法

取點 y=4x+1 健壯性高低

7.2.3 判定表

當你的需求是不同條件組合,得到不同結果的時候,並且這裡的每個條件取值是隻有兩種的情況下

設計用例思路

1.從需求裡面提取出條件樁

2.畫出條件項.2ⁿ

3.從需求裡面提取出動作樁

4.根據需求填寫動作項

5.合併

6.寫測試用例,一種情況一條用例

7.2.4 因果圖

7.2.5 正交表

當你的需求是不同條件組合,得到不同結果的時候,並且這裡的每個條件取值可能大於等於1，可以使用正交，減少測試用例

7.2.6 狀態遷移

7.2.7 其他方法（C）

場景圖、錯誤猜測、輸入域、輸出域

7.3 測試用例設計的原則（C）

• 測試用例對需求覆蓋的完整性
• 測試用例的有效性
• 測試用例的可理解性
• 測試用例的清晰性
• 測試用例的可維護性

8. 缺陷（A）

8.1 缺陷屬性

8.2 缺陷型別

遺漏、錯誤、額外實現、改進

8.3 缺陷的劃分

8.3.1 優先順序

8.3.2 嚴重程度

8.3 缺陷的生命週期

9.其他相關

流程管理平臺：禪道、Bitnami Redmine Stack Manager Tool

正交表、評審、正規檢視