第七講軟件測試技術(shù)

GIS軟件測試技術(shù)

第七講軟件測試概論軟件測試法則軟件測試方法軟件測試范例軟件測試組織軟件測試技術(shù)－內(nèi)容提要2概論－軟件質(zhì)量與缺陷軟件產(chǎn)品既必需滿足用戶的功能要求，又必須穩(wěn)定可靠地完成用戶的作業(yè)。軟件質(zhì)量體現(xiàn)在多個方面，但首先要面對并必須解決的方面是軟件缺陷。軟件缺陷有可能會給系統(tǒng)質(zhì)量尤其是可靠性帶來重大影響。3概論－現(xiàn)狀我們無法提供無缺陷的軟件各種研究報告表明，每寫1000行代碼會產(chǎn)生30到85個缺陷大多數(shù)缺陷可通過測試捕獲在大量的已完成測試的軟件中，每1000行代碼仍存在0.5—3缺陷4概論－軟件缺陷例1錯誤或含糊的規(guī)格說明不適當(dāng)?shù)脑O(shè)計需求:“阻止魚雷攻擊發(fā)射它的潛艇“(198?)設(shè)計:魚雷發(fā)射后在發(fā)生180度轉(zhuǎn)向時自毀。5概論－軟件缺陷例2事件1999年；火星氣象衛(wèi)星(MarsClimateOrbiter)到達(dá)火星之后不久就消失；火星極地登陸者(MarsPolarLander)在火星上著陸時墜毀。原因地面系統(tǒng)軟件和飛行器上軟件分別使用公制和英制兩種單位。教訓(xùn)沒有進(jìn)行充分的測試；發(fā)現(xiàn)異常時，沒有被恰當(dāng)?shù)慕忉尅?概論－軟件缺陷例3事件

1996年6月4日，Ariane5發(fā)射40秒后爆炸。

原因?qū)⒁粋€64位浮點值轉(zhuǎn)換為16位有符號整數(shù)值時，超出了16位整數(shù)的表示范圍，而這個異常未得到正確解決。教訓(xùn)對于重用模塊，作了Ariane5和Ariane4具有相同環(huán)境的假設(shè)；錯誤處理模塊的處理機(jī)制不正確；重用模塊在新的環(huán)境下完全沒有進(jìn)行測試。7概論－軟件缺陷的屬性失誤(mistake)在軟件開發(fā)過程中軟件開發(fā)人員產(chǎn)生隱錯／缺陷(bug/defect)在軟件產(chǎn)品中軟件中存在設(shè)計者的錯誤行為(失誤)→導(dǎo)致軟件中留有錯誤的設(shè)計(缺陷)→導(dǎo)致軟件錯誤地執(zhí)行(故障)→導(dǎo)致軟件的錯誤行為(失效)。故障(fault)在軟件運行中缺陷被激活失效(failure)在運行階段用戶經(jīng)歷的8概論－獲得高質(zhì)量軟件軟件工程方法正式技術(shù)評審度量與控制標(biāo)準(zhǔn)與過程SQA測試軟件質(zhì)量9概論－缺陷過濾容錯(Defecttolerance)編譯失誤避錯(Defectavoidance)排錯(defectremoval)復(fù)查使用缺陷逃逸測試10概論－定義國家標(biāo)準(zhǔn)GB/T11457—1995軟件工程術(shù)語:由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部件的過程，以驗證它是否滿足規(guī)定的需求；或識別出期望的結(jié)果和實際結(jié)果之間有無差別。IEEE/ANSI:使用為發(fā)現(xiàn)錯誤所選擇的輸入和狀態(tài)的組合而執(zhí)行代碼的過程。11概論－目標(biāo)在給定的時限內(nèi)盡可能多的發(fā)現(xiàn)缺陷和隱患證實給定的軟件產(chǎn)品滿足其需求規(guī)格說明用最低的成本和投入確認(rèn)軟件測試的質(zhì)量建立高質(zhì)量的測試用例，完成有效地測試，提交有用的問題報告為軟件開發(fā)過程的改進(jìn)提供數(shù)據(jù)支持12概論－驗證與確認(rèn)驗證與確認(rèn)是廣泛認(rèn)可的質(zhì)量保證方法和手段軟件測試是軟件驗證與確認(rèn)的重要組成部分驗證是指對某項規(guī)定活動進(jìn)行檢查的過程，以確保該活動實現(xiàn)了規(guī)定功能。確認(rèn)是指審查已建立的軟件產(chǎn)品是否符合客戶需要的過程。Boehm:驗證(Verification):”Arewebuildingtheproductright?”確認(rèn)(Validation):”Arewebuildingtherightproduct?”13概論－測試與調(diào)試測試不是調(diào)試，調(diào)試也不是測試。主要區(qū)別：測試是一種檢驗，調(diào)試是推理過程。測試從已知條件開始，使用預(yù)先定義的規(guī)程并且有可預(yù)知的結(jié)果；調(diào)試的開始條件可能是不可知的，結(jié)果不可預(yù)見。測試經(jīng)常由非程序設(shè)計人員完成，調(diào)試必須由程序設(shè)計者完成。14概論－神話可以對程序進(jìn)行徹底的測試只要測試人員盡力做好工作，就可以發(fā)現(xiàn)所有程序錯誤可以通過嘗試程序所有可能的輸入和狀態(tài)對程序進(jìn)行測試好的測試包必須包含大量的測試用例好的測試用例總是復(fù)雜難懂的軟件測試自動化可以替代測試工程師，很好的完成軟件測試軟件測試簡單又容易，任何人都可以做，不需要培訓(xùn)jmerchant1@

15概論－局限性技術(shù)不可能通過測試獲得100%的質(zhì)量信心無法確信可以達(dá)到100%足夠的軟件測試不存在發(fā)現(xiàn)全部缺陷的單項技術(shù)，一種測試技術(shù)在發(fā)現(xiàn)特定類型的缺陷方面最有效率工程無法確信規(guī)格說明100%正確無法確信測試系統(tǒng)(或環(huán)境)的正確性無法確信測試人員完全理解了軟件產(chǎn)品沒有能夠適用于所有軟件的測試工具沒有足夠的資源徹底完成軟件測試16概論－正確理解測試有效的測試對于開發(fā)可靠、安全和成功的軟件是必須的。測試具有有效范圍，它不是其他軟件工程方法的替代品。17概論－測試投入適量的測試投入取得最佳的測試效果風(fēng)險管理影響測試投入的因素系統(tǒng)的目的潛在的用戶數(shù)量信息的價值開發(fā)機(jī)構(gòu)的成熟度18概論－測試投入(HP)19概論－測試投入(IBM)一般項目：項目總投入的30%~40%高可靠性和高安全性項目：項目其它投入的3~5倍20概論－回顧軟件質(zhì)量與缺陷的關(guān)系導(dǎo)致軟件致命缺陷的原因往往很簡單軟件測試的定義、目標(biāo)和作用有關(guān)軟件測試的一些神話軟件測試的局限性應(yīng)正確的理解軟件測試軟件測試的投入視具體情況而定21法則－無止境除了最簡單的程序，任何程序的完全測試都是不可能的。測試可以表明缺陷的存在，但絕不能證明沒有缺陷。測試只能使好的設(shè)計變得更好“Youcan’ttestinquality.Ifit’snottherebeforeyoubegintesting,itwon’tbetherewhenyou’refinishedtesting.”22法則－復(fù)雜性高質(zhì)量的測試要求測試人員徹底理解系統(tǒng)或產(chǎn)品測試質(zhì)量需要適當(dāng)?shù)臏y試集和有效的測試方法保證缺乏有效的測試工具日程安排得不當(dāng)23法則－盡早開始開發(fā)過程每前進(jìn)一步，發(fā)現(xiàn)和修復(fù)缺陷的平均代價要增長10倍；隨著開發(fā)過程的進(jìn)展，測試的有效性會不斷下降；促使開發(fā)人員盡早考慮軟件的可測試性；缺陷放大模型：來自以前步驟的錯誤通過的錯誤放大的錯誤1:X新產(chǎn)生的錯誤錯誤檢測有效百分比傳給下一個階段的錯誤24法則－需要有效管理應(yīng)建立有效的測試過程，測試過程是否與其它軟件過程協(xié)調(diào)一致，對測試有效性有重要影響；測試工作應(yīng)該有計劃進(jìn)行；對被測對象和測試本身實施配置與變更管理，不能為了便于測試擅自修改程序；分派有經(jīng)驗、富有創(chuàng)造性的人員承擔(dān)測試；采用獨立測試保證測試有效性。25法則－基于風(fēng)險測試是一種高風(fēng)險的活動，其質(zhì)量依賴于：對軟件產(chǎn)品及其相關(guān)領(lǐng)域知識的理解高效率的測試方法、覆蓋率、工具有創(chuàng)造力并具有豐富軟件測試經(jīng)驗的工程師質(zhì)量費用日程測試需要在時間、成本和質(zhì)量之間權(quán)衡26法則－可追溯所有的測試源于用戶需求維持完整的證據(jù)鏈進(jìn)行可重復(fù)的測試和可再現(xiàn)的測試避免不可重復(fù)的即興測試27法則－系統(tǒng)化全面的測試多種方法多個層次多類角色針對性測試符合性驅(qū)動測試缺陷驅(qū)動測試自動的測試肯定與否定的測試測試軟件應(yīng)該做的和不該做的測試有效和無效、期望和不期望的輸入28法則－類聚性軟件缺陷具有類聚性；缺陷隱藏在角落里，聚集在邊界上；程序中隱藏缺陷的概率與其已發(fā)現(xiàn)的缺陷數(shù)成比例。29法則－Pareto法則軟件測試的Pareto法則(8:2):20%的模塊產(chǎn)生80%的缺陷20%的缺陷消耗80%的維護(hù)費用圖例：模塊B模塊C缺陷數(shù)模塊A274184%96%100%30法則－回顧測試是無止境的測試是復(fù)雜的測試應(yīng)盡早開始測試需要有效管理應(yīng)基于風(fēng)險開展軟件測試測試應(yīng)做到可追溯測試必須系統(tǒng)化測試對象存在類聚性Pareto法則適用于測試領(lǐng)域31方法－相關(guān)概念方法:測試用例(testcase):

輸入、執(zhí)行條件以及為一個特殊目標(biāo)所開發(fā)的預(yù)期結(jié)果的集合。32設(shè)計－好的測試用例具有合理的捕獲缺陷的概率執(zhí)行了重要的區(qū)域做了應(yīng)引起注意的事情不做多余的事情既不太簡單也不太復(fù)雜不與其它測試用例冗余使得缺陷顯而易見考慮缺陷的隔離和識別33方法－測試方法分類靜態(tài)測試技術(shù)動態(tài)測試技術(shù)白盒測試(White-BoxTesting)黑盒測試(Black-BoxTesting)34方法－靜態(tài)測試的特征靜態(tài)測試是不動態(tài)執(zhí)行程序代碼而尋找程序代碼中可能存在的缺陷或評估程序代碼的過程?？梢杂扇斯みM(jìn)行，充分發(fā)揮人的邏輯思維優(yōu)勢?？梢越柚浖ぞ咦詣舆M(jìn)行。35方法－常用靜態(tài)測試方法代碼復(fù)查代碼檢查(CodeInspection)代碼走查(Walkthrough)桌面檢查(DeskChecking)代碼審查(CodeReview)靜態(tài)分析(主要由軟件工具自動進(jìn)行)36方法－代碼復(fù)查的入口準(zhǔn)則需求描述文檔程序設(shè)計文檔程序的源代碼清單編碼標(biāo)準(zhǔn)代碼復(fù)查檢查表37方法－代碼復(fù)查規(guī)程獲得程序的源代碼清單選擇代碼復(fù)查方法進(jìn)行代碼復(fù)查記錄發(fā)現(xiàn)的缺陷修復(fù)所發(fā)現(xiàn)的每個缺陷確保所做的修復(fù)正確無誤將缺陷登錄到缺陷日志38方法－代碼復(fù)查的基本內(nèi)容覆蓋率復(fù)查程序邏輯復(fù)查命名和類型復(fù)查變量檢查程序語法檢查程序檢查39方法－代碼復(fù)查的出口準(zhǔn)則完整的、修復(fù)過的源程序清單完整的時間記錄日志完整的缺陷記錄日志40方法－代碼復(fù)查的優(yōu)缺點優(yōu)點：代碼復(fù)查能快速找到缺陷代碼復(fù)查比動態(tài)測試更有效率(3~5倍)代碼復(fù)查看到的是問題本身而非征兆缺點：代碼復(fù)查非常耗費時間(30min/100line)代碼復(fù)查需要知識和經(jīng)驗(30%~80%)代碼復(fù)查應(yīng)在編譯和動態(tài)測試之前進(jìn)行41方法－靜態(tài)分析的內(nèi)容控制流分析數(shù)據(jù)流分析接口分析表達(dá)式分析與軟件缺陷相關(guān)的其它信息過程的調(diào)用層次編碼與命名規(guī)則模塊規(guī)模、調(diào)用/被調(diào)用關(guān)系、扇入/扇出數(shù)所用變量和常量的交叉引用表42方法－動態(tài)測試特征實際運行被測試程序，取得程序運行的真實情況和動態(tài)情況，進(jìn)行分析；測試的質(zhì)量依賴于使用的測試數(shù)據(jù)；生成測試數(shù)據(jù)和分析測試結(jié)果需要時間與經(jīng)費投入；動態(tài)測試涉及人員、設(shè)備和數(shù)據(jù)等多個方面，要求有較好的管理和工作規(guī)程。43方法－白盒測試已知產(chǎn)品內(nèi)部工作流程，通過測試來檢測產(chǎn)品的內(nèi)部動作是否按照詳細(xì)設(shè)計規(guī)格說明的規(guī)定正常進(jìn)行，而不管它的功能；也稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試；目標(biāo)是對所有邏輯路徑進(jìn)行測試，窮舉路徑；依據(jù)詳細(xì)設(shè)計規(guī)范；一種驗證技術(shù)。44方法－邏輯路徑的數(shù)量程序的執(zhí)行序列(邏輯路徑)的數(shù)目是龐大的，簡單的重復(fù)就有可能使執(zhí)行序列的數(shù)目增大到天文數(shù)字。例子：For(inti=0;i<n;++i) {if(a.get(i)==b.get(i)) x[i]=x[i]+100; else x[i]=x[i]/2;}解：可能的執(zhí)行序列/路徑數(shù)是2n＋1當(dāng)n=20時，執(zhí)行序列/路徑數(shù)是1,048,57745方法－基本覆蓋基于控制流的測試語句覆蓋分支覆蓋條件覆蓋條件組合覆蓋基本路徑覆蓋循環(huán)覆蓋數(shù)據(jù)流覆蓋變元覆蓋(mutationcoverage)46方法－控制流圖一個段是一個或多個無條件連續(xù)執(zhí)行的語句。一個段在控制流圖中用一個結(jié)點表示，結(jié)點可以用任何方便的形式命名。一個控制條件轉(zhuǎn)移是一個分支，一個分支段在控制流圖中用一個輸出邊表示。一個程序的入口點用入口結(jié)點表示，它是一個沒有輸入邊的結(jié)點，一個程序的出口點用出口結(jié)點表示，它是一個沒有輸出邊的結(jié)點。47方法－控制流圖例XYZ48方法－語句覆蓋程序中每條語句至少被執(zhí)行一次行覆蓋、段覆蓋、基本塊覆蓋語句覆蓋的盲點(=>0;循環(huán);條件)語句覆蓋是最起碼的測試要求49方法－分支覆蓋程序中的每一個分支至少通過一次決策覆蓋分支覆蓋的盲點短路估值使分支覆蓋不必考慮所有條件忽略了從復(fù)合謂詞引出的隱含路徑分支覆蓋不能保證所有入口－出口路徑都被執(zhí)行50方法－條件覆蓋判定中的每個條件獲得各種可能的結(jié)果不要求測試所有可能的分支51方法－條件組合覆蓋每個判定中條件的各種組合至少出現(xiàn)一次。達(dá)到了條件組合覆蓋，所有的語句、分支和條件都將覆蓋，但不保證路徑覆蓋。在實際測試中，由于謂詞表達(dá)式的短路估值和排它性條件使得達(dá)到所有條件組合不可能。52方法－基本路徑覆蓋圈復(fù)雜度C=e-n+2基本路徑覆蓋要求測試C條不同的入口－出口路徑在某些程序中，分支覆蓋可在少于C條路徑的情況下獲得基本路徑覆蓋可能既沒有獲得語句覆蓋也沒有獲得分支覆蓋。53方法－循環(huán)覆蓋每種循環(huán)結(jié)構(gòu)都有一個不同的控制流圖簡單循環(huán)、嵌套循環(huán)、順序循環(huán)、面條循環(huán)從最內(nèi)層循環(huán)開始測試，直到最外層控制變量值最低完全最小值－1??

最小值??

?

最小值＋1?

?

典型值?

最大值－1?

最大值?

?

最大值＋1??

54方法－數(shù)據(jù)流覆蓋通過一定的覆蓋準(zhǔn)則檢查程序中每個數(shù)據(jù)對象的每次定義、使用和消除。數(shù)據(jù)流模型(DUK)數(shù)據(jù)流覆蓋策略55方法－變元覆蓋測試覆蓋被測實現(xiàn)的指定的變體，如測試探測到變元，則變體“退役”，如測試探測不到變元，則修正測試包。變元是指為程序植入小的變化，一般是常出現(xiàn)的錯誤，如將>=改寫成>。用于檢查系統(tǒng)的容錯能力和測試套件的充分性。56方法－覆蓋分析器覆蓋分析器是分析測試覆蓋率的工具覆蓋分析器工作原理通過對源代碼的詞法分析，插入可跟蹤代碼，再編譯連接；當(dāng)裝配過可跟蹤代碼的軟件執(zhí)行時，就會產(chǎn)生一個跟蹤文件；測試完成后，利用跟蹤文件生成覆蓋報告。57方法－覆蓋率的作用不可執(zhí)行的路徑或條件不可能到達(dá)或冗余的代碼不充分的測試用例集58方法－覆蓋率與缺陷查找覆蓋與發(fā)現(xiàn)缺陷之間沒有必然聯(lián)系獲得任何覆蓋目標(biāo)都不意味著沒有缺陷需求相關(guān)的缺陷丟失的代碼中斷相關(guān)的缺陷兼容性/配置相關(guān)的缺陷59方法－黑盒測試已知軟件產(chǎn)品應(yīng)該具有的功能，通過測試來檢測每個功能是否都能正常使用；黑盒法著眼于程序外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)；窮舉輸入/狀態(tài)測試，測試情況有無窮多個；依據(jù)需求規(guī)范；檢查程序?qū)崿F(xiàn)的功能，是一種確認(rèn)技術(shù)；也稱為功能測試或數(shù)據(jù)驅(qū)動測試。60方法－輸入/狀態(tài)空間

一些很普通的程序所包含的輸入輸出組合的數(shù)目都是非常驚人的，有些更是天文數(shù)字。

例：讀入三個數(shù)值，表示三角形的三條邊，程序輸出一條信息，說明該三角形是等邊三角形、等腰三角形、不等邊三角形。解：在限制坐標(biāo)點取值為1~10的整數(shù)的情況下，3條直線有104╳104╳104＝1012種可能的輸入，每秒測試1000條直線，需要1012/103＝109s，每年按3.1536╳107s計算，需要109/(3.1536╳107)=31.7年。注：考慮輸入域之外/實數(shù)/更大范圍61方法－黑盒測試的不徹底性不可能測試所有的輸入有效的輸入無效的輸入輸入的編輯特性輸入時間的考慮不可能測試多個輸入的所有組合StateSpaceExplosion62方法－黑盒測試的常用方法邊界值分析(boundaryanalysis)等價類劃分(equivalenceclasspartitioning)組合邏輯測試(combinationallogictesting)基于狀態(tài)轉(zhuǎn)換的測試(state-basedtesting)隨機(jī)測試(randomtesting)63方法－邊界值測試任何程序都可以看做是一個函數(shù)，程序的輸入構(gòu)成函數(shù)的定義域，程序的輸出構(gòu)成函數(shù)的值域?？苫诙x域或值域進(jìn)行邊界值測試；邊界值測試更適合于非強(qiáng)類型語言，如C；邊界區(qū)域是錯誤高發(fā)區(qū)；邊界值測試融入了一定程度的否定測試設(shè)計；邊界值測試通過邊界值分析獲得測試用例。64方法－邊界值分析abx1x2cd65方法－邊界值分析基本思想最小值、略高于最小值、正常值、略低于最大值、最大值假設(shè)單缺陷66方法－邊界值分析abx1x2cdn個變量有4n＋1個測試用例67方法－健壯性測試abx1x2cdn個變量有6n＋1個測試用例68方法－最壞情況測試abx1x2cdn個變量有5n個測試用例69方法－健壯最壞情況測試abx1x2cdn個變量有7n個測試用例70方法－特殊值測試使用最佳工程判斷，依賴測試人員的能力；具有高度主觀性，但是非常有效；例子:NextDate()的測試多種情況:1－28，1－29，1－30，1－31閏年71方法－邊界值分析局限性變量具有獨立性變量受物理量的約束對于復(fù)雜軟件完全使用邊界值分析可能不現(xiàn)實邊界值測試的用例集存在大量冗余和嚴(yán)重漏洞72方法－等價類劃分的含義選擇有限子集來“代表”所有可能的輸入全集；將被測軟件的輸入和輸出分成區(qū)許多區(qū)域，對于一個區(qū)中的任何值，軟件的行為是等價的；等價類劃分假設(shè)任何單一區(qū)內(nèi)的所有值具有相同的測試目的，因此，每個區(qū)測試一個值；等價類劃分屬于肯定類測試設(shè)計技術(shù)；等價類劃分受測試者主觀因素的影響。73方法－等價類劃分步驟劃分等價類考慮有效等價類和無效等價類確定測試用例給每個等價類一個唯一編號設(shè)計一個新的測試用例，使其覆蓋未被覆蓋的有效等價類，直到所有有效等價類都被覆蓋為止。設(shè)計一個新的測試用例，使其覆蓋未被覆蓋的無效等價類，直到所有無效等價類都被覆蓋為止。74方法－等價類劃分舉例例子：計算一個實數(shù)的平方根規(guī)格說明：輸入–實數(shù)輸出–實數(shù)當(dāng)輸入為0或更大的數(shù)值時,將返回輸入值的正數(shù)平方根當(dāng)輸入為小于0的數(shù)值時,將顯示錯誤信息“Squarerooterror-negativeinput”并返回0函數(shù)Print_Line將用于顯示錯誤信息75方法－等價類劃分例解四個等價類劃分:兩個輸入劃分:{<0},{>=0}輸出劃分:{>=0},{error}兩個測試用例:用例1:輸入4,返回2實現(xiàn)了>=0的輸入劃分實現(xiàn)了>=0的輸出劃分用例2:輸入-10,返回0,用Print_Line輸出"Squarerooterror-illegalnegativeinput"實現(xiàn)了<0的輸入劃分實現(xiàn)了"error“的輸出劃分76方法－可用等價類分析的變量輸入變量輸出變量內(nèi)部變量硬件與系統(tǒng)軟件配置設(shè)備狀態(tài)77方法－組合邏輯測試意義方法因果圖判定表邏輯函數(shù)78方法－基于狀態(tài)轉(zhuǎn)換的測試狀態(tài)轉(zhuǎn)換測試用于被設(shè)計成狀態(tài)機(jī)的軟件，或者被測軟件實現(xiàn)了模型化成狀態(tài)機(jī)的需求。通過建立導(dǎo)致轉(zhuǎn)換的事件的方法來設(shè)計測試用例，測試狀態(tài)之間的轉(zhuǎn)換。使用狀態(tài)和事件的非法組合來設(shè)計否定類的測試用例。79方法－隨機(jī)測試測試輸入數(shù)據(jù)是在所有可能輸入值中隨機(jī)選取。隨機(jī)選取用隨機(jī)模擬的方法，包括用偽隨機(jī)數(shù)發(fā)生器、硬件隨機(jī)模擬器產(chǎn)生輸入數(shù)據(jù)。在測試次數(shù)很大時，可在數(shù)據(jù)輸入空間按均勻分布選用。在測試次數(shù)較少時，最好在常用的輸入數(shù)據(jù)域以及最可能發(fā)生錯誤的輸入數(shù)據(jù)域選用。80方法－總結(jié)(1)從原理上講，功能(黑盒)測試能檢測出所有錯誤，但要花費無限的時間。結(jié)構(gòu)(白盒)測試基本上是有限的，但即使是全部執(zhí)行也不能測試出全部的錯誤。某種程度上講，測試的技巧就是在結(jié)構(gòu)(白盒)測試與功能(黑盒)測試之間如何進(jìn)行選擇。-----Beizer81方法－總結(jié)(2)不同測試用例設(shè)計方法具有不同的測試粒度；代碼覆蓋分析可幫助減少黑盒測試無法避免的盲點；測試應(yīng)首先考慮被測程序?qū)崿F(xiàn)需求的測試，然后進(jìn)行代碼覆蓋分析。82范例－相關(guān)概念范例：提供了某一領(lǐng)域的思考框架。測試設(shè)計(testdesign):通過使用一定的測試方法與策略產(chǎn)生一個測試用例包的過程。包括：測試點的識別、將測試點置入測試序列和為測試序列中的每個測試點定義預(yù)期輸出。測試包(testsuite):

一組相關(guān)的測試用例。它服務(wù)于被測實現(xiàn)的一個特殊版本或一個特定測試目標(biāo)。83范例－典型范例功能測試(Functiontesting)域測試(Domaintesting)基于規(guī)范的測試(Specification-basedtesting)基于風(fēng)險的測試(Risk-basedtesting)壓力測試(Stresstesting)探索性測試(Exploratorytesting)想定測試(Scenariotesting)隨機(jī)測試(StochasticorRandomtesting)84范例－功能測試特征基本目標(biāo):詳盡測試每一個功能,每次一個。能力:詳盡分析每個被測試項目典型案例:字處理程序,孤立測試每一個菜單項數(shù)據(jù)庫,孤立測試每份報表盲點:遺漏了交互作用85范例－功能測試方法使用擴(kuò)充式用例技術(shù)進(jìn)行測試設(shè)計利用覆蓋CRUD分析完善測試設(shè)計 CRUD－Create,Read,Update,Delete使用基于操作剖面方法在一個成熟的測試包中，破壞性測試與確認(rèn)性測試的比例大約為4:186范例－域測試特征基本目標(biāo):所面對的問題需要太多的測試用例。采取分層抽樣的策略，合理的從巨大的總量中選取較少的測試用例。能力:用相對小的測試集高概率的發(fā)現(xiàn)問題直觀清晰的方法,良好的歸納典型案例:簡單數(shù)值字段的等價類劃分打印機(jī)兼容性測試盲點:不在邊界值或明顯特別情況的缺陷實際的域經(jīng)常是未知的87范例－域測試方法一般方法:將一個字段的可能值的集化分成若干子集,挑選一些值代表每個子集。典型的值就是邊界，更為一般的情況,找到每個子集的“最佳代表”,并用這些有代表性的值運行測試。更進(jìn)一步方法:將幾個“最佳代表”組合進(jìn)行測試。一些方法還選擇最優(yōu)化的組合子集。88范例－基于規(guī)范的測試基本目標(biāo):檢查產(chǎn)品與需求文檔中每條規(guī)范的一致性能力:發(fā)現(xiàn)需求規(guī)范實現(xiàn)的遺漏和問題典型案例:可追溯矩陣,追蹤測試用例與每個規(guī)范項用戶文檔測試盲點:不在規(guī)范中的問題89范例－基于風(fēng)險的測試基本目標(biāo):根據(jù)你試圖管理的問題(或風(fēng)險)的類別定義和提練測試根據(jù)測試的區(qū)域或問題的相關(guān)風(fēng)險確定優(yōu)先次序典型案例:等價類分析基于使用頻度的測試壓力測試,錯誤處理測試,安全性測試,尋找預(yù)期或擔(dān)心的錯誤的測試從預(yù)測錯誤列表中抽樣失效模式和影響分析(FMEA)90范例－基于風(fēng)險的測試能力:最佳優(yōu)先次序(假設(shè)能正確識別風(fēng)險并確定優(yōu)先權(quán))高能力測試盲點:無法確定的風(fēng)險，更加象意外的風(fēng)險一些“風(fēng)險驅(qū)動”測試人員似乎比較主觀。如何知道覆蓋率水平?如何知道沒有遺漏關(guān)鍵內(nèi)容?91范例－壓力測試基本目標(biāo):通過極端情況下運行產(chǎn)品來了解軟件的能力和弱點，在極端環(huán)境下的失敗告訴我們在正常情況下應(yīng)該對軟件進(jìn)行什么修改。典型案例:緩沖區(qū)溢出缺陷大量數(shù)據(jù),超常事務(wù)鏈低內(nèi)存條件,驅(qū)動程序失效,病毒,其它危險92范例－壓力測試能力:暴露將會出現(xiàn)的弱點暴露安全風(fēng)險盲點:通過壓力測試無法使其更加可見的弱點93范例－探索性測試基本目標(biāo):測試人員得到的軟件沒有文檔或者很遲才會有文檔，測試人員必須一邊了解產(chǎn)品，一邊設(shè)計測試用例，以便運行測試尋找缺陷。典型案例:對整個產(chǎn)品進(jìn)行技巧性探索測試快速測試緊急情況測試第三方構(gòu)件發(fā)現(xiàn)問題/繼續(xù)探究缺陷94范例－探索性測試能力:關(guān)注客戶,關(guān)注風(fēng)險發(fā)揮每個測試人員的能力優(yōu)勢快速響應(yīng)環(huán)境的變化好管理,避免重復(fù)的分析和測試高的缺陷發(fā)現(xiàn)率盲點:遺漏的比知道的風(fēng)險更多受到每個測試人員弱點的局限這是技巧性工作,不是很適合新手95范例－想定測試基本目標(biāo):挑戰(zhàn)反映實際使用的用例典型案例:用商業(yè)規(guī)則、客戶數(shù)據(jù)、競爭者的結(jié)果來評價產(chǎn)品生命歷史測試使用用例描述產(chǎn)品能力和使用模型，按照使用用例擴(kuò)展測試用例96范例－想定測試能力:復(fù)雜,現(xiàn)實的事件，可以處理復(fù)雜的不易于模型化的情況暴露那些因超時產(chǎn)生的失效盲點:單個功能失效會降低這個方法的效率必須仔細(xì)考慮以便達(dá)到好的覆蓋97范例－想定測試?yán)硐氲南攵y試的特征:現(xiàn)實(來源于實際的客戶或競爭對手的情景)測試是失敗還是通過，很明確復(fù)雜,它使用了多個特征和功能98范例－隨機(jī)測試基本目標(biāo):利用計算機(jī)創(chuàng)建、執(zhí)行、評價大量的測試。單個測試達(dá)不到能力，能力有賴于大量的測試可以在大范圍內(nèi)抽樣,在超常的時間范圍內(nèi)測試,提供了發(fā)現(xiàn)長時間大量測試才能發(fā)現(xiàn)的缺陷的機(jī)會。能力:每次回歸不依賴于舊的測試部分預(yù)言可以在幼稚的代碼中快速、經(jīng)濟(jì)的發(fā)現(xiàn)缺陷可以發(fā)現(xiàn)長而復(fù)雜的操作鏈產(chǎn)生的問題，通過有計劃的測試發(fā)現(xiàn)這些問題很困難99范例－隨機(jī)測試典型案例:偽隨機(jī)隨機(jī)測試統(tǒng)計可靠性評估測試非模型化隨機(jī)測試模型化隨機(jī)測試基于其它屬性的隨機(jī)測試盲點:需要辨別通過與失敗的能力，太多的人認(rèn)為“不垮臺=不失敗”執(zhí)行的預(yù)期結(jié)果需要仔細(xì)管理測試人員化費很多時間分析代碼，很少時間用于分析客戶100范例－總結(jié)好測試用例的特征幾種黑盒測試模式101組織－系統(tǒng)組成支撐平臺軟件構(gòu)件模塊系統(tǒng)102組織－模塊與構(gòu)件模塊：軟件系統(tǒng)的基本組成單位由一個程序員完成在系統(tǒng)詳細(xì)規(guī)范中詳細(xì)說明其功能特性能被單獨地匯編和測試規(guī)模較小，邏輯較簡單構(gòu)件：一個構(gòu)件包括實現(xiàn)一個或多個產(chǎn)品功能所需的所有數(shù)據(jù)文件、庫、可重用模塊和工程化組件。一個構(gòu)件可與其它構(gòu)件進(jìn)行集成。103組織－軟件開發(fā)與測試過程104組織－V模型圖例：計劃修改需求可行性研究需求定義項目啟動需求規(guī)范化概要設(shè)計詳細(xì)設(shè)計編碼需求規(guī)范設(shè)計規(guī)范模塊規(guī)范代碼單元測試已測模塊集成集成軟件集成測試已測軟件已確認(rèn)軟件系統(tǒng)測試項目完成可操作軟件操作項目結(jié)束確認(rèn)測試需求描述評審評審走查讀代碼測試用例測試用例測試用例測試用例測試用例測試用例集成計劃構(gòu)件資料階段基線產(chǎn)品105組織－測試為什么要分階段？與軟件開發(fā)過程相適應(yīng)為了說明軟件系統(tǒng)內(nèi)組件/構(gòu)件的互操作性需要進(jìn)行三種基本的測試單獨組件/構(gòu)件的測試測試組件/構(gòu)件間互操作測試組件/構(gòu)件結(jié)合成的軟件系統(tǒng)106組織－單元測試特點單元測試關(guān)注程序的基本組成部分－模塊單元測試的依據(jù)－軟件設(shè)計規(guī)格說明若干個模塊可以并行測試由于單元測試的對象規(guī)模和復(fù)雜性較低，可利用以白盒為主的多種測試技術(shù)進(jìn)行比較充分細(xì)致的測試，發(fā)現(xiàn)錯誤后容易隔離和定位被測模塊測試用例結(jié)果測試工程師107組織－單元測試內(nèi)容被測模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立執(zhí)行路徑錯誤處理的路徑測試用例108組織－單元測試環(huán)境被測模塊驅(qū)動模塊結(jié)果測試用例模塊接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立執(zhí)行路徑錯誤處理的路徑樁1樁2樁n109組織－單元測試進(jìn)入條件要求的文檔可提交；符合規(guī)格要求的軟件單元源程序清單，并已無錯誤地通過編譯或匯編；被測試軟件單元已納入配置管理中；具備了規(guī)定的單元測試環(huán)境和測試工具。110組織－單元測試通過準(zhǔn)則命名符合規(guī)則；控制流程正確；變量存取無誤差；所有軟件單元達(dá)到質(zhì)量度量指標(biāo)；功能與設(shè)計說明一致；性能達(dá)到軟件設(shè)計指標(biāo)；覆蓋測試達(dá)到規(guī)定的覆蓋率；對發(fā)現(xiàn)的問題已進(jìn)行修改并通過回歸測試。111組織－集成的概念集成可在多個層次上進(jìn)行兩個組件集成的例子:Component#1OperationsandFunctionswithI/OinputinterfaceoperationComponent#2OperationsandFunctionswithI/Ooutputinterfaceoperation112組織－集成測試特征一組相互依賴的組件或模塊放在一起進(jìn)行測試，以確保其作為一個整體的質(zhì)量。集成測試是一個漸進(jìn)的過程

模塊構(gòu)件軟件配置項子系統(tǒng)軟件系統(tǒng)113組織－集成測試策略非漸增式集成(大爆炸集成)漸增式集成自頂向下集成深度優(yōu)先方法廣度優(yōu)先方法自底向上集成高頻集成114組織－大爆炸集成測試含義前提被測系統(tǒng)在通過系統(tǒng)范圍的測試后，只有少量構(gòu)件加入或修改。被測系統(tǒng)較小并具有良好可測試性，每個構(gòu)件都經(jīng)過充分測試。被測系統(tǒng)的構(gòu)件緊密連接，無法分別測試。測試未考慮構(gòu)件之間的相依性或風(fēng)險。115組織－自頂向下集成測試頂上的模塊借助樁進(jìn)行測試每次替換一個樁，可選用“深度優(yōu)先”或者“廣度優(yōu)先”方式。每當(dāng)新的模塊集成進(jìn)來，重新運行一些測試子集。ABCDEFG116組織－自頂向下集成測試步驟首先開發(fā)和測試在最高控制層的構(gòu)件，下層構(gòu)件用樁實現(xiàn)；繼續(xù)在每一層按寬度或深度優(yōu)先進(jìn)行，用真正的模塊代替樁，并建立下層樁；每一個模塊集成進(jìn)來的時候都要進(jìn)行測試；用回歸測試保證沒有引入新錯誤；以這種方式繼續(xù)直到所有被測系統(tǒng)中的樁已經(jīng)實現(xiàn)和測試。117組織－自頂向下集成測試模式ABEHCDFIGJLMK廣度優(yōu)先–ABCDEFGHIJKLM深度優(yōu)先–ABEHCFIDGJLMK118組織－自頂向下集成測試特性優(yōu)點：測試和集成可以較早開始；減少了驅(qū)動器開發(fā)費用。缺點：需要建立大量的樁；底層的需求變化會影響上層構(gòu)件。119組織－自底向上集成測試ABCDEFG以深度優(yōu)先次序每次替換一個驅(qū)動模塊可工作的模塊被聚合在一起，形成build并集成。簇120組織－自底向上集成測試步驟第一階段對底層模塊編碼，并使用驅(qū)動模塊對其測試；底層模塊組合成能夠?qū)崿F(xiàn)軟件特定子功能的簇，寫驅(qū)動模塊對簇進(jìn)行測試；移走驅(qū)動模塊，沿著程序結(jié)構(gòu)的層次向上對簇進(jìn)行組合，使用驅(qū)動模塊對其測試；以這種方式繼續(xù)集成直到整個系統(tǒng)使用真實的主控制模塊進(jìn)行測試。121組織－自底向上集成測試模式ABEHCDFIGJLMKBuild1–HEBBuild2–IFCDBuild3–LMJKG將build1,2和3與A集成。122組織－自底向上集成測試特性優(yōu)點:不需要樁；可并行測試。缺點:需要大量驅(qū)動器123組織－高頻集成測試特征適用于時間緊復(fù)雜度高的軟件自底向上/自頂向下的集成方式每日構(gòu)建與冒煙測試(DailyBuildandSmokeTesting)冒煙測試：冒煙測試從頭到尾檢測整個系統(tǒng)(當(dāng)前狀態(tài)下)。它不一定必須是窮舉的，但是應(yīng)該能夠暴露主要問題。冒煙測試應(yīng)該是足夠充分的，如果構(gòu)件通過了冒煙測試，就可以假定該構(gòu)件已經(jīng)足夠穩(wěn)定，可以繼續(xù)進(jìn)行更加徹底的測試。

－McConnel,S.124組