軟件測試?yán)碚撜n程第三章(軟件測試策略)

軟件測試軟件測試策略章節(jié)目標(biāo)軟件測試的策略途徑策略問題單元測試集成測試確認(rèn)測試系統(tǒng)測試Unit標(biāo)題2軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認(rèn)測試系統(tǒng)測試3軟件測試的特征

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

4驗證和確認(rèn)

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

確認(rèn)：“我們是否完成了正確的產(chǎn)品？”

5軟件測試組織的誤解

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

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

開發(fā)人員和ITG在軟件項目中應(yīng)當(dāng)緊密合作

7軟件測試策略Unit標(biāo)題單元測試集成測試確認(rèn)測試系統(tǒng)測試8測試完成的標(biāo)準(zhǔn)－幾種看法你永遠(yuǎn)也不可能完成測試，這個重?fù)?dān)將會簡單地從你(或者開發(fā)人員)身上轉(zhuǎn)移到你的客戶身上

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

我們不能絕對地認(rèn)定軟件永遠(yuǎn)也不會再出錯，但可以根據(jù)合理和有效的統(tǒng)計模型來判定軟件的測試程度9軟件故障模型

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

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

10軟件測試策略軟件測試的策略途徑策略問題單元測試集成測試確認(rèn)測試系統(tǒng)測試11策略問題

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

明顯地指出測試目標(biāo)

了解軟件的用戶并為每一類用戶建立相應(yīng)檔案，著重于測試產(chǎn)品的實際用途建立一個強(qiáng)調(diào)“快速循環(huán)測試”的測試計劃

12策略問題（續(xù)）設(shè)計一個能夠測試自身是否“強(qiáng)壯”的軟件

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

使用正式技術(shù)復(fù)審來評估測試策略和測試用例本身

為測試過程建立一種連續(xù)改善的實現(xiàn)方法

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

模塊

樁

樁

驅(qū)動器

結(jié)果測試用例接口本地數(shù)據(jù)結(jié)構(gòu)邊緣條件獨立路徑錯誤處理路徑18單元測試規(guī)程

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

樁模塊(stub)

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

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

當(dāng)新的模塊被集成時，一些測試子集被重新運(yùn)行ABCDEFG29測試者的三種選擇

把測試推遲到穩(wěn)定樁被換成實際的模塊之后再進(jìn)行

開發(fā)能夠?qū)崿F(xiàn)有限功能的用來模擬實際模塊的穩(wěn)定樁

從層次結(jié)構(gòu)的最底部向上來對軟件進(jìn)行集成

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

一次代替一個驅(qū)動器,"深度優(yōu)先"模塊被劃分成構(gòu)建并進(jìn)行集成ABCDEFG簇

33兩種實施方法的比較優(yōu)點缺點自頂向下測試

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

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

自底向上測試

由于驅(qū)動模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構(gòu)成有向的非環(huán)狀圖，生成測試數(shù)據(jù)也沒有困難特別適合于關(guān)鍵模塊在結(jié)構(gòu)圖的底部的情況

直到最后一個模塊被加進(jìn)去之后才能看到整個程序（系統(tǒng)）的框架

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

軟件測試的策略途徑策略問題單元測試集成測試確認(rèn)測試系統(tǒng)測試35確認(rèn)測試的標(biāo)準(zhǔn)

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

所有性能需求都達(dá)到了

文檔是正確且合理的

其他的需求

可移植性

兼容性

錯誤恢復(fù)

可維護(hù)性

36

Alpha和Beta測試

Alpha測試是由一個用戶在開發(fā)者的場所來進(jìn)行的，軟件在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試，開發(fā)者負(fù)責(zé)記錄錯誤和使用中出現(xiàn)的問題，Alpha測試是在一個受控的環(huán)境中進(jìn)行的。

Beta

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

Alpha測試，開發(fā)者通常來說不會在場，因此，Beta測試是在軟件在一個開發(fā)者不能控制的環(huán)境進(jìn)行的。

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

許多基于計算機(jī)的系統(tǒng)必須在一定的時間內(nèi)從錯誤中恢復(fù)過來，然后繼續(xù)運(yùn)行?；謴?fù)測試是通過各種手段，讓軟件強(qiáng)制性地發(fā)生故障，然后來驗證恢復(fù)是否能正常進(jìn)行的一種系統(tǒng)測試方法。

41安全測試

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

42壓力測試

在本質(zhì)上說，進(jìn)行壓力測試的人應(yīng)該這樣問：“我們能夠?qū)⑾到y(tǒng)折騰到什么程度而又不會出錯？”

壓力測試是在一種需要反常數(shù)量、頻率或資源的方式下執(zhí)行系統(tǒng)。43性能測試

硬盤使用率內(nèi)存使用率處理器使用率網(wǎng)絡(luò)使用率44驗收測試

驗收測試是檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。驗收測試通常更突出客戶的作用，同時軟件開發(fā)人員也有一定的參與。45逆向思維訓(xùn)練1請從理論上或邏輯的角度在后面填入后續(xù)字母或數(shù)字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