第四章執(zhí)行測試(1)S

1、軟軟 件件 測測 試試 技技 術(shù)術(shù)1第四章第四章 執(zhí)行測試執(zhí)行測試4.1 測試執(zhí)行概述4.2 執(zhí)行系統(tǒng)測試4.3 執(zhí)行單元測試4.4 執(zhí)行集成測試2單元單元測試測試單元單元測試測試單元單元測試測試集成集成測試測試集成集成測試測試系統(tǒng)系統(tǒng)測試測試被測模塊被測模塊被測模塊被測模塊被測模塊被測模塊設(shè)計信息設(shè)計信息軟件需求軟件需求用戶信息用戶信息其它元素其它元素* 驗收驗收測試測試* 交付用戶交付用戶軟件測試的過程流程34.1 測試執(zhí)行概述測試執(zhí)行概述測試執(zhí)行過程建立測試環(huán)境執(zhí)行測試用例記錄測試結(jié)果 管理有軟件錯誤報告測試結(jié)果執(zhí)行測試的過程，也是不斷發(fā)現(xiàn)缺陷的過程。在發(fā)現(xiàn)和記錄了軟件缺陷后，還需要對缺

2、陷進行管理，包括對缺陷的分類、報告、重現(xiàn)、跟蹤和統(tǒng)計分析。454.3 4.3 執(zhí)行單元測試執(zhí)行單元測試6在單元測試的過程中，會綜合運用靜態(tài)測試技術(shù)和動態(tài)測試技術(shù)。在進行單元測試的過程中，一般會使用白盒測試，但也會結(jié)合使用黑盒測試。單元測試是針對程序模塊進行正確性檢驗的測試工作。在編碼的過程中作單元測試，其花費是最小的， 在代碼編寫完成后的單元測試工作主要分為兩個步驟：人工靜態(tài)檢查動態(tài)執(zhí)行跟蹤74.3.1 靜態(tài)檢查靜態(tài)檢查合格的代碼應該具備以下性質(zhì)：正確性：指代碼邏輯必須正確，能夠?qū)崿F(xiàn)預期的功能清晰性：指代碼必須簡明、易懂，注釋準確沒有歧義規(guī)范性：指代碼必須符合企業(yè)所定義的共同規(guī)范包括命名規(guī)則，

3、代碼風格等等一致性：指代碼必須在命名上風格上都保持統(tǒng)一高效性：指代碼不但要滿足以上性質(zhì)，而且需要盡可能降低代碼的執(zhí)行時間8單元測試時，靜態(tài)測試常采用以下方式：代碼走查桌面審查（同級復查）代碼評審9通常的人工檢查階段需要執(zhí)行下列內(nèi)容： P113大多數(shù)單元測試會使用同級復查，即由開發(fā)人員的同伴（另外一個程序員）對文檔和代碼進行檢驗。不同公司、不同的項目會有不同的復查項檢查清單，例如下面的一些典型復查項：函數(shù)入口處的形式參數(shù)的合法性有沒有顯然的數(shù)組越界操作代碼的注釋量是否符合公司規(guī)范是否設(shè)置了適當?shù)某鲥e處理靜態(tài)測試也可采用一些輔助工具軟件進行，例如PC-Lint一款C/C+語言代碼靜態(tài)測試工具。10

4、單元測試時，應該對模塊進行如下檢查：對模塊內(nèi)所有獨立的執(zhí)行路徑至少測試一次；對所有的邏輯判定，取“真“與”假“的情況至少各執(zhí)行一次；在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體；測試內(nèi)部數(shù)據(jù)的有效性等等。4.3.2 動態(tài)跟蹤動態(tài)跟蹤測試排錯調(diào)試11模塊模塊模塊接口模塊接口局部數(shù)據(jù)結(jié)構(gòu)局部數(shù)據(jù)結(jié)構(gòu)獨立的路徑獨立的路徑出錯處理出錯處理邊界條件邊界條件4.3.3 單元測試的重點單元測試的重點12單元測試的重點：模塊接口：檢查參數(shù)個數(shù)、數(shù)據(jù)類型、順序是否正確，確定返回值的類型及有效性；局部數(shù)據(jù)結(jié)構(gòu)：測試其內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯誤。 獨立的路徑：在單元測試中，最主要的

5、測試是針對路徑的測試。 邊界條件：軟件常常在邊界地區(qū)發(fā)生問題。 錯誤處理：測試出錯處理的要點是模塊在工作中發(fā)生了錯誤，其中的出錯處理設(shè)施是否有效。 131415161718測試用例測試用例被測模塊被測模塊驅(qū)動模塊驅(qū)動模塊測試結(jié)果測試結(jié)果樁模塊樁模塊1樁模塊樁模塊2樁模塊樁模塊3樁模塊樁模塊n樁模塊樁模塊19驅(qū)動模塊主要完成以下事情：1、接受測試輸入；2、對輸入進行判斷；3、將輸入傳給被測單元，驅(qū)動被測單元執(zhí)行；4、接受被測單元執(zhí)行結(jié)果，并對結(jié)果進行判斷；5、將判斷結(jié)果作為用例執(zhí)行結(jié)果輸出。 被測單元用什么語言，驅(qū)動就用什么語言寫。 總而言之，寫驅(qū)動和樁不需要太高深編程知識。如果有模板或框架作為

6、參考的話，差不多就成了一個體力活。2021222324驅(qū)動模塊一般結(jié)構(gòu)： Int DriverModule( ) . 調(diào)用被測試的模塊； 處理運行結(jié)果； .n樁模塊一般結(jié)構(gòu)： Int StubModule(.) . Return 返回值； .2526單元測試的通過標準單元測試的通過標準正確地實現(xiàn)規(guī)定的功能錯誤處理正確邊界條件處理正確達到預定的代碼覆蓋率(語句覆蓋、判定覆蓋、條件組合覆蓋、路徑覆蓋等)。 一般要求語句覆蓋率達到一般要求語句覆蓋率達到100%。 少于30代碼行的函數(shù)一般不需要做單元測試，只要代碼走查即可。27測試與調(diào)試測試與調(diào)試 調(diào)試：bug的過程。 調(diào)試與測試的區(qū)別：n測試的目的

7、：尋找和發(fā)現(xiàn)缺陷。n調(diào)試的目的：找出缺陷的原因，并修正缺陷。通常，在測試以后緊接著要進行調(diào)試。實際上，測試工作和調(diào)試工作是交叉進行的。2829304.4 執(zhí)行集成測試執(zhí)行集成測試31主要是單元之間的接口測試接口測試： 檢查單元調(diào)用關(guān)系、數(shù)據(jù)傳遞等，如函數(shù)形參中的類型、個數(shù)、順序必須與實參相匹配。 一個單元是否使其他單元出現(xiàn)問題？全局數(shù)據(jù)結(jié)構(gòu)的使用是否出現(xiàn)問題（建議少用全局變量）？幾個模塊組合起來可否實現(xiàn)主功能？誤差不斷積累達到不可接受的程度？3233集成測試的模式集成測試的模式非增量式測試模式（非漸增式）增量式測試模式（漸增式）3435 AS3S4S5d2 Cd4 Ed5 Fd1 B s1d3

8、 s2 DABCDEFABCDEF（1）程序結(jié)構(gòu)圖（3）集成測試示意圖（2）各模塊的單元測試示意圖3637383940 A B C D E F A S1 S2 S3 A B C D S4 S5 A B C D E F（1）（2）（3）廣度優(yōu)先方式廣度優(yōu)先方式41 A B C D E F A S1 S2 S3 A B S2 S3S4 A B C S3 E（1）（2）（3）深度優(yōu)先方式深度優(yōu)先方式（4）4243 A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F44適合于規(guī)模較大的應用。4546 自底向上的集成測試方案是工程實踐中最常用的測試方法。相關(guān)技術(shù)也較為成熟。它的優(yōu)點很明顯: 管理方便、測試人員能較好地鎖定軟件故障所在位置。但它對于某些開發(fā)模式不一定適用。盡管如此，自底向上的集成測試方法仍不失為一個可供參考的集成測試方案。 47三明治方法三明治方法 它將自頂向下和自底向上的集