軟件測(cè)試第2章測(cè)試原理

1、本章內(nèi)容提要本章內(nèi)容提要 測(cè)試原則測(cè)試原則 軟件測(cè)試的分類軟件測(cè)試的分類 軟件測(cè)試流程軟件測(cè)試流程 軟件測(cè)試的過程模型軟件測(cè)試的過程模型2.12.1測(cè)試原則測(cè)試原則 兩種測(cè)試原則兩種測(cè)試原則從用戶的角度出發(fā)從用戶的角度出發(fā)希望通過軟件測(cè)試能希望通過軟件測(cè)試能充分暴露軟件中存在充分暴露軟件中存在的問題和缺陷的問題和缺陷從開發(fā)者的角度從開發(fā)者的角度出發(fā)出發(fā)希望測(cè)試能表明軟件產(chǎn)希望測(cè)試能表明軟件產(chǎn)品不存在錯(cuò)誤，已經(jīng)正品不存在錯(cuò)誤，已經(jīng)正確地實(shí)現(xiàn)了用戶的需求確地實(shí)現(xiàn)了用戶的需求1 1所有的測(cè)試都應(yīng)追溯到用戶需求所有的測(cè)試都應(yīng)追溯到用戶需求2 2應(yīng)當(dāng)把應(yīng)當(dāng)把“盡早測(cè)試和不斷地進(jìn)行軟件盡早測(cè)試和不斷地進(jìn)行

2、軟件測(cè)試測(cè)試”作為軟件測(cè)試者的座右銘作為軟件測(cè)試者的座右銘3 3paretopareto原則應(yīng)用于軟件測(cè)試原則應(yīng)用于軟件測(cè)試4 4測(cè)試應(yīng)從測(cè)試應(yīng)從“小規(guī)模小規(guī)?！遍_始，逐步轉(zhuǎn)向開始，逐步轉(zhuǎn)向“大規(guī)模大規(guī)?！? 5窮舉測(cè)試是不可能的窮舉測(cè)試是不可能的6 6為了達(dá)到最佳效果，應(yīng)該由獨(dú)立的第為了達(dá)到最佳效果，應(yīng)該由獨(dú)立的第三方來構(gòu)造測(cè)試三方來構(gòu)造測(cè)試7 7不充分的測(cè)試是不負(fù)責(zé)任的，過分的不充分的測(cè)試是不負(fù)責(zé)任的，過分的測(cè)試是一種資源的浪費(fèi)，同樣也是一種不測(cè)試是一種資源的浪費(fèi)，同樣也是一種不負(fù)責(zé)任的表現(xiàn)負(fù)責(zé)任的表現(xiàn)測(cè)測(cè)試試原原則則 軟件測(cè)試的目標(biāo)在于揭示缺陷和錯(cuò)軟件測(cè)試的目標(biāo)在于揭示缺陷和錯(cuò)誤。而最嚴(yán)

3、重的錯(cuò)誤（從用戶角度誤。而最嚴(yán)重的錯(cuò)誤（從用戶角度來看）是那些導(dǎo)致程序無法滿足需來看）是那些導(dǎo)致程序無法滿足需求的錯(cuò)誤，從而無法滿足用戶需求求的錯(cuò)誤，從而無法滿足用戶需求1 1所有的測(cè)試都應(yīng)追溯到用戶需求所有的測(cè)試都應(yīng)追溯到用戶需求不應(yīng)該將軟件測(cè)試看成是程序?qū)懲瓴粦?yīng)該將軟件測(cè)試看成是程序?qū)懲曛蟛砰_始的一項(xiàng)工作。問題發(fā)現(xiàn)之后才開始的一項(xiàng)工作。問題發(fā)現(xiàn)得越早，解決問題的代價(jià)越小，反得越早，解決問題的代價(jià)越小，反之，缺陷發(fā)現(xiàn)得越晚，缺陷修復(fù)的之，缺陷發(fā)現(xiàn)得越晚，缺陷修復(fù)的成本越高。若缺陷遺留到用戶手中，成本越高。若缺陷遺留到用戶手中，則將對(duì)公司、對(duì)用戶都有可能帶來則將對(duì)公司、對(duì)用戶都有可能帶來極其

4、嚴(yán)重的后果極其嚴(yán)重的后果。2.2.把把“盡早測(cè)試和不斷地進(jìn)行軟件測(cè)試盡早測(cè)試和不斷地進(jìn)行軟件測(cè)試”作為座右銘作為座右銘簡(jiǎn)單地講，簡(jiǎn)單地講，paretopareto原則暗示著測(cè)試發(fā)現(xiàn)的原則暗示著測(cè)試發(fā)現(xiàn)的錯(cuò)誤中的錯(cuò)誤中的80%80%很可能起源于程序模塊中的很可能起源于程序模塊中的20%20%，這就是缺陷群集現(xiàn)象。，這就是缺陷群集現(xiàn)象。3 3paretopareto原則應(yīng)用于軟件測(cè)試原則應(yīng)用于軟件測(cè)試 所謂小規(guī)模是指測(cè)試的粒度，或某所謂小規(guī)模是指測(cè)試的粒度，或某種程序的單元測(cè)試。進(jìn)一步的測(cè)試種程序的單元測(cè)試。進(jìn)一步的測(cè)試將從單個(gè)單元的測(cè)試逐步過渡到多將從單個(gè)單元的測(cè)試逐步過渡到多個(gè)單元的組合測(cè)試，

5、即集成測(cè)試，個(gè)單元的組合測(cè)試，即集成測(cè)試，最終過渡到系統(tǒng)測(cè)試最終過渡到系統(tǒng)測(cè)試。4 4測(cè)試應(yīng)從測(cè)試應(yīng)從“小規(guī)模小規(guī)模”開始逐步轉(zhuǎn)向開始逐步轉(zhuǎn)向“大規(guī)模大規(guī)?！保?）每個(gè)輸入條件的數(shù)據(jù)量太大，不同輸入條）每個(gè)輸入條件的數(shù)據(jù)量太大，不同輸入條件之間的組合情況太多件之間的組合情況太多（2）從輸出來看，輸出結(jié)果太多）從輸出來看，輸出結(jié)果太多（3）數(shù)據(jù)的處理方式是常規(guī)的方法，然而由于）數(shù)據(jù)的處理方式是常規(guī)的方法，然而由于要處理的數(shù)據(jù)量太大，每種數(shù)據(jù)類型所包含的要處理的數(shù)據(jù)量太大，每種數(shù)據(jù)類型所包含的有效和無效數(shù)據(jù)往往是無窮多的有效和無效數(shù)據(jù)往往是無窮多的（4）從計(jì)算來看，由于算法的復(fù)雜度越來越高，）從計(jì)

6、算來看，由于算法的復(fù)雜度越來越高，結(jié)合業(yè)務(wù)的復(fù)雜性，導(dǎo)致路徑組合近似天文數(shù)結(jié)合業(yè)務(wù)的復(fù)雜性，導(dǎo)致路徑組合近似天文數(shù)字，遍歷每條路徑的窮舉測(cè)試，即使對(duì)于一個(gè)字，遍歷每條路徑的窮舉測(cè)試，即使對(duì)于一個(gè)非常熟練的測(cè)試員而言，也是不可能的非常熟練的測(cè)試員而言，也是不可能的5 5窮舉測(cè)試是不可能的窮舉測(cè)試是不可能的測(cè)試出口條件參考標(biāo)準(zhǔn)測(cè)試出口條件參考標(biāo)準(zhǔn)遺留缺陷數(shù)量低于遺留缺陷數(shù)量低于1010個(gè)，其中嚴(yán)重個(gè)，其中嚴(yán)重的缺陷少于的缺陷少于5 5個(gè)個(gè)測(cè)試用例的執(zhí)行率為測(cè)試用例的執(zhí)行率為100%100%，通過率，通過率為為95%95%對(duì)于單元測(cè)試，關(guān)鍵模塊的語句覆對(duì)于單元測(cè)試，關(guān)鍵模塊的語句覆蓋率為蓋率為100

7、%100%，判定覆蓋率為，判定覆蓋率為85%85% 6 6為達(dá)到最佳效果，應(yīng)該由獨(dú)立的第三方來構(gòu)造測(cè)試為達(dá)到最佳效果，應(yīng)該由獨(dú)立的第三方來構(gòu)造測(cè)試?yán)砝?由由不愿否定自己的工作不愿否定自己的工作受到思維定勢(shì)的局限受到思維定勢(shì)的局限受進(jìn)度壓力的影響受進(jìn)度壓力的影響程序員對(duì)程序的功能和接口很熟悉，程序員對(duì)程序的功能和接口很熟悉，這與最終用戶的情況往往并不吻合，這與最終用戶的情況往往并不吻合，開發(fā)人員自己來測(cè)試程序難以具有典開發(fā)人員自己來測(cè)試程序難以具有典型性型性測(cè)試級(jí)別測(cè)試級(jí)別測(cè)測(cè) 試試 活活 動(dòng)動(dòng)測(cè)試類別測(cè)試類別測(cè)試測(cè)試的文的文檔檔基基礎(chǔ)礎(chǔ)測(cè)試責(zé)測(cè)試責(zé)任主體任主體測(cè)測(cè) 試試 重重 點(diǎn)點(diǎn)級(jí)別級(jí)別0

8、0結(jié)構(gòu)結(jié)構(gòu)化化檢查檢查靜態(tài)測(cè)試靜態(tài)測(cè)試各各類類文文檔檔檢查檢查小小組組各方面各方面級(jí)別級(jí)別1 1單單元元測(cè)試測(cè)試白盒白盒測(cè)試測(cè)試軟軟件件詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)文文檔檔開發(fā)開發(fā)人人員員軟軟件件單單元元設(shè)計(jì)設(shè)計(jì)級(jí)別級(jí)別2 2配置配置項(xiàng)項(xiàng)集成集成測(cè)試測(cè)試白盒白盒測(cè)試測(cè)試軟軟件件概概要要設(shè)計(jì)設(shè)計(jì)文文檔檔獨(dú)獨(dú)立立測(cè)試組測(cè)試組配置項(xiàng)設(shè)計(jì)配置項(xiàng)設(shè)計(jì)/ /構(gòu)構(gòu)架架級(jí)別級(jí)別3 3配置配置項(xiàng)資項(xiàng)資格格測(cè)試測(cè)試黑盒黑盒測(cè)試測(cè)試軟軟件需求件需求規(guī)規(guī)格格說說明明書書獨(dú)獨(dú)立立測(cè)試組測(cè)試組配置配置項(xiàng)項(xiàng)需求需求級(jí)別級(jí)別4 4集成集成測(cè)試測(cè)試白盒白盒測(cè)試測(cè)試系系統(tǒng)統(tǒng)的子系的子系統(tǒng)設(shè)計(jì)統(tǒng)設(shè)計(jì)文文檔檔獨(dú)獨(dú)立立測(cè)試組測(cè)試組系統(tǒng)設(shè)計(jì)系統(tǒng)設(shè)計(jì)

9、/ /構(gòu)架構(gòu)架級(jí)別級(jí)別5 5系系統(tǒng)測(cè)試統(tǒng)測(cè)試黑盒黑盒測(cè)試測(cè)試系系統(tǒng)規(guī)統(tǒng)規(guī)格格說說明明書書獨(dú)獨(dú)立立測(cè)試組測(cè)試組系系統(tǒng)統(tǒng)需求需求級(jí)別級(jí)別6 6dt&edt&e測(cè)試測(cè)試黑盒黑盒測(cè)試測(cè)試用用戶戶手手冊(cè)冊(cè)獨(dú)獨(dú)立立測(cè)試組測(cè)試組用用戶戶手手冊(cè)冊(cè)一致性一致性級(jí)別級(jí)別7 7ot&eot&e測(cè)試測(cè)試黑盒黑盒測(cè)試測(cè)試可操作性需求文可操作性需求文檔檔可操作性可操作性測(cè)試測(cè)試組組可操作性需求可操作性需求級(jí)別級(jí)別8 8外外場(chǎng)測(cè)試場(chǎng)測(cè)試黑盒黑盒測(cè)試測(cè)試交付交付計(jì)劃計(jì)劃（場(chǎng)場(chǎng)地配置）地配置） 外外場(chǎng)場(chǎng)安裝安裝組組場(chǎng)場(chǎng)地需求地需求7.7.不充分的測(cè)試是不負(fù)責(zé)的，過分的測(cè)試是一種資源的浪費(fèi)不充分的

10、測(cè)試是不負(fù)責(zé)的，過分的測(cè)試是一種資源的浪費(fèi)測(cè)試級(jí)別測(cè)試級(jí)別2.2 2.2 軟件測(cè)試的分類軟件測(cè)試的分類 2.2 2.2 軟件測(cè)試的分類軟件測(cè)試的分類 按測(cè)試階段分類按測(cè)試階段分類 按是否需要執(zhí)行被測(cè)試軟件分類按是否需要執(zhí)行被測(cè)試軟件分類 按是否需要查看代碼分類按是否需要查看代碼分類 按測(cè)試執(zhí)行時(shí)是否需要人工干預(yù)分類按測(cè)試執(zhí)行時(shí)是否需要人工干預(yù)分類 其他測(cè)試類型其他測(cè)試類型logo2.2.1 2.2.1 按測(cè)試階段分類按測(cè)試階段分類單元測(cè)試單元測(cè)試確認(rèn)測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試等驗(yàn)收測(cè)試等集成測(cè)試集成測(cè)試 定義定義 單元測(cè)試（unit testing）又稱模塊測(cè)試（module tes

11、ting），是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行測(cè)試，目的是檢查每個(gè)單元是否能夠正確實(shí)現(xiàn)詳細(xì)設(shè)計(jì)說明中的功能、性能、接口和設(shè)計(jì)約束等要求，發(fā)現(xiàn)各個(gè)模塊內(nèi)部可能存在的各種缺陷。 優(yōu)點(diǎn)優(yōu)點(diǎn) 減輕調(diào)試的難度 提供同時(shí)測(cè)試多個(gè)單元的可能 1. 1.單單元元測(cè)試測(cè)試 集成測(cè)試（integration testing）又稱組裝測(cè)試， 是在單元測(cè)試的基礎(chǔ)上，按照設(shè)計(jì)要求，將通過單元測(cè)試的單元組裝成系統(tǒng)或子系統(tǒng)而進(jìn)行的有序的測(cè)試，目的是檢驗(yàn)不同程序單元或部件之間的接口關(guān)系是否符合概要設(shè)計(jì)的要求，能否正常運(yùn)行。 確認(rèn)測(cè)試是通過檢驗(yàn)和提供客觀證據(jù)，證實(shí)軟件是否滿足特定預(yù)期用途的需求。確認(rèn)測(cè)試檢測(cè)與證實(shí)軟件是否滿足軟件

12、需求說明書中規(guī)定的要求。 2.2.集成集成測(cè)試測(cè)試 3.3.確確認(rèn)測(cè)試認(rèn)測(cè)試系統(tǒng)測(cè)試（system testing）是為了驗(yàn)證和確認(rèn)系統(tǒng) 是否達(dá)到其原始目標(biāo)，而對(duì)集成的硬件和軟件系統(tǒng)進(jìn)行的測(cè)試，是在真實(shí)或模擬系統(tǒng)運(yùn)行的環(huán)境下，檢查完整的程序系統(tǒng)是否能和系統(tǒng)正確配置、連接，并滿足用戶需求。系統(tǒng)測(cè)試主要由黑盒測(cè)試工程師在整個(gè)系統(tǒng)集成好之后進(jìn)行。前期主要看系統(tǒng)功能是否滿足需求，這被稱為功能測(cè)試。后期主要測(cè)試系統(tǒng)運(yùn)行是否滿足要求，以及系統(tǒng)在不同硬件和軟件環(huán)境中的兼容性等，這被分別稱為性能測(cè)試、兼容性測(cè)試、用戶界面測(cè)試等。 系統(tǒng)測(cè)試的主要依據(jù)是軟件的需求規(guī)格說明文檔。 4.4.系系統(tǒng)測(cè)試統(tǒng)測(cè)試 定義定義

13、 驗(yàn)收測(cè)試（acceptance testing）又稱接受測(cè)試，是一種正式的測(cè)試，是在系統(tǒng)測(cè)試后期，以用戶測(cè)試為主，是一般由用戶或其他權(quán)威機(jī)構(gòu)來決定是否可以接受產(chǎn)品的驗(yàn)證性測(cè)試。驗(yàn)收測(cè)試是軟件正式交付給用戶使用的最后一個(gè)測(cè)試環(huán)節(jié)，并決定用戶是否最終驗(yàn)收簽字和結(jié)清所有應(yīng)付款。 主要依據(jù)主要依據(jù) 軟件需求規(guī)格說明文檔和驗(yàn)收標(biāo)準(zhǔn)。 測(cè)試用例測(cè)試用例 可以直接采用內(nèi)部測(cè)試組所設(shè)計(jì)的系統(tǒng)測(cè)試用例的子集，也可由驗(yàn)收人員自行設(shè)計(jì)。 5.5.驗(yàn)驗(yàn)收收測(cè)試測(cè)試驗(yàn)驗(yàn)收收測(cè)測(cè)試試 測(cè)試測(cè)試測(cè)試也稱開發(fā)方測(cè)試測(cè)試也稱開發(fā)方測(cè)試，開發(fā)，開發(fā)方通過檢測(cè)和提供客觀證據(jù)，方通過檢測(cè)和提供客觀證據(jù)，證明軟件運(yùn)行是否滿足用戶規(guī)證

14、明軟件運(yùn)行是否滿足用戶規(guī)定的需求定的需求。 測(cè)試測(cè)試測(cè)試是內(nèi)部測(cè)試之后的外部測(cè)試是內(nèi)部測(cè)試之后的外部公開測(cè)試，是將軟件完全交給公開測(cè)試，是將軟件完全交給用戶，讓用戶在實(shí)際使用環(huán)境用戶，讓用戶在實(shí)際使用環(huán)境下進(jìn)行的對(duì)產(chǎn)品預(yù)發(fā)布版本的下進(jìn)行的對(duì)產(chǎn)品預(yù)發(fā)布版本的測(cè)試測(cè)試。測(cè)試的優(yōu)勢(shì)測(cè)試的優(yōu)勢(shì) 提升了產(chǎn)品價(jià)值。 可發(fā)現(xiàn)一些在測(cè)試實(shí)驗(yàn)室無法發(fā)現(xiàn)、甚至重復(fù)出現(xiàn)的缺陷。測(cè)試常常會(huì)發(fā)現(xiàn)產(chǎn)品的局限所在，并測(cè)試產(chǎn)品的整個(gè)開發(fā)過程。 可以將公司推到“基準(zhǔn)框架”之外。 有助于產(chǎn)品的成功發(fā)布。一、靜態(tài)測(cè)試一、靜態(tài)測(cè)試二、動(dòng)態(tài)測(cè)試二、動(dòng)態(tài)測(cè)試 一、靜態(tài)測(cè)試一、靜態(tài)測(cè)試定義定義 靜態(tài)測(cè)試（靜態(tài)測(cè)試（static testi

15、ng）又稱靜態(tài)分析（又稱靜態(tài)分析（static analysis），），是不實(shí)際運(yùn)行被測(cè)軟件，而是直接分是不實(shí)際運(yùn)行被測(cè)軟件，而是直接分析軟件的形式和結(jié)構(gòu)，查找缺陷。析軟件的形式和結(jié)構(gòu)，查找缺陷。靜態(tài)測(cè)試靜態(tài)測(cè)試（1 1）對(duì)于源代碼）對(duì)于源代碼 主要是看代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范，主要是看代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范，如可讀性、可維護(hù)性等，其工作過程類似一如可讀性、可維護(hù)性等，其工作過程類似一個(gè)編譯器，隨著語法分析的進(jìn)行做特定工作，個(gè)編譯器，隨著語法分析的進(jìn)行做特定工作，如分析模塊調(diào)用圖、程序的控制流圖等圖表，如分析模塊調(diào)用圖、程序的控制流圖等圖表，度量軟件的代碼質(zhì)量等。度量軟件的代碼質(zhì)量等

16、。（2 2）對(duì)于程序界面）對(duì)于程序界面（3 3）對(duì)于文檔）對(duì)于文檔 主要是檢查用戶手冊(cè)與需求說明是否真正符主要是檢查用戶手冊(cè)與需求說明是否真正符合用戶的實(shí)際要求合用戶的實(shí)際要求。1. 1. 靜態(tài)測(cè)試是采用走查、同行評(píng)審、會(huì)審等靜態(tài)測(cè)試是采用走查、同行評(píng)審、會(huì)審等方法來查找錯(cuò)誤或收集所需度量數(shù)據(jù)的方法來查找錯(cuò)誤或收集所需度量數(shù)據(jù)的。2. 2. 靜態(tài)分析的查錯(cuò)和分析功能是其他方法所靜態(tài)分析的查錯(cuò)和分析功能是其他方法所不能替代的，靜態(tài)分析能發(fā)現(xiàn)文檔中的問題不能替代的，靜態(tài)分析能發(fā)現(xiàn)文檔中的問題（也只能通過靜態(tài)測(cè)試發(fā)現(xiàn)），通過文檔中（也只能通過靜態(tài)測(cè)試發(fā)現(xiàn)），通過文檔中的問題或其他軟件評(píng)審發(fā)現(xiàn)來找出需

17、求分析、的問題或其他軟件評(píng)審發(fā)現(xiàn)來找出需求分析、軟件設(shè)計(jì)等問題，而且能有效地檢查代碼是軟件設(shè)計(jì)等問題，而且能有效地檢查代碼是否具有可讀性、可維護(hù)性，是否遵守編程規(guī)否具有可讀性、可維護(hù)性，是否遵守編程規(guī)范范。 1:char *report(int m,int n,char *p) 2: 3: int result; 4: char *temp,*q=null; 5: long nm; 6: int i,k,kk; 7: char name12=joe jakeson; 8: nm=n*m; 9: temp=p=?q:p;10: for(i=0;i0) result=1;17: else if(k

18、0) result=-1;18: if(m=result) return(temp);19: else return(name);20:pc-lintpc-lint編譯出現(xiàn)的警告：編譯出現(xiàn)的警告：第第9 9行的邏輯判定有問題行的邏輯判定有問題第第1212行的變量行的變量k k沒有初始化沒有初始化第第1313行的行的kkkk未被使用未被使用第第1818行的行的resultresult有可能沒有可能沒有被初始化有被初始化第第1919行返回的是一個(gè)局部行返回的是一個(gè)局部對(duì)象的地址對(duì)象的地址樹狀視圖樹狀視圖定位違反編碼規(guī)范的代碼定位違反編碼規(guī)范的代碼使用使用logiscope來檢查代碼的規(guī)范性：來檢查

19、代碼的規(guī)范性： 使用使用logiscope統(tǒng)計(jì)被測(cè)試程序的測(cè)試覆蓋率：統(tǒng)計(jì)被測(cè)試程序的測(cè)試覆蓋率： 用例覆蓋率情況用例覆蓋率情況使用使用logiscope統(tǒng)計(jì)被測(cè)試程序的測(cè)試覆蓋率：統(tǒng)計(jì)被測(cè)試程序的測(cè)試覆蓋率： 各函數(shù)覆蓋情況各函數(shù)覆蓋情況以流程圖形式顯示覆蓋情況以流程圖形式顯示覆蓋情況 使用使用logiscope查看某函數(shù)的覆蓋情況：查看某函數(shù)的覆蓋情況： 二、動(dòng)態(tài)測(cè)試二、動(dòng)態(tài)測(cè)試定義定義 動(dòng)態(tài)測(cè)試（動(dòng)態(tài)測(cè)試（dynamic testingdynamic testing）又稱動(dòng)態(tài)）又稱動(dòng)態(tài)分析（分析（dynamic analysisdynamic analysis），是指需要實(shí)際運(yùn)），是指需

20、要實(shí)際運(yùn)行被測(cè)軟件，通過觀察程序運(yùn)行時(shí)所表現(xiàn)出行被測(cè)軟件，通過觀察程序運(yùn)行時(shí)所表現(xiàn)出來的狀態(tài)、行為等發(fā)現(xiàn)軟件缺陷，包括在程來的狀態(tài)、行為等發(fā)現(xiàn)軟件缺陷，包括在程序運(yùn)行時(shí)，通過有效的測(cè)試用例來分析被測(cè)序運(yùn)行時(shí)，通過有效的測(cè)試用例來分析被測(cè)程序的運(yùn)行情況或進(jìn)行跟蹤對(duì)比，發(fā)現(xiàn)程序程序的運(yùn)行情況或進(jìn)行跟蹤對(duì)比，發(fā)現(xiàn)程序所表現(xiàn)的行為與設(shè)計(jì)規(guī)格或客戶需求不一致所表現(xiàn)的行為與設(shè)計(jì)規(guī)格或客戶需求不一致的地方。的地方。動(dòng)態(tài)測(cè)試的局限性動(dòng)態(tài)測(cè)試的局限性往往需要借助測(cè)試用例來完成往往需要借助測(cè)試用例來完成。即通過執(zhí)行測(cè)。即通過執(zhí)行測(cè)試用例、分析測(cè)試用例來對(duì)被測(cè)軟件重點(diǎn)考查，試用例、分析測(cè)試用例來對(duì)被測(cè)軟件重點(diǎn)考查，

21、以期發(fā)現(xiàn)缺陷。相比靜態(tài)測(cè)試，動(dòng)態(tài)測(cè)試增加以期發(fā)現(xiàn)缺陷。相比靜態(tài)測(cè)試，動(dòng)態(tài)測(cè)試增加了測(cè)試用例的設(shè)計(jì)、執(zhí)行和分析了測(cè)試用例的設(shè)計(jì)、執(zhí)行和分析，以及由測(cè)試，以及由測(cè)試用例所帶來的用例組織與管理等活動(dòng)用例所帶來的用例組織與管理等活動(dòng)。需要搭建軟件特定的運(yùn)行環(huán)境需要搭建軟件特定的運(yùn)行環(huán)境，增加了有關(guān)測(cè)，增加了有關(guān)測(cè)試環(huán)境的配置、維護(hù)和管理的工作量。試環(huán)境的配置、維護(hù)和管理的工作量。不能發(fā)現(xiàn)文檔問題不能發(fā)現(xiàn)文檔問題，必須等程序代碼完成后進(jìn)，必須等程序代碼完成后進(jìn)行，發(fā)現(xiàn)問題相對(duì)遲得多。行，發(fā)現(xiàn)問題相對(duì)遲得多。三靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試的比較三靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試的比較 測(cè)試方法測(cè)試方法比較項(xiàng)目比較項(xiàng)目靜態(tài)測(cè)試靜態(tài)

22、測(cè)試動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試是否需要運(yùn)行軟件否是是否需要測(cè)試用例否是是否可以直接定位缺陷是否測(cè)試實(shí)施難易程度容易困難靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試比較靜態(tài)測(cè)試與動(dòng)態(tài)測(cè)試比較（1 1）協(xié)同性）協(xié)同性靜態(tài)測(cè)試靜態(tài)測(cè)試是保守和健壯的，其測(cè)試結(jié)果離我們的期望是保守和健壯的，其測(cè)試結(jié)果離我們的期望值可能還有距離，但它保證了將來的執(zhí)行。值可能還有距離，但它保證了將來的執(zhí)行。動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試是有效和精確的，它不需要花費(fèi)大量的分析是有效和精確的，它不需要花費(fèi)大量的分析過程，盡管它確實(shí)需要測(cè)試用例的設(shè)計(jì)、執(zhí)行和結(jié)果過程，盡管它確實(shí)需要測(cè)試用例的設(shè)計(jì)、執(zhí)行和結(jié)果分析。動(dòng)態(tài)測(cè)試給出了高度精確的結(jié)果。分析。動(dòng)態(tài)測(cè)試給出了高度精確的結(jié)果。

23、 （2 2）獨(dú)立性）獨(dú)立性靜態(tài)測(cè)試靜態(tài)測(cè)試需要建立程序的狀態(tài)模型（如函數(shù)調(diào)用圖、需要建立程序的狀態(tài)模型（如函數(shù)調(diào)用圖、控制流圖等），在此基礎(chǔ)上確定程序?qū)υ摖顟B(tài)的反映控制流圖等），在此基礎(chǔ)上確定程序?qū)υ摖顟B(tài)的反映（如通過各種圖表分析，找出多入口多出口的模塊、（如通過各種圖表分析，找出多入口多出口的模塊、高層控制模塊等）。因系統(tǒng)可能執(zhí)行的狀態(tài)有很多，高層控制模塊等）。因系統(tǒng)可能執(zhí)行的狀態(tài)有很多，測(cè)試必須跟蹤多個(gè)不同的狀態(tài)，通常經(jīng)過大量細(xì)致的測(cè)試必須跟蹤多個(gè)不同的狀態(tài)，通常經(jīng)過大量細(xì)致的分析后也不一定能考慮到所有的系統(tǒng)狀態(tài)。因此，靜分析后也不一定能考慮到所有的系統(tǒng)狀態(tài)。因此，靜態(tài)分析通常采用程序狀態(tài)

24、的抽象模型，并需要較長(zhǎng)時(shí)態(tài)分析通常采用程序狀態(tài)的抽象模型，并需要較長(zhǎng)時(shí)間的等待。間的等待。動(dòng)態(tài)測(cè)試動(dòng)態(tài)測(cè)試過程中不存在近似和抽象的概念，它直接執(zhí)過程中不存在近似和抽象的概念，它直接執(zhí)行程序段，檢查實(shí)時(shí)的行為，在控制流程路徑中，幾行程序段，檢查實(shí)時(shí)的行為，在控制流程路徑中，幾乎不存在不確定因素。乎不存在不確定因素。 2.2.3 2.2.3 按是否需要查看代按是否需要查看代碼分類碼分類黑盒測(cè)試黑盒測(cè)試白盒測(cè)試白盒測(cè)試灰盒測(cè)試灰盒測(cè)試黑盒測(cè)試是將被測(cè)試軟件看做一個(gè)黑盒子，只考慮系統(tǒng)的輸入和輸出，完全不考慮程序內(nèi)部邏輯結(jié)構(gòu)和處理過程。黑盒測(cè)試的依據(jù)是各階段的規(guī)格說明書。黑盒測(cè)試又稱功能性測(cè)試（func

25、tional testing）或數(shù)據(jù)驅(qū)動(dòng)測(cè)試（data-driven testing）。黑黑盒盒測(cè)測(cè)試試黑盒測(cè)試黑盒測(cè)試優(yōu)點(diǎn)優(yōu)點(diǎn)局限性局限性黑盒測(cè)試用例與程序如何實(shí)現(xiàn)無關(guān)黑盒測(cè)試用例與程序如何實(shí)現(xiàn)無關(guān)測(cè)試用例的設(shè)計(jì)與程序的開發(fā)可以測(cè)試用例的設(shè)計(jì)與程序的開發(fā)可以并行進(jìn)行。并行進(jìn)行。輸入條件多、輸入條件多、組合復(fù)雜、數(shù)據(jù)量組合復(fù)雜、數(shù)據(jù)量大，大，不可能做到窮舉測(cè)試。不可能做到窮舉測(cè)試。因只選擇部分輸入構(gòu)成測(cè)試用例，因只選擇部分輸入構(gòu)成測(cè)試用例，黑盒測(cè)試是很有可能存在漏洞的。黑盒測(cè)試是很有可能存在漏洞的。白盒測(cè)試是將黑盒子打開，研究源代碼和程序內(nèi)部的邏輯結(jié)構(gòu)。白盒測(cè)試的依據(jù)是程序代碼。白盒測(cè)試又稱結(jié)

26、構(gòu)性測(cè)試（structural testing）或邏輯驅(qū)動(dòng)測(cè)試（logic-driven testing）。白白盒盒測(cè)測(cè)試試白盒測(cè)試白盒測(cè)試白盒測(cè)試可以利用不同的覆蓋準(zhǔn)則測(cè)試多個(gè)分支白盒測(cè)試的覆蓋指標(biāo)可以充當(dāng)黑盒測(cè)試的檢查手段。例如，若采用黑盒方法設(shè)計(jì)的測(cè)試用例沒有滿足某些白盒測(cè)試覆蓋指標(biāo)（如判定覆蓋）的要求，則證明該測(cè)試用例集合必然存在漏洞。代碼中常存在內(nèi)存泄露的問題，尤其是c/c+程序，白盒測(cè)試可以方便地發(fā)現(xiàn)內(nèi)存泄露的問題，且是直接定位缺陷，而黑盒測(cè)試只能通過長(zhǎng)時(shí)間運(yùn)行程序，并仔細(xì)地檢查用例執(zhí)行結(jié)果，才能發(fā)現(xiàn)這類問題。特特殊殊的的應(yīng)應(yīng)用用領(lǐng)領(lǐng)域域白盒測(cè)試白盒測(cè)試無法窮舉：程序中的邏輯路徑太

27、多， 常常要面對(duì)路徑爆炸的問題。例如， 有的代碼可能不到100行，卻具有520條可能的路徑，若每條路徑設(shè)計(jì)一個(gè)測(cè)試用例，且每個(gè)測(cè)試用例執(zhí)行一次需要1ms，則連續(xù)執(zhí)行所有的測(cè)試用例大約需要3170年。無法發(fā)現(xiàn)程序違反設(shè)計(jì)規(guī)范的地方，無法發(fā)現(xiàn)程序是否符合用戶需求。局局限限性性介于白盒測(cè)試和黑盒測(cè)試之間的測(cè)試。灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性；同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不像白盒測(cè)試那樣詳細(xì)、完整?；液袦y(cè)試結(jié)合了白盒測(cè)試和黑盒測(cè)試的要素。它考慮了用戶端、特定的系統(tǒng)知識(shí)和操作環(huán)境?；一液泻袦y(cè)測(cè)試試軟件測(cè)試方法和技術(shù)的分類與軟件開發(fā)過軟件測(cè)試方法和技術(shù)的分類與軟件開發(fā)過程相關(guān)聯(lián)，它貫穿了整個(gè)軟件生命周

28、期。走查、程相關(guān)聯(lián)，它貫穿了整個(gè)軟件生命周期。走查、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試應(yīng)用于整個(gè)開單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試應(yīng)用于整個(gè)開發(fā)過程中的不同階段。開發(fā)文檔和源程序可以發(fā)過程中的不同階段。開發(fā)文檔和源程序可以應(yīng)用單元測(cè)試應(yīng)用走查的方法；單元測(cè)試可應(yīng)應(yīng)用單元測(cè)試應(yīng)用走查的方法；單元測(cè)試可應(yīng)用白盒測(cè)試方法；集成測(cè)試應(yīng)用近似灰盒測(cè)試用白盒測(cè)試方法；集成測(cè)試應(yīng)用近似灰盒測(cè)試方法；而系統(tǒng)測(cè)試和確認(rèn)測(cè)試應(yīng)用黑盒測(cè)試方方法；而系統(tǒng)測(cè)試和確認(rèn)測(cè)試應(yīng)用黑盒測(cè)試方法。法。2.2.4 2.2.4 n手工測(cè)試手工測(cè)試n自動(dòng)測(cè)試自動(dòng)測(cè)試手手動(dòng)測(cè)試動(dòng)測(cè)試手動(dòng)測(cè)試是完全由人工完手動(dòng)測(cè)試是完全由人工完測(cè)試工作，包括測(cè)試計(jì)

29、劃測(cè)試工作，包括測(cè)試計(jì)劃的制定，測(cè)試用例的設(shè)計(jì)的制定，測(cè)試用例的設(shè)計(jì)和執(zhí)行，以及測(cè)試結(jié)果的和執(zhí)行，以及測(cè)試結(jié)果的檢查和分析等。傳統(tǒng)的測(cè)檢查和分析等。傳統(tǒng)的測(cè)試工作都是由人工來完成試工作都是由人工來完成的。的。自自動(dòng)測(cè)試動(dòng)測(cè)試自動(dòng)測(cè)試是使用自動(dòng)化測(cè)試自動(dòng)測(cè)試是使用自動(dòng)化測(cè)試工具或自動(dòng)化測(cè)試腳本來進(jìn)工具或自動(dòng)化測(cè)試腳本來進(jìn)行的測(cè)試，包括測(cè)試腳本的行的測(cè)試，包括測(cè)試腳本的開發(fā)與執(zhí)行等，以某種自動(dòng)開發(fā)與執(zhí)行等，以某種自動(dòng)測(cè)試工具來驗(yàn)證測(cè)試需求。測(cè)試工具來驗(yàn)證測(cè)試需求。這類測(cè)試在執(zhí)行過程中一般這類測(cè)試在執(zhí)行過程中一般不需要人干預(yù)，通常在功能不需要人干預(yù)，通常在功能測(cè)試、回歸測(cè)試和性能測(cè)試測(cè)試、回歸測(cè)試和

30、性能測(cè)試中使用較為廣泛。中使用較為廣泛。自動(dòng)測(cè)試自動(dòng)測(cè)試優(yōu)點(diǎn)優(yōu)點(diǎn) 能夠產(chǎn)生出可靠的系統(tǒng)能夠產(chǎn)生出可靠的系統(tǒng)改進(jìn)測(cè)試工作質(zhì)量改進(jìn)測(cè)試工作質(zhì)量減少測(cè)試工作并縮短進(jìn)度減少測(cè)試工作并縮短進(jìn)度2.2.5 其他測(cè)試類型冒煙測(cè)試冒煙測(cè)試隨機(jī)測(cè)試隨機(jī)測(cè)試 冒煙測(cè)試 定義定義在測(cè)試中發(fā)現(xiàn)問題，找到了一個(gè)缺陷，在測(cè)試中發(fā)現(xiàn)問題，找到了一個(gè)缺陷，然后開發(fā)人員會(huì)來修復(fù)這個(gè)缺陷。這時(shí)想知道這然后開發(fā)人員會(huì)來修復(fù)這個(gè)缺陷。這時(shí)想知道這次修復(fù)是否真的解決了程序的缺陷，或者是否會(huì)次修復(fù)是否真的解決了程序的缺陷，或者是否會(huì)對(duì)其他模塊造成影響，就需要針對(duì)此問題進(jìn)行專對(duì)其他模塊造成影響，就需要針對(duì)此問題進(jìn)行專門測(cè)試，這個(gè)過程就被稱

31、為冒煙測(cè)試。門測(cè)試，這個(gè)過程就被稱為冒煙測(cè)試。 優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間，防止創(chuàng)建失?。蝗秉c(diǎn)是覆優(yōu)點(diǎn)是節(jié)省測(cè)試時(shí)間，防止創(chuàng)建失?。蝗秉c(diǎn)是覆蓋率還是比較低。蓋率還是比較低。 冒煙測(cè)試是自由測(cè)試的一種。冒煙測(cè)試是自由測(cè)試的一種。 隨機(jī)測(cè)試 定義定義 根據(jù)測(cè)試說明書執(zhí)行樣例測(cè)試的重要補(bǔ)充根據(jù)測(cè)試說明書執(zhí)行樣例測(cè)試的重要補(bǔ)充手段，是保證測(cè)試覆蓋完整性的有效方式和過程手段，是保證測(cè)試覆蓋完整性的有效方式和過程 主要是對(duì)被測(cè)軟件的一些重要功能進(jìn)行復(fù)主要是對(duì)被測(cè)軟件的一些重要功能進(jìn)行復(fù)測(cè)，也包括測(cè)試那些當(dāng)前的測(cè)試樣例沒有覆蓋到測(cè)，也包括測(cè)試那些當(dāng)前的測(cè)試樣例沒有覆蓋到的部分。另外，對(duì)于軟件更新和新增加的功能要的部

32、分。另外，對(duì)于軟件更新和新增加的功能要重點(diǎn)測(cè)試。重點(diǎn)對(duì)一些特殊情況點(diǎn)、特殊的使用重點(diǎn)測(cè)試。重點(diǎn)對(duì)一些特殊情況點(diǎn)、特殊的使用環(huán)境、并發(fā)性進(jìn)行檢查。尤其對(duì)以前測(cè)試發(fā)現(xiàn)的環(huán)境、并發(fā)性進(jìn)行檢查。尤其對(duì)以前測(cè)試發(fā)現(xiàn)的重大缺陷，進(jìn)行再次測(cè)試，可以結(jié)合回歸測(cè)試一重大缺陷，進(jìn)行再次測(cè)試，可以結(jié)合回歸測(cè)試一起進(jìn)行。起進(jìn)行。2.3 軟件測(cè)試的流程軟件測(cè)試的流程按生命周期和工作活動(dòng)來分：需求評(píng)審設(shè)計(jì)評(píng)審單元測(cè)試集成測(cè)試功能測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試測(cè)試計(jì)劃測(cè)試設(shè)計(jì)測(cè)試腳本開發(fā)測(cè)試執(zhí)行測(cè)試結(jié)果分析和報(bào)告2.4 軟件測(cè)試的過程模型軟件測(cè)試的過程模型 2.4.2 w 模型模型 2.4.1 v 模型模型 2.4.4 x 模型模型

33、 2.4.3 h 模型模型四四種種模型模型2.4.1 v 2.4.1 v 模型模型 v模型是軟件開發(fā)傳統(tǒng)開發(fā)模型-瀑布模型的變種，它反映了測(cè)試活動(dòng)與分析和設(shè)計(jì)的關(guān)系，描述了基本的開發(fā)過程和測(cè)試行為，非常明確地標(biāo)明了測(cè)試過程中存在的不同級(jí)別，并且清楚地描述了這些測(cè)試階段和開發(fā)過程中各階段的對(duì)應(yīng)關(guān)系。 v模型2.4.1 v 2.4.1 v 模型模型2.4.1 v 2.4.1 v 模型模型 v模型指出，單元和集成測(cè)試應(yīng)檢測(cè)程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；系統(tǒng)測(cè)試應(yīng)當(dāng)驗(yàn)證系統(tǒng)設(shè)計(jì)，檢測(cè)系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)設(shè)計(jì)的指標(biāo)；由測(cè)試人員和用戶進(jìn)行軟件的確認(rèn)測(cè)試和驗(yàn)收測(cè)試，追溯軟件需求說明書進(jìn)行測(cè)試，以確定軟件的實(shí)現(xiàn)是否滿足用戶需求或合同的要求。2.4.1 v 2.4.1 v 模型模型v v模型的模型的軟軟件件測(cè)測(cè)試試策略策略低低層測(cè)試層測(cè)試: : 是為了源代碼的正確性高高層測(cè)試層測(cè)試: :是為了使整個(gè)系統(tǒng)滿足用戶的需求。2.4.1 v 2.4.1 v 模型模型 局限性：局限性：v模型僅僅把測(cè)試過程作為在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)及編碼之后的一個(gè)階段。容易使人理解為測(cè)試是軟件開發(fā)的最后的一個(gè)階段，主要是針對(duì)程序進(jìn)行測(cè)試尋找錯(cuò)誤，而需求