測試基礎知識整理

軟件測試基礎

TIP：

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

B:理解，可以講出來

C:了解，了解相關知識

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

正交表、評審、正規檢視