軟件生命周期中的測試

第二章 軟件生命周期中的測試

1.開發模型

1.1開發模型和測試

• 軟件測試不是孤立存在的，測試活動與開發活動息息相關

• 軟件測試活動不僅僅包括測試執行，它應該貫穿於整個軟件的生命周期中

• 不同的開發生命周期模型需要對應不同的測試階段、測試活動和測試方法

1.2瀑布模型

用戶需求-->需求分析-->概要設計-->詳細設計-->編碼和實現-->測試-->運行維護

• 軟件測試作為整個軟件生命周期中的一個階段！

瀑布模型的階段

• 用戶需求：用戶需求一般由用戶提出，系統人員或者產品市場人員從客戶或將來的系統中收集原始的項目信息

• 需求分析：對用戶需求進行可行性分析，並對用戶需求和要求進行詳細買書，並最終得到管理層和客戶的批准。通過需求分析，定義了開發系統的目的和需要實現的特性和功能

• 概要設計：明確系統的架構、系統的模塊數量，以及各個模塊之間的接口、數據結構，以及可能的網絡環境支持和后台數據庫。簡單地說，就是將需求映射到新系統的功能和框圖上，從而可以對每個子系統進行獨立的開發。

• 詳細設計：細化概要設計的框架，定義每個子系統的任務、行為、內部結構以及與其他子系統的接口

• 編碼和實現：通過編程語言實現所有已經定義的單元，比如模塊、單元和類

• 測試：作為開發周期的一個階段，主要是指測試執行活動

• 運行維護：軟件系統或者產品發布，在用戶中使用，以及根據反饋進行必要的維護活動

瀑布模型的特點

• 軟件測試是開發過程中的一個階段，對產品質量進行的最后檢查

• 在客戶需求明確，以及開發過程中沒有平凡的需求變更，比較適合瀑布開發模型

• 假如需求不明確或者需求經常發生變更，采用瀑布模型是非常不適合的

1.2 V模型

 

V模型階段

• 除了前面瀑布模型中介紹的用戶需求、需求分析、詳細設計、概要設計、編碼和實現幾個階段之外，還強調了不同的測試級別概念

單元測試：驗證軟件單元是否按照單元規格說明（詳細設計說明）正確實行，即保證每個最小的單元能夠正常運行。單元測試一般由開發人員來執行，首先設定最小的測試單元，然后通過設計相應的測試用例來驗證各個單元功能的正確性

集成測試：檢查讀個單元是否按照系統概要設計描述的方式協同工作。集成測試的主要關注點是系統能夠成功編譯，實現了主要的業務功能，系統各個模塊

集成測試：驗證整個系統是否滿足需求規格說明

驗收測試：從用戶的角度檢查系統是否滿足合同中定義的需求或者用戶需求

V模型的特點

• V模型體現的主要思想是開發和測試同等重要，左側代表的是開發活動，而右側代表的是測試活動

• V模型針對每個開發階段，都有一個測試級別與之想對應

• 測試依舊是開發生命周期中的階段，與瀑布模型不同的是，有多個測試級別與開發階段對應

• V模型適用於需求明確和需求變更不頻繁的情形

V模型的驗證和確認

驗證：通過檢查和提供客觀證據來證實指定的需求是否滿足。也就是說，輸入與輸出之間的比較（是否正確地構建了系統？）

確認：通過檢查和提供客觀證據來證實特定目的的功能或應用是否已經實現。在確認是，應考慮使用和應用的條件范圍要遠遠大於輸入是確定的范圍（是否構建了正確的系統？）

• 實際上每個測試都包括確認測試和驗證測試這兩個方面。而確認測試的內容。而確認測試的內容隨着測試級別的不斷提高而增加。

• 瀑布模型和V模型，都是屬於線性模型的范疇，他們的重要特點就是線性的，即前置條件是軟件系統具有比較明確的需求，且沒有頻繁的需求變更

1.3非線性模型

• 需求是可變的：某些應用軟件的需求，與外部環境、公司經營策略或經營內容等密切相關，這些都是經常調整和變化的，因此需求也是變化的。

• 需求是模糊的：許多用戶對他們的需求最初只是模糊的概念，想要求一個對需求只有初步設想的人准確無誤的說出全部的需求，顯然是不切實際的

• 用戶和開發者難於溝通：大多數戶和領域專家不熟悉計算機和軟件技術，而軟件開發人員也往往不熟悉用戶的專業領域，開發人員和用戶之間很能做到完全溝通和相互理解，在需求分析階段做出的用戶需求常常是不完整、不正確的

增量模型

• 增量模型在每個階段交付滿足客戶需求的一個子集的可運行產品。因此可以較好的適應變化，以及控制風險。

• 增量的一個缺點是后面並入的構建不能破壞已構造好的系統部分，這需要軟件具備開放式的體系結構

• 在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力大大優於線性模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性

1.4迭代模型

迭代模型的特點

• 迭代模型包括了一系列的迭代，每一個迭代有包括了一些或者很多的開發活動（需求、分析、設計、實現等等）

• 每個后續的迭代都建立在前一個迭代的基礎上以使系統得到發展和細化，直到最終產品被完成

• 迭代模型中集成不是在項目中的尾聲進行的“大動作”，每一次迭代都以集成構建系統各部分結束，這樣不斷的積累將使日后的返工最小化

1.5開發模型的選擇

• 在前期需求明確的情況下盡量采用瀑布模型或改進型的瀑布模型

• 在用戶無信息系統使用經驗，需求分析人員技能不足情況下一定要借助原型

• 在不確定性因素很多，或者需求不穩定的情況下，無法有效的進行計划的情況下，盡量采用增量迭代和螺旋模型

• 資金和成本無法一次到位情況下可以采用增量模型，軟件產品分多個版本進行發布

• 對於完全多個獨立功能功能開發可以在需求階段就分功能進並行，但每個宮那個呢內都應該遵循瀑布模型

• 對於全新系統的開發必須在總體設計完成后再開始增量或並行

• 對於編碼人員經驗較少情況下建議不要采用敏捷開發或迭代生命周期模型

• 增量、迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口准則

1.6什么是好的測試

好的測試應該具備

• 每個開發活動都有相對應的測試活動

• 每個測試級別都有其特有的測試目標

• 對於每個測試級別，需要在相應的開發活動過程中進行相應的測試分析和設計

• 在開發生命周期中，測試人員在文檔初稿階段就應該參與文檔的評審

2.測試級別

2.1測試級別

 

測試活動貫穿於整個軟件生命周期

• 單元測試

• 集成測試

• 系統測試

• 驗收測試

針對不同得的測試級別，我們應該明確

• 不同的測試的對象

• 每個測試級別的測試目的

• 測試用例參考的工作產品：測試依據

• 發現的典型缺陷和失效

• 測試工具的需求和支持

• 不同的測試技術和方法

2.2單元測試

基本含義

• 單元測試的對象可以是模塊、類、函數和對象等，不同的軟件語言來決定

• 單元測試的主要目的是驗證單元是否滿足了詳細設計規格說明，發現需求和設計中的作物

• 單元測試設計的主要輸入是詳細設計規格說明、軟件測試和數據模型等

• 單元測試主要采用白盒測試技術，黑盒測試技術作為單元你測試的輔助

• 單元測試應該覆蓋功能需求和非功能需求

• 單元測試經常會使用測試驅動的方法（測試驅動開發）

測試環境

• 單元測試處理的對象直接來自開發人員，通常由開發人員來展開測試

• 單元測試可能並不能形成完成的系統，因此需要驅動模塊和樁模塊的支持； 樁模塊：用以模擬被測工作過程中所調用的模塊工作過程中所調用的模塊，他們一般只有進行很少的數據處理，例如打印入口和返回 驅動模塊：用以模擬被測模塊的上級模塊，它接受測試數據，把相關的數據傳送給被測數據模塊，啟動被測模塊，並打印相關的結果

• 驅動模塊和樁模塊是測試使用的軟件，而不是軟件產品的組成部分，但它需要一定的開發費用

單元測試關注點

• 單元測試關注點： 實際參數和形式參數的個數是否相同； 實際參數和形式參數的屬性是否匹配； 調用函數的參數順序、個數和屬性是否正確；

• 單元模塊局部數據結構： 不適合或者不相容的類型說明； 變量沒有初始化； 不正確的變量名；

• 單元模塊的獨立路徑測試： 誤解或者用錯了算符優先級； 混合類型運算；

• 與控制流相關的的測試： 錯誤的修改了循環變量； 循環中止條件不可能出現

• 與異常處理相關的測試： 輸出的錯誤信息難以理解； 錯誤的信息和實際的錯誤不符

2.3集成測試

基本含義

• 集成測試，又叫組裝測試、聯合測試等

• 集成測試是對組件之間的接口進行測試，以及和系統其它部分的相互作用

• 最簡單的形式的兩個已經測試的單元組合成一個組件，來測試它們之間的接口和數據

• 集成測試的主要工作：把單元測試通過的各個模塊逐步集成在一起，來測試數據是否能夠正確傳遞和調用，以及各個模塊是否能正確的協同工作

• 集成測試可以應用在不同的測試等級，比如單元集成測試、系統集成測試等。

集成測試的關注點

• 單元模塊是否傳輸了錯誤的數據，或者沒有傳輸數據

• 接受數據的單元不能操作或者崩潰，比如單元功能缺陷、接口格式不兼容、協議不兼容等

• 單元之間通訊正常，但是使用不同的方法來解析收到的數據，比如規格說明矛盾、理解錯誤等

• 數據能正常傳輸，但是傳輸時間錯誤，比如時序問題，或者傳輸的時間間隔太短，比如吞吐量、負荷、容量問題。

2.4集成測試策略

自底向上集成測試步驟

• 明確被測模塊並進行先后順序分層

• 按照時間線序關系，將不同單元進行集成

• 將不同的模塊集成為子系統，或者分系統

• 將子系統集成為系統

自底向上集成測試特點

• 不需要樁

• 需要構造不同的驅動模塊

自頂向下集成測試步驟

• 以主控模塊作為測試驅動，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代。

• 依據所選的集成策略（深度優先或廣度優先），每一個

• 每集成一個模塊立即測試一遍

• 只有每組測試完成之后，才着手替換下一個樁模塊

• 為避免引入新的錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）

自頂向下集成測試特點

• 優點：不需要測試驅動器，或者只需要簡單的測試驅動，這是因為經過測試的較高級別單元組成了測試環境的主要部分

• 還沒有集成的較低級別的單元必須用樁代替，成本很高

核心系統優先集成測試步驟

• 對核心系統中的模塊進行單獨的、充分的測試

• 核心系統的所有模塊一次性集合到被測系統中，在規模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統的各組成模

• 按照各外圍軟件部件的重要程度以及模塊見得相互制約關系，擬定外圍軟件部件集成到核心系統中的順序方案

• 完成外圍軟件部件內部的集成測試

• 按順序不斷加入外圍軟件部件到核心系統

隨意測試的步驟

• 按照單元的完成時間進行集成

隨意集成測試特點

• 優點：節省時間，因為每個單元可以最快的集成到環境中來

• 缺點：樁和測試驅動都需要

大爆炸集成策略：避免

• 本來可以用作測試的時間浪費在等待大爆炸集成上了。由於王總是缺乏用於測試的時間，所以不應該浪費可以用於測試的任何時間

• 所有的失效將會同時發生。有時集成后的系統根本無法運行起來。此外，定位和修正缺陷會很困難，並且消耗很多時間

2.5系統測試

測試目標

• 系統測試的目標是確認整個系統是否滿足了規格說明中的功能和非功能需求，以及滿足的程度

• 系統測試應該發現由於需求不正確、不完整或實現和需求不一致二引起的失效，並識別沒有文檔化或被忘記的需求

• 常見的系統測試包括壓力測試、容量測試、性能測試、安全測試、容錯測試等

為什么系統測試

• 在較低的測試級別，測試主要是針對技術規格說明，即從軟件開發者的技術觀點角度加以考慮。而系統測試從客戶或用戶的觀點來考慮整個系統。測試人員確認是否完全正確地滿足了需求

• 許多功能和系統屬性是從系統的所有組件相互協調的過程中得到的，因為只能字啊整個系統級別才能看到，也只能在這個時候才能夠法進行觀察並測試。

2.6驗收測試

基本含義

• 驗收測試通常是由使用系統的用戶來進行，同時系統的其他利益相關者也可以參與其中。

• 驗收測試目的是通過驗收測試，對系統功能、系統特定部分或特定的系統非工能特征進行測試

• 發現缺陷不是驗收測試的主要目標，驗收測試也可以用來評估系統是否可以在市場部署、用戶使用系統的准備情況等

驗收測試類型

• 合同驗收測試

• 規范驗收測試

• Alpha和Beta測試

• 用戶驗收測試

• 運行驗收測試

 

3.測試類型

3.1功能測試

基本含義

• 功能測試指的是軟件系統“做什么”

• 功能測試的測試依據包括：需求規格說明、用例、功能對個說明。他們描述了系統必須完成的功能

• 功能測試主要考慮的是系統的外部表現，即一般才用的黑盒測試的技術

• 功能測試可以應用在各個測試級別

功能測試包括

• 合適性

• 准確性

• 互操作性

• 安全性

3.2非功能測試

基本含義

• 非功能性指的是系統工作的“怎么樣”，比如系統有多容易使用等

• 非功能測試不是功能的測試，二十對功能行為的測試，或作為整體系統能力的測試

• 非功能測試可以應用在任何測試級別上

非功能測試包括

• 可靠性

• 易用性

• 可維護性

• 可移植性

非功能測試例子

• 負載測試：增加系統負載來測量系統的行為（如並發用戶數、事物數）

• 性能測試：測量特定用例的處理速度和響應時間，通常依賴於不斷增加的負載

• 容量測試：再打容量數據下系統行為額觀察（如處理非常大的文件）

• 壓力測試：觀察超負荷下系統行為

• 安全性測試：針對未授權的訪問攻擊等。

• 穩定性：或可靠性測試：在長時間運行中測試（如事項的平均時間或指定用戶配置的失效率）

• 健壯性測試：測量在系統對於錯誤操作、錯誤編程、硬件故障的相應，以及檢查系統異常處理和恢復的能力

• 金融新和數據轉換測試：檢查給定系統的兼容性，導入/導出數據等

• 系統不同配置的測試：例如：操作系統的不同版本，用戶接口語言，硬件平台等等（比對測試（back-to-back testing））

• 可用性測試：檢查客戶學習系統的容易醒、操作性和效率、系統輸出的可理解性等，經常與特定用戶組的需求相關

3.3結構測試

基本含義

• 結構測試，或者白盒測試，使用測試對象的內部代碼結構和架構信息（語句或判斷、遞歸調用、菜單結構），也可能使用軟件的抽象模型（例如：過程流模型或狀態轉換模型）等作為輸入；

• 結構測試可以在任何測試級別上進行

• 結構測試技術通常通過評估結構類型測試的覆蓋性，來測量測試的完整性

• 結構測試通常應用在低級別的測試上，比如單元測試和集成測試，但它同樣使用其他級別的測試

覆蓋類型

• 語句覆蓋

• 判定覆蓋

• 條件組合覆蓋

• 判定/條件覆蓋

• 路徑覆蓋

4.維護測試

維護測試

• 系統在未預料的和沒有計划過德行的運行環境中運行

• 客戶表達了新的願望

• 需要處理不可預見的很少發生的情況

• 出現很少發生或只在運行時間很長后才發生程序崩潰

為什么回歸測試

• 通過重新進行測試以確定原來的缺陷已經成功的修改、或者新增的功能已經正確實現

• 通過測試，確認系統的變更比如新增功能或者缺陷修改，沒有影響原來的功能和操作

如何回歸測試

• 維護測試的范圍取決於變更的風險、現有系統規模和變更的大小

• 確定變更如何影響現有系統的過程，稱之為影響分析，它有助於決定實施回歸測試的廣度和深度

回歸測試步驟

• 軟件變更分析

• 變更影響分析

• 定義回歸測試策略

• 定義回歸測試套件

• 執行回歸測試套件

• 報告測試結果

版本開發和維護測試