第六章 物件導向軟體測試.

Presentation on theme: "第六章 物件導向軟體測試."— Presentation transcript:

1 第六章 物件導向軟體測試

2 大綱 物件導向軟體測試概論 單元測試 整合測試 系統測試 驗收測試 測試案例設計 結論

3 物件導向軟體測試概論 簡述。 物件導向測試模型。 物件導向分析測試。 物件導向設計測試。 物件導向程式設計測試。

4 簡述1 物件導向軟體測試其主要目的跟傳統的軟體測試大致上是相同的，使用最少的資源來找出存在軟體內的錯誤。
物件導向軟體跟之前傳統軟體內部的內容、策略以及在方法上大大不為相同。 物件導向技術有獨特的特性，比如多型、繼承、封裝使物件導向產生錯誤的可能性比傳統軟體測試還要大。

5 簡述2 物件導向技術正逐漸的被廣泛使用，成為解決軟體危機的新技術。
物件導向的結構不是傳統的功能模組結構，作為一個整體，原有整合測試所要求的逐步將開發的模組搭建一起進行測試方法。

6 物件導向測試模型1 物件導向將開發分成 使用開發階段的測試及程式設計完成後的單元測試、整合測試、系統測試成為一個整體。
物件導向分析 (OOA)。 物件導向設計 (OOD)。 物件導向程式設計 (OOP)。 使用開發階段的測試及程式設計完成後的單元測試、整合測試、系統測試成為一個整體。

7 物件導向測試模型2

8 物件導向測試模型3 軟體發展過程中不斷測試的模型，使開發階段成為一個整體。 物件導向分析測試與物件導向設計測試對分析結果與設計結果的測試。
物件導向程式設計測試對程式設計風格實現進行測試。

9 物件導向測試模型4 物件導向程式設計測試對程式的程式碼進行測試。 物件導向單元測試是對程式內部類別成員函數的測試。
物件導向單元測試是進行物件導向整合測試的基礎。

10 物件導向測試模型5 物件導向整合測試主要針對系統內的相互服務進行測試。 物件導向整合測試要參考物件導向設計的結果。
Ex：類別間的訊息傳遞。 函數間的相互作用。 物件導向整合測試要參考物件導向設計的結果。 物件導向整合測試要參考物件導向設計測試的結果。

11 物件導向測試模型6 物件導向系統測試在物件導向整合測試的最後階段測試。
物件導向系統測試以使用者需求為測試標準，且要參考物件導向分析測試及物件導向設計測試的結果。

12 物件導向分析測試1 傳統系統分析是功能分解的過程，是把系統可以看成分解的功能性集合。
物件導向分析測試把資訊塑膜中的概念，與物件導向程式設計的概念結合一起的分析方法。 物件導向分析測試直接映射問題空間，將問題空間的實例直接抽象化為物件。

13 物件導向分析測試2 物件導向分析測試階段類別選定與實現、類別層次結構的組織和實現提供平台。 物件導向分析測試的重點在於，完整性以及冗長性。

14 物件導向分析測試3 電腦設備管理系統的物件導向分析結果圖

15 物件導向分析測試4 對物件導向分析測試分成了五種方面 確認物件的認定。 確認類別的結構。 主題名稱的確認。 確認屬性及關聯。
確認操作方法及訊息。

16 確認物件的認定1 認定的物件對問題空間中的結構、其他系統、設備、事件、人員實際案例的抽象。 如下：
認定的物件是否全面，問題空間中涉及到實例是否都反映在認定的抽象物件。 認定的物件是否具有多種屬性。 認定同一物件的實例是否有共同的屬性。

17 確認物件的認定2 認定同一物件的實例是否也要提供相同 的服務。 系統沒有必要始終保持物件代表的 實例資訊。 認定的對象名聲應該盡量準確。

18 確認類別的結構1 結構內有多種物件的組織方式。 用來反映問題空間中的複雜實例及 複雜關係。 可以分成兩種結構，如下。

19 確認類別的結構2 對繼承結構的測試： 位於上層的物件是否在空間中含有不同下層 物件的特殊可能性。 在下層的物件是否能夠抽象出比上層物件
的可能性 所有認定物件能否向上層抽象出有意義 的物件 上層物件特性是否完全表現下層共同性 下層是否有高層特性基礎

20 確認類別的結構3 對組裝結構的測試： 整體物件與個別物件是否符合現實關係。 整體物件與個別物件考慮出有實際應用。
整體物件是否遺漏反映在有用的個別物件。

21 主題名稱的確認1 物件及類別結構更上層的抽象，提供分析結果的可見性： 主題反應物件及結構使否有相同的屬性。 並且確認是否應該使用相同的服務。
主題間的訊息聯繫代表主題所反映的物件以及結構所有的關聯。

22 確認屬性及關聯1 屬性描述物件及結構來反映案例的特性。 定義的屬性相對應的物件及分類結構是否都適用。 定義的屬性問題空間是否於案例關係密切。
定義的屬性是否能不依賴其他屬性。 每個物件屬性是否定義完整。 要注意一對多及多對多的案例關聯。

23 確認操作方法及訊息1 定義每種物件與結構在問題空間要求行為 物件與類別是否都定義相對應的服務。 物件與類別所需要的服務。 定義出訊息關聯。
沿著訊息關聯執行緒是否合理。 定義的操作方法是否重複。

24 物件導向設計測試1 傳統的系統分析是面向作業的設計方法，把系統分解成功能的集合。
物件導向設計採用造型的觀點，以物件導向分析為基礎建構出類別庫。 物件導向設計測試是物件導向測試分析的更進步及更高層的抽象。 物件導向設計測試透過系統不斷重組，實現功能的擴增及重覆使用。

25 物件導向設計測試2 對物件導向設計測試，可以分成三構面來考量。 確認類別名稱合理性。 確認類別層次結構適合性。 確認類別庫的支援。

26 確認類別名稱合理性1 物件導向設計測試認定的類別可以是物件導向分析測試中的物件。 是否涵蓋物件導向測試分析的物件。
是否能實現物件導向測試分析的屬性。 是否能實現物件導向測試分析的服務。 能否盡少依賴其他類別。

27 確認類別層次結構適合性1 物件導向設計測試的類別層次結構基於物件導向分析測試產生分類結構。 可以發揮物件導向的繼承特性。
確認設計階段能夠實現物件導向分析測試需求結構。

28 確認類別層次結構適合性2 用以下方法驗證適合性。 能否實現物件導向分析測試的實例關聯。 能否實現物件導向分析測試的訊息關聯。
子類別能否具有父類別沒有的新特性。

29 確認類別庫的支援1 軟體發展若採用螺旋式的遞增模式。 因為物件導向分析測試及物件導向設計測試。 不斷評估類別庫是否支援新功能。

30 確認類別庫的支援2 由這兩方面評估： 一致性： 演化的性質在模型內要包含分析、設計及 程式設計。 類別、屬性、操作、訊息要正確且一致性。
正確性： 分析模型所使用的符號是否具有正確性。 類別間關聯是否反映真實世界的物件關聯。

31 物件導向程式設計測試1 物件導向的程式特性：繼承、封裝、多型 封裝是對資料的隱藏，降低資料被任意修改及讀寫的可能性。
繼承是重要一種特性，使程式碼的重用率變高，但錯誤率也會提高。 多型讓物件導向程式對外呈現出強大的處理能力。

32 物件導向程式設計測試2 物件導向程式把功能的實現分佈在類別中 能夠正確的實現功能的類別 物件導向程式的測試要依循傳統的方法

33 物件導向程式設計測試3 測試各類別的方法是否實現物件導向程式設計測試。 資料成員封裝性測試 類別功能的正確性測試
檢查資料成員是否滿足資料封裝的要求。 是否會影響類別對外的介面，外界是否必須變更。 有時強制類型轉換會破壞資料的封裝特性。 類別功能的正確性測試 確認類別成員函數的正確性。 實現要求的功能基礎。 需要進行物件導向的整合測試。

34 單元測試1 單元測試在物件導向程式設計完成後 即可進行。 物件導向單元測試一個操作功能只能作為一個類別的部分。
類別中有多各種功能就要進行多個操作測試。 在非物件導向內單元為模組，物件導向內 單元為類別。

35 單元測試2 每個類別均含有資料及方法或服務。 父類別定義的某些操作被許多子類別 繼承。 類別的測試可以使用多種方法。 故障測試。 隨機測試。
分割測試。

36 單元測試3 設計測試案例輸入時會有兩種假設： 函數對某類別輸入正確時，代表同類別其他輸入也能正確。 需要選擇字串為輸入時，無須計較字串的
長度。 注意物件導向程式的特性，進行測試分析及設計測試案例。

37 單元測試4 子類別繼承或超載父類別成員所需考慮的兩種問題。 多型的類型 繼承的成員函數是否都不需要測試？
對父類別的測試是否都能照搬到子類別？ 多型的類型 參數多型 包含多型 超載多型

38 整合測試1 物件導向軟體無法編譯不完全的程式上進行類別的整合測試。 物件導向採用編譯後程式用黑箱測試的整合測試策略。 使用兩種測試策略：
基於執行緒的測試 (Thread-Based-Testing)。 基於使用者測試 (Use-Based-Testing)。

39 基於執行緒的測試1 合作對應一個事件類別及合組裝起來。 回應系統的一個事件請求來組裝類別集合。 每個執行緒分別進行組裝及測試。

40 基於使用者測試1 按照分層來組裝系統。 可以進行獨立類別測試。 獨立類別測試後，下層稱之從屬類別。 從屬類別用獨立類別進行測試。
從屬類別的順序測試值到整個系統被建構。

41 整合測試2 物件導向的系統組裝必須進行類別間合作。 可用隨機應用及分割測試來完成。 無法檢測出類別相互作用才會產生的錯誤。
整合測試關注系統的結構及內部的相互作用。 物件導向整合測試可分成： 靜態測試。 動態測試。

42 整合測試3 靜態測試 針對程式的結構進行，檢測程式結構是否符合設計要求。
目前測試軟體能提供 (可逆性工程)的功能，透過原程式得到類別關係圖及函數功能的呼叫圖。 可逆性工程檢測程式結構和實現上是否會有缺陷。 檢測物件導向程式設計是否達到設計的要求。

43 整合測試4 動態測試 使用功能呼叫結構圖、類別關係圖及實體 關係圖。 最佳化測試來減少測試工作量，進行測試能夠達到一定覆蓋標準。
達到對所有執行緒有一定的覆蓋率。

44 系統測試1 開發軟體必須經過規範的系統測試。 滿足使用者的需要。 是否存在會被誘發的錯誤性存在。
盡量搭建與使用者實際使用環境相同的測試平台。 保證系統的完整性。 應具有臨時沒有系統設備元件的各種模擬手段。

45 系統測試2 參考物件導向測試分析，對應出相關的物件、屬性及服務。 檢測軟體是否能夠完全重現問題空間。 具體測試內容包含：
功能測試(functions tests)： 測試是否能夠滿足開發要求。 測試是否能夠提供設計所描述的功能。 測試是否使用者的需求能夠得到滿足。

46 系統測試3 強度測試 (Stress tests)： 測試系統在特殊條件下的最高實際上限度。 驗證系統在面臨同時許多要求的時候，是否
可以在繼續運作。 要求軟體進行大量重複、輸入大量資料、大 數值的資料…等。

47 系統測試4 效能測試 (Performance tests)： 測試軟體在執行時的執行效能。 通常與強度測試結合進行測試。
事先被測軟體提出效能指標。

48 系統測試5 安全測試 (Security tests)： 驗證安裝系統內的保護機構能確實的對系統 進行保護。
對於一些非法存取的使用者，驗證訪問機制 的工作。 設計一些測試專用的案例。

49 系統測試6 修復測試 (Recovery tests)： 測試系統的可靠性及可修復性。 採用人工的干擾使軟體出錯，中斷使用。
驗證系統失敗後的恢復能力，並參考效能測 試的相關測試指標。

50 系統測試7 可用性測試 (Availability tests)： 測試使用者是否能夠滿意的使用。 測試使用者再使用時會不會出現一些少見且
在之前並未被發現的錯誤。

51 系統測試8 安裝 / 移除測試 (Install / Uninstall test)： 需要對被測試的軟體結合需求分析仔細的測
試分析，建立測試案例。

52 驗收測試1 驗收測試介紹。 驗收測試的測試技術。 驗收測試結論。

53 驗收測試介紹1 是一個流程，以獲得確認企業，最好是使用者這方面的對象進行測試，通過審判或審查，該修改或增補符合雙方協定的要求。
使用者或客戶會制定一些驗收標準，來驗收產品。

54 驗收測試介紹2 驗收測試是以使用者為主的測試。 使用使用者介面輸入資料，並且分析測試後的輸出結果，使用一般生產中的實際資料進行測試。
驗收測試對整個測試計畫進行一種”走查(Walkthrough)“。

55 驗收測試的測試技術1 使用者驗收測試包括在企業驗收測試，即測試完成之前，可以移動到用戶端由用戶驗收。
合約和規範驗收測試合約驗收測試，指系統要驗收之前，此系統要已被測試採納，以確保它符合政府法律和安全標準。

56 驗收測試測試技術2 業務驗收測試(業務準備測試) 這是指做了檢查制度，以確保過程、 程序與系統的使用和保養。
這項目包括後備設施、程序、損壞恢 復，最終用戶教育訓練、維修程序和 安全程序。

57 驗收測試結論1 驗收測試階段，我們的目標是提供信 心，並且交付系統，以滿足業務需求 和用戶。 驗收階段也可作為最後的品質觀察，
凡是之前階段沒有發現的質量缺陷， 都有可能在此階段發現。

58 測試案例設計1 物件導向軟體測試著重於適當的操作序列，來實現對類別的說明。 黑箱測試也可用來作物件導向軟體測試。
白箱測試也可用來作物件導向的軟體類別的操作定義。 物件導向的度量中所講的五種特性，區域性、封裝性、資訊隱藏、繼承性、物件的抽象會對案例設計帶來額外的麻煩及困難

59 測試案例設計2 故障測試。 腳本測試。 物件導向類別的隨機測試。 類別層次分割測試。 由行為模式導出的測試。

60 故障測試1 具有較高的發現可能故障的能力。 系統必須滿足使用者的需求。 故障測試關鍵取決於如何理解可能的錯誤。
故障測試可以用整合測試進而去發現可能性的故障。 可以用來確認不同類型的物件行為是否有正確性的屬性值。

61 腳本測試1 以腳本基礎的測試主要關鍵在於使用者 的需求。 可以在一個單元測試情況下檢查多 重系統。
腳本測試會來得比案例測試更為實際，且更為複雜一點。

62 物件導向類別的隨機測試1 一個類別有多種功能，這些功能序列則會有多種排列方式。 不同變化的操作序列稱之為隨機產生。
這些操作每一項均可用來計算。 儘管這個操作序列是最小測試序列，這個序列能可發生其他的行為。

63 類別層次分割測試1 減少完全相同的方式檢查類別測試案例 的數目。 分割測試又可分成三種： 狀態的分割： 類別操作是否改變類別的情況來區分。
屬性的分割： 類別操作是否用到的屬性來區分。 類型的分割： 完成的功能性區分。

64 由行為模式導出的測試1 行為模式大致上又可分成： 狀態轉換圖導出類別動態行為的 測試序列。 類別與合作的類別動態行為測試序列。 狀態。
活動。 順序。 合作圖。 狀態轉換圖導出類別動態行為的 測試序列。 類別與合作的類別動態行為測試序列。

65 由行為模式導出的測試2 設計的測試案例應當是完成所有狀態 轉換。 操作序列可能會導致類別所有允許的狀態進行轉換。
保證類別所有行為可以被充分檢查。

66 結論 傳統軟體測試的方法很多還是可以應用在物件導向軟體的測試，本章分別從軟體測試的各個階段，介紹其與傳統軟體測試不同之處。