軟件測試過程方法

1、軟件測試技術(shù)2.1 全過程的軟件測試方法概述2.2 軟件測試的過程簡介2.3 單元測試過程技術(shù)2.4 集成測試過程技術(shù)2.5 系統(tǒng)測試過程技術(shù)2.6 其它測試過程技術(shù)第四章第四章 軟件測試過程方法軟件測試過程方法4.1 4.1 軟件測試過程方法概述軟件測試過程方法概述工程碩士4經(jīng)典的瀑布模型-測試是亡羊補(bǔ)牢需求分析需求分析概要設(shè)計(jì)概要設(shè)計(jì)詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼編碼系統(tǒng)測試系統(tǒng)測試測試測試單元測試單元測試集成測試集成測試維護(hù)維護(hù)驗(yàn)收測試驗(yàn)收測試測試是軟件開發(fā)的最后階段。當(dāng)測試發(fā)現(xiàn)了需求的問題時(shí)，可能導(dǎo)致工作產(chǎn)品的大量返工，產(chǎn)品交付將因此延期。而這種情況在實(shí)際的測試工作中經(jīng)常發(fā)生。工程碩士5V模型-

2、全流程的測試思想需求規(guī)格說明書需求規(guī)格說明書評審評審概要設(shè)計(jì)說明書概要設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)說明書編碼編碼單元測試單元測試集成測試集成測試系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試文檔系統(tǒng)測試文檔集成測試文檔集成測試文檔單元測試文檔單元測試文檔評審評審評審評審評審評審評審評審評審評審工程碩士6V模型全過程軟件測試的思想l在瀑布模型中，測試是軟件開發(fā)過程的最后階段，而在V模型中，軟件測試從軟件項(xiàng)目需求分析階段開始，貫穿于整個軟件開發(fā)過程活動中l(wèi)測試人員可以盡早進(jìn)入項(xiàng)目1.測試人員更加熟悉產(chǎn)品，對設(shè)計(jì)出高質(zhì)量的測試用例非常有幫助2.更多缺陷將在早期被發(fā)現(xiàn)，這有利于大幅度降低成本l在項(xiàng)目后期發(fā)現(xiàn)嚴(yán)重缺陷的風(fēng)

3、險(xiǎn)大大降低l很多組織選用V模型作為項(xiàng)目的開發(fā)模型全過程測試軟件過程規(guī)范示例工程碩士7業(yè)務(wù)計(jì)劃制定業(yè)務(wù)計(jì)劃制定產(chǎn)品計(jì)劃（軟件計(jì)劃）產(chǎn)品計(jì)劃（軟件計(jì)劃）產(chǎn)品規(guī)格制定產(chǎn)品規(guī)格制定需求分析（需求分析（SDPSDP優(yōu)化）優(yōu)化）概要設(shè)計(jì)概要設(shè)計(jì)詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)實(shí)現(xiàn)和單元測試實(shí)現(xiàn)和單元測試集成測試（執(zhí)行）集成測試（執(zhí)行）系統(tǒng)測試（執(zhí)行）系統(tǒng)測試（執(zhí)行）驗(yàn)收測試（執(zhí)行）驗(yàn)收測試（執(zhí)行）產(chǎn)品維護(hù)產(chǎn)品維護(hù)單元測試參考詳細(xì)設(shè)計(jì)集成測試參考概要設(shè)計(jì)系統(tǒng)測試參考需求規(guī)格說明書全過程測試軟件過程規(guī)范示例工程碩士8l系統(tǒng)需求系統(tǒng)需求l制訂業(yè)務(wù)計(jì)劃制訂業(yè)務(wù)計(jì)劃l業(yè)務(wù)計(jì)劃業(yè)務(wù)計(jì)劃l系統(tǒng)需求系統(tǒng)需求l分配系統(tǒng)需求分配系統(tǒng)需求l軟

4、件子系統(tǒng)需求軟件子系統(tǒng)需求l驗(yàn)收測試項(xiàng)驗(yàn)收測試項(xiàng)l軟件子系統(tǒng)需求軟件子系統(tǒng)需求lSDPSDPl制訂和確認(rèn)制訂和確認(rèn)SVVPSVVPlSVVPSVVPl軟件子系統(tǒng)需求軟件子系統(tǒng)需求lSDPSDPlSVVPSVVPlSDPSDP優(yōu)化優(yōu)化l制訂和確認(rèn)系統(tǒng)測試計(jì)劃制訂和確認(rèn)系統(tǒng)測試計(jì)劃lSVVPSVVP優(yōu)化優(yōu)化l系統(tǒng)測試計(jì)劃系統(tǒng)測試計(jì)劃業(yè)務(wù)計(jì)劃制定業(yè)務(wù)計(jì)劃制定產(chǎn)品計(jì)劃（軟件計(jì)劃）產(chǎn)品計(jì)劃（軟件計(jì)劃）產(chǎn)品規(guī)格制定產(chǎn)品規(guī)格制定需求分析（需求分析（SDPSDP優(yōu)化）優(yōu)化）全過程測試軟件過程規(guī)范示例工程碩士9l單元測試計(jì)劃單元測試計(jì)劃l集成測試方案集成測試方案l系統(tǒng)測試用例系統(tǒng)測試用例l系統(tǒng)預(yù)測試用例系統(tǒng)預(yù)測

5、試用例lSRSlSTPl編寫系統(tǒng)編寫系統(tǒng) 測試方案測試方案l制定和確認(rèn)集成測試計(jì)劃制定和確認(rèn)集成測試計(jì)劃l集成測試計(jì)劃集成測試計(jì)劃l系統(tǒng)測試方案系統(tǒng)測試方案概要設(shè)計(jì)概要設(shè)計(jì)l需求規(guī)格說明書需求規(guī)格說明書l概要設(shè)計(jì)說明書概要設(shè)計(jì)說明書l系統(tǒng)測試計(jì)劃、方案系統(tǒng)測試計(jì)劃、方案l集成測試計(jì)劃集成測試計(jì)劃l編寫系統(tǒng)測試用例編寫系統(tǒng)測試用例l編寫系統(tǒng)預(yù)測試項(xiàng)編寫系統(tǒng)預(yù)測試項(xiàng)l編寫集成測試方案編寫集成測試方案l制定和確認(rèn)單元測試計(jì)劃制定和確認(rèn)單元測試計(jì)劃l進(jìn)行軟件測試測試工具評估進(jìn)行軟件測試測試工具評估詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)l需求規(guī)格說明書需求規(guī)格說明書l概要設(shè)計(jì)說明書概要設(shè)計(jì)說明書l詳細(xì)設(shè)計(jì)說明書詳細(xì)設(shè)計(jì)說明書

6、l系統(tǒng)測試計(jì)劃、方案、用例系統(tǒng)測試計(jì)劃、方案、用例l集成測試計(jì)劃、方案集成測試計(jì)劃、方案l單元測試計(jì)劃單元測試計(jì)劃l編寫系統(tǒng)測試用例編寫系統(tǒng)測試用例l編寫集成測試用例編寫集成測試用例l編寫單元測試方案、用例編寫單元測試方案、用例l執(zhí)行單元測試執(zhí)行單元測試l單元測試方案、報(bào)告單元測試方案、報(bào)告l集成測試用例集成測試用例實(shí)現(xiàn)和單元測試實(shí)現(xiàn)和單元測試全過程測試軟件過程規(guī)范示例工程碩士10l單元測試報(bào)告單元測試報(bào)告l集成測試計(jì)劃集成測試計(jì)劃l集成測試方案集成測試方案l集成測試用例集成測試用例l執(zhí)行集成測試執(zhí)行集成測試l集成測試報(bào)告集成測試報(bào)告l集成測試報(bào)告集成測試報(bào)告l系統(tǒng)測試計(jì)劃系統(tǒng)測試計(jì)劃l系統(tǒng)測

7、試方案系統(tǒng)測試方案l系統(tǒng)測試用例系統(tǒng)測試用例l系統(tǒng)預(yù)測試項(xiàng)系統(tǒng)預(yù)測試項(xiàng)l執(zhí)行系統(tǒng)預(yù)測試執(zhí)行系統(tǒng)預(yù)測試l轉(zhuǎn)系統(tǒng)測試轉(zhuǎn)系統(tǒng)測試l執(zhí)行系統(tǒng)測試執(zhí)行系統(tǒng)測試l系統(tǒng)預(yù)測試、報(bào)告系統(tǒng)預(yù)測試、報(bào)告l系統(tǒng)測試報(bào)告系統(tǒng)測試報(bào)告l安裝包安裝包l用戶文檔用戶文檔l用戶數(shù)據(jù)用戶數(shù)據(jù)l驗(yàn)收測試項(xiàng)驗(yàn)收測試項(xiàng)l執(zhí)行驗(yàn)收測試執(zhí)行驗(yàn)收測試l驗(yàn)收測試報(bào)告驗(yàn)收測試報(bào)告l安裝包安裝包l用戶文檔用戶文檔l用戶數(shù)據(jù)用戶數(shù)據(jù)l維護(hù)計(jì)劃維護(hù)計(jì)劃集成測試（執(zhí)行）集成測試（執(zhí)行）系統(tǒng)測試（執(zhí)行）系統(tǒng)測試（執(zhí)行）驗(yàn)收測試（執(zhí)行）驗(yàn)收測試（執(zhí)行）產(chǎn)品維護(hù)產(chǎn)品維護(hù)工程碩士11全過程測試軟件過程規(guī)范示例制定制定軟軟件件驗(yàn)證驗(yàn)證和確和確認(rèn)計(jì)劃認(rèn)計(jì)劃（So

8、ftware Verification and Validation Plan SVVP）單單元元測試過測試過程程 涉及詳細(xì)設(shè)計(jì)，實(shí)現(xiàn)和單元測試兩個階段 過程定義內(nèi)容：各種角色職責(zé)、 進(jìn)入準(zhǔn)則、 輸入、步驟、 輸出集成集成測試過測試過程程 涉及概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)，實(shí)現(xiàn)和單元測試以及集成測試等階段 過程定義內(nèi)容：各種角色職責(zé)、 進(jìn)入準(zhǔn)則、 輸入、步驟、 輸出系系統(tǒng)測試過統(tǒng)測試過程程 涉及需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)和單元測試以及系統(tǒng)測試執(zhí)行等階段 過程定義內(nèi)容：各種角色職責(zé)、 進(jìn)入準(zhǔn)則、 輸入、步驟、 輸出4.2 4.2 軟件測試的過程簡介軟件測試的過程簡介工程碩士13測試過程（階段）規(guī)格

9、定義設(shè)計(jì)編碼系統(tǒng)測試集成測試單元測試用戶需求驗(yàn)收測試回歸測試配置管理缺陷跟蹤 工程碩士14軟件開發(fā)過程中的測試執(zhí)行過程 分為以下幾個階段： 單元測試：測試程序最小單位有無錯誤，單元可以是一個或一組過程（函數(shù)）、菜單、類等。 集成測試：將單元集成起來測試它們之間的交互。 系統(tǒng)測試：在一個完整的系統(tǒng)上執(zhí)行測試，評價(jià)系統(tǒng)是否滿足對規(guī)格說明書的要求。工程碩士15不同階段的缺陷修復(fù)成本不同階段的缺陷修復(fù)成本l上圖表明上圖表明l缺陷發(fā)現(xiàn)得越晚，它的修復(fù)成本可能是數(shù)十倍的上升l結(jié)論結(jié)論 l為了降低軟件開發(fā)成本并交付高質(zhì)量產(chǎn)品，啟動測試越早越好工程碩士16不同階段測試相同功能的成本不同階段測試相同功能的成本l

10、上圖表明上圖表明l在不同的測試階段，測試同樣功能的測試成本有數(shù)倍差異l結(jié)論結(jié)論l為了降低測試成本，提高測試效率，最好隨著軟件開發(fā)過程一步步測試產(chǎn)品，也就是從單元測試到系統(tǒng)測試依次進(jìn)行工程碩士17測試過程單元測試 單元測試（Unit Testing） 目標(biāo)：(1) 檢驗(yàn)程序最小單元有無錯誤(2) 檢驗(yàn)單元編碼與設(shè)計(jì)是否吻合 時(shí)機(jī)：編碼完成后，首先要實(shí)施的測試 方法：黑盒測試白盒測試 責(zé)任：開發(fā)工程師接口數(shù)據(jù)結(jié)構(gòu)邊界覆蓋邏輯工程碩士18測試過程集成測試 集成測試（Integration Testing） 目標(biāo)：(1) 檢驗(yàn)組成系統(tǒng)的模塊接口有無錯誤(2) 代碼實(shí)現(xiàn)的系統(tǒng)設(shè)計(jì)與需求定義是否吻合 時(shí)機(jī)

11、：主要的單元測試完成后，經(jīng)常與單元測試同步進(jìn)行 方法：黑盒測試/白盒測試 責(zé)任：開發(fā)工程師測試工程師工程碩士19測試過程系統(tǒng)測試 系統(tǒng)測試（System Testing） 目標(biāo)：(1) 檢驗(yàn)組成整個系統(tǒng)的代碼、以及系統(tǒng)的軟硬件配合有無錯誤(2) 代碼實(shí)現(xiàn)的系統(tǒng)與用戶需求是否吻合(3) 檢驗(yàn)系統(tǒng)的文檔等各種是否完整、有效(4) 模擬驗(yàn)收測試的要求，檢查系統(tǒng)是否符合用戶的驗(yàn)收標(biāo)準(zhǔn) 時(shí)機(jī)：多數(shù)集成測試完成后 方法：黑盒測試 責(zé)任：測試工程師工程碩士20測試過程驗(yàn)收測試 驗(yàn)收測試（Acceptance Testing） 目標(biāo)：使客戶驗(yàn)收簽字系統(tǒng)是否符合事先約定的驗(yàn)收標(biāo)準(zhǔn) 時(shí)機(jī)：系統(tǒng)測試完成后，在項(xiàng)目組

12、看來開發(fā)和測試工作已經(jīng)全部完成，可以交付使用 方法：黑盒測試責(zé)任：產(chǎn)品經(jīng)理或其他高級經(jīng)理開發(fā)工程師測試工程師用戶工程碩士21測試過程回歸測試 回歸測試（Regression Testing） 目標(biāo)：驗(yàn)證程序修改或者版本更新以后，以前正確的功能和其他指標(biāo)仍舊正確。 時(shí)機(jī)：每次錯誤修改之后，或者版本更新之后 方法：白盒測試/黑盒測試 責(zé)任：開發(fā)工程師測試工程師工程碩士22測試過程缺陷跟蹤 缺陷跟蹤（Defect Tracing） 目標(biāo)：確保所有發(fā)現(xiàn)的錯誤被正確記錄、分發(fā)、評估、關(guān)閉、統(tǒng)計(jì) 時(shí)機(jī)：從錯誤發(fā)現(xiàn)開始到錯誤關(guān)閉為止，每次錯誤狀態(tài)修改之后 方法：缺陷跟蹤系統(tǒng) 責(zé)任：開發(fā)工程師測試工程師測試經(jīng)

13、理用戶4.3 4.3 單元測試過程技術(shù)單元測試過程技術(shù)相關(guān)概念單元測試用例設(shè)計(jì)及其實(shí)現(xiàn)單元測試環(huán)境單元測試執(zhí)行及其工具M(jìn)odule to be tested 4.3.1 4.3.1 單元測試的基本概念單元測試的基本概念 一、一、單元測試的含義 單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，或者說是針對軟件設(shè)計(jì)的最小單位程序模塊，進(jìn)行正確性檢驗(yàn)的測試工作。其目的在于發(fā)現(xiàn)每個程序模塊內(nèi)部可能存在的差錯。 對軟件的基本組成單元進(jìn)行的測試，檢驗(yàn)程序最小單位有無錯誤。一般在編碼之后，由開發(fā)人員完成。 二二、單元的含義 單元是軟件開發(fā)中的最小的獨(dú)立部分，具有一些基本屬性，可清晰的與同一程序中的其他

14、單元劃分開來。 沒有精確的概念，可以小到一條語句，也可以大到多個模塊的組合； 傳統(tǒng)上，認(rèn)為一個函數(shù)、子過程、菜單、一個界面、一個類是一個單元； 單元的最顯著的特征就是可以作為一個整體； 例如：C語言中的單元可以是函數(shù)或者子過程；C+語言中的單元通常是類。 三、單元測試步驟與分工三、單元測試步驟與分工 在單元測試活動中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試，主要工作分為兩個步驟：人工靜態(tài)檢查和動態(tài)執(zhí)行跟蹤。前者是盡可能地發(fā)現(xiàn)程序中沒有發(fā)現(xiàn)的錯誤，后者是跟蹤比較實(shí)際結(jié)果與預(yù)期結(jié)果來發(fā)現(xiàn)錯誤。 單元測試的分工大致如下：一般由開發(fā)組在開發(fā)組組長監(jiān)督下進(jìn)行，保證使用合適的測試技術(shù)，根

15、據(jù)單元測試計(jì)劃和測試說明文檔中制定的要求，執(zhí)行充分的測試；由編寫該單元的開發(fā)組中的成員設(shè)計(jì)所需要的測試用例，測試該單元并修改缺陷。 四、單元測試的目標(biāo)四、單元測試的目標(biāo)（P101P101）檢查代碼實(shí)現(xiàn)是否符合設(shè)計(jì)不能檢查設(shè)計(jì)是否正確盡早發(fā)現(xiàn)錯誤Microsoft applicationsMicrosoft applications 10-20 10-20 defects/KLOC during unit testingdefects/KLOC during unit testing 0.5 defects/KLOC after release0.5 defects/KLOC after rel

16、ease性價(jià)比最好 五五、單元測試誤區(qū)單元測試誤區(qū) 1、單元測試是一種浪費(fèi)時(shí)間的工作 2、單元測試只能證明代碼做了什么 3、我是個很棒的程序員， 我是不是可以不進(jìn)行單元測試？ 4、集成測試能捕捉到所有的Bug 5、單元測試的成本效率不高 目前狀況： 實(shí)施效果非常好，但是實(shí)施阻力比較大(主要是人員和管理因素)，一般只在關(guān)鍵的程序單元中實(shí)施 有比較系統(tǒng)的理論和方法，但也依賴于系統(tǒng)的特殊性和開發(fā)人員的經(jīng)驗(yàn) 有大量的輔助工具，開發(fā)人員也經(jīng)常自己開發(fā)測試代碼和測試工具 主要使用白盒測試和靜態(tài)分析，也使用黑盒測試;工程碩士3.2、單元測試的內(nèi)容與出發(fā)點(diǎn)、單元測試的內(nèi)容與出發(fā)點(diǎn) 一、單元測

17、試的內(nèi)容單元測試的內(nèi)容 1.模塊接口測試（P112）數(shù)據(jù)在接口處出錯就好像丟掉了進(jìn)入大門的鑰匙，無法進(jìn)行下一步的工作，只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。 2.模塊局部數(shù)據(jù)結(jié)構(gòu)測試（P112） 局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，對其檢查主要是為了保證臨時(shí)存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確，因此應(yīng)仔細(xì)設(shè)計(jì)測試用例。 32 3.模塊邊界條件測試（P110） 邊界條件是指軟件計(jì)劃的操作界限所在的邊緣條件。邊界條件測試是單元測試中最后也是最重要的一項(xiàng)任務(wù)。在使用邊界值測試的方法時(shí)，不妨結(jié)合實(shí)際項(xiàng)目參考以下測試技巧：輸入了完全偽造或者和要求不一致的數(shù)據(jù)。 1）輸入一個格式錯誤

18、的數(shù)據(jù)。 2）提供一個空值或者不完整的值。 3）與意料之中的值相差很遠(yuǎn)的值。 33 4）假如一個列表中不允許有重復(fù)的數(shù)值存在，就可以給它傳入一組存在重復(fù)數(shù)值的列表；如果某個字段的值要求唯一，那么可以輸入兩個或多個相同的數(shù)值來進(jìn)行測試。 5）假如一個列表中不允許有重復(fù)的數(shù)值存在，就可以給它傳入一組存在重復(fù)數(shù)值的列表；如果某個字段的值 要求唯一，那么可以輸入兩個或多個相同的數(shù)值來進(jìn)行測試。 6） 如果要求按照一定的順序來存儲一些數(shù)據(jù)，那么可以輸入一些順序打亂的數(shù)據(jù)來做測試。 7）對于一些做了安全限制的部分，盡量通過各種途徑嘗試能否繞過安全限制的測試。 8） 如果功能的啟用有一定的順序限制，就用和期

19、望不一致的順序來進(jìn)行測試。34 4.模塊獨(dú)立執(zhí)行路徑測試（P112） 在模塊中應(yīng)對每一條獨(dú)立執(zhí)行路徑進(jìn)行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。 5.模塊內(nèi)部錯誤處理測試 二、單元測試的出發(fā)點(diǎn)單元測試的出發(fā)點(diǎn) 1、判斷得到的結(jié)果是否正確？ 因?yàn)?，對于測試而言，首要的任務(wù)就是察看一下所期望的結(jié)果是否正確，即對結(jié)果進(jìn)行驗(yàn)證。 2、分析能否使用反向關(guān)聯(lián)檢查？ 在實(shí)際程序中，有一些方法可以使用反向的邏輯關(guān)系來驗(yàn)證它們。 3、分析是否能使用其他手段來交叉檢查一下結(jié)果？ 一般而言，對某個值進(jìn)行計(jì)算會有一種以上的算法，但我們會因考慮到運(yùn)行效率或其他方面的原因而選擇其中的一種。 4、分析是否

20、可以強(qiáng)制一些錯誤發(fā)生？ 5、分析出錯處理是否正確？ 一個好的設(shè)計(jì)應(yīng)能預(yù)見各種出錯條件，并進(jìn)行適當(dāng)?shù)某鲥e處理，即預(yù)設(shè)各種出錯處理通路。 4.3.3 4.3.3 單元測試與系統(tǒng)集成測試區(qū)別單元測試與系統(tǒng)集成測試區(qū)別 一、單元測試與集成測試區(qū)別一、單元測試與集成測試區(qū)別 單元測試與集成測試的主要區(qū)別在于測試的對象不同。單元測試對象是實(shí)現(xiàn)具體功能的單元，一般對應(yīng)詳細(xì)設(shè)計(jì)中所描述的設(shè)計(jì)單元。集成測試是針對概要設(shè)計(jì)所包含的模塊以及模塊組合進(jìn)行的測試。 單元測試所使用的主要測試方法是基于代碼的白盒測試。而集成測試所使用的主要測試方法是基于功能的黑盒測試。 因?yàn)榧蓽y試要在所有要集成的模塊都通過了單元測試之后

21、才能進(jìn)行，也就是說在測試時(shí)間上，集成測試要晚于單元測試，所以單元測試的好壞直接影響著集成測試。 單元測試的工作內(nèi)容包括模塊內(nèi)程序的邏輯、功能、參數(shù)傳遞、變量引用、出錯處理、需求和設(shè)計(jì)中有具體的要求等方面測試。集成測試的工作內(nèi)容主要是驗(yàn)證各個接口、接口之間的數(shù)據(jù)傳遞關(guān)系、模塊組合后能否達(dá)到預(yù)期效果。 雖然單元測試和集成測試有一些區(qū)別，但是二者之間也有著千絲萬縷的聯(lián)系。目前集成測試和單元測試的界限趨向模糊。 二二、單元測試與系統(tǒng)測試區(qū)別單元測試與系統(tǒng)測試區(qū)別 單元測試與系統(tǒng)測試的區(qū)別不僅僅在于測試的對象和測試的層次的不同，最重要的區(qū)別是測試性質(zhì)不同。在單元測試過程中，單元測試的執(zhí)行早于系統(tǒng)測試，測

22、試的是軟件單元的具體實(shí)現(xiàn)、內(nèi)部邏輯結(jié)構(gòu)以及數(shù)據(jù)流向等。系統(tǒng)測試屬于后期測試，主要是根據(jù)需求規(guī)格說明書進(jìn)行的，是從用戶角度來進(jìn)行的功能測試和性能測試等等，證明系統(tǒng)是否滿足用戶的需求。 單元測試中發(fā)現(xiàn)的錯誤容易進(jìn)行定位，并且多個單元測試可以并行進(jìn)行；而系統(tǒng)測試發(fā)現(xiàn)的錯誤比較難定位。Unit Test Environment工程碩士40 驅(qū)動器：替代調(diào)用被測模塊的模塊功能。一般只是一個接收測試數(shù)據(jù)，并將測試數(shù)據(jù)傳送給被測模塊，然后打印相關(guān)結(jié)果的“主程序”。 樁：替代被測模塊所調(diào)用模塊，需要使用子模塊間的接口。 4.3.4 4.3.4 單單元元測試環(huán)測試環(huán)境境 由于一個模塊或一個方法（Method）并

23、不是一個獨(dú)立的程序，在考慮測試它時(shí)要同時(shí)考慮它和外界的聯(lián)系，因此要用到一些輔助模塊，來模擬與所測模塊相聯(lián)系的其他模塊。一般把這些輔助模塊分為兩種： 1、驅(qū)動模塊（driver）:相當(dāng)于所測模塊的主程序。 2、樁模塊（stub）:用于代替所測模塊調(diào)用的子模塊。 那么，所測模塊和與它相關(guān)的驅(qū)動模塊及樁模塊共同構(gòu)成了一個“測試環(huán)境”，如圖3-2所示。被測單元驅(qū)動模塊樁模塊1樁模塊樁模塊N測試結(jié)果測試用例圖3-2 單元測試環(huán)境4.3.5 4.3.5 單元測試策略單元測試策略 單元測試包括：一是針對被測單元需求的功能測試，二是用于代碼評審和代碼走讀的靜態(tài)測試、白盒測試、狀態(tài)轉(zhuǎn)換測試和非功能測試。 為了提

24、高單元測試的質(zhì)量，只了解這些單元測試技術(shù)還遠(yuǎn)遠(yuǎn)不夠，還要選擇合適的測試策略。在選擇測試策略時(shí)，主要考慮如下3種方式：自頂向下（Top Down Unit Testing）的單元測試策略、自底向上的單元測試策略（Bottom up Unit Testing）和孤立的單元測試策略。 一一、自頂向下單元測試策略自頂向下單元測試策略 1、步驟 1)從最頂層開始，把頂層調(diào)用的單元做成樁模塊。 2)對第二層測試，使用上面已測試的單元做驅(qū)動模塊。 3)依次類推，直到全部單元測試結(jié)束。 先對最頂層的單元進(jìn)行測試，把頂層所調(diào)用的單元做成樁模塊，其次對第二層進(jìn)行測試，使用上面已測試的單元作驅(qū)動。以此類推直到完成所

25、有模塊。樁: 替代被測單元所調(diào)用模塊的模塊單元輔助測試模塊。 2、優(yōu)點(diǎn) 可以在集成測試之前為系統(tǒng)提供早期的集成途徑。(提供較早的集成路徑) 3、缺點(diǎn) 單元測試被樁模塊控制，隨著單元測試的不斷進(jìn)行，測試過程也會變得越來越復(fù)雜，測試難度以及開發(fā)和維護(hù)的成本都不斷增加。(同詳細(xì)設(shè)計(jì)順序一樣，越到下層測試過程越復(fù)雜，并行性不好，測試周期長，任何一單元的修改都將影響其相關(guān)單元被重新測試。) 要求的低層次的結(jié)構(gòu)覆蓋率也難以得到保證；由于需求變更或其他原因而必須更改任何一個單元時(shí)，就必須重新測試該單元下層調(diào)用的所有單元；低層單元測試依賴頂層測試，無法進(jìn)行并行測試，使測試進(jìn)度受到不同程度的影響，延長測試周期。

26、 從上述分析中，不難看出該測試策略的成本要高于孤立的單元測試成本，因此從測試成本方面來考慮，并不是最佳的單元測試策略。二二、自底向上的單元測試自底向上的單元測試 1.步驟： 1)先對模塊調(diào)用圖上的最底層模塊開始測試，模擬調(diào)用該模塊的模塊為驅(qū)動模塊。 2)對上一層模塊進(jìn)行單元測試，用已經(jīng)被測試過的模塊做樁模塊。 3)依次類推，直到全部單元測試結(jié)束。 先對最底層的單元進(jìn)行測試，把調(diào)用該單元的模塊做成驅(qū)動模塊，其次對上層進(jìn)行測試，使用下面已測試的單元作樁。以此類推直到完成所有模塊； 驅(qū)動：替代調(diào)用被測單元的模塊功能的模塊。 2)優(yōu)點(diǎn) 不需要單獨(dú)設(shè)計(jì)樁模塊。(提供較早的集成路徑) 3）缺點(diǎn) 隨著單元測

27、試的不斷進(jìn)行，測試過程會變得越來越復(fù)雜，測試周期延長，測試和維護(hù)的成本增加；隨著各個基本單元逐步加入，系統(tǒng)會變得異常龐大，因此測試人員不容易控制；越接近頂層的模塊的測試其結(jié)構(gòu)覆蓋率就越難以保證； 另外，頂層測試易受底層模塊變更的影響，任何一個模塊修改之后，直接或間接調(diào)用該模塊的所有單元都要重新測試。 同詳細(xì)設(shè)計(jì)順序一樣，越到上層測試過程越復(fù)雜，并行性不好，測試周期長，任何一單元的修改都將影響其相關(guān)單元被重新測試。 由于只有在底層單元測試完畢之后才能夠進(jìn)行頂層單元的測試，所以并行性不好。另外，自底向上的單元測試也不能和詳細(xì)設(shè)計(jì)、編碼同步進(jìn)行。 總結(jié)：相對其它測試策略而言，該測試策略比較合理,尤其

28、是需要考慮對象或復(fù)用時(shí)。它屬于面向功能的測試，而非面向結(jié)構(gòu)的測試。對那些以高覆蓋率為目標(biāo)或者軟件開發(fā)時(shí)間緊張的軟件項(xiàng)目來說，這種測試方法不適用。工程碩士50ADBCEFCd1s1Ds2Bd2d3As3s4s5單元測試進(jìn)程策略 例： 三三、孤立測試孤立測試 1.步驟 無需考慮每個模塊與其他模塊之間的關(guān)系，分別為每個模塊單獨(dú)設(shè)計(jì)樁模塊和驅(qū)動模塊，逐一完成所有單元模塊的測試。 2.優(yōu)點(diǎn)：該方法簡單、容易操作，因此所需測試時(shí)間短，能夠達(dá)到高覆蓋率。 3.缺點(diǎn)：不能為集成測試提供早期的集成途徑。依賴結(jié)構(gòu)設(shè)計(jì)信息，需要設(shè)計(jì)多個樁模塊和驅(qū)動模塊，增加了額外的測試成本。 總結(jié)：該方法是比較理想的單元測試方法。

29、如輔助適當(dāng)?shù)募蓽y試策略，有利于縮短項(xiàng)目的開發(fā)時(shí)間。 四、綜合測試四、綜合測試 在單元測試中，為了有效地減少開發(fā)樁模塊的工作量，可以考慮綜合自底向上測試策略和孤立測試策略。 工程碩士534.3.6 4.3.6 單元測試技術(shù)單元測試技術(shù)靜態(tài)分析靜態(tài)分析 含義：不實(shí)際運(yùn)行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質(zhì)量的軟件測試技術(shù)。也稱為靜態(tài)測試技術(shù)。 方法： 走查：WalkThrough 審查：Inspection 評審：Review工程碩士54單元測試技術(shù)靜態(tài)分析（走查） 含義： 開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯誤的活動。 經(jīng)驗(yàn)： 限時(shí)避免跑題 參加人員經(jīng)驗(yàn)

30、豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項(xiàng)目組的新人 由本模塊的開發(fā)者進(jìn)行講解、回答問題并記錄不要現(xiàn)場修改 檢查要點(diǎn)邏輯錯誤代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格是人工測試的方法，屬于靜態(tài)白盒測試，通過閱讀程序源代碼查找程序的錯誤。工程碩士55單元測試技術(shù)靜態(tài)分析（審查） 含義： 開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。 經(jīng)驗(yàn)： 以會議的形式，制定會議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告 參加人員經(jīng)驗(yàn)豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項(xiàng)目組的新人 由另外一名開發(fā)者進(jìn)行講解、其他開發(fā)者主要按照Checklist進(jìn)行提問并填表、本模塊開發(fā)者

31、回答問題并記錄不要現(xiàn)場修改 檢查要點(diǎn)設(shè)計(jì)需求代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格工程碩士56單元測試技術(shù)靜態(tài)分析（評審）定義：開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用Checklist方式進(jìn)行的查找錯誤的活動。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。經(jīng)驗(yàn)：以會議的形式，制定會議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告。相關(guān)資料要在會議前下發(fā)并閱讀。參加人員經(jīng)驗(yàn)豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員測試組和相關(guān)人員由另外一名開發(fā)者進(jìn)行講解、其他開發(fā)者主要按照Checklist進(jìn)行提問并填表、本模塊開發(fā)者回答問題并記錄不要現(xiàn)場修改檢查要點(diǎn)設(shè)計(jì)需求代碼標(biāo)準(zhǔn)/規(guī)范/風(fēng)格文檔的完整性和一致性工程碩

32、士574.3.7單元測試技術(shù)測試用例設(shè)計(jì) 黑盒方法 - 等價(jià)類 - 邊界值 - 決策表 - 基于類定義 - 狀態(tài)圖 - 錯誤猜測法 考慮對象 - 模塊接口 - 局部數(shù)據(jù)結(jié)構(gòu) - 獨(dú)立路徑 - 異常處理 - 邊界條件 白盒方法 - 基本路徑 - 分支-條件 - 循環(huán) - 覆蓋度工程碩士58 模塊接口 檢查進(jìn)出模塊的數(shù)據(jù)是否正確 Checklist： 模塊的實(shí)際輸入與定義的輸入是否一致：個數(shù)、類型、順序； 模塊中對于非內(nèi)部/局部變量是否合理使用； 使用其他模塊時(shí)，是否檢查可用性和處理結(jié)果； 使用外部資源時(shí)，是否檢查可用性并及時(shí)釋放資源，如內(nèi)存、文件、硬盤、端口等 其他獨(dú)立路徑出錯處理模塊接口局部數(shù)

33、據(jù)結(jié)構(gòu)邊界條件單元測試用例分析工程碩士59 局部數(shù)據(jù)結(jié)構(gòu) 檢查局部數(shù)據(jù)結(jié)構(gòu)能否保持完整性 Checklist： 變量從來沒有被使用 可能別的地方使用了錯誤的變量名 變量沒有初始化 錯誤的類型轉(zhuǎn)換 數(shù)組越界 非法指針 變量或函數(shù)名稱拼寫錯誤 使用了外部變量或函數(shù) 其他獨(dú)立路徑出錯處理模塊接口邊界條件局部數(shù)據(jù)結(jié)構(gòu)單元測試用例分析工程碩士60獨(dú)立路徑出錯處理模塊接口邊界條件局部數(shù)據(jù)結(jié)構(gòu)單元測試用例分析 出錯處理 檢查內(nèi)部錯誤處理設(shè)施是否有效 Checklist：是否檢查錯誤出現(xiàn)資源使用前后其他模塊使用前后出現(xiàn)錯誤，是否進(jìn)行錯誤處理拋出錯誤通知用戶進(jìn)行記錄錯誤處理是否有效在系統(tǒng)干預(yù)前處理報(bào)告和記錄的錯

34、誤真實(shí)詳細(xì)其他工程碩士61 獨(dú)立路徑 檢查由于計(jì)算錯誤、判定錯誤、控制流錯誤導(dǎo)致的程序錯誤 Checklist： 死代碼 錯誤的計(jì)算優(yōu)先級 精度錯誤 比較運(yùn)算錯誤 賦值錯誤 表達(dá)式的不正確符號 、=；=、=、!= 循環(huán)變量的使用錯誤 錯誤賦值 其他獨(dú)立路徑出錯處理模塊接口邊界條件局部數(shù)據(jù)結(jié)構(gòu)單元測試用例分析工程碩士62 邊界條件 檢查臨界數(shù)據(jù)是否正確處理 Checklist： 普通合法數(shù)據(jù)是否正確處理 普通非法數(shù)據(jù)是否正確處理 邊界內(nèi)最接近邊界的(合法)數(shù)據(jù)是否正確處理 邊界外最接近邊界的(非法)數(shù)據(jù)是否正確處理 其他獨(dú)立路徑出錯處理模塊接口邊界條件局部數(shù)據(jù)結(jié)構(gòu)單元測試用例分析工程碩士63 運(yùn)

35、行時(shí)問題（C/C+） 容器越界訪問 虛函數(shù)動態(tài)決議 函數(shù)動態(tài)鏈接 動態(tài)內(nèi)存分配 異常處理 RTTI（Runtime Type Information ）單元測試用例分析工程碩士64單元測試用例分析例子（C語言的內(nèi)存泄漏）工程碩士65修改后的代碼例子（C語言的內(nèi)存泄漏）工程碩士664.3.8 單元測試工具 單元測試的兩種方式： 自己編寫代碼 使用單元測試工具 單元測試工具的種類 靜態(tài)分析工具 代碼規(guī)范審核工具 內(nèi)存和資源檢查工具 測試數(shù)據(jù)生成工具 測試框架工具 測試結(jié)果比較工具 測試度量工具 測試文檔生成和管理工具工程碩士67單元測試工具 代碼檢查工具 Lint 覆蓋率測試工具 IBM Rati

36、onal PureCoverage TrueCoverage 內(nèi)存檢查工具 IBM Rational Purify（http:/ BounderChecker JUnit Framework（http:/ 性能檢查工具 Quantify 其他 HindSight LogiScope4.3.8 4.3.8 單元測試用例設(shè)計(jì)單元測試用例設(shè)計(jì)一、試用例設(shè)計(jì)概述試用例設(shè)計(jì)概述 單元測試用例的設(shè)計(jì)既可以使用白盒測試也可以使用黑盒測試，但以白盒測試為主。 白盒測試進(jìn)入的前提條件是測試人員已經(jīng)對被測試對象有了一定的了解，基本上明確了被測試軟件的邏輯結(jié)構(gòu)。 黑盒測試是要首先了解軟件產(chǎn)品具備的功能和性能等需求，

37、再根據(jù)需求設(shè)計(jì)一批測試用例以驗(yàn)證程序內(nèi)部活動是否符合設(shè)計(jì)要求的活動。 測試人員在實(shí)際工作中至少應(yīng)該設(shè)計(jì)能夠覆蓋如下需求的基于功能的單元測試用例： 測試程序單元的功能是否實(shí)現(xiàn)； 測試程序單元性能是否滿足要求（可選）； 是否有可選的其它測試特性，如邊界、余量、安全性、可靠性、強(qiáng)度測試、人機(jī)交互界面測試等。 無論是白盒測試還是黑盒測試，每個測試用例都應(yīng)該包含下面4 個關(guān)鍵元素： (1) 被測單元模塊初始狀態(tài)聲明，即測試用例的開始狀態(tài)（僅適用于被測單元維持了調(diào)用中間狀態(tài)的情況)； (2) 被測單元的輸入，包含由被測單元讀入的任何外部數(shù)據(jù)值； (3) 該測試用例實(shí)際測試的代碼，用被測單元的功能和測試用例

38、設(shè)計(jì)中使用的分析來說明，如：單元中哪一個決策條件被測試； (4) 測試用例的期望輸出結(jié)果（在測試進(jìn)行之前的測試說明中定義）。 二、測試用例設(shè)計(jì)步驟二、測試用例設(shè)計(jì)步驟 以下描述進(jìn)行測試用例設(shè)計(jì)的6步通用過程。 步驟1：首先使被測單元運(yùn)行； 這個階段適合的技術(shù)有： 模塊設(shè)計(jì)說明導(dǎo)出的測試 對等區(qū)間劃分 步驟2：正面測試(Positive Testing) 這個階段適合的技術(shù)： 設(shè)計(jì)說明導(dǎo)出的測試 對等區(qū)間劃分 狀態(tài)轉(zhuǎn)換測試 步驟3：負(fù)面測試(Negative Testing) 適合的技術(shù)有： 錯誤猜測 邊界值分析 內(nèi)部邊界值測試 狀態(tài)轉(zhuǎn)換測試 步驟4: 模塊設(shè)計(jì)需求中其它測試特性用例設(shè)計(jì) 適合的

39、技術(shù)：設(shè)計(jì)說明導(dǎo)出的測試 步驟5：覆蓋率測試用例設(shè)計(jì) 適合的技術(shù)： 分支測試 條件測試 數(shù)據(jù)定義使用測試 狀態(tài)轉(zhuǎn)換測試 步驟6：測試執(zhí)行 步驟7：完善代碼覆蓋 適合的技術(shù)： 分支測試 條件測試 設(shè)計(jì)定義試驗(yàn)測試 狀態(tài)轉(zhuǎn)換測試 4.3.9 4.3.9 單元測試過程單元測試過程圖3-7從宏觀的角度概括了單元測試的工作過程圖。 一、單元測試進(jìn)入和退出準(zhǔn)則 如表3-1和表3-2所示：表3-1 進(jìn)入準(zhǔn)則要素判斷準(zhǔn)則詳細(xì)設(shè)計(jì)說明書單元測試用例 經(jīng)過審查 獲得批準(zhǔn) 進(jìn)入配置庫 要素判斷準(zhǔn)則源代碼文件源代碼文件清單 源代碼文件獲得批準(zhǔn) 源代碼文件進(jìn)入配置庫的 源代碼區(qū) 測試用例源代碼通過同級 評審軟件Bug

40、清單單元測試報(bào)告 提交測試負(fù)責(zé)人 提交軟件產(chǎn)品配置管理表3-2 退出準(zhǔn)則二、單元測試過程詳 細(xì) 設(shè) 計(jì) 說 明 書原 程 序 文 件測 試 用 例 文 件單 元 測 試 報(bào) 告軟 件 Bug清 單準(zhǔn)備代碼編制代碼審查單元測試圖3-7 單元測試工作過程（1）準(zhǔn)備階段（2）編制階段（3）代碼審查階段（4）單元測試階段（5）評審、提交階段4.4 4.4 集成測試過程技術(shù)集成測試過程技術(shù)相關(guān)概念集成測試策略集成測試環(huán)境 4.4.1 4.4.1 集成測試概述集成測試概述 一、集成測試的含義 集成測試是指根據(jù)實(shí)際情況對程序模塊采用適當(dāng)?shù)牡募蓽y試策略組裝起來，對系統(tǒng)的接口以及集成后的功能進(jìn)行正確性檢驗(yàn)的測

41、試工作。 在單元測試的基礎(chǔ)上，將所有模塊按照概要設(shè)計(jì)要求組裝為子系統(tǒng)或者系統(tǒng)進(jìn)行測試，關(guān)注各個模塊之間的交互是否正確。 二二、集成測試與系統(tǒng)測試的區(qū)別集成測試與系統(tǒng)測試的區(qū)別 1、測試對象 集成測試的測試對象是由通過了單元測試的各個模塊所集成起來的組件。而系統(tǒng)測試的測試對象，除了軟件之外，還有計(jì)算機(jī)硬件及相關(guān)的外圍設(shè)備、數(shù)據(jù)采集和傳輸機(jī)構(gòu)、計(jì)算機(jī)系統(tǒng)操作人員等的整個系統(tǒng)。 2、 測試時(shí)間 集成測試是介于單元測試和系統(tǒng)測試之間的測試. 在測試時(shí)間上，先于系統(tǒng)測試。 3、測試方法 集成測試通常會采用灰盒測試。而系統(tǒng)測試通常使用黑盒測試。 4、測試內(nèi)容 集成測試的主要內(nèi)容就是各個單元模塊之間的接口，

42、以及各個模塊集成后所實(shí)現(xiàn)的功能。而系統(tǒng)測試的主要內(nèi)容就是整個系統(tǒng)的功能和性能。 5、測試目的 集成測試的主要目的就是發(fā)現(xiàn)單元之間接口的錯誤，以及發(fā)現(xiàn)集成后的軟件同軟件概要設(shè)計(jì)說明不一致的地方。而系統(tǒng)測試的主要目的就是，通過與系統(tǒng)需求定義相比較之后發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或矛盾的地方。 6、測試角度 集成測試工作的開展更多的是站在測試工作人員的角度上。系統(tǒng)測試工作的開展更多的是站在用戶的角度來進(jìn)行。A產(chǎn)品子系統(tǒng)1子系統(tǒng)2硬件子系統(tǒng)1軟件子系統(tǒng)1軟件模塊1軟件模塊2軟件程序1軟件程序2單元1單元2單元3單元4硬件子系統(tǒng)2軟件子系統(tǒng)2軟件模塊3軟件模塊4（軟件結(jié)構(gòu)圖）（軟件模塊結(jié)構(gòu)）4-1 軟件結(jié)構(gòu)

43、圖 三、集成測試與開發(fā)的關(guān)系三、集成測試與開發(fā)的關(guān)系 為了使讀者更好的了解集成測試與開發(fā)的關(guān)系，圖4-1給出了軟件基本結(jié)構(gòu)圖。 四四、集成測試的重點(diǎn)集成測試的重點(diǎn) 1、各個模塊連接起來后，穿過模塊接口的數(shù)據(jù)是否會丟失，是否能夠按期望值傳遞給另外一個模塊； 2、各個模塊連接起來后，需要判斷是否仍然存在單元測試時(shí)所沒發(fā)現(xiàn)的資源競爭問題； 3、分別通過單元測試的子功能模塊集成到一起能否實(shí)現(xiàn)所期望的父功能； 4、兼容性，檢查引入一個模塊后，是否對其他與之相關(guān)的模塊產(chǎn)生負(fù)面影響； 5、全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否正確，是否被不正常的修改； 6、集成后，每個模塊的誤差是否會累計(jì)擴(kuò)大，是否會達(dá)到了不可接受的程度； 五五

44、、集成測試的層次集成測試的層次 對于傳統(tǒng)軟件來說，按集成粒度不同，可以把集成測試分為3個層次，即：- 模塊內(nèi)集成測試- 子系統(tǒng)內(nèi)集成測試- 子系統(tǒng)間集成測試 對于面向?qū)ο髴?yīng)用系統(tǒng)來說，按集成粒度不同，可以把集成測試分為2個層次：- 類內(nèi)集成測試- 類間集成測試 4.4.2 4.4.2 集成測試任務(wù)集成測試任務(wù) 一、集成測試任務(wù)集成測試任務(wù) 在把各個模塊連接起來時(shí)，穿越模塊接口的數(shù)據(jù)是否會丟失； 各個子功能組合起來，是否能夠達(dá)到預(yù)期要求的父功能； 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響； 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改； 單個模塊的誤差積累起來，是否會放大，從而達(dá)到不可接

45、受的程度； 二二、集成測試基礎(chǔ)分析集成測試基礎(chǔ)分析 1、體系結(jié)構(gòu)分析 首先，跟蹤需求分析，對要實(shí)現(xiàn)的系統(tǒng)劃分出結(jié)構(gòu)層次圖。 其次，是對系統(tǒng)各個組件之間的依賴關(guān)系進(jìn)行分析，然后據(jù)此確定集成測試的粒度，即集成模塊的大小。2、模塊分析 一般，可從以下幾個角度進(jìn)行模塊分析： 1）確定本次要測試的模塊；2） 找出與該模塊相關(guān)的所有模塊，并且按優(yōu)先級對這 些模塊進(jìn)行排列；3）從優(yōu)先級別最高的相關(guān)模塊開始，把被測模 塊與其集成到一起；4）然后依次集成其他模塊。3、接口分析 接口的劃分要以概要設(shè)計(jì)為基礎(chǔ)，一般通過以下幾個步驟來完成： (1)確定系統(tǒng)的邊界、子系統(tǒng)的邊界和模塊的邊界。 (2)確定模塊內(nèi)部的接口。

46、 (3)確定子系統(tǒng)內(nèi)模塊間接口。 (4)確定子系統(tǒng)間接口。 (5)確定系統(tǒng)與操作系統(tǒng)的接口。 (6)確定系統(tǒng)與硬件的接口。 (7)確定系統(tǒng)與第三方軟件的接口。4、風(fēng)險(xiǎn)分析 風(fēng)險(xiǎn)通常被分為3種類型： 項(xiàng)目風(fēng)險(xiǎn)：包括項(xiàng)目管理和項(xiàng)目環(huán)境的風(fēng)險(xiǎn)。 商業(yè)風(fēng)險(xiǎn)：它和領(lǐng)域的相關(guān)概念及規(guī)則息息相關(guān)。 技術(shù)風(fēng)險(xiǎn)：這是針對應(yīng)用程序的具體實(shí)現(xiàn)而言的，主要和代碼級的測試有關(guān)。 風(fēng)險(xiǎn)分析是一個定義風(fēng)險(xiǎn)并且找出阻止?jié)撛诘膯栴}變成現(xiàn)實(shí)的方法的過程。 通常把風(fēng)險(xiǎn)分析分為3個階段：風(fēng)險(xiǎn)識別、風(fēng)險(xiǎn)評估和風(fēng)險(xiǎn)處理。 5、可測試性分析 必須盡可能早地分析接口的可測試性，提前為后續(xù)的測試工作做好準(zhǔn)備。 6、集成測試策略分析 集成測試策

47、略分析的主要任務(wù)就是根據(jù)被測對象選擇合適的集成測試策略。工程碩士89 基于功能分解的集成 大爆炸 自頂向下集成 自底向上集成 三明治集成 基于調(diào)用圖的集成 成對集成 相鄰集成 基于路徑的集成 集成測試策略工程碩士90SATMSATM系統(tǒng)系統(tǒng)設(shè)備傳感與控制設(shè)備傳感與控制中央銀行通信中央銀行通信終端傳感與控制終端傳感與控制管理會話管理會話通道傳感與控制通道傳感與控制槽傳感與控制槽傳感與控制屏幕驅(qū)動器屏幕驅(qū)動器鍵盤傳感器鍵盤傳感器驗(yàn)證卡驗(yàn)證卡驗(yàn)證驗(yàn)證PINPIN取數(shù)字取數(shù)字管理事務(wù)管理事務(wù)結(jié)束會話結(jié)束會話集成測試功能分解圖和調(diào)用圖示例工程碩士911A10BC2511 12 13151416ED234

48、82621201822F17919242376527集成測試功能分解圖工程碩士92123456789101112131415161718192021222324252627集成測試調(diào)用圖示例工程碩士93 在完成單元測試后就立即將所有模塊連接成一個整體進(jìn)行測試是一個好方法。 Not always！集成測試策略大爆炸集成工程碩士94 從頂層開始，采用同設(shè)計(jì)順序一樣的思路對被測系統(tǒng)進(jìn)行測試，一般集中于頂層的組件，然后逐步測試處于底層的組件，被上層單元調(diào)用的下層單元以樁出現(xiàn)； 自頂向下的集成方式可以采用深度優(yōu)先和廣度優(yōu)先策略。集成測試策略自頂向下集成工程碩士95ABCDEFAS1S2S3AS4S2S3

49、BAS2S3BEAS3BECABECDS5ABECFD集成測試策略自頂向下集成示例 深度優(yōu)先有一個程序的結(jié)構(gòu)如下圖所示，當(dāng)采用自頂向下深度優(yōu)先的策略進(jìn)行集成測試時(shí)，請?jiān)敿?xì)描述該程序的測試過程。ABCD自頂向下深度優(yōu)先的策略進(jìn)行集成測試的方法是：以先左后右的方式選擇模塊集成主線路徑，主模塊作為測試驅(qū)動，為主模塊編制相應(yīng)的樁基模塊。 測試主模塊A，編制樁基模塊S1和S2來代替模塊A實(shí)際調(diào)用的模塊B和C，如圖（a）所示。 用模塊B代替樁基模塊S1，編制樁基模塊S3來代替模塊B實(shí)際調(diào)用的模塊D，對模塊B進(jìn)行測試，如圖（b）所示。 用模塊D代替樁基模塊S3，對模塊D進(jìn)行測試，如圖（c）所示。 用模塊D代

50、替樁基模塊S3，對模塊C進(jìn)行測試，如圖（d）所示。 AS1S2ABS2S3ABS2DABCD （a） （b） （c） （d）工程碩士99ABCDEFAS1S2S3AS4S2S3BACS3BS4ABECDS5ABECFDADBS4CS5集成測試策略自頂向下集成示例 廣度優(yōu)先工程碩士100 從最底層組件開始，按照分解樹的結(jié)構(gòu)，逐層向上集成，調(diào)用下層單元的上層單元以驅(qū)動出現(xiàn)。 示例集成測試策略自底向上集成Ed1d3FCd2BEd4DFd5ABCDEFABCDEF工程碩士101 在分解樹的子樹上進(jìn)行集成 優(yōu)先模塊優(yōu)先集成集成測試策略三明治集成工程碩士102 成對集成 測試思想：依據(jù)調(diào)用圖，測試調(diào)用圖中

51、的每一對單元 測試會話的數(shù)量：調(diào)用圖中的邊的數(shù)目 相鄰集成 測試思想：依據(jù)調(diào)用圖，測試節(jié)點(diǎn)的鄰居，節(jié)點(diǎn)的鄰居是包括節(jié)點(diǎn)的所有直接前軀節(jié)點(diǎn)和所有直接后繼節(jié)點(diǎn) 測試會話的數(shù)量： 鄰居 = 節(jié)點(diǎn) 匯節(jié)點(diǎn)（有葉直接連到根節(jié)點(diǎn)） 鄰居 = 節(jié)點(diǎn) 匯節(jié)點(diǎn)-源節(jié)點(diǎn)（沒有葉直接連到根節(jié)點(diǎn)）集成測試策略成對集成&相鄰集成工程碩士103123456789101112131415161718192021222324252627集成測試策略成對集成示例工程碩士104123456789101112131415161718192021222324252627集成測試策略相鄰集成示例工程碩士105 測試思想:來源于

52、路徑測試，集成的策略是測試從一個單元沿類似于控制的線索進(jìn)入另一 個單元。 相關(guān)概念 源節(jié)點(diǎn)：程序執(zhí)行開始時(shí)或重新開始處的語句片斷（單元中的第一個可執(zhí)行語句，緊接著轉(zhuǎn)移控制到其他單元節(jié)點(diǎn)之后的節(jié)點(diǎn)）。 匯節(jié)點(diǎn)：程序執(zhí)結(jié)束處的語句片斷（單元中的最后一個可執(zhí)行語句，轉(zhuǎn)移控制到其他單元的節(jié)點(diǎn)）。 模塊執(zhí)行路徑: 以源節(jié)點(diǎn)開始，以匯節(jié)點(diǎn)結(jié)束的一些列語句，中間沒有插入?yún)R節(jié)點(diǎn)。 消息：一種程序設(shè)計(jì)語言機(jī)制，通過這種機(jī)制一個單元將控制轉(zhuǎn)移給另一個單元。集成測試策略基于路徑的集成工程碩士106MM-路徑是穿插出現(xiàn)模塊執(zhí)行路徑和消息的序列;通過MM-路徑可以描述包含在單獨(dú)單元之間控制轉(zhuǎn)移的模塊執(zhí)行路徑序列1234

53、56123412345ABC MEP(A,1) = MEP(A,2) = MEP(A,3) = MEP(B,1) = MEP(B,2) = MEP(C,1) = MEP(C,2) = 集成測試策略基于路徑的集成工程碩士107集成測試策略基于路徑的集成 給定一組單元，其MM-路徑圖是一種有向圖，其中的節(jié)點(diǎn)表示模塊執(zhí)行路徑，邊表示消息和單元之間的返回，實(shí)線表示消息，相應(yīng)的返回由虛線表示 MM-路徑有多長（深）？消息靜止點(diǎn)和數(shù)據(jù)靜止點(diǎn) 覆蓋準(zhǔn)則：至少遍歷所有的消息工程碩士108123456123412345ABC MEP(A,1) = MEP(A,2) = MEP(A,3) = MEP(B,1) =

54、 MEP(B,2) = MEP(C,1) = MEP(C,2) = MEP(A,2)MEP(A,1)MEP(C,1)MEP(B,2)MEP(A,3)MEP(c,2)MEP(B,1)集成測試策略基于路徑的集成示例工程碩士109硬件硬件環(huán)環(huán)境：境：盡盡可能的考可能的考慮實(shí)際環(huán)慮實(shí)際環(huán)境，境，實(shí)實(shí)在不可用使用模在不可用使用模擬環(huán)擬環(huán)境境 操作操作環(huán)環(huán)境：考境：考慮慮到不同機(jī)型的不同操作系到不同機(jī)型的不同操作系統(tǒng)統(tǒng)版本版本數(shù)數(shù)據(jù)據(jù)庫環(huán)庫環(huán)境境網(wǎng)絡(luò)環(huán)網(wǎng)絡(luò)環(huán)境境接口模擬器接口模擬器1驅(qū)動驅(qū)動已集成模塊已集成模塊新增模塊新增模塊樁樁樁樁樁樁驅(qū)動驅(qū)動已集成模塊已集成模塊新增模塊新增模塊樁樁樁樁樁樁接口模擬器接

55、口模擬器2測試控制中心測試控制中心測試數(shù)據(jù)庫測試數(shù)據(jù)庫測試規(guī)程庫測試規(guī)程庫TCP/IPTCP/IPTCP/IPTCP/IPTCP/IPPC機(jī)機(jī)PC機(jī)機(jī)PC機(jī)機(jī)PC機(jī)機(jī)小型機(jī)小型機(jī)集成測試環(huán)境工程碩士110 將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計(jì)算機(jī)系統(tǒng)的一個元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行（使用）環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。 測試任務(wù)： 發(fā)現(xiàn)與系統(tǒng)定義不符或矛盾的地方 系統(tǒng)各個部分是否可以協(xié)調(diào)工作4.5 4.5 系統(tǒng)測試系統(tǒng)測試過程技術(shù)過程技術(shù)工程碩士111 功能性測試 性能測試 壓力測試 容量測試 協(xié)議一致性測試

56、安全性測試 恢復(fù)性測試 備份測試 GUI測試 健壯性測試 兼容性測試 可用性測試 可安裝性測試 文檔測試 在線幫助測試 數(shù)據(jù)轉(zhuǎn)換測試系統(tǒng)測試內(nèi)容工程碩士112系統(tǒng)測試功能性測試 測試思想：功能測試是系統(tǒng)測試中最基本的測試，根據(jù)產(chǎn)品的需求規(guī)格書和測試需求列表，驗(yàn)證產(chǎn)品的功能實(shí)現(xiàn)是否符合產(chǎn)品的需求規(guī)格。主要發(fā)現(xiàn)以下幾類錯誤： 是否有不正確或遺漏了的功能？ 功能實(shí)現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計(jì)的隱藏需求？ 是否能正常地接受輸入？能否正確地輸出結(jié)果？ 對測試設(shè)計(jì)者的要求：非常熟悉產(chǎn)品的規(guī)格說明、需求文檔和產(chǎn)品業(yè)務(wù)功能，掌握測試用例的設(shè)計(jì)方法。工程碩士113 對每個明確的功能需求進(jìn)行標(biāo)號 對每個可能隱含的

57、功能需求進(jìn)行標(biāo)號 對于可能出現(xiàn)的功能異常進(jìn)行分類，并進(jìn)行標(biāo)號 對于前三步獲得的功能需求進(jìn)行分級，確定關(guān)鍵功能和非關(guān)鍵功能 設(shè)計(jì)每個功能的測試用例（等價(jià)類，邊界值，決策表，錯誤猜測等） 系統(tǒng)測試功能性測試（用例分析方法）工程碩士114系統(tǒng)測試功能性測試（用例設(shè)計(jì)方法） 規(guī)范導(dǎo)出法； 等價(jià)類劃分； 邊界分析； 因果圖； 決策表； 基于風(fēng)險(xiǎn)的測試； 錯誤猜測法；工程碩士115 測試思想：軟件的性能和效率目標(biāo)描述為在特定負(fù)載和配置環(huán)境下程序的響應(yīng)時(shí)間和吞吐率。性能測試的目的是設(shè)計(jì)測試用例來說明程序不能滿足其性能目標(biāo)，監(jiān)控的關(guān)鍵性能指標(biāo)（例如響應(yīng)時(shí)間、CPU、內(nèi)存、I/O使用情況、網(wǎng)絡(luò)連接等） 。 例如

58、：應(yīng)用程序能夠以1000ms的最大響應(yīng)時(shí)間處理750個同時(shí)發(fā)生的活躍用戶；峰值時(shí)刻支持800個用戶，響應(yīng)時(shí)間下降7%。系統(tǒng)測試性能測試（以Web應(yīng)用為例）工程碩士116系統(tǒng)測試性能測試（以Web應(yīng)用為例） 性能度量指標(biāo)： 響應(yīng)時(shí)間的定義：對計(jì)算機(jī)系統(tǒng)的一個查詢或請求結(jié)束和一個響應(yīng)開始之間所逝去的時(shí)間，例如在指示一個查詢結(jié)束和在用戶終端上顯示相應(yīng)的第一個字符之間的時(shí)間長度。 事務(wù)時(shí)間：客戶、網(wǎng)絡(luò)和服務(wù)器完成一個事務(wù)所需要的時(shí)間總量。 等待時(shí)間：完成一個請求所需的時(shí)間，如網(wǎng)絡(luò)延遲和服務(wù)器延遲。在Web應(yīng)用中，相應(yīng)時(shí)間可以度量為用戶點(diǎn)擊一個按鈕或鏈接和瀏覽器開始顯示導(dǎo)出的頁面之間的時(shí)間。在Web應(yīng)用

59、中，事務(wù)時(shí)間可以度量為用戶點(diǎn)擊一個按鈕或鏈接和瀏覽器開始顯示導(dǎo)出的頁面之間的時(shí)間（包括客戶端腳本、Java小程序等的執(zhí)行）。工程碩士117系統(tǒng)測試性能測試（以Web應(yīng)用為例）一個典型的Web事務(wù)范例 客戶端用戶輸入U(xiǎn)RL或者在瀏覽器上點(diǎn)擊鏈接，請求服務(wù)器提供某個文件。域名服務(wù)器將服務(wù)器的主機(jī)名轉(zhuǎn)換成合適的IP地址。客戶連接到Web服務(wù)器?？蛻粝蚍?wù)器發(fā)送一個超文本傳輸協(xié)議請求。在Internet上網(wǎng)絡(luò)將數(shù)據(jù)從客戶端傳輸?shù)椒?wù)器端。在服務(wù)器端一旦請求到達(dá)服務(wù)器，數(shù)據(jù)在合適的通訊協(xié)議上被拆分；服務(wù)器對請求作出響應(yīng)；服務(wù)器通過檢索數(shù)據(jù)或者將數(shù)據(jù)寫入數(shù)據(jù)庫來處理請求，一旦處理完成，服務(wù)器向客戶返回請求

60、文件或者結(jié)果信息。在Internet上回傳（網(wǎng)絡(luò)）網(wǎng)絡(luò)從服務(wù)器端向客戶端傳輸數(shù)據(jù)返回到客戶端瀏覽器接受請求的數(shù)據(jù)，顯示HTML內(nèi)容并執(zhí)行動態(tài)內(nèi)容。工程碩士118系統(tǒng)測試性能測試（以Web應(yīng)用為例） 性能測試的關(guān)鍵元素 工作負(fù)載：系統(tǒng)需要進(jìn)行處理和通信管理的信息總量。 考慮的因素： 用戶 應(yīng)用 資源 通過對用戶數(shù)量（和日?；顒樱?、需要應(yīng)用處理用戶活動的命令、系統(tǒng)的資源需求的分析，計(jì)算出系統(tǒng)的工作負(fù)載。工程碩士119系統(tǒng)測試性能測試（以Web應(yīng)用為例） 性能測試的關(guān)鍵元素 系統(tǒng)環(huán)境和可利用資源：客戶端的瀏覽器、網(wǎng)絡(luò)和服務(wù)器。 Web應(yīng)用中涉及的環(huán)境資源包括： 網(wǎng)絡(luò)訪問量 人員變量 地域變量 ISP基礎(chǔ)結(jié)構(gòu)