軟件測試技術(shù)及應(yīng)用_04需求測試方法

1、軟件測試技術(shù)詳解及應(yīng)用17.1 引 言7.2 需求測試的概念7.2.1 為什么要引入需求測試7.2.2 需求工程師對用戶需求的誤解2 客戶是這樣描述需求的 項(xiàng)目經(jīng)理是這么理解的 分析師是這么設(shè)計(jì)的 程序員是這么編寫的 商業(yè)顧問是這么描繪的 項(xiàng)目書寫出來是這樣的 操作中用了這樣的工具 客戶是這么建造的 提供的支持就這個(gè)樣子 而這才是 客戶真正需要的 圖7-1 關(guān)于信息傳遞的漫畫7.2.3 軟件缺陷的主要來源7.3 如何實(shí)施需求測試7.3.1 需求測試的手段7.3.2 需求評審7.3.3 需求測試3 5 6 % 2 7 % 1 0 % 7 % 需 求 設(shè) 計(jì) 編 碼 其 他 圖7-2 來源于錯(cuò)誤的

2、需求導(dǎo)致的缺陷所占的比例7.3.4 需求規(guī)格說明書的檢查步驟需求規(guī)格說明書的測試步驟如圖7-3所示。4 需求規(guī)格說明 原始需求文檔 檢查列表 嘗試?yán)斫?討論、評審、修訂 圖7-3 需求規(guī)格說明書測試步驟第1步：獲取最新版本的軟件需求規(guī)格說明書，同時(shí)盡量取得用戶原始需求文檔。第2步：閱讀和嘗試?yán)斫廛浖枨笠?guī)格說明書描述的所有需求項(xiàng)。第3步：對照軟件需求規(guī)格說明書評審檢查單（SRS Review Checklist）進(jìn)行檢查并記錄。第4步：針對檢查結(jié)果進(jìn)行討論、修訂軟件需求規(guī)格說明書后回到第1步，直到評審檢查單的所有項(xiàng)通過。57.4 其他測試需求的方法7.4.1 通過用戶調(diào)查來測試需求7.4.2

3、通過設(shè)計(jì)測試用例來測試需求7.4.3 利用現(xiàn)存的產(chǎn)品對需求進(jìn)行測試軟件測試技術(shù)詳解及應(yīng)用78.1 引 言8.2 單元測試的定義8.2.1 單元測試的目標(biāo) 8.2.2 單元測試的過程8.2.3 單元測試的內(nèi)容8.2.4 單元測試的意義8.2.5 單元測試用例設(shè)計(jì) 1）設(shè)計(jì)一個(gè)能使系統(tǒng)運(yùn)行的測試用例：該測試用例一般使用最簡單的方法測試被測單元。通過執(zhí)行這個(gè)用例，能夠確定測試環(huán)境和測試單元是否具有可用性。2）設(shè)計(jì)測試功能的正向測試用例：閱讀相關(guān)的設(shè)計(jì)說明，每一個(gè)測試用例都是有針對性的測試說明書中的一項(xiàng)或者多項(xiàng)內(nèi)容，用以驗(yàn)證設(shè)計(jì)說明書所對應(yīng)的功能是否實(shí)現(xiàn)。3）設(shè)計(jì)測試功能的反向測試用例：用可能導(dǎo)致模塊

4、功能失效的無效數(shù)據(jù)，測試模塊對無效數(shù)據(jù)的反應(yīng)是否合理，對異?；蝈e(cuò)誤的處理后，模塊反應(yīng)如何，驗(yàn)證模塊是否做了不應(yīng)該做的工作。4）設(shè)計(jì)其他的測試用例驗(yàn)證設(shè)計(jì)對模塊的要求。5）加載測試用例運(yùn)行程序，查看和記錄測試結(jié)果，尤其注意測試結(jié)果與預(yù)期結(jié)果不一致的情況。6）補(bǔ)充測試用例，執(zhí)行前面測試用例運(yùn)行沒有覆蓋到的分支和語句。8.2.6 單元測試評審 8.3 單元測試規(guī)程單元測試規(guī)程包括靜態(tài)的代碼審查和動(dòng)態(tài)測試兩個(gè)階段。代碼審查是按照代碼審查單中的條項(xiàng)對單元模塊進(jìn)行逐項(xiàng)檢查，并填寫單元測試缺陷清單。8.3 單元測試規(guī)程動(dòng)態(tài)測試階段首先編寫驅(qū)動(dòng)模塊（或主類）和樁模塊后，在驅(qū)動(dòng)模塊和樁模塊中設(shè)計(jì)相應(yīng)的測試用例，

5、對所有的測試用例進(jìn)行統(tǒng)一編號，在源代碼中進(jìn)行注釋標(biāo)識。測試用例應(yīng)該覆蓋單元模塊的所有功能項(xiàng)，如果單元模塊有性能、余量等其他測試特性要求，則必須設(shè)計(jì)相應(yīng)的測試用例測試這些特性，編制完測試用例后，把測試用例提交給配置管理員或測試主管進(jìn)行審查，審查沒有通過則根據(jù)審查意見進(jìn)行修改，直到審查通過后測試人員加載測試用例，編譯運(yùn)行得到測試結(jié)果，比對測試結(jié)果，如果發(fā)現(xiàn)錯(cuò)誤或缺陷則需要填寫單元測試缺陷清單并提交給測試經(jīng)理和配置管理人員。8.3 單元測試規(guī)程在進(jìn)行功能測試時(shí)，可以利用其他測試工具進(jìn)行內(nèi)存溢出分析、代碼覆蓋率分析、代碼性能測試等。軟件測試技術(shù)詳解及應(yīng)用139.1 引 言在上一章介紹單元測試的方法時(shí)，

6、已經(jīng)提到，靜態(tài)測試技術(shù)是單元測試階段常用的早期測試技術(shù)之一。通過靜態(tài)測試，可以發(fā)現(xiàn)程序代碼中隱藏的問題，在這一章將具體介紹軟件靜態(tài)測試技術(shù)。9.2 靜態(tài)測試與動(dòng)態(tài)測試靜態(tài)測試1.動(dòng)態(tài)測試9.3 桌 面 檢 查9.3.1 桌面檢查的概念 桌面檢查是一種傳統(tǒng)的檢查方法，由程序員自己檢查自己編寫的程序。程序員在程序通過編譯之后，進(jìn)行單元測試設(shè)計(jì)之前，對源程序代碼進(jìn)行分析，對照錯(cuò)誤列表進(jìn)行檢查，對程序推演測試數(shù)據(jù)，并補(bǔ)充相關(guān)的文檔。目的是發(fā)現(xiàn)程序中的錯(cuò)誤。9.3.2 桌面檢查的項(xiàng)目9.4 代 碼 檢 查9.4.1 代碼檢查的概念9.4.2 角色和職責(zé)9.4.3 代碼檢查的過程9.4.4 用于代碼檢查的

7、錯(cuò)誤列表9.5 走 查9.5.1 走查的概念 走查與代碼檢查很相似，是以小組為單位進(jìn)行的，是一系列規(guī)程和錯(cuò)誤檢查技術(shù)的集合。走查的過程與代碼檢查大體相同，但是規(guī)程稍微有所不同，采用的錯(cuò)誤檢查技術(shù)也不一樣。 走查的目的是要評價(jià)一個(gè)產(chǎn)品，通常是程序代碼。走查一直以來都與代碼檢查聯(lián)系在一起，其實(shí)走查也可以應(yīng)用到產(chǎn)品的其他階段，如結(jié)構(gòu)設(shè)計(jì)、詳細(xì)設(shè)計(jì)、測試計(jì)劃等文檔上。走查最主要的目標(biāo)是要發(fā)現(xiàn)缺陷、遺漏和矛盾的地方；改進(jìn)產(chǎn)品；考慮可替換的實(shí)現(xiàn)方法。 走查還有其他的一些目的，包括技術(shù)交流、參與人員的技術(shù)培訓(xùn)、設(shè)計(jì)思想的介紹等。走查可以指出代碼中效率和可讀性方面的問題，設(shè)計(jì)或不可測試設(shè)計(jì)規(guī)格中的構(gòu)件應(yīng)用問題

8、。9.5.2 角色和職能9.5.3 走查的過程9.5.4 走查中的靜態(tài)分析技術(shù) READY A Y0? XXY XY B C D 真 假 圖9-1 一個(gè)典型的控制流程圖 Y0? XY X0? 調(diào)用函數(shù) P READY A 真 假 B 假 E 真 D C 圖9-2 調(diào)用圖分析 q 能整除 p? 假 t?; p?; q?; READ(p); READ(q);?; tq;mod q; 假 打印 q; tp; pq? pq;qt; 真 真 1: 2: 3: 4: 5: 6: 7: 圖9-3 數(shù)據(jù)流分析9.6 同 行 評 審9.6.1 同行評審的概念9.6.2 角色和職能9.6.3 同行評審的內(nèi)容1. 管理評審 質(zhì)量部門制定管理評審計(jì)劃 管理評審計(jì)劃的公告、下發(fā) 按管理評審計(jì)劃，組織相關(guān)部門， 組織相應(yīng)材料 召開管理評審會議，指出糾正預(yù)防措施 相關(guān)部門按照糾正預(yù)防措施，實(shí)施