第9講 單元測試

1、ECJTU軟軟 件件 測測 試試 技技 術(shù)術(shù)bugs 第第8 8講講 單元測試單元測試軟件工程 呂敬欽創(chuàng)新大樓 西樓403-2-ECJTU軟件測試 軟件項目測試過程 測試需求分析 軟件測試實踐幾道小題 單元測試技術(shù)-3-ECJTU軟件測試 軟件項目測試工作是持續(xù)進(jìn)行的過程 JPGs9p4.png 課本P4 計劃測試依據(jù)軟件項目計劃，制定測試計劃哪些人，時間安排哪些測試工作使用什么測試方法需要什么資源遵循怎樣的規(guī)范-4-ECJTU軟件測試 設(shè)計測試多個階段的測試內(nèi)容分析功能需求 測試需求 設(shè)計測試用例測試設(shè)計說明書 實施測試為運行測試，開發(fā)腳本，測試驅(qū)動/測試樁。-5-ECJTU軟件測試 執(zhí)行測

2、試手動或運行測試腳本來執(zhí)行測試用例記錄發(fā)現(xiàn)的缺陷 JPGs9p4.png 評估測試每次執(zhí)行測試用例，實際結(jié)果與預(yù)期輸出通過 / 失敗 - 缺陷報告評估一段時間內(nèi)的測試工作-6-ECJTU軟件測試 軟件項目測試過程 測試需求分析 軟件測試實踐 單元測試技術(shù)-7-ECJTU測試需求分析 測試需求分析測試需求分析 用戶和他們的需求描述用戶對產(chǎn)品功能的使用要求，通常很籠統(tǒng)，例如，UR1能上網(wǎng)繳電話費能看最新的電視劇，視頻，下次能接著看，要清晰流暢，視覺效果好 系統(tǒng)需求分析員用戶 和 分析員。-8-ECJTU測試需求分析 系統(tǒng)需求100%覆蓋用戶需求描述軟件設(shè)計和編程人員所完成的工作內(nèi)容系統(tǒng)分析員分析用

3、戶需求，在技術(shù)層面上將其轉(zhuǎn)換成要開發(fā)的系統(tǒng)的一些功能點SR1 登錄繳費系統(tǒng)：要求加密傳輸，密碼不少于6位SR2 輸入電話號碼：要求驗證號碼的正確性SR3 查詢特定的電話費：查詢結(jié)果中要包含各類明細(xì)SR4 繳費：要求連接網(wǎng)上銀行頁面，根據(jù)具體網(wǎng)銀做不同的判斷；要明確繳費結(jié)果-9-ECJTU測試需求分析 測試需求100%覆蓋系統(tǒng)需求，描述測試人員的測試任務(wù)測試人員對照系統(tǒng)需求，面向各個功能點等，產(chǎn)生測試需求SR1 登錄繳費系統(tǒng)：要求加密傳輸，密碼不少于6位TR1-1 登錄成功：要求對合法用戶能成功登錄系統(tǒng)TR1-2 登錄失?。阂竽茏R別非法用戶，阻止其登錄系統(tǒng)，并給出錯誤提示。 設(shè)計測試用例100

4、%覆蓋測試需求根據(jù)測試需求，通過測試方法設(shè)計測試用例-10-ECJTU測試需求分析 4.2節(jié) 信息采集系統(tǒng)系統(tǒng)需求 3.1-3.9 P88照片導(dǎo)入 校驗、信息文件導(dǎo)入校驗，查看結(jié)果等測試需求等價劃分、邊界值/特殊值，實驗二的方法P94 表 4.9測試用例 表 4.10-11-ECJTU測試需求分析 靜態(tài)黑盒測試靜態(tài)黑盒測試檢查分析需求規(guī)格說明書等，認(rèn)真查找里面的缺陷。如信息采集系統(tǒng)的 需求規(guī)格說明書bug引入的階段：需求，設(shè)計，編碼，其他。其中需求文檔中有不明確、不清晰、不正確，很容易導(dǎo)致bug。-12-ECJTU測試需求分析 需求測試 (測試員周某) 電話本某模塊：內(nèi)置記憶卡，最多可以保存多

5、少條電話本記錄？(測試員阮某) 電話號碼除了數(shù)字外，是否允許字符，未明確？ 解決方案(處理人 王某) 補充需求：允許支持以下幾個字符：+, -, P, W，其他字符不支持主要形式：需求內(nèi)審，外審后期設(shè)計測試方案及測試用例中，也會發(fā)現(xiàn)需求中的問題-13-ECJTU測試需求分析MP4的日歷提醒事件丟失 某公司生產(chǎn)MP4，應(yīng)用軟件，日歷行程 測試員卓某測試時發(fā)現(xiàn)電力不足以開機，事件提醒，再次開機，無提示，這屬于特殊情況，需求中并未有明確定義 設(shè)計員不認(rèn)同，認(rèn)為如果一個月沒開機，事務(wù)又多，用戶未必愿意 成都某女士，取出MP4電池充電，忙了幾天。錯過了提前3天預(yù)訂機票的提醒。測試員要有質(zhì)疑精神獵人與鳥的

6、故事-14-ECJTU測試需求分析當(dāng)中的一些問題提取測試需求時，注意隱式需求： 用戶的隱式需求軟件系統(tǒng)應(yīng)遵守的規(guī)范或規(guī)則（但需求規(guī)格書SRS中未明確加以描述）例如，行業(yè)規(guī)范、業(yè)務(wù)規(guī)則、原有系統(tǒng)已實現(xiàn)的約定俗稱的操作或功能設(shè)計人員可能會為節(jié)省時間，而省略這類需求。一旦開發(fā)團(tuán)隊未考慮這些規(guī)范規(guī)則，必然導(dǎo)致缺陷。測試人員就是最后把關(guān)的關(guān)鍵了-15-ECJTU測試需求分析 計算機領(lǐng)域的規(guī)范或習(xí)慣用戶對于功能和性能的要求主要針對主業(yè)務(wù)，不包含具體的軟件系統(tǒng)的細(xì)節(jié)。例如，性別的輸入，一般建議采用下拉列表易用性方面：進(jìn)入系統(tǒng)界面，默認(rèn)輸入焦點位置應(yīng)該考慮用戶的使用習(xí)慣。這類需求，若都寫在SRS中，文檔編寫的

7、工作量太大，太細(xì)節(jié)。依靠程序員自己根據(jù)情況來確定。測試員要充分挖掘這類隱式需求，從操作步驟和輸入數(shù)據(jù)的角度，多考慮用戶可能的無效情況，確保測試覆蓋-16-ECJTU測試需求分析 用戶認(rèn)為開發(fā)方應(yīng)該理解的需求用戶是行業(yè)專家，但并不了解業(yè)務(wù)流程會對系統(tǒng)開發(fā)帶來的影響和要求。例如運行系統(tǒng)的硬件設(shè)備所處的實際使用環(huán)境，是否受到外部電磁干擾的情況；偏遠(yuǎn)山區(qū)的能否保證網(wǎng)絡(luò)實時通暢。在需求定義和分析過程中，若未充分挖掘用戶的需求，可能導(dǎo)致部分遺漏沒有寫到SRS中。-17-ECJTU測試需求分析 提問：測試需求 需求測試 二者的共同點和區(qū)別是什么？ 可測試性需求為了確保對測試任務(wù)的具體可行而提出的要求。對不同

8、的開發(fā)階段，有不同的可測試性需求。例如，為方便觀察軟件模塊的調(diào)試與測試，設(shè)計軟件模塊的調(diào)試測試觀察點和輸出機制。-18-ECJTU軟件測試 軟件項目測試過程 測試需求分析 軟件測試實踐 單元測試技術(shù)-19-ECJTU測試實踐軟件測試的實踐 完全測試程序很難輸入量太大，輸出結(jié)果太多，執(zhí)行路徑太多，軟件說明書比較主觀，從旁觀者來看是缺陷1+0=, 1+1=, 1+2=, , 1+999 (32個)=1.0+0.1=, 1.0+0.2=, 退格鍵和刪除鍵等按鍵的測試12+2=因此需要運用等價劃分、正交表、結(jié)合白盒代碼等方法來解決-20-ECJTU測試實踐 軟件測試是有風(fēng)險的行為對于復(fù)雜大型軟件，做不

9、到真正的完全測試，很可能會有測試遺漏。 1994年，Intel P CPU芯片就有一個缺陷(4195835/3145727)x3145727 4195835計算結(jié)果不是0，表示計算機的浮點除法存在缺陷！當(dāng)然，Intel 內(nèi)部測試時發(fā)現(xiàn)了這個缺陷。僅在進(jìn)行精度要求很高的數(shù)學(xué)、科學(xué)和工程計算中才導(dǎo)致錯誤。一般計算不會遇到此類問題。-21-ECJTU測試實踐 軟件測試是有風(fēng)險的行為測試員做不到完全全部的測試，而又會有測試遺漏，容易漏掉軟件缺陷。軟件要及時發(fā)布，測試工作終歸是有限的！關(guān)鍵思想：把數(shù)量巨大的可能測試減少到可以控制的范圍；以及如何針對風(fēng)險做出明智的選擇，哪些測試重要，哪些不重要！-22-E

10、CJTU測試實踐 軟件測試是有風(fēng)險的行為軟件要及時發(fā)布，測試終歸是有限量的！測試的目的：保證軟件符合用戶的需求，而非追求完美。隨著時間增長，發(fā)現(xiàn)的缺陷增多，主要嚴(yán)重缺陷會逐漸發(fā)現(xiàn)，得到修復(fù)。-23-ECJTU測試實踐時間繼續(xù)推移，所能發(fā)現(xiàn)的新缺陷越來越少， 發(fā)現(xiàn)新缺陷更加困難， 且基本是次要的缺陷。測不足，過度測都不大合理最優(yōu)測試量-24-ECJTU測試實踐 測試無法顯示潛伏的缺陷衛(wèi)生檢疫員 害蟲的跡象軟件測試工作，可以報告軟件存在缺陷，卻不能報告軟件不存在缺陷。 找到的軟件缺陷越多，就說明軟件缺陷多通常測試員在一段時間找不到缺陷。接著找到一個，然后接二連三。程序員的情緒；往往犯老問題老錯誤；

11、某些缺陷是冰山一角，由于軟件的設(shè)計或體系有問題，源自一個嚴(yán)重的主要原因。另一面，設(shè)計合理的軟件，內(nèi)在的缺陷數(shù)量少-25-ECJTU測試實踐 殺蟲劑怪事老用一種農(nóng)藥，害蟲最后就有抵抗力每種測試方法經(jīng)過幾個回合，能發(fā)現(xiàn)的缺陷都發(fā)現(xiàn)了需要新的測試，或測試程序新的部分。 并非所有軟件缺陷都要修復(fù)交付時間限期；不值得修復(fù)；修復(fù)風(fēng)險太大；不算真正的軟件缺陷（不常出現(xiàn)；不常用的功能）前面的 MP4 和 CPU 的缺陷最后不值得修復(fù)觀點做主-26-ECJTU軟件缺陷軟件缺陷的定義Ron Patton 1. 軟件測試員認(rèn)為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認(rèn)為不好需要站在用戶的立場需要站在用戶的

12、立場，根據(jù)用戶的業(yè)務(wù)流程來開發(fā)，確，根據(jù)用戶的業(yè)務(wù)流程來開發(fā)，確保軟件滿足用戶的需求。保軟件滿足用戶的需求。 2. 軟件未達(dá)到需求規(guī)格說明書中指明的功能基本業(yè)務(wù)功能和性能指標(biāo)基本業(yè)務(wù)功能和性能指標(biāo)是是用戶最關(guān)心的用戶最關(guān)心的方面方面 3. 軟件出現(xiàn)了需求規(guī)格說明書中指明不會出現(xiàn)的錯誤軟件的軟件的容錯性容錯性：SRS中所要求的，系統(tǒng)對無效輸入或無效中所要求的，系統(tǒng)對無效輸入或無效操作的合理處理和響應(yīng)操作的合理處理和響應(yīng)-27-ECJTU軟件缺陷 4. 軟件功能超出需求規(guī)格說明書中指明的范圍 ？完成的功能越多，引入缺陷的風(fēng)險越大。完成的功能越多，引入缺陷的風(fēng)險越大。開發(fā)人員可能會添加自認(rèn)為用戶需要

13、的功能；或者為了開發(fā)人員可能會添加自認(rèn)為用戶需要的功能；或者為了自己的調(diào)試方便而加入的功能，如快捷鍵、調(diào)試代碼等。自己的調(diào)試方便而加入的功能，如快捷鍵、調(diào)試代碼等。SRS中不包含這些，容易造成測試漏洞。中不包含這些，容易造成測試漏洞。 5. 軟件未達(dá)到需求規(guī)格說明書中雖未指出但應(yīng)達(dá)到的目標(biāo)有些目標(biāo)是有些目標(biāo)是SRS中未明確指出，實際上被測系統(tǒng)應(yīng)該達(dá)到中未明確指出，實際上被測系統(tǒng)應(yīng)該達(dá)到的。如軟件對外部使用環(huán)境的要求，對硬件故障情況的處理，的。如軟件對外部使用環(huán)境的要求，對硬件故障情況的處理，意外斷電等。意外斷電等。提取需求時要分析隱式需求-28-ECJTU單元測試 靜態(tài)白盒測試中，主要的方式有

14、_和_。其中，小組會使用_和_。 靜態(tài)白盒測試的測試對象有_1系統(tǒng)需求 2軟件設(shè)計 3體系結(jié)構(gòu) 4源代碼 A. 134 B. 124 C.234 D.1234代碼檢查，代碼走查；編碼錯誤列表，書面測試用例。-29-ECJTU軟件測試的目的是找出軟件的所有缺陷。 （ ）關(guān)于軟件測試，_的敘述是正確的。 測試開始越早，越有利于發(fā)現(xiàn)軟件缺陷 采用正確的測試用例設(shè)計方法，軟件測試可以做到窮舉測試 測試覆蓋度和測試用例數(shù)量成正比 軟件測試的時間越長越好 A B C、 D、X B-30-ECJTU 3、下面關(guān)于軟件測試的說法，_是錯誤的。 A軟件測試就是程序測試 B軟件測試貫穿于軟件定義和開發(fā)的整個期間C

15、需求規(guī)格說明、設(shè)計規(guī)格說明都是軟件測試的對象D程序是軟件測試的對象A-31-ECJTU 在沒有產(chǎn)品說明書和需求文檔的條件下可以進(jìn)行動態(tài)黑盒測試。 （ ） 靜態(tài)白盒測試可以找出遺漏之處和問題 （ ）V V-32-ECJTU軟件測試 軟件項目測試過程 測試需求分析 軟件測試實踐 單元測試技術(shù)-33-ECJTU單元測試 單元測試對軟件中的最小可測試單元進(jìn)行檢查測試和驗證。具有：明確的功能定義，性能定義，接口定義且可以與其他的單元區(qū)分開來 具體的單元1) C語言等面向過程的開發(fā)語言，函數(shù)或子過程如幾個函數(shù)有強耦合性，整體作為一個單元更大的單元：功能模塊或組件-34-ECJTU單元測試2) C+, Ja

16、va, C#等，單元指一個類然而，某些基礎(chǔ)類龐大，由數(shù)人共同開發(fā)；需類內(nèi)、類間測試（集成測試）面向?qū)ο筌浖y試 3) 圖形化軟件中，單元常指一個窗口或菜單。 單元編譯后能正確運行，即可展開單元測試單元測試要結(jié)合靜態(tài)檢查和動態(tài)測試綜合應(yīng)用各種黑盒測試（單元的功能）和白盒測試（單元的代碼）方法-35-ECJTU單元測試 單元測試被測單元有獨立性，能隔離測試，避免其他單元對它的影響。盡早盡早且有效地有效地發(fā)現(xiàn)單元內(nèi)的缺陷單元測試沒做好，之后的測試中會發(fā)現(xiàn)更多的，各種各樣的錯誤；大量的時間會花費在定位單元內(nèi)的簡單錯誤，且會遺漏不少缺陷-36-ECJTU單元測試 目標(biāo)確保單元完成其功能代碼在結(jié)構(gòu)上可靠且

17、健全在各種條件下給予正確地響應(yīng)一定的性能要求-37-ECJTU單元測試 具體測試內(nèi)容1) 語句和控制流的測試運算方面：誤解或用錯算符優(yōu)先級；混合類型計算；變量初始值錯誤；精度不夠；表達(dá)式符號錯誤 控制流：不同類型對象的比較；錯誤使用邏輯運算符；比較運算或變量出錯；循環(huán)變量，終止條件的錯誤；迭代發(fā)散，無法退出 -38-ECJTU單元測試 2) 局部數(shù)據(jù)結(jié)構(gòu)測試不合適或不相容的類型說明；變量初始值錯誤；上溢、下溢或地址異常 3) 單元接口測試數(shù)據(jù)能正確地輸入和輸出；形參和實參是否一致；是否修改了只讀形參還包括外部輸入輸出，如讀寫文件方面的各種錯誤。-39-ECJTU單元測試 4) 模塊邊界條件邊界

18、條件是單元測試中最重要的一項測試任務(wù)。忽略的邊界條件，在以后的測試中很難被發(fā)現(xiàn)；且發(fā)現(xiàn)后定位也不容易。 5) 錯誤處理單元應(yīng)具有良好的容錯性輸出信息是否好理解；是否有不當(dāng)?shù)漠惓Ｌ幚?6) 內(nèi)存分析內(nèi)存泄漏錯誤、內(nèi)存分配錯誤-40-ECJTU單元測試 驅(qū)動程序和樁程序為了隔離被測單元，以進(jìn)行測試，需要為每個被測單元的接口開發(fā)測試程序。Test() /驅(qū)動程序 TestbinSearch(array, key) /調(diào)用 is_sorted() 判斷是否排序Stub_ is_sorted(array) /樁程序is_sorted()尚未開發(fā)/測試驅(qū)動程序(Driver)：模擬被測單元的上級模塊，用于接受測試數(shù)據(jù)、啟動被測單元和輸出結(jié)果。樁程序(Stub)：模擬被測單元所調(diào)用的下層模塊（未開發(fā)好，或未經(jīng)單元測試）。-41-ECJTU單元測試 1應(yīng)盡量避免開發(fā)驅(qū)動模塊和樁模塊；簡單函數(shù)無需開發(fā)樁模塊-42-ECJTU單元測試 過程1) 計劃階段依據(jù)需求規(guī)格書、軟件詳細(xì)設(shè)計書，并參考測試計劃和集成方案測試的項目范圍；測試方法（是否靜態(tài)、黑盒方法、覆蓋指標(biāo)等）所需要的資源；任務(wù)分解表，進(jìn)度安排等2) 設(shè)計單元測試用例，驅(qū)動和樁模塊的代碼開發(fā)3) 執(zhí)行測