軟件工程課件：第12章 軟件驗(yàn)證和確認(rèn)

1、第12章 軟件驗(yàn)證和確認(rèn) 2軟件危機(jī)軟件危機(jī)實(shí)際上源于軟件中的錯(cuò)誤正是這些錯(cuò)誤導(dǎo)致了軟件開發(fā)在成本、進(jìn)度和質(zhì)量上的失控 32022/9/21基本術(shù)語(yǔ)（補(bǔ)充）錯(cuò)誤（Error）錯(cuò)誤是指導(dǎo)致系統(tǒng)可能包含故障的人的行為，如輸入錯(cuò)誤、需求錯(cuò)誤、設(shè)計(jì)錯(cuò)誤等。缺陷（Defect，Bug）缺陷是錯(cuò)誤的表現(xiàn)，包括過(guò)錯(cuò)缺陷和遺漏缺陷。故障（Fault）故障是指系統(tǒng)的規(guī)格說(shuō)明與其行為之間的偏差，通常由一個(gè)或多個(gè)缺陷引起。42022/9/21定義軟件錯(cuò)誤的規(guī)則（補(bǔ)充）軟件未達(dá)到產(chǎn)品說(shuō)明書標(biāo)明的功能；軟件出現(xiàn)了產(chǎn)品說(shuō)明書指明不會(huì)出現(xiàn)的錯(cuò)誤；軟件功能超出了產(chǎn)品說(shuō)明書指明的范圍；軟件未達(dá)到產(chǎn)品說(shuō)明書雖未指出但應(yīng)達(dá)到的目標(biāo)

2、；軟件測(cè)試人員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢、或者最終用戶不滿意。52022/9/21為什么要有驗(yàn)證和確認(rèn)活動(dòng)？盡管軟件活動(dòng)的每個(gè)階段一般均經(jīng)過(guò)嚴(yán)格的技術(shù)審查，以盡可能早地發(fā)現(xiàn)并糾正錯(cuò)誤，但經(jīng)驗(yàn)表明階段審查并不能發(fā)現(xiàn)所有錯(cuò)誤，新的活動(dòng)還會(huì)引入新的錯(cuò)誤。 有錯(cuò)是軟件的屬性，而且是無(wú)法改變的。關(guān)鍵在于如何避免錯(cuò)誤的產(chǎn)生和消除已經(jīng)產(chǎn)生的錯(cuò)誤，使程序中的錯(cuò)誤密度達(dá)到盡可能低的程度。Solution: 進(jìn)行驗(yàn)證和確認(rèn)活動(dòng)612.1 驗(yàn)證和確認(rèn)驗(yàn)證和確認(rèn)（Verification & Validation，簡(jiǎn)稱V&V）工作是在整個(gè)軟件生命周期中對(duì)軟件的規(guī)范性評(píng)估活動(dòng)，以保證軟件開發(fā)各個(gè)環(huán)節(jié)的正確

3、性。系統(tǒng)開發(fā)完畢后再測(cè)試的觀念是錯(cuò)誤的。如果早期開發(fā)中出現(xiàn)的錯(cuò)誤不能及時(shí)發(fā)現(xiàn)和解決，將帶到設(shè)計(jì)、編碼、測(cè)試等各階段，影響會(huì)逐步擴(kuò)大。 72022/9/21驗(yàn)證與確認(rèn)的活動(dòng)模型（補(bǔ)充）82022/9/2112.1 驗(yàn)證和確認(rèn)驗(yàn)證和確認(rèn)是兩個(gè)相互獨(dú)立但卻相輔相成的活動(dòng)，二者很容易混淆驗(yàn)證（Verification）Are we building the product right“（我們是否在正確地制造產(chǎn)品？）軟件驗(yàn)證試圖證明在軟件生存周期的各個(gè)階段，軟件產(chǎn)品或中間產(chǎn)品是否能夠滿足客戶需求，包括邏輯協(xié)調(diào)性、完備性和正確性 。確認(rèn)（Validation）Are we building the rig

4、ht product“（我們是否在制造正確的產(chǎn)品？）軟件確認(rèn)是一系列的活動(dòng)和過(guò)程，其目的是保證軟件產(chǎn)品能夠符合其描述的要求。 912.1 驗(yàn)證和確認(rèn)確認(rèn)（Validation）：包括需求規(guī)格說(shuō)明的確認(rèn)和程序的確認(rèn)程序的確認(rèn)又分為靜態(tài)的確認(rèn)和動(dòng)態(tài)的確認(rèn)。靜態(tài)的確認(rèn)一般不在計(jì)算機(jī)上實(shí)際執(zhí)行程序，而是通過(guò)人工分析或程序正確性證明來(lái)確認(rèn)程序的正確性動(dòng)態(tài)確認(rèn)主要通過(guò)動(dòng)態(tài)分析和程序測(cè)試來(lái)檢查程序的執(zhí)行狀態(tài)，以確認(rèn)程序是否有問題 102022/9/2112.1 驗(yàn)證和確認(rèn)驗(yàn)證強(qiáng)調(diào)對(duì)于過(guò)程的檢驗(yàn)！確認(rèn)強(qiáng)調(diào)對(duì)于結(jié)果的檢驗(yàn)！11驗(yàn)證與確認(rèn)的技術(shù)分類方法：靜態(tài)技術(shù)和動(dòng)態(tài)技術(shù)軟件審查和軟件測(cè)試12驗(yàn)證與確認(rèn)的技術(shù)在V

5、&V過(guò)程中，可以使用軟件審查和軟件測(cè)試兩種系統(tǒng)檢查和分析技術(shù) 軟件審查：是對(duì)系統(tǒng)的各種表示形式，如需求文檔、設(shè)計(jì)圖和程序源代碼等，進(jìn)行分析和檢查。這個(gè)過(guò)程貫穿軟件開發(fā)過(guò)程的所有階段。審查活動(dòng)可以輔之一些能對(duì)系統(tǒng)源文本和相關(guān)聯(lián)的文檔的自動(dòng)分析。軟件審查和自動(dòng)分析是一種靜態(tài)V&V技術(shù)，不需要系統(tǒng)的執(zhí)行。軟件測(cè)試是使用測(cè)試數(shù)據(jù)對(duì)軟件的實(shí)現(xiàn)進(jìn)行運(yùn)行檢查，查看系統(tǒng)的輸出內(nèi)容以及運(yùn)行行為是否符合要求。測(cè)試是V&V過(guò)程中的動(dòng)態(tài)技術(shù)，需要讓系統(tǒng)運(yùn)行起來(lái)以觀察其動(dòng)態(tài)行為。1312.1 驗(yàn)證和確認(rèn) 其中軟件審查技術(shù)程序?qū)彶?12.2.1)、自動(dòng)化的源代碼分析(12.2.2)和形式化檢驗(yàn)靜態(tài)的軟件審查只能檢查程序及

6、其描述之間的吻合程度，不能夠說(shuō)明軟件真是有用的，而且也不能檢驗(yàn)軟件的非功能特性，如性能和可靠性等。程序測(cè)試仍然是起決定作用的軟件驗(yàn)證和確認(rèn)技術(shù)。 142022/9/2112.3軟件測(cè)試軟件測(cè)試的定義：傳統(tǒng)：測(cè)試是一種旨在評(píng)估一個(gè)程序或系統(tǒng)的屬性或能力，確定它是否符合其所需結(jié)果的活動(dòng)。Myers：測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行一個(gè)程序或系統(tǒng)的過(guò)程。IEEE：測(cè)試是使用人工和自動(dòng)手段來(lái)運(yùn)行或檢測(cè)某個(gè)系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)系統(tǒng)是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。152022/9/2112.3.1軟件測(cè)試的目的和原則測(cè)試的目的：測(cè)試是為了發(fā)現(xiàn)程序的錯(cuò)誤，而不是證明程序無(wú)錯(cuò)誤；一個(gè)好的測(cè)

7、試用例在于能夠發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。牢記這三句話！162022/9/2112.3.1軟件測(cè)試的目的和原則用戶和軟件開發(fā)者的測(cè)試觀點(diǎn)：從用戶的角度出發(fā)普遍希望通過(guò)軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過(guò)程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對(duì)軟件質(zhì)量的信心。一種正確的態(tài)度測(cè)試的目的應(yīng)從用戶角度出發(fā)。 測(cè)試只能證明程序中錯(cuò)誤的存在，但不能證明程序中沒有錯(cuò)誤。因?yàn)榧词箤?shí)施了最嚴(yán)格的測(cè)試，仍然可能還有尚未被發(fā)現(xiàn)的錯(cuò)誤或缺陷存在于程序當(dāng)中，因而測(cè)試不能證明程序沒有錯(cuò)誤

8、，但可能查出程序中的錯(cuò)誤。1712.3.1軟件測(cè)試的目的和原則軟件測(cè)試的原則把“盡早地和不斷地測(cè)試”作為開發(fā)者的座右銘程序員應(yīng)避免檢查自己的程序設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)包括合理的和不合理的輸入及各種邊界條件，測(cè)試極端狀態(tài)和意外狀態(tài)對(duì)測(cè)試結(jié)果一定要全面檢查制定嚴(yán)格的測(cè)試計(jì)劃，排除測(cè)試的隨意性注意回歸測(cè)試的關(guān)聯(lián)性，往往修改一個(gè)錯(cuò)誤會(huì)引起更多錯(cuò)誤程序中尚未發(fā)現(xiàn)的錯(cuò)誤數(shù)量通常和該程序中已經(jīng)發(fā)現(xiàn)的錯(cuò)誤數(shù)量成正比。妥善保存一切測(cè)試過(guò)程文檔（測(cè)試計(jì)劃，測(cè)試規(guī)范，測(cè)試用例，出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告），測(cè)試重現(xiàn)往往要靠測(cè)試文檔。182022/9/21軟件測(cè)試文檔-測(cè)試用例(補(bǔ)充)Test Case: 一組數(shù)據(jù)輸入和所期

9、望結(jié)果“輸入”是對(duì)被測(cè)軟件接收外界數(shù)據(jù)的描述“期望結(jié)果”是對(duì)于相應(yīng)輸入軟件應(yīng)該出現(xiàn)的輸出結(jié)果的描述測(cè)試用例還應(yīng)明確指出使用具體測(cè)試案例產(chǎn)生的測(cè)試程序的任何限制。測(cè)試用例可以被組織成一個(gè)測(cè)試系列，即為實(shí)現(xiàn)某個(gè)特定的測(cè)試目的而設(shè)計(jì)的一組測(cè)試用例。例如，一部分測(cè)試用例用來(lái)測(cè)試系統(tǒng)的兼容性，另一部分是用來(lái)測(cè)試系統(tǒng)在特定的環(huán)境中，系統(tǒng)的典型應(yīng)用是否能夠很好地運(yùn)作。192022/9/2112.3.2單元測(cè)試軟件測(cè)試過(guò)程（圖12.3）202022/9/2112.3.2單元測(cè)試軟件測(cè)試過(guò)程（圖12.3續(xù)）通常軟件測(cè)試過(guò)程活動(dòng)有4個(gè)，即單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和確認(rèn)測(cè)試。 212022/9/2112.3.2

10、單元測(cè)試又稱“組件測(cè)試”最小的程序設(shè)計(jì)單元（軟件組件或模塊）進(jìn)行測(cè)試，單元測(cè)試需要從程序的內(nèi)部邏輯結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，在單元測(cè)試階段，多個(gè)組件可并行進(jìn)行。 一般由編寫該單元代碼的開發(fā)人員執(zhí)行，該人員負(fù)責(zé)設(shè)計(jì)和運(yùn)行一系列的測(cè)試以確保該單元符合需求。單元測(cè)試的目的驗(yàn)證代碼是與設(shè)計(jì)相符的跟蹤需求和設(shè)計(jì)的實(shí)現(xiàn)發(fā)現(xiàn)設(shè)計(jì)和需求中存在的錯(cuò)誤發(fā)現(xiàn)在編碼過(guò)程中引入的錯(cuò)誤222022/9/2112.3.2單元測(cè)試23（1）接口測(cè)試 由于模塊接口是數(shù)據(jù)出入模塊的通道。接口不正常，其他測(cè)試則無(wú)從進(jìn)行，所以在其他測(cè)試開始之前，首先要對(duì)通過(guò)模塊接口的數(shù)據(jù)進(jìn)行測(cè)試。 接口測(cè)試應(yīng)做如下考慮：模塊接收實(shí)際參數(shù)個(gè)數(shù)是否與模塊形

11、式參數(shù)個(gè)數(shù)一致，實(shí)際參數(shù)與形式參數(shù)的屬性是否匹配，實(shí)際參數(shù)與形式參數(shù)的單位是否一致；調(diào)用其他模塊時(shí)，所給的實(shí)際參數(shù)的個(gè)數(shù)是否與被調(diào)用模塊的形參個(gè)數(shù)相等，實(shí)際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配，實(shí)際參數(shù)的單位是否與被調(diào)模塊的形參單位匹配；調(diào)用內(nèi)部函數(shù)所用參數(shù)的個(gè)數(shù)、屬性和次序是否正確；.24（1）接口測(cè)試若一個(gè)模塊需要完成外部的輸入或輸出時(shí)，還應(yīng)檢查下述各點(diǎn)：文件屬性是否正確；OPEN/CLOSE語(yǔ)句是否正確；格式說(shuō)明與I/O語(yǔ)句是否匹配；緩沖器大小與記錄長(zhǎng)度是否匹配；文件是否先打開后使用；文件結(jié)束的條件是否處理過(guò)；I/O的錯(cuò)誤是否處理過(guò)；輸出信息中是否有正文的錯(cuò)誤；25（2）局部數(shù)據(jù)結(jié)構(gòu)測(cè)

12、試檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時(shí)存儲(chǔ)在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過(guò)程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是錯(cuò)誤的根源。 26（3）重要的執(zhí)行路徑測(cè)試對(duì)模塊中每一條獨(dú)立的執(zhí)行路徑進(jìn)行測(cè)試 保證模塊中每條語(yǔ)句至少執(zhí)行一次，方法：設(shè)計(jì)測(cè)試用例發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腻e(cuò)誤。基本路徑測(cè)試和循環(huán)測(cè)試是最常用、最有效的測(cè)試技術(shù) 27（4）異常處理測(cè)試一個(gè)好的設(shè)計(jì)應(yīng)能預(yù)見各種出錯(cuò)條件，并預(yù)設(shè)各種出錯(cuò)處理通路。出錯(cuò)處理通路同樣需要認(rèn)真測(cè)試，測(cè)試應(yīng)著重檢查下列問題：錯(cuò)誤描述難以理解；錯(cuò)誤提示與實(shí)際錯(cuò)誤不相符；在程序自定義的出錯(cuò)處理段運(yùn)行之前，系統(tǒng)已介入；對(duì)錯(cuò)誤的處理不正確；提供的錯(cuò)誤信息不足，無(wú)法

13、確定錯(cuò)誤位置和差錯(cuò)。28（5）邊界測(cè)試邊界測(cè)試是單元測(cè)試步驟中的最后一步，也是最重要的一項(xiàng)任務(wù)。原因：軟件通常容易在邊界上失效方法：采用邊界值分析技術(shù)，針對(duì)邊界值及其左、右值設(shè)計(jì)測(cè)試用例，很有可能發(fā)現(xiàn)新的錯(cuò)誤。292022/9/2112.3.2單元測(cè)試單元測(cè)試環(huán)境（圖12.4）驅(qū)動(dòng)模塊：模擬被測(cè)模塊的上一級(jí)模塊樁模塊：模擬被測(cè)單元需調(diào)用的其他函數(shù)接口單元測(cè)試的動(dòng)態(tài)環(huán)境：生成測(cè)試數(shù)據(jù)302022/9/21單元測(cè)試舉例：編寫 MyClass的樁模塊三種方式main ( )函數(shù)MyClass的靜態(tài)成員函數(shù)負(fù)責(zé)實(shí)現(xiàn)測(cè)試用例的單獨(dú)驅(qū)動(dòng)類312022/9/21MyClass的測(cè)試驅(qū)動(dòng)322022/9/21

14、MyClass的測(cè)試驅(qū)動(dòng)332022/9/2112.3.3集成測(cè)試Integration Testing集成測(cè)試也稱組裝測(cè)試，綜合測(cè)試 在單元測(cè)試的基礎(chǔ)上，將所有模塊按照總體設(shè)計(jì)的要求組裝成為子系統(tǒng)或系統(tǒng)進(jìn)行的測(cè)試。集成測(cè)試的對(duì)象是模塊間的接口，其目的是找出在模塊接口上，包括系統(tǒng)體系結(jié)構(gòu)上的問題。數(shù)據(jù)經(jīng)過(guò)接口是否會(huì)丟失；一個(gè)模塊對(duì)另一模塊是否造成不應(yīng)有的影響；幾個(gè)子功能組合起來(lái)能否實(shí)現(xiàn)主功能；誤差不斷積累是否達(dá)到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題。3412.3.3集成測(cè)試集成測(cè)試分為非漸增式測(cè)試和漸增式測(cè)試。非漸增式測(cè)試方法是先分別測(cè)試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求集成在一起，組合成所要

15、的程序再進(jìn)行測(cè)試。漸增式測(cè)試是逐步將待測(cè)模塊同已測(cè)試好的模塊集成起來(lái)進(jìn)行測(cè)試。當(dāng)使用漸增方式把模塊結(jié)合到軟件系統(tǒng)中去時(shí)，有自頂向下和自底向上兩種結(jié)合方法。352022/9/21（1）自頂向下方法 從主控模塊開始起，按照軟件的層次結(jié)構(gòu)，以深度優(yōu)先或者寬度優(yōu)先策略，逐步把各個(gè)模塊結(jié)合在一起36（1）自頂向下方法37（1）自頂向下方法自頂向下綜合測(cè)試可歸納為五個(gè)步驟：用主控制模塊做測(cè)試驅(qū)動(dòng)程序，把對(duì)主控模塊進(jìn)行單元測(cè)試時(shí)引入的所有樁模塊用實(shí)際模塊替代；依據(jù)所選的集成策略（深度優(yōu)先或?qū)挾葍?yōu)先），每次只用一個(gè)實(shí)際模塊替換一個(gè)樁模塊；每集成一個(gè)模塊立即測(cè)試一遍；只有每組測(cè)試完成后，才用實(shí)際模塊替換下個(gè)樁模

16、塊；為避免引入新錯(cuò)誤，須不斷進(jìn)行回歸測(cè)試（即全部或部分地重復(fù)已做過(guò)的測(cè)試）。38（1）自頂向下方法優(yōu)點(diǎn)能盡早地對(duì)程序的主要控制和決策機(jī)制進(jìn)行檢驗(yàn)，因而能較早發(fā)現(xiàn)錯(cuò)誤。缺點(diǎn)在于測(cè)試較高層模塊時(shí)，低層處理采用樁模塊替代，這并不能夠反映實(shí)際情況，重要數(shù)據(jù)不能及時(shí)回送到上層模塊，因而測(cè)試并不充分和完善。測(cè)試需要開發(fā)能模擬真實(shí)模塊的樁模塊，無(wú)疑要大大增加開銷。392022/9/21（2）自底向上結(jié)合自底向上測(cè)試是從軟件結(jié)構(gòu)最低層的模塊開始向上組裝模塊、進(jìn)行集成測(cè)試，當(dāng)測(cè)試到較高模塊時(shí)，所需的下層模塊均己測(cè)試完畢，因而不再需要樁模塊。但要設(shè)計(jì)驅(qū)動(dòng)模塊，設(shè)計(jì)驅(qū)動(dòng)模塊的時(shí)候，需要把底層模塊分為模塊族40（2）

17、自底向上結(jié)合自底向上綜合測(cè)試可歸納為以下四個(gè)步驟：把低層模塊組合成實(shí)現(xiàn)一個(gè)特定軟件子系統(tǒng)的族為每個(gè)族設(shè)計(jì)一個(gè)驅(qū)動(dòng)軟件，作為測(cè)試的控制程序，以協(xié)調(diào)測(cè)試用例的輸入和輸出；對(duì)模塊族進(jìn)行測(cè)試；按系統(tǒng)結(jié)構(gòu)逐層向上序，用實(shí)際模塊替換驅(qū)動(dòng)程序，將模塊族集成起來(lái)組裝成新的模塊族再進(jìn)行測(cè)試，直至全部完成。 41兩種方法的優(yōu)缺點(diǎn)自頂向下方法不需驅(qū)動(dòng)模塊的設(shè)計(jì)，可在程序測(cè)試的早期實(shí)現(xiàn)并驗(yàn)證系統(tǒng)的主要功能，及早發(fā)現(xiàn)上層模塊的接口錯(cuò)誤。但自頂向下方法必須設(shè)計(jì)樁模塊，使低層關(guān)鍵模塊中錯(cuò)誤發(fā)現(xiàn)較晚，并且不能在早期很快且充分地展開測(cè)試的人力。自底向上方法與自頂向下方法相比較，它的優(yōu)缺點(diǎn)與自頂向下方法恰恰相反一般在實(shí)際應(yīng)用中，

18、采用兩種方法相結(jié)合的混合法，即對(duì)軟件結(jié)構(gòu)的較上層使用自頂向下的結(jié)合方法，對(duì)下層使用自底向上的結(jié)合方法，以充分發(fā)揮兩種方法的優(yōu)點(diǎn)，盡量避免其缺點(diǎn)。422022/9/2112.3.4 系統(tǒng)測(cè)試System Testing將已經(jīng)集成好的軟件系統(tǒng)作為一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下進(jìn)行的一系列測(cè)試。主要目的是充分運(yùn)行系統(tǒng)，驗(yàn)證系統(tǒng)各個(gè)部件是否都能正常工作并完成所分配的功能，并能滿足性能的要求。系統(tǒng)測(cè)試包括：恢復(fù)測(cè)試、安全性測(cè)試、壓力測(cè)試和性能測(cè)試功能測(cè)試GUI測(cè)試等432022/9/2112.3.4系統(tǒng)測(cè)試-恢復(fù)測(cè)試Recovery Test

19、ing：采用各種人工干預(yù)方式使軟件出錯(cuò)，而不能正常工作，從而檢驗(yàn)系統(tǒng)從軟件或者硬件失敗中恢復(fù)的能力。恢復(fù)性測(cè)試的示例當(dāng)供電出現(xiàn)問題時(shí)的恢復(fù)恢復(fù)程序的執(zhí)行對(duì)選擇的文件和數(shù)據(jù)進(jìn)行恢復(fù)恢復(fù)處理日志方面的能力通過(guò)切換到一個(gè)并行系統(tǒng)來(lái)進(jìn)行恢復(fù)442022/9/2112.3.4 系統(tǒng)測(cè)試-安全性測(cè)試檢驗(yàn)在系統(tǒng)中已存在的系統(tǒng)安全性措施、保密性措施是否發(fā)揮作用，有無(wú)漏洞。 安全性測(cè)試的示例想方設(shè)法截取或破譯口令；專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制；故意導(dǎo)致系統(tǒng)失敗，企圖趁系統(tǒng)恢復(fù)之機(jī)非法進(jìn)入；試圖通過(guò)瀏覽非保密數(shù)據(jù)而導(dǎo)出自己所需的信息等等。系統(tǒng)安全設(shè)計(jì)的準(zhǔn)則是使非法入侵的代價(jià)超過(guò)被保護(hù)信息的價(jià)值，這樣，非法入侵者

20、就會(huì)失去攻擊意向。452022/9/2112.3.4系統(tǒng)測(cè)試-壓力測(cè)試Press Testing：檢查系統(tǒng)在資源超負(fù)荷情況下的表現(xiàn)示例對(duì)于一個(gè)固定輸入速率（如每分鐘 120 個(gè)單詞）的單詞處理響應(yīng)時(shí)間在極短的時(shí)間內(nèi)引入超負(fù)荷的數(shù)據(jù)容量成千上萬(wàn)的用戶在同一時(shí)間從網(wǎng)上登錄到系統(tǒng)引入需要大量?jī)?nèi)存資源的操作壓力測(cè)試通常采用邊界值和錯(cuò)誤猜測(cè)方法，且需要工具的支持。462022/9/2112.3.4系統(tǒng)測(cè)試-性能測(cè)試 測(cè)試軟件在被組裝進(jìn)系統(tǒng)的環(huán)境下運(yùn)行時(shí)的性能。性能測(cè)試應(yīng)覆蓋測(cè)試過(guò)程的每一步。即使在單元層，單個(gè)模塊的性能也可以通過(guò)白盒測(cè)試來(lái)評(píng)價(jià)，而不是等到所有系統(tǒng)元素全組裝以后，再確認(rèn)系統(tǒng)的真正性能。性能

21、測(cè)試有時(shí)是與壓力測(cè)試聯(lián)系在一起的，常常需要硬件和軟件測(cè)試設(shè)備。472022/9/2112.3.4系統(tǒng)測(cè)試-功能測(cè)試（補(bǔ)充）是系統(tǒng)測(cè)試中最基本的測(cè)試，它不管軟件內(nèi)部的實(shí)現(xiàn)邏輯，主要根據(jù)軟件需求規(guī)格說(shuō)明和測(cè)試需求列表，驗(yàn)證產(chǎn)品的功能實(shí)現(xiàn)是否符合需求規(guī)格。功能測(cè)試主要發(fā)現(xiàn)以下錯(cuò)誤：是否有不正確或遺漏的功能？功能實(shí)現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計(jì)的隱藏需求？能否正確地接受輸入？能否正確地輸出結(jié)果？常用的測(cè)試技術(shù)黑盒測(cè)試方法：等價(jià)類劃分、邊界值測(cè)試482022/9/2112.3.4系統(tǒng)測(cè)試-GUI測(cè)試 檢查用戶界面實(shí)現(xiàn)與設(shè)計(jì)的符合情況，確認(rèn)用戶界面處理的正確性。提倡界面與功能的設(shè)計(jì)分離，其重點(diǎn)關(guān)注在界面層和

22、界面與功能接口層上。GUI自動(dòng)化測(cè)試工具WinRunner，QARun，QARobot，Visual Test常用的測(cè)試技術(shù)等價(jià)類劃分、邊界值分析、基于狀態(tài)圖方法、錯(cuò)誤猜測(cè)法492022/9/2112.3.5 確認(rèn)測(cè)試Acceptance Testing：確認(rèn)測(cè)試又稱有效性測(cè)試、合格測(cè)試或驗(yàn)收測(cè)試，是軟件交付前的最后測(cè)試。一般使用用戶環(huán)境中的實(shí)際數(shù)據(jù)進(jìn)行測(cè)試。在測(cè)試過(guò)程中，除了考慮軟件的功能和性能外，還應(yīng)對(duì)軟件的兼容性、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn)。測(cè)試與測(cè)試產(chǎn)品在正式發(fā)布前經(jīng)常進(jìn)行的兩種測(cè)試；測(cè)試是由開發(fā)人員在開發(fā)環(huán)境下進(jìn)行的測(cè)試,盡可能的覆蓋用戶的所有操作，通過(guò)測(cè)試調(diào)整的軟件為版本測(cè)

23、試是由開發(fā)方組織多個(gè)典型用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試，匯報(bào)異常，提出意見，對(duì)版本進(jìn)行改錯(cuò)和完善。502022/9/21其他測(cè)試（補(bǔ)充）回歸測(cè)試（Regression Testing）驗(yàn)證對(duì)系統(tǒng)的變更沒有影響以前的功能，并且保證當(dāng)前功能的變更是正確的?？梢园l(fā)生在軟件測(cè)試的任何階段，包括單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，其令人煩惱的原因在于頻繁的重復(fù)性勞動(dòng)。回歸測(cè)試應(yīng)考慮的因素范圍：有選擇地執(zhí)行以前的測(cè)試用例；自動(dòng)化：測(cè)試程序的自動(dòng)執(zhí)行和自動(dòng)配置、測(cè)試用例的管理和自動(dòng)輸入、測(cè)試結(jié)果的自動(dòng)采集和比較、測(cè)試結(jié)論的自動(dòng)輸出。5112.4軟件測(cè)試方法軟件測(cè)試通過(guò)動(dòng)態(tài)執(zhí)行被測(cè)程序來(lái)完成，由執(zhí)行結(jié)果分析程序可能

24、出現(xiàn)的錯(cuò)誤。軟件測(cè)試把程序看作為一個(gè)函數(shù)，輸入的全體稱為函數(shù)的定義域，輸出的全體稱為函數(shù)的值域，函數(shù)則描述了輸入的定義域與輸出值域的關(guān)系。這樣軟件測(cè)試的算法可歸納為：選取定義域中的有效值，或定義域外無(wú)效值。對(duì)己選取的值決定預(yù)期的結(jié)果。用選取的值執(zhí)行程序。觀察程序行為，記錄執(zhí)行結(jié)果。將程序運(yùn)行的結(jié)果與預(yù)期的結(jié)果相比較，不吻合則程序有錯(cuò)。軟件測(cè)試方法常用白盒測(cè)試和黑盒測(cè)試。522022/9/2112.4.1 白盒測(cè)試方法White Box Testing：白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試已知軟件內(nèi)部結(jié)構(gòu)和算法，對(duì)軟件的過(guò)程性細(xì)節(jié)進(jìn)行檢驗(yàn)。把測(cè)試對(duì)象看做一個(gè)透明的盒子，允許測(cè)試人員利用程序內(nèi)部的

25、邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。軟件白盒測(cè)試是一個(gè)與黑盒測(cè)試相對(duì)的概念，是指測(cè)試者針對(duì)可見代碼進(jìn)行的一種測(cè)試。 53為什么要做白盒測(cè)試？ 假設(shè)有一臺(tái)的面包機(jī)，從上面倒入面粉與水，開動(dòng)機(jī)器后從下面出來(lái)的就是烤好了的面包這個(gè)機(jī)器的功能比較單一，接口很清晰，輸入是面粉與水，輸出是面包現(xiàn)在假定這個(gè)面包機(jī)多年未用，內(nèi)部都生銹了，現(xiàn)在要清洗它，類似于我們開發(fā)的軟件，軟件有Bug，那得通過(guò)測(cè)試來(lái)清理。 54為什么要做白盒測(cè)試？那如何更快速的清洗這臺(tái)面包機(jī)呢？有兩種洗法一是拿水從上往下灌，這是采用黑盒測(cè)試的方法的系統(tǒng)測(cè)試。另一種是拆開來(lái)洗，拆開機(jī) 器后，拿抺布沾點(diǎn)清潔劑，把

26、各零件的坑坑槽槽擦洗一遍，然后組裝回來(lái)，再用水從上往下沖一遍拆開來(lái)洗是白盒方法，組裝回來(lái)用水沖是黑盒方式，相當(dāng)于白盒 測(cè)試之后再追加一次系統(tǒng)測(cè)試。無(wú)疑，上面第二種方法是正確的。所以，軟件的白盒測(cè)試不可或缺，因?yàn)檫z留Bug的影響很大，就像面包機(jī)沒洗凈留鐵銹會(huì)致癌，還因?yàn)檐浖到y(tǒng)遠(yuǎn)比面包機(jī)復(fù)雜，不拆開來(lái)怎么能洗干凈！ 55白盒測(cè)試白盒測(cè)試應(yīng)該根據(jù)程序的控制結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，原則：保證模塊中每一個(gè)獨(dú)立的路徑至少執(zhí)行一次保證所有判斷的每一分支至少執(zhí)行一次保證每一循環(huán)都在邊界條件和一般條件下至少各執(zhí)行一次驗(yàn)證所有內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效總結(jié)：窮舉法。562022/9/21白盒測(cè)試的問題對(duì)一個(gè)具有多重選擇和循環(huán)

27、嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。（圖12.7）5712.4.1 白盒測(cè)試方法窮舉法實(shí)際不可能實(shí)現(xiàn)。解決方法：精心設(shè)計(jì)測(cè)試用例，使少量的測(cè)試用例覆蓋全部。需從大量的可用測(cè)試用例中精選出少量的測(cè)試數(shù)據(jù)，使得采用這些測(cè)試數(shù)據(jù)能夠達(dá)到最佳的測(cè)試效果，即能高效地、盡可能多地發(fā)現(xiàn)隱藏的錯(cuò)誤。路徑測(cè)試、邏輯覆蓋測(cè)試、循環(huán)測(cè)試。 582022/9/21（1）基本路徑測(cè)試方法：建立在程序控制流圖(程序流圖，PDL或源代碼等)的基礎(chǔ)上，分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，由此設(shè)計(jì)測(cè)試用例。保證在測(cè)試中程序的每一個(gè)可執(zhí)行語(yǔ)句至少要執(zhí)行一次,每一條路徑都至少通過(guò)一次。目的：壓縮路徑，將所有可能

28、路徑壓縮為通過(guò)至少一次代碼的基本路徑（獨(dú)立路徑）集合59程序流程圖和程序流圖程序流程圖1325在已經(jīng)源碼的情況下，可畫出程序流程圖程序流程圖中矩形框所表示的處理（謂詞節(jié)點(diǎn)) 菱形表示的兩個(gè)甚至多個(gè)出口判斷 多條流線相交的匯合點(diǎn) 60程序流程圖和程序流圖程序流圖12435abcdef符號(hào)為控制流圖的一個(gè)結(jié)點(diǎn)，表示一個(gè)或多個(gè)無(wú)分支的源程序語(yǔ)句（謂詞節(jié)點(diǎn)）。箭頭為邊，表示控制流的方向。為有向圖612022/9/21程序流圖（有向圖）中找出基本路徑62程序流圖（有向圖）中找出基本路徑 導(dǎo)出獨(dú)立路徑（用語(yǔ)句編號(hào)表示） 路徑1：414 路徑2：46714 路徑3：4691013414 路徑4：469121

29、341446791012131463（1）基本路徑測(cè)試導(dǎo)出基本路徑集合后，如何完成基本路徑測(cè)試？設(shè)計(jì)測(cè)試用例。軟件測(cè)試人員可以根據(jù)判斷點(diǎn)給出的條件，選擇適當(dāng)數(shù)據(jù)作為測(cè)試用例，保證每一條路徑可以被測(cè)試。每一個(gè)測(cè)試用例執(zhí)行后，與預(yù)期的結(jié)果進(jìn)行比較，如果所有的測(cè)試用例都執(zhí)行完畢，則可以確信程序中所有可執(zhí)行語(yǔ)句至少被執(zhí)行了一次。 642022/9/2112.4.2 黑盒測(cè)試方法Black Box Testing又稱功能測(cè)試將測(cè)試對(duì)象看做一個(gè)黑盒子，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō)明書，檢查程序的功能是否符合它的功能說(shuō)明?；A(chǔ)為窮舉原則：輸入全部有效數(shù)據(jù)和無(wú)效數(shù)據(jù)對(duì)程序進(jìn)行測(cè)試。有效的輸入用于檢查程序是否得到正確結(jié)果