軟件測試軟件測試策略章節目標軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試Unit標題2軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試3軟件測試的特征

測試開始于模塊層，然后“延伸”到整個基于計算機的系統集合中不同的測試技術適用于不同的時間點測試是由軟件的開發人員和(對大型系統來說)獨立的測試組來管理的測試和調試是不同的活動，但是調試必須能夠適應任何的測試策略

4驗證和確認

軟件測試是驗證和確認的一部分驗證：“我們是否正確地完成了產品？”

確認：“我們是否完成了正確的產品？”

5軟件測試組織的誤解

軟件的開發人員根本不應當參與測試軟件應當給那些會無情地挑毛病的陌生人來測試測試者只有在測試的步驟即將開始的時候才參與項目6參與測試的角色和職責軟件開發人員負責程序的單個單元(模塊)的測試

獨立測試組織(ITG)的功能是為了避免讓開發者進行測試時引發固有問題。

開發人員和ITG在軟件項目中應當緊密合作

7軟件測試策略Unit標題單元測試集成測試確認測試系統測試8測試完成的標準－幾種看法你永遠也不可能完成測試，這個重擔將會簡單地從你(或者開發人員)身上轉移到你的客戶身上

當你時間不夠或者資金不夠用的時候，就完成了測試

我們不能絕對地認定軟件永遠也不會再出錯，但可以根據合理和有效的統計模型來判定軟件的測試程度9軟件故障模型

f(t)=(1/p)1n(l0pt+1)

其中f(t)=軟件在一定的測試時間t后，可能會發生故障的預期累計數目。l0=在測試剛開始時的初始軟件故障密度(單位時間內的故障數)。p=錯誤被發現和修正的過程中故障密度的指數遞減值。瞬時的故障密度，l(t)可以使用f(t)的導數得出，l(t)=l0/(l0pt+1)

10軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試11策略問題

在著手開始測試之前較長時間內，就要以量化的形式確定產品的需求

明顯地指出測試目標

了解軟件的用戶并為每一類用戶建立相應檔案，著重于測試產品的實際用途建立一個強調“快速循環測試”的測試計劃

12策略問題（續）設計一個能夠測試自身是否“強壯”的軟件

使用有效的正式技術復審作為測試之前的過濾器

使用正式技術復審來評估測試策略和測試用例本身

為測試過程建立一種連續改善的實現方法

13軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試14單元測試模塊將被測試測試用例結果軟件工程師15單元測試（模塊測試）單元測試又稱模塊測試，是針對軟件設計的最小單位─程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。16單元測試接口本地數據結構邊界條件獨立路徑錯誤處理路徑將被測試的模塊測試用例17單元測試規程

模塊

樁

樁

驅動器

結果測試用例接口本地數據結構邊緣條件獨立路徑錯誤處理路徑18單元測試規程

模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。驅動模塊(driver)模擬被測試模塊的上一級模塊

樁模塊(stub)

模擬被測試模塊工作過程中所調用的模塊驅動模塊和樁模塊設計都是額外的工作，兩種都屬于必須開發但又不能和最終軟件一起提交的軟件。19測試思維訓練---帶廣告圖案的花紙杯測試方案20測試思維訓練---帶廣告圖案的花紙杯測試方案1、觀察紙杯的外觀大小是否美觀、是否能方便地拿起；2、廣告是否吸引人、賞心悅目；3、廣告圖案放的位置是否合理，比如不能離杯口太近，盡量不要讓嘴碰到；4、裝入滿杯的水，記錄多久以后紙杯會漏水；5、裝入滿杯的熱水，觀察廣告的顏色是否會因為受熱而褪色；6、測試裝入多少溫度的水，會使人感到太冰或太燙以致于無法端握；21測試思維訓練---帶廣告圖案的花紙杯測試方案7、裝入半杯的水，并在杯中放入湯匙，看杯子是否能平穩放置而不會傾倒在桌上；8、裝入半杯的水，將杯子放置有風的窗口，看杯子是否平穩放置而不會被風吹倒；9、裝入有顏色的飲料如咖啡，果汁等，喝完以后，再裝入純凈的水，看是否因為杯壁的殘留而致使純凈的水變色；22測試思維訓練---帶廣告圖案的花紙杯測試方案10、用手隨意捏癟空的杯子，然后再把杯子還原，還原后是否還能再承載與原來一樣的冷，熱水……11、裝水前以及裝水后分別測試能否被撕碎；12、用打火機點燃杯子，或丟入未熄滅的煙頭，看杯子是否會燒起來；23軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試24集成測試?“大動作的”方法? 增量式的構建策略25集成測試（綜合測試）通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。通常，把模塊組裝成為系統的方式有兩種1、非增量式測試2、增量式測試

26自頂向下的增量式測試這種組裝方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。自頂向下的增量式測試在測試過程中較早地驗證了主要的控制和判斷點。選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件功能。27自頂向下的增量式測試28自頂向下集成使用樁測試上層模塊深度優先

當新的模塊被集成時，一些測試子集被重新運行ABCDEFG29測試者的三種選擇

把測試推遲到穩定樁被換成實際的模塊之后再進行

開發能夠實現有限功能的用來模擬實際模塊的穩定樁

從層次結構的最底部向上來對軟件進行集成

30自底向上的增量式測試這種組裝的方式是從程序模塊結構的最底層的模塊開始組裝和測試。因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。31自底向上的增量式測試32自底向上集成

一次代替一個驅動器,"深度優先"模塊被劃分成構建并進行集成ABCDEFG簇

33兩種實施方法的比較優點缺點自頂向下測試

可以自然地做到逐步求精，一開始便能讓測試者看到系統的框架

需要提供樁模塊在輸入/輸出模塊接入系統以前，在樁模塊中表示測試數據有一定困難由于樁模塊不能模擬數據，如果模塊間的數據流不能構成有向的非環狀圖，一些模塊的測試數據難于生成；觀察和解釋測試輸出往往也是困難的

自底向上測試

由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，生成測試數據也沒有困難特別適合于關鍵模塊在結構圖的底部的情況

直到最后一個模塊被加進去之后才能看到整個程序（系統）的框架

只有到測試過程的后期才能發現時序問題和資源競爭問題34軟件測試策略

軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試35確認測試的標準

所有的功能需求都得到了滿足

所有性能需求都達到了

文檔是正確且合理的

其他的需求

可移植性

兼容性

錯誤恢復

可維護性

36

Alpha和Beta測試

Alpha測試是由一個用戶在開發者的場所來進行的，軟件在開發者對用戶的“指導”下進行測試，開發者負責記錄錯誤和使用中出現的問題，Alpha測試是在一個受控的環境中進行的。

Beta

測試是由軟件的最終用戶在一個或多個用戶場所來進行的，不象

Alpha測試，開發者通常來說不會在場，因此，Beta測試是在軟件在一個開發者不能控制的環境進行的。

37軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認測試系統測試38系統測試系統測試，是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的集成測試和確認測試。系統測試的目的在于通過與系統的需求定義作比較,發現軟件與系統的定義不符合或與之矛盾的地方。39系統測試分類恢復測試安全測試強度測試性能測試可靠性測試兼容性測試40恢復測試

許多基于計算機的系統必須在一定的時間內從錯誤中恢復過來，然后繼續運行。恢復測試是通過各種手段，讓軟件強制性地發生故障，然后來驗證恢復是否能正常進行的一種系統測試方法。

41安全測試

系統的安全當然必須能夠經受住正面的攻擊系統的安全也必須能夠經受住側面的和背后的攻擊在安全測試過程中，測試者扮演著一個試圖攻擊系統的個人角色只要有足夠的時間和資源，好的安全測試就一定能夠最終侵入一個系統

42壓力測試

在本質上說，進行壓力測試的人應該這樣問：“我們能夠將系統折騰到什么程度而又不會出錯？”

壓力測試是在一種需要反常數量、頻率或資源的方式下執行系統。43性能測試

硬盤使用率內存使用率處理器使用率網絡使用率44驗收測試

驗收測試是檢驗軟件產品質量的最后一道工序。驗收測試通常更突出客戶的作用，同時軟件開發人員也有一定的參與。45逆向思維訓練1請從理論上或邏輯的角度在后面填入后續字母或數字A,D,G,J1,3,6,101,1,2,3,521,20,18,15,118,6,7,5,6,465536,256,161,0,-1,0