軟件測試軟件測試技術(shù).PPT

1、1軟件測試22.1 軟件測試技術(shù)概述2.2 軟件測試的分類與流程策略2.3 靜態(tài)測試與動態(tài)測試概述2.4 軟件測試的評審技術(shù)第二章第二章 測試方法概述與靜態(tài)分析測試方法概述與靜態(tài)分析32.1.1 軟件測試技術(shù)的分類2.1.2 軟件測試技術(shù)間的關(guān)系2.1.3 軟件測試技術(shù)的選擇2.1 2.1 軟件測試技術(shù)概述軟件測試技術(shù)概述4 從不同的角度，可以對軟件測試方法進(jìn)行分成不同種類。p 執(zhí)行代碼p 程序結(jié)構(gòu)p 開發(fā)過程p 功能性能 2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類5 1 1、從是否執(zhí)行代碼來分、從是否執(zhí)行代碼來分u 靜態(tài)測試：不實(shí)際運(yùn)行被測試軟件，只靜態(tài)地檢查程序代碼、界面或文

2、檔中可能存在的錯誤的過程。u 動態(tài)測試：實(shí)際運(yùn)行被測試程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程。2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類6 2 2、從是否需了解程序結(jié)構(gòu)來分。、從是否需了解程序結(jié)構(gòu)來分。 黑盒測試（Black-Box Testing）、 白盒測試（White-Box Testing）、灰盒測試。 黑盒測試：黑盒測試又稱為功能測試、數(shù)據(jù)驅(qū)動測試和基于規(guī)格說明的測試。是一種從用戶觀點(diǎn)出發(fā)的測試，主要以軟件規(guī)格說明書為依據(jù)，對程序功能和程序接口進(jìn)行的測試。 白盒測試：白盒測試（White-box Testing）也稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試，

3、是在知道產(chǎn)品的內(nèi)部工作過程，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行。2.1.1 2.1.1 軟件測試方法分類軟件測試方法分類7工程碩士7黑盒測試和白盒測試？X=2Y=4黑盒y=2xX=2Y=4白盒2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類8灰盒測試：灰盒測試介于白盒測試和黑盒測試之間，是現(xiàn)代測試的一種理念。就是指在白盒測試中交叉使用黑盒測試的方法；在黑盒測試中交叉使用白盒測試的方法。2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類9 3 3、從軟件測試策略或過程來分、從軟件測試策略或過程來分 單元測試(Unit Testing) 集成測試(Integr

4、ation Testing) 確認(rèn)測試(Validation Testing) 系統(tǒng)測試(System Testing) 驗(yàn)收測試(Verification Testing)。 2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類10單元測試對程序中最小可測試單元進(jìn)行檢查和驗(yàn)證。集成測試將通過測試的單元模塊組裝成系統(tǒng)或子系統(tǒng)，再進(jìn)行測試，重點(diǎn)測試不同模塊的接口部分。確認(rèn)測試：檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后 手段。系統(tǒng)測試集成測試完成之后，將整個(gè)系統(tǒng)看成整體進(jìn)行測試，包括功能、性能以及運(yùn)行的軟硬件環(huán)境。用戶驗(yàn)收測試系統(tǒng)測試的后期，以用戶測試為主，按照功能需求說明書以及用戶手

5、冊為標(biāo)準(zhǔn)測試整個(gè)系統(tǒng)，保證軟件達(dá)到可以交付使用的狀態(tài)。2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類11 4 4、從軟件測試的作用來分、從軟件測試的作用來分功能測試：檢查軟件的功能是否符合用戶的需求，包括：邏輯功能測試界面測試易用性測試安裝測試兼容性測試非功能測試：對系統(tǒng)功能之外的特性進(jìn)行測試，包括：性能測試安全測試強(qiáng)度測試容量測試。2.1.1 2.1.1 軟件測試技術(shù)分類軟件測試技術(shù)分類122.1.2 2.1.2 軟件測試軟件測試技術(shù)技術(shù)間的關(guān)系間的關(guān)系13工程碩士13不實(shí)際運(yùn)行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質(zhì)量的軟件測試技術(shù)。也稱為靜態(tài)分析技術(shù)。實(shí)際運(yùn)行程序，

6、并通過觀察程序運(yùn)行的實(shí)際結(jié)果來發(fā)現(xiàn)錯誤的軟件測試技術(shù)。在不知道程序內(nèi)部結(jié)構(gòu)，只知道程序規(guī)格的情況下采用的測試技術(shù)或策略。在知道程序內(nèi)部結(jié)構(gòu)的情況下采用的測試技術(shù)或策略。開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯誤的活動。開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。2.1.2 2.1.2 軟件測試軟件測試技術(shù)技術(shù)間的關(guān)系間的關(guān)系14工程碩士14針對要求的程

7、序功能，按照規(guī)范的流程進(jìn)行的測試。針對要求的程序功能以外的其他要求，包括性能、安全、配置、負(fù)載等指標(biāo)，按照規(guī)范的流程進(jìn)行的測試。針對要求的程序功能、性能、安全、配置、負(fù)載等指標(biāo)，基于破壞目的、按照經(jīng)驗(yàn)進(jìn)行的隨機(jī)測試。程序修改或者版本更新以后，為了確保以前正確的功能和其他指標(biāo)仍舊正確，而重新進(jìn)行的測試。在測試過程中，選擇足夠的測試用例，使得每一個(gè)可執(zhí)行語句至少被執(zhí)行一次。在測試過程中，選擇足夠的測試用例，使得程序中的每一個(gè)分支判斷的每一種可能結(jié)果都至少被執(zhí)行一次。在測試過程中，選擇足夠的測試用例，使得程序中的每一條可能執(zhí)行的路徑都至少執(zhí)行一次。15n 單元測試 測試方法：白盒測試 參考規(guī)范：詳細(xì)

8、設(shè)計(jì)說明和代碼結(jié)構(gòu)n 集成測試 測試方法：黑盒測試和白盒測試 參考規(guī)范：詳細(xì)設(shè)計(jì)說明和概要設(shè)計(jì)說明n 系統(tǒng)測試 測試方法：黑盒測試 參考規(guī)范：概要設(shè)計(jì)和需求規(guī)格說明n 可接受性測試 測試方法：黑盒測試 參考規(guī)范：需求規(guī)格說明n 回歸測試 測試方法：黑盒測試和白盒測試 參考規(guī)范：需求變更文檔和概要設(shè)計(jì)說明2.1.3 2.1.3 軟件測試軟件測試技術(shù)技術(shù)的選擇的選擇162.2.1 軟件測試的分類2.2.2 軟件測試的流程2.2.3 軟件測試的策略2.2 2.2 軟件測試的分類與流程策略軟件測試的分類與流程策略172.2.1 2.2.1 軟件測試的分類軟件測試的分類 從不同的角度，軟件測試有多種不同

9、的分類。p 測試范圍p 測試目的p 測試對象p 測試過程p 其它 18 1 1、按測試范圍來分、按測試范圍來分u 單元測試u 組件測試u 集成測試u 系統(tǒng)測試u 驗(yàn)收測試u 安裝測試2.2.1 2.2.1 軟件測試的分類軟件測試的分類19 2 2、按測試目的來分、按測試目的來分u 正確性測試 白盒測試 黑盒測試 u 性能測試u 可靠性測試 強(qiáng)壯性測試 異常處理測試 負(fù)載測試u 安全性測試2.2.1 2.2.1 軟件測試的分類軟件測試的分類20 3 3、按測試對象來分、按測試對象來分u 單元測試u 組件測試u 模塊測試u 程序測試u 系統(tǒng)測試u 文檔測試2.2.1 2.2.1 軟件測試的分類軟件

10、測試的分類21 4 4、按測試過程來分、按測試過程來分u 需求階段測試u 設(shè)計(jì)階段測試u 程序階段測試u 測試結(jié)果評估u 安裝測試u 測試變化：維護(hù)2.2.1 2.2.1 軟件測試的分類軟件測試的分類22 5 5、其它測試、其它測試（P38P38）u 回歸測試u 壓力測試u 恢復(fù)測試u 兼容性測試2.2.1 2.2.1 軟件測試的分類軟件測試的分類23 1 1、軟件測試的階段劃分、軟件測試的階段劃分 軟件測試是由一系列不同測試階段組成的，這些階段分為：規(guī)格說明書審查、系統(tǒng)和程序設(shè)計(jì)審查、單元測試、集成測試、功能測試、確認(rèn)測試、系統(tǒng)測試、驗(yàn)收測試和安裝測試。 （P39P39）規(guī)格說明書審查：系統(tǒng)

11、和程序設(shè)計(jì)審查：單元測試： 集成測試： 功能測試： 確認(rèn)測試系統(tǒng)測試： 驗(yàn)收測試 安裝測試2.2.2 2.2.2 軟件測試的流程軟件測試的流程24 2 2、從軟件測試流程、從軟件測試流程2.2.2 2.2.2 軟件測試的流程軟件測試的流程 從軟件開發(fā)來看252.2.2 2.2.2 軟件測試的流程軟件測試的流程 從軟件測試來看26 1 1、軟件測試策略的概念、軟件測試策略的概念 測試策略通常是描述測試工程的總體方法和目標(biāo)。描述目前在進(jìn)行哪一階段的測試（如單元測試、集成測試、系統(tǒng)測試）以及每個(gè)階段內(nèi)進(jìn)行的測試種類（如功能測試、性能測試、壓力測試等），以確定合理的測試方案使得測試更有效。2.2.3

12、2.2.3 軟件測試的策略軟件測試的策略27 2 2、軟件測試策略的原則、軟件測試策略的原則p 全面細(xì)致地了解產(chǎn)品的項(xiàng)目信息全面細(xì)致地了解產(chǎn)品的項(xiàng)目信息:應(yīng)用領(lǐng)域,測試范圍,市場需求,產(chǎn)品的特點(diǎn)和主要功能,技術(shù)架構(gòu)。p 全面細(xì)致地分析影響產(chǎn)品的因素：全面細(xì)致地分析影響產(chǎn)品的因素：基于模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個(gè)因素。p 客觀嚴(yán)格地執(zhí)行測試計(jì)劃：客觀嚴(yán)格地執(zhí)行測試計(jì)劃：p 制定出度量測試等級和測試重點(diǎn)的標(biāo)準(zhǔn)：制定出度量測試等級和測試重點(diǎn)的標(biāo)準(zhǔn)：一般是根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定。p 使用盡可能少的有效測試用例使用盡可能少的有效測試用例, ,發(fā)現(xiàn)盡

13、可能多的程序錯誤是策略制發(fā)現(xiàn)盡可能多的程序錯誤是策略制訂的目標(biāo)：訂的目標(biāo)：一次完整的軟件測試后,如果程序中遺漏的錯誤過多且很嚴(yán)重,則表明本次測試是失敗的或不足的;而測試不足意味著讓用戶承擔(dān)隱藏錯誤帶來的危險(xiǎn)。反過來,如果過度測試,又會浪費(fèi)許多寶貴的資源。找到一個(gè)最佳平衡點(diǎn)。2.2.3 2.2.3 軟件測試的策略軟件測試的策略28 3 3、軟件測試策略制訂的輸入輸出、軟件測試策略制訂的輸入輸出（P55P55） p 輸入輸入 p 輸出輸出2.2.3 2.2.3 軟件測試的策略軟件測試的策略292.3.1 靜態(tài)測試2.3.2 動態(tài)測試2.3.3 黑盒測試2.3.4 白盒測試2.3.5 黑盒與白盒測試

14、的比較2.3 2.3 靜態(tài)測試與動態(tài)測試概述靜態(tài)測試與動態(tài)測試概述靜態(tài)測試與動態(tài)測試的比喻30 1 1、靜態(tài)測試及其特征、靜態(tài)測試及其特征 靜態(tài)測試是對被測程序進(jìn)行特性分析的方法總稱，由于并不真正運(yùn)行被測試的程序，只對被測程序進(jìn)行特性分析，因此常稱為“靜態(tài)分析”。所謂靜態(tài)分析是指不需要執(zhí)行測試程序，只是通過掃描程序正文，對程序的數(shù)據(jù)流和控制流等信息進(jìn)行分析，找出系統(tǒng)的缺陷，得出測試報(bào)告。 靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，以發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具自動進(jìn)行。2.3.1 2.3.1 靜態(tài)測試靜態(tài)測試31 特別地，靜態(tài)分析的差錯分析功能是編譯程序

15、所不能替代的。編譯系統(tǒng)雖然能發(fā)現(xiàn)某些程序錯誤，但這些錯誤遠(yuǎn)非軟件中存在的大部分錯誤。目前，已經(jīng)開發(fā)了一些靜態(tài)分析系統(tǒng)作為軟件靜態(tài)測試的工具，靜態(tài)分析已被當(dāng)作一種自動化的代碼校驗(yàn)方法。2.3.1 2.3.1 靜態(tài)測試靜態(tài)測試32 2 2、靜態(tài)測試的活動、靜態(tài)測試的活動 檢查算法的邏輯正確性，確定算法是否實(shí)現(xiàn)了所要求的功能； 檢查模塊接口的正確性，確定形參的個(gè)數(shù)、數(shù)據(jù)類型、順序是否正確，確定返回值類型及返回值的正確性； 檢查輸入?yún)?shù)是否有合法性檢查。如果沒有合法性檢查，則應(yīng)確定該參數(shù)是否不需要合法性檢查，否則應(yīng)加上參數(shù)的合法性檢查； 2.3.1 2.3.1 靜態(tài)測試靜態(tài)測試33 檢查調(diào)用其他模塊的

16、接口是否正確，檢查實(shí)參類型、實(shí)參個(gè)數(shù)是否正確，返回值是否正確，若被調(diào)用模塊出現(xiàn)異常或錯誤，程序是否有適當(dāng)?shù)某鲥e處理代碼； 檢查是否設(shè)置了適當(dāng)?shù)某鲥e處理，以便在程序出錯時(shí)，能對出錯部分進(jìn)行重做安排，保證其邏輯的正確性； 檢查表達(dá)式、語句是否正確，是否含存在二義性。如表達(dá)式或運(yùn)算符的優(yōu)先級：=、&、|、+、-等； 檢查常量或全局變量使用是否正確； 檢查標(biāo)識符的使用是否規(guī)范、一致，變量命名是否能夠望名知義、簡潔、規(guī)范和易記；2.3.1 2.3.1 靜態(tài)測試靜態(tài)測試34 檢查程序風(fēng)格的一致性、規(guī)范性，代碼是否符合行業(yè)規(guī)范，是否所有模塊的代碼風(fēng)格一致、規(guī)范； 檢查代碼是否可以優(yōu)化，算法效率是否最高； 檢

17、查代碼注釋是否完整，是否正確反映了代碼的功能，并查找錯誤的注釋。2.3.1 2.3.1 靜態(tài)測試靜態(tài)測試35 不同的測試方法各自的目標(biāo)和側(cè)重點(diǎn)不一樣，在實(shí)際工作中要將靜態(tài)測試和動態(tài)測試結(jié)合起來，以達(dá)到更加完美的效果。 1 1、動態(tài)測試及其特征、動態(tài)測試及其特征 動態(tài)方法是通過源程序運(yùn)行時(shí)所體現(xiàn)出來的特征，來進(jìn)行執(zhí)行跟蹤、時(shí)間分析以及測試覆蓋等方面的測試。動態(tài)測試是真正運(yùn)行被測程序，在執(zhí)行過程中，通過輸入有效的測試用例，對其輸入與輸出的對應(yīng)關(guān)系進(jìn)行分析，以達(dá)到檢測的目的。2.3.2 2.3.2 動態(tài)測試動態(tài)測試36 2 2、動態(tài)測試的基本步驟、動態(tài)測試的基本步驟 選取定義域的有效值，或選取定義域

18、外的無效值； 對已選取值決定預(yù)期的結(jié)果； 用選取值執(zhí)行程序； 執(zhí)行結(jié)果與預(yù)期的結(jié)果相比，不吻合則說明程序有錯。 3 3、動態(tài)測試方法的類型、動態(tài)測試方法的類型 在動態(tài)測試中，又可有基于程序結(jié)構(gòu)的白盒測試（或稱為覆蓋測試）和基于功能的黑盒測試。 2.3.2 2.3.2 動態(tài)測試動態(tài)測試37 1 1、黑盒測試的定義、黑盒測試的定義 黑盒測試也稱作功能測試和行為測試，是指根據(jù)功能需求來測試程序是否按照預(yù)期工作。黑盒測試是一種從用戶觀點(diǎn)出發(fā)的測試，主要以軟件規(guī)格說明書為依據(jù)，對程序功能和程序接口進(jìn)行的測試。 黑盒測試把系統(tǒng)被看成一個(gè)不透明的黑匣，在完全不考慮軟件內(nèi)部結(jié)構(gòu)和處理過程的情況下驗(yàn)證系統(tǒng)是否達(dá)

19、到用戶需求。黑盒測試的示意圖如圖所示，從圖可以看出黑盒測試只考慮程序的輸入和輸出，無須考慮程序的內(nèi)部代碼。2.3.3 2.3.3 黑盒測試黑盒測試382.3.3 2.3.3 黑盒測試黑盒測試黑盒測試過程示意圖 39 黑盒測試有兩種基本思想，即通過測試和失敗測試。 在進(jìn)行通過測試時(shí)，實(shí)際上是確認(rèn)軟件能做什么，而不會去考驗(yàn)其能力如何，軟件測試人員只是運(yùn)用最簡單、最直觀的測試用例。在設(shè)計(jì)和執(zhí)行測試用例時(shí)，總是先要進(jìn)行通過測試，驗(yàn)證軟件的基本功能是否都已實(shí)現(xiàn)。 在確信了軟件正確運(yùn)行之后，就可以采取各種手段通過搞垮軟件來找出缺陷。純粹為了破壞軟件而設(shè)計(jì)和執(zhí)行的測試用例，被稱為失敗測試或迫使出錯測試。 2

20、.3.3 2.3.3 黑盒測試黑盒測試40 2 2、黑盒測試的基礎(chǔ)、黑盒測試的基礎(chǔ) 黑盒測試的基本觀點(diǎn)是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程，被測程序被認(rèn)為是一個(gè)打不開的黑盒子，黑盒中的內(nèi)容（實(shí)現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測試作為軟件功能的測試手段，是重要的測試方法。它主要根據(jù)規(guī)格說明設(shè)計(jì)測試用例，并不涉及程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性，只依靠被測程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計(jì)測試用例。2.3.3 2.3.3 黑盒測試黑盒測試41 3 3、黑盒測試的目的、黑盒測試的目的 如果外部特性本身有問題或規(guī)格說明書的規(guī)定有誤，黑盒測試方法顯然是發(fā)現(xiàn)不了的。黑盒測試方

21、法著重測試軟件的功能需求，是在程序接口上進(jìn)行測試，其目的主要是為了發(fā)現(xiàn)以下錯誤：u 是否有不正確的功能，是否有遺漏的功能；u 在接口上，是否能夠正確地接收輸入數(shù)據(jù)并產(chǎn)生正確的輸出結(jié)果；u 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息訪問錯誤；u 性能上是否能夠滿足要求；u 是否有程序初始化和終止方面的錯誤。2.3.3 2.3.3 黑盒測試黑盒測試42 4. 4. 黑盒測試的特點(diǎn)黑盒測試的特點(diǎn) 黑盒測試有兩個(gè)顯著的特點(diǎn)：u 黑盒測試不考慮軟件的具體實(shí)現(xiàn)過程，當(dāng)在軟件實(shí)現(xiàn)的過程發(fā)生變化時(shí)，測試用例仍然可以使用；黑盒測試用例的設(shè)計(jì)可以和軟件實(shí)現(xiàn)同時(shí)進(jìn)行，這樣能夠壓縮總的開發(fā)時(shí)間。u 黑盒測試不僅能夠找到大多數(shù)其他測

22、試方法無法發(fā)現(xiàn)的錯誤，而且一些外購軟件、參數(shù)化軟件包以及某些自動生成的軟件，由于無法得到源程序，只能選擇黑盒測試。2.3.3 2.3.3 黑盒測試黑盒測試43 1 1、白盒測試的定義、白盒測試的定義 白盒測試也稱作結(jié)構(gòu)測試或邏輯驅(qū)動測試，是一種基于程序內(nèi)部實(shí)現(xiàn)結(jié)構(gòu)和邏輯尋找缺陷的測試技術(shù)，它根據(jù)程序的控制結(jié)構(gòu)設(shè)計(jì)測試用例。 白盒測試（White-box Testing）是在知道產(chǎn)品內(nèi)部工作過程的情況下，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行。按照程序內(nèi)部的結(jié)構(gòu)檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作，而不顧它的功能。 白盒測試是一種可視的測試方法，即把測試對象看作一個(gè)

23、透明的盒子，測試人員要了解程序結(jié)構(gòu)和處理過程。白盒測試的過程如圖所示。2.3.4 2.3.4 白盒測試白盒測試44 源程序測試用例被測程序執(zhí)行路徑分析覆蓋情況分析白盒測試過程示意圖 2.3.4 2.3.4 白盒測試白盒測試45 2 2、白盒測試的必要性、白盒測試的必要性 邏輯錯誤和不正確假設(shè)與一條程序路徑被運(yùn)行的可能性成反比。 程序的邏輯流往往和直覺不一樣。 筆誤是隨機(jī)。 功能測試本身有局限。2.3.4 2.3.4 白盒測試白盒測試46 3 3、白盒測試的目的、白盒測試的目的 在對被測軟件進(jìn)行白盒測試時(shí)，主要對程序進(jìn)行以下幾個(gè)方面的檢查。u 保證一個(gè)模塊中的所有獨(dú)立執(zhí)行路徑至少測試一次；u 對

24、所有邏輯判定取值“true”和“false”的兩種情況都至少測試一次；u 在循環(huán)邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體；u 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性。2.3.4 2.3.4 白盒測試白盒測試47 4 4、白盒測試的應(yīng)用、白盒測試的應(yīng)用 在軟件測試領(lǐng)域，有六種基本的測試類型：單元測試，集成測試，功能測試/系統(tǒng)測試，可接受性測試，回歸測試和Beta測試。白盒測試可以用在其中的三種測試類型中： 單元測試 集成測試 回歸測試2.3.4 2.3.4 白盒測試白盒測試48 5、白盒測試與調(diào)試的不同點(diǎn)、白盒測試與調(diào)試的不同點(diǎn) 從承擔(dān)的任務(wù)來看，白盒測試同其他類型測試一樣，它的任務(wù)是發(fā)現(xiàn)所開發(fā)的項(xiàng)目中的缺陷；但調(diào)試不屬于

25、測試，其任務(wù)是糾正軟件中的缺陷。 從最終的結(jié)果來看，白盒測試有預(yù)知結(jié)果，不可預(yù)知的只是程序是否通過測試，且成功測試的結(jié)果是發(fā)現(xiàn)錯誤的癥狀，從而引起調(diào)試的進(jìn)行；而調(diào)試的結(jié)果是消除項(xiàng)目中的錯誤。 從執(zhí)行的過程來看，測試是一個(gè)發(fā)現(xiàn)錯誤、改正錯誤、重新測試的過程；而調(diào)試是一個(gè)推理過程。2.3.4 2.3.4 白盒測試白盒測試49 從準(zhǔn)備工作來看，測試從已知的條件開始，使用預(yù)先定義的程序；調(diào)試一般是以不可知的內(nèi)部條件開始，做統(tǒng)一性調(diào)試 。 從執(zhí)行的計(jì)劃性來看，測試是有計(jì)劃的并要進(jìn)行測試設(shè)計(jì)；而調(diào)試則不受時(shí)間約束。 從執(zhí)行的人員來看，測試經(jīng)常是由獨(dú)立的測試組在不了解軟件設(shè)計(jì)的條件下完成的，而調(diào)試必須由程序

26、員來完成。 從所使用的工具來看，大多數(shù)白盒測試的執(zhí)行和設(shè)計(jì)可有工具支持，而調(diào)試程序員能利用的工具主要是調(diào)試器。 2.3.4 2.3.4 白盒測試白盒測試50 1 1、白盒測試的優(yōu)缺點(diǎn)白盒測試的優(yōu)缺點(diǎn)u優(yōu)點(diǎn) 可構(gòu)成測試數(shù)據(jù)對特定程序部分測試，可以檢測代碼中的每條分支和路徑； 揭示隱藏在代碼中的錯誤； 對代碼的測試比較徹底； 有較多工具支持； 有一定的充分性度量手段。 2.3.5 2.3.5 黑盒與白盒測試的比黑盒與白盒測試的比較較51u缺點(diǎn) 工作量大, 成本高。通常只用于單元測試，有應(yīng)用局限； 無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤； 不能驗(yàn)證規(guī)格說明的正確性； 無法對規(guī)格說明中未實(shí)現(xiàn)的部分進(jìn)

27、行測試； 不易生成測試數(shù)據(jù)(通常)。2.3.5 2.3.5 黑盒與白盒測試的比黑盒與白盒測試的比較較52 2 2、黑盒測試的優(yōu)缺點(diǎn)黑盒測試的優(yōu)缺點(diǎn)u優(yōu)點(diǎn) 對于較大的代碼單元來說，效率高； 測試人員不需要了解實(shí)現(xiàn)的細(xì)節(jié)，包括具體的編程語言； 測試員和程序員可以由不同的人員來擔(dān)任； 從用戶的角度進(jìn)行測試，容易被理解和接受； 有助于暴露任何規(guī)格不一致或有歧義的問題； 測試用例的設(shè)計(jì)可以在規(guī)格說明完成之后馬上進(jìn)行； 容易入手生成測試數(shù)據(jù)； 適用于各階段測試。2.3.5 2.3.5 黑盒與白盒測試的比黑盒與白盒測試的比較較53u缺點(diǎn)實(shí)際上，只有一小部分可能的輸入被測試到，某些代碼得不到測試；如果沒有清晰

28、、簡潔的規(guī)格說明，難以設(shè)計(jì)測試用例；如果測試人員不知道開發(fā)人員已經(jīng)執(zhí)行過該測試用例，會存在不必要的重復(fù)測試；會有很多程序路徑?jīng)]有被測試到；不能直接針對可能隱蔽了許多問題的特定程序段進(jìn)行測試；如果規(guī)格說明有誤，則無法發(fā)現(xiàn)；不易進(jìn)行充分性測試。2.3.5 2.3.5 黑盒與白盒測試的比黑盒與白盒測試的比較較54 3 3、白盒測試和黑盒測試的比較白盒測試和黑盒測試的比較 白盒測試只關(guān)注軟件產(chǎn)品的測試，不能夠確保產(chǎn)品已經(jīng)實(shí)現(xiàn)了規(guī)格說明中的所有功能。黑盒測試則只關(guān)注規(guī)格說明中的測試，不能夠保證已經(jīng)實(shí)現(xiàn)的各個(gè)部分都被測試到。 與黑盒測試相比，白盒測試的成本要高一些。 黑盒測試是一種確認(rèn)技術(shù)，回答“我們在構(gòu)

29、造一個(gè)正確的系統(tǒng)嗎？白盒測試是一種驗(yàn)證技術(shù)，回答“我們在正確地構(gòu)造一個(gè)系統(tǒng)嗎？” 總之，建議測試人員在進(jìn)行測試的過程中，可以考慮先使用黑盒測試，然后統(tǒng)計(jì)相應(yīng)的覆蓋率，再設(shè)計(jì)適當(dāng)?shù)陌缀袦y試用例作為補(bǔ)充以保證測試的完整性。2.3.5 2.3.5 黑盒與白盒測試的比黑盒與白盒測試的比較較552.4.1 軟件評審及其評審點(diǎn)2.4.2 軟件評審的組織與流程2.4.3 測試和評審的比較2.4.4 軟件評審方法2.4.5 軟件評審2.4.6 其它軟件評審2.4.7 代碼走讀2.4 2.4 軟件測試的評審技術(shù)軟件測試的評審技術(shù)56工程碩士562.4.1 2.4.1 軟件評審及其評審點(diǎn)軟件評審及其評審點(diǎn) 1 1

30、、什么是軟件評審什么是軟件評審 軟件評審是指在軟件開發(fā)過程中，由參與軟件評審是指在軟件開發(fā)過程中，由參與評審的人員對軟件開發(fā)文檔或代碼進(jìn)行審定或評審的人員對軟件開發(fā)文檔或代碼進(jìn)行審定或檢查，幫助查找缺陷和改進(jìn)。其工作內(nèi)容有：檢查，幫助查找缺陷和改進(jìn)。其工作內(nèi)容有：檢驗(yàn)產(chǎn)品是否滿足規(guī)范，如需求或設(shè)計(jì)文檔；檢驗(yàn)產(chǎn)品是否滿足規(guī)范，如需求或設(shè)計(jì)文檔；識別產(chǎn)品相對于標(biāo)準(zhǔn)的偏差；識別產(chǎn)品相對于標(biāo)準(zhǔn)的偏差；向作者提出改進(jìn)建議；向作者提出改進(jìn)建議；促進(jìn)技術(shù)交流和學(xué)習(xí)。促進(jìn)技術(shù)交流和學(xué)習(xí)。57工程碩士572.4.1 2.4.1 軟件評審及其評審點(diǎn)軟件評審及其評審點(diǎn) 2. 2. 軟件評審原則軟件評審原則對事不對人

31、，評審不是對責(zé)任人績效的評價(jià)對事不對人，評審不是對責(zé)任人績效的評價(jià)責(zé)任人保持開發(fā)思想，接受別人意見，避免爭論責(zé)任人保持開發(fā)思想，接受別人意見，避免爭論評審組規(guī)模保持評審組規(guī)模保持3-73-7人人評審期間要努力發(fā)現(xiàn)問題，但不要試圖去解決問評審期間要努力發(fā)現(xiàn)問題，但不要試圖去解決問題題會議限制在兩個(gè)小時(shí)之內(nèi)會議限制在兩個(gè)小時(shí)之內(nèi)正式評審需要事先準(zhǔn)備正式評審需要事先準(zhǔn)備58工程碩士58需求規(guī)格說明書需求規(guī)格說明書評審評審概要設(shè)計(jì)說明書概要設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)說明書編碼編碼單元測試單元測試集成測試集成測試系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試文檔系統(tǒng)測試文檔用戶資料和培訓(xùn)文檔用戶資料和培訓(xùn)文檔可交付產(chǎn)品

32、可交付產(chǎn)品集成測試文檔集成測試文檔單元測試文檔單元測試文檔評審評審評審評審評審評審評審評審評審評審評審評審 3 3、軟件項(xiàng)目中的評審點(diǎn)軟件項(xiàng)目中的評審點(diǎn)2.4.1 2.4.1 軟件評審及其評審點(diǎn)軟件評審及其評審點(diǎn)5959 1. 1. 軟件評審的角色（實(shí)例）軟件評審的角色（實(shí)例）責(zé)任人：是準(zhǔn)備要評審的信息或工作產(chǎn)品的人。責(zé)任人：是準(zhǔn)備要評審的信息或工作產(chǎn)品的人。 主審人：是評審組長，評審會議主持人，帶領(lǐng)評審團(tuán)隊(duì)工作主審人：是評審組長，評審會議主持人，帶領(lǐng)評審團(tuán)隊(duì)工作保證評審達(dá)到預(yù)期的目的。保證評審達(dá)到預(yù)期的目的。講解員：負(fù)責(zé)在評審會議期間對被審的工作產(chǎn)品部分進(jìn)行釋講解員：負(fù)責(zé)在評審會議期間對被審

33、的工作產(chǎn)品部分進(jìn)行釋義，使評審組可側(cè)重于重要信息，將注意力由責(zé)任人轉(zhuǎn)向產(chǎn)義，使評審組可側(cè)重于重要信息，將注意力由責(zé)任人轉(zhuǎn)向產(chǎn)品。品。 記錄員：記錄下評審會議過程中的相關(guān)信息，如對預(yù)審問題記錄員：記錄下評審會議過程中的相關(guān)信息，如對預(yù)審問題的確認(rèn)，新出現(xiàn)的問題等。的確認(rèn)，新出現(xiàn)的問題等。 評審專家：了解評審對象，是尋找評審對象與所依照的文檔、評審專家：了解評審對象，是尋找評審對象與所依照的文檔、標(biāo)準(zhǔn)之間存在的差異。標(biāo)準(zhǔn)之間存在的差異。 2.4.2 2.4.2 軟件評審的組織與流程軟件評審的組織與流程60工程碩士60制定計(jì)劃制定計(jì)劃責(zé)責(zé) 任任 人人主主 審審 人人預(yù)備會議預(yù)備會議*所有評審專家所有

34、評審專家其他出席者其他出席者準(zhǔn)準(zhǔn) 備備責(zé)責(zé) 任任 人人主主 審審 人人講講 解解 員員記記 錄錄 員員評審專家評審專家評審會議評審會議責(zé)責(zé) 任任 人人主主 審審 人人講講 解解 員員記記 錄錄 員員評審專家評審專家跟跟 蹤蹤責(zé)責(zé) 任任 人人主主 審審 人人評審專家評審專家第三次會議第三次會議*責(zé)責(zé) 任任 人人主主 審審 人人講講 解解 員員記記 錄錄 員員評審專家評審專家可評審對象可評審對象會議安排（人員，地點(diǎn)，時(shí)間等）會議安排（人員，地點(diǎn)，時(shí)間等）可交付產(chǎn)品可交付產(chǎn)品評審總結(jié)報(bào)告評審總結(jié)報(bào)告評審問題列表評審問題列表評審問題列表評審問題列表預(yù)審問題列表預(yù)審問題列表相關(guān)質(zhì)量標(biāo)準(zhǔn)相關(guān)質(zhì)量標(biāo)準(zhǔn)2.

35、2. 軟件評審的流程軟件評審的流程 2.4.2 2.4.2 軟件評審的組織與流程軟件評審的組織與流程61工程碩士612.4.3 2.4.3 測試和評審的比較測試和評審的比較表現(xiàn)形式表現(xiàn)形式測試：單元測試、集成測試、確認(rèn)測試、測試：單元測試、集成測試、確認(rèn)測試、系統(tǒng)測試、驗(yàn)收測試系統(tǒng)測試、驗(yàn)收測試評審：審查、小組評審、走查、結(jié)對編程、評審：審查、小組評審、走查、結(jié)對編程、同級桌查、輪查、臨時(shí)評審?fù)壸啦?、輪查、臨時(shí)評審 62工程碩士622.4.3 2.4.3 測試和評審的比較測試和評審的比較工作對象工作對象測試：編譯后可運(yùn)行的程序測試：編譯后可運(yùn)行的程序評審：需求規(guī)格說明書、架構(gòu)（概要）設(shè)評審：

36、需求規(guī)格說明書、架構(gòu)（概要）設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、項(xiàng)目計(jì)劃、項(xiàng)目計(jì)文檔、詳細(xì)設(shè)計(jì)文檔、項(xiàng)目計(jì)劃、項(xiàng)目過程文檔、源代碼、系統(tǒng)界面、測試計(jì)劃、過程文檔、源代碼、系統(tǒng)界面、測試計(jì)劃、測試用例和數(shù)據(jù)、用戶手冊測試用例和數(shù)據(jù)、用戶手冊 63工程碩士632.4.3 2.4.3 測試和評審的比較測試和評審的比較識別缺陷的階段識別缺陷的階段 測試：編碼完成后測試：編碼完成后 評審：需求階段、設(shè)計(jì)階段、編碼階段、評審：需求階段、設(shè)計(jì)階段、編碼階段、測試階段測試階段 64工程碩士64識別缺陷的成效識別缺陷的成效 測試：最多識別軟件所有缺陷中的測試：最多識別軟件所有缺陷中的30-35%30-35%評審：最多識別軟

37、件所有缺陷中的評審：最多識別軟件所有缺陷中的70-75%70-75%2.4.3 2.4.3 測試和評審的比較測試和評審的比較65工程碩士65識別缺陷的成本識別缺陷的成本 測試：識別一個(gè)重要缺陷平均花費(fèi)測試：識別一個(gè)重要缺陷平均花費(fèi)15-2515-25小時(shí)小時(shí) 評審：識別一個(gè)重要缺陷平均花費(fèi)評審：識別一個(gè)重要缺陷平均花費(fèi) 需求階段需求階段2-32-3小時(shí)；小時(shí)； 設(shè)計(jì)階段設(shè)計(jì)階段3-43-4小時(shí)；小時(shí)； 代碼階段代碼階段3-53-5小時(shí)；小時(shí)； 測試計(jì)劃測試計(jì)劃3-53-5小時(shí)。小時(shí)。 2.4.3 2.4.3 測試和評審的比較測試和評審的比較66工程碩士66解決缺陷的成本解決缺陷的成本 測試：消

38、除一個(gè)重要缺陷平均花費(fèi)測試：消除一個(gè)重要缺陷平均花費(fèi)30-8030-80小小 時(shí)（含識別缺陷時(shí)間）。開發(fā)后期識別缺時(shí)（含識別缺陷時(shí)間）。開發(fā)后期識別缺陷，成本較高陷，成本較高 評審：需求及設(shè)計(jì)階段消除一個(gè)重要缺陷評審：需求及設(shè)計(jì)階段消除一個(gè)重要缺陷花費(fèi)花費(fèi)5-105-10小時(shí)；代碼評審階段消除一個(gè)重小時(shí)；代碼評審階段消除一個(gè)重要缺陷花費(fèi)要缺陷花費(fèi)5-155-15小時(shí)。傾向于在開發(fā)前期小時(shí)。傾向于在開發(fā)前期識別缺陷，成本較低識別缺陷，成本較低 2.4.3 2.4.3 測試和評審的比較測試和評審的比較67工程碩士672.4.4 2.4.4 軟件評審方法軟件評審方法 1 1、軟件評審方法的類型軟件評

39、審方法的類型審查（審查（InspectionInspection）團(tuán)隊(duì)團(tuán)隊(duì)/ /技術(shù)評審（技術(shù)評審（Team Review/Technical Team Review/Technical ReviewReview）走查（走查（WalkThroughWalkThrough）結(jié)對編程（結(jié)對編程（Pair ProgrammingPair Programming）同級桌查（同級桌查（Peer DeskCheckPeer DeskCheck）臨時(shí)輪查（臨時(shí)輪查（Ad hoc ReviewAd hoc Review68工程碩士68Team Review/Technical Review Team Revi

40、ew/Technical Review WalkThrough WalkThrough Pair Programming Pair Programming Peer DeskCheckPeer DeskCheckAd hoc ReviewAd hoc ReviewInspectionInspection最正式最正式最不正式最不正式2.4.4 2.4.4 軟件評審方法軟件評審方法1 1、軟件評審方法的類型軟件評審方法的類型69工程碩士692 2、軟件評審的活動、軟件評審的活動2.4.4 2.4.4 軟件評審方法軟件評審方法70工程碩士703 3、軟件評審方法的選擇、軟件評審方法的選擇 選擇的原則

41、是工作成果產(chǎn)生風(fēng)險(xiǎn)的可能性越大，采用的評選擇的原則是工作成果產(chǎn)生風(fēng)險(xiǎn)的可能性越大，采用的評審方法越正式。審方法越正式。 對于需求規(guī)格說明書，因?yàn)樗牟粶?zhǔn)確和不完善會給對于需求規(guī)格說明書，因?yàn)樗牟粶?zhǔn)確和不完善會給軟件的后期開發(fā)帶來極大的風(fēng)險(xiǎn)，所以必須要采用最正式軟件的后期開發(fā)帶來極大的風(fēng)險(xiǎn)，所以必須要采用最正式的評審方法，比如審查或者技術(shù)評審；的評審方法，比如審查或者技術(shù)評審； 核心代碼的失效也會帶來很嚴(yán)重的后果，所以也應(yīng)該核心代碼的失效也會帶來很嚴(yán)重的后果，所以也應(yīng)該采用審查或者技術(shù)評審的方法進(jìn)行評審；采用審查或者技術(shù)評審的方法進(jìn)行評審； 一般的代碼，采用同行桌查或者臨時(shí)評審就可以滿足一般的

42、代碼，采用同行桌查或者臨時(shí)評審就可以滿足要求了。要求了。2.4.4 2.4.4 軟件評審方法軟件評審方法71工程碩士714 4、各評審方法的評審目標(biāo)、各評審方法的評審目標(biāo)2.4.4 2.4.4 軟件評審方法軟件評審方法72工程碩士72 1 1、什么是審查、什么是審查Michael Fagan 20Michael Fagan 20世紀(jì)世紀(jì)7070年代在年代在IBMIBM提出，提出， 也被稱為也被稱為“正正式審查式審查”，包含制定計(jì)劃、總體會議、準(zhǔn)備、會議、返工、，包含制定計(jì)劃、總體會議、準(zhǔn)備、會議、返工、跟蹤和因果分析等階段，每個(gè)階段都有不同的角色參與，跟蹤和因果分析等階段，每個(gè)階段都有不同的角

43、色參與，是有計(jì)劃有結(jié)構(gòu)的評審方法是有計(jì)劃有結(jié)構(gòu)的評審方法 FaganFagan審查方法有多種變體審查方法有多種變體Gilb/GrahamGilb/Graham方法方法High-ImpactHigh-Impact審查審查分階段審查分階段審查2.4.5 2.4.5 軟件審查軟件審查73工程碩士732 2、審查角色、審查角色作者：準(zhǔn)備要評審的信息或工作產(chǎn)品的人。作者：準(zhǔn)備要評審的信息或工作產(chǎn)品的人。 評審組長：審查會議主持人，帶領(lǐng)審查團(tuán)隊(duì)工作，保證評審評審組長：審查會議主持人，帶領(lǐng)審查團(tuán)隊(duì)工作，保證評審達(dá)到預(yù)期目的。達(dá)到預(yù)期目的。講解員：負(fù)責(zé)在審查會議期間對被審的工作產(chǎn)品進(jìn)行解釋，講解員：負(fù)責(zé)在審查

44、會議期間對被審的工作產(chǎn)品進(jìn)行解釋，使審查組側(cè)重于重要信息，將注意力由責(zé)任人轉(zhuǎn)向產(chǎn)品。使審查組側(cè)重于重要信息，將注意力由責(zé)任人轉(zhuǎn)向產(chǎn)品。 記錄者：記錄審查會議過程中的相關(guān)信息，如對預(yù)審問題的記錄者：記錄審查會議過程中的相關(guān)信息，如對預(yù)審問題的確認(rèn)、新出現(xiàn)的問題等。確認(rèn)、新出現(xiàn)的問題等。審查專家：尋找審查對象與所依照的規(guī)范、標(biāo)準(zhǔn)之間存在的審查專家：尋找審查對象與所依照的規(guī)范、標(biāo)準(zhǔn)之間存在的差異。差異。2.4.5 2.4.5 軟件審查軟件審查74工程碩士743 3、審查專家的選取、審查專家的選取2.4.5 2.4.5 軟件審查軟件審查75工程碩士754 4、審查的流程、審查的流程制定計(jì)劃制定計(jì)劃作作

45、 者者評審組長評審組長總體會議總體會議所有審查者所有審查者其他出席者其他出席者準(zhǔn)準(zhǔn) 備備作作 者者評審組長評審組長讀讀 者者記記 錄錄 者者審查專家審查專家審查包審查包會議公告會議公告作者目標(biāo)作者目標(biāo)缺陷檢查表缺陷檢查表規(guī)則表規(guī)則表規(guī)格說明或規(guī)格說明或前期資料前期資料排印錯誤排印錯誤清清 單單初始可交付初始可交付產(chǎn)產(chǎn) 品品轉(zhuǎn)下頁轉(zhuǎn)下頁2.4.5 2.4.5 軟件審查軟件審查76工程碩士76審查流程（續(xù)）返返 工工作作 者者跟跟 蹤蹤作作 者者驗(yàn)證者驗(yàn)證者會會 議議作作 者者評審組長評審組長讀讀 者者記記 錄錄 者者審查專家審查專家審查總結(jié)報(bào)告審查總結(jié)報(bào)告審查經(jīng)驗(yàn)教訓(xùn)審查經(jīng)驗(yàn)教訓(xùn)排印錯誤排印錯誤

46、清清 單單初始可交付初始可交付產(chǎn)產(chǎn) 品品接上頁接上頁因果分析因果分析審查者審查者質(zhì)保工程師質(zhì)保工程師問題日志問題日志過程改進(jìn)過程改進(jìn)修改后的修改后的可交付產(chǎn)品可交付產(chǎn)品基線化的基線化的可交付產(chǎn)品可交付產(chǎn)品2.4.5 2.4.5 軟件審查軟件審查77工程碩士77 1 1、技術(shù)評審技術(shù)評審 有時(shí)簡稱為“評審”或“輕型審查”，是有計(jì)劃有結(jié)構(gòu)的評審，但沒有審查正式也沒有審查嚴(yán)格，講解角色可以由評審組長代替。 審查的組織與流程，適用于技術(shù)評審。 技術(shù)評審方法發(fā)現(xiàn)問題的數(shù)量是審查的2/3。2.4.6 2.4.6 其它軟件評審其它軟件評審78工程碩士78 2 2、走查走查由產(chǎn)品作者將產(chǎn)品向一組同事介紹，希望

47、他們給出意見。由產(chǎn)品作者將產(chǎn)品向一組同事介紹，希望他們給出意見。是為了滿足作者的需要而不是達(dá)到預(yù)期的質(zhì)量目標(biāo)。是為了滿足作者的需要而不是達(dá)到預(yù)期的質(zhì)量目標(biāo)。一種非正式的評審一種非正式的評審?fù)ǔ２话凑帐孪阮A(yù)定的過程進(jìn)行通常不按照事先預(yù)定的過程進(jìn)行不制定詳細(xì)的準(zhǔn)出條件不制定詳細(xì)的準(zhǔn)出條件不需要管理報(bào)告不需要管理報(bào)告不測量不測量 走查可以采用正式或不正式的的流程進(jìn)行走查可以采用正式或不正式的的流程進(jìn)行 走查發(fā)現(xiàn)問題的數(shù)量是審查的走查發(fā)現(xiàn)問題的數(shù)量是審查的1/21/22.4.6 2.4.6 其它評審方法其它評審方法79工程碩士79 3 3、結(jié)對編程結(jié)對編程兩個(gè)開發(fā)者在一個(gè)電腦上同時(shí)操作一個(gè)程序，兩個(gè)開

48、發(fā)者在一個(gè)電腦上同時(shí)操作一個(gè)程序，每一行代碼都由兩個(gè)人共同編寫每一行代碼都由兩個(gè)人共同編寫。 一種非正式的評審一種非正式的評審沒有結(jié)構(gòu)和制定流程，不需要準(zhǔn)備和評審文沒有結(jié)構(gòu)和制定流程，不需要準(zhǔn)備和評審文檔；檔；缺乏正式評審中來自編程者以外的其他人的缺乏正式評審中來自編程者以外的其他人的想法，更像是一種開發(fā)方法。想法，更像是一種開發(fā)方法。2.4.6 2.4.6 其它評審方法其它評審方法80工程碩士804 4、同級、同級桌查桌查 桌查：仔細(xì)地檢查源代碼，以保證程序正確執(zhí)行，桌查：仔細(xì)地檢查源代碼，以保證程序正確執(zhí)行，是一種自評審。是一種自評審。 桌查特點(diǎn)：桌查特點(diǎn)：除作者外只有一個(gè)人對工作產(chǎn)品進(jìn)行

49、檢查；除作者外只有一個(gè)人對工作產(chǎn)品進(jìn)行檢查；依靠評審者自身的知識、技能和自律等因素，不依靠評審者自身的知識、技能和自律等因素，不同的評審者得到的結(jié)果可能不同。同的評審者得到的結(jié)果可能不同。 桌查可以采用缺陷檢查表、相應(yīng)的分析方法和度桌查可以采用缺陷檢查表、相應(yīng)的分析方法和度量表格，也可以不采用。量表格，也可以不采用。 2.4.6 2.4.6 其它評審方法其它評審方法81工程碩士814 4、輪、輪查查 輪查：又稱輪查：又稱“分配審查分配審查”，是一種由多人，是一種由多人組成的并行同級桌查，輪查時(shí)作者將產(chǎn)品副組成的并行同級桌查，輪查時(shí)作者將產(chǎn)品副本發(fā)給幾位評審員并收集整理意見。本發(fā)給幾位評審員并收

50、集整理意見。 請他人幫忙，在短時(shí)間內(nèi)解決一些問題，請他人幫忙，在短時(shí)間內(nèi)解決一些問題，在團(tuán)隊(duì)合作中非常常見的事情。在團(tuán)隊(duì)合作中非常常見的事情。2.4.6 2.4.6 其它評審方法其它評審方法82工程碩士821 1、代碼走查及其流程、代碼走查及其流程 代碼走查：以組為單位閱讀代碼，是一系代碼走查：以組為單位閱讀代碼，是一系列規(guī)程和錯誤檢查技術(shù)的集合，但規(guī)程與檢列規(guī)程和錯誤檢查技術(shù)的集合，但規(guī)程與檢查不同。查不同。 人工測試的方法，屬于靜態(tài)白盒測試，人工測試的方法，屬于靜態(tài)白盒測試，通過閱讀程序源代碼查找程序的錯誤。通過閱讀程序源代碼查找程序的錯誤。2.4.7 2.4.7 代碼走查代碼走查83工程

51、碩士83 1 1、代碼走查及其流程、代碼走查及其流程2.4.7 2.4.7 代碼走查代碼走查作者作者組員、技術(shù)專家組員、技術(shù)專家初始初始評審對象評審對象問題清單問題清單缺陷檢查表缺陷檢查表可交付可交付評審對象評審對象Project Manager84工程碩士842 2、代碼走查規(guī)程、代碼走查規(guī)程小組組成：協(xié)調(diào)人、秘書、測試人員、富有經(jīng)驗(yàn)的程序員、程序設(shè)計(jì)語言專家、程序員新手、維護(hù)人員、其他項(xiàng)目組的成員走查活動：使用書面的測試用例，采用人腦模擬計(jì)算機(jī)執(zhí)行測試用例，即把測試數(shù)據(jù)跟程序的邏輯結(jié)構(gòu)走一遍，以發(fā)現(xiàn)錯誤。2.4.7 2.4.7 代碼走查代碼走查85工程碩士853 3、代碼錯誤檢查技術(shù)、代碼錯誤檢查技術(shù)代碼錯誤檢查技術(shù)錯誤列表數(shù)據(jù)引用錯誤；數(shù)據(jù)聲明錯誤；運(yùn)算錯誤；比較錯誤；控制流程錯誤；接口錯誤；輸入/輸出錯誤；其它檢查；數(shù)據(jù)引用錯誤1、是否有引用的變量未賦值或未初始化？2、下標(biāo)的值是否在范圍之內(nèi)？3、是