課件內(nèi)容回顧測試過程_第1頁
課件內(nèi)容回顧測試過程_第2頁
課件內(nèi)容回顧測試過程_第3頁
課件內(nèi)容回顧測試過程_第4頁
課件內(nèi)容回顧測試過程_第5頁
已閱讀5頁,還剩29頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、軟件測試過程單元測試集成測試確認(rèn)測試系統(tǒng)測試驗(yàn)收測試測試后的調(diào)試軟件測試過程單元測試單元測試單元測試集成測試集成測試確認(rèn)測試系統(tǒng)測試* 這三個(gè)測試可能交叉與前后互換被測模塊被測模塊被測模塊設(shè)計(jì)信息單元 軟件需求其它元素用戶信息其它元素* * 驗(yàn)收測試* 交付用戶軟件測試的過程流程單元測試單元測試單元測試集成測試集成測試確認(rèn)測試系統(tǒng)測試* 這三個(gè)測試可能交叉與前后互換被測模塊被測模塊被測模塊設(shè)計(jì)信息單元 軟件需求其它元素用戶信息其它元素* * 驗(yàn)收測試* 交付用戶軟件測試過程(續(xù))單元測試:針對每個(gè)單元的測試, 以確保每個(gè)模塊能正常工作為目標(biāo)。集成測試:對已測試過的模塊進(jìn)行組裝,進(jìn)行集成測試。目

2、的在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。確認(rèn)(有效性)測試:是檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段。系統(tǒng)測試:檢驗(yàn)軟件產(chǎn)品能否與系統(tǒng)的其他部分(比如,硬件、數(shù)據(jù)庫及操作人員)協(xié)調(diào)工作。驗(yàn)收(用戶)測試:檢驗(yàn)軟件產(chǎn)品質(zhì)量的最后一道工序。主要突出用戶的作用,同時(shí)軟件開發(fā)人員也應(yīng)有一定程度的參與。一個(gè)實(shí)用軟件測試過程一種簡單實(shí)用的軟件測試過程模型 POCERM。測試過程中必需的基本測試活動及其產(chǎn)生的結(jié)果:擬定軟件測試計(jì)劃 (Plans)編制軟件測試大綱 (Outlines)設(shè)計(jì)和生成測試用例 (test Case generation)實(shí)施測試 (Execution)生成軟件測試報(bào)告

3、 (software testing Reports)軟件問題報(bào)告SPR (Software Problem Report)測試結(jié)果報(bào)告 (test result Reports)一個(gè)實(shí)用軟件測試過程(續(xù))基本特性:(1)計(jì)劃性: 任務(wù) 人員 設(shè)備 時(shí)間 相關(guān).(2)平行性: 開發(fā) 編碼 | 測試 再測試(3)完整性: 計(jì)劃+大綱+用例+SPRs+.(4)重用性: 測試 再測試 回歸測試 升級 多平臺(5)可重復(fù)性: SPRs 用例 大綱 再現(xiàn)Bugs(6)周期性: test cycles, regression, update(7)可管理性: well structured and orga

4、nized QE group + well planned and prepared task測試階段 測試過程的三個(gè)主要的測試活動(計(jì)劃、準(zhǔn)備和實(shí)施) 可被分成五個(gè)階段:The planning and control phase計(jì)劃和控制階段The preparation phase準(zhǔn)備階段The specification phase規(guī)范階段The execution phase實(shí)施執(zhí)行階段The completion phase完成(收尾)階段測試的五個(gè)階段Plan & ControlCSEPP&CPreparationSpecificationExecutionCompletion計(jì)

5、劃與控制階段它是整個(gè)測試過程中最重要的階段,為實(shí)現(xiàn)可管理且高質(zhì)量的測試過程提供基礎(chǔ) 。本階段的主要工作內(nèi)容: (1)擬定測試計(jì)劃 (2)論證那些使開發(fā)過程難于管理和控制的因素 (3)明確軟件產(chǎn)品的最重要部分 (風(fēng)險(xiǎn)評估)準(zhǔn)備階段開始本階段的前提條件:完成測試計(jì)劃的擬定。需求規(guī)格說明書(第一版)的確定。本階段的主要工作內(nèi)容:對需求規(guī)格說明書的仔細(xì)研究。將要測試的產(chǎn)品分解成可獨(dú)立測試的單元。為每個(gè)測試單元確定采用的測試技術(shù)。為測試的下一個(gè)階段及其活動制定計(jì)劃。規(guī)范階段本階段的主要工作內(nèi)容:編寫測試大綱/測試用例,測試腳本搭建測試環(huán)境(測試數(shù)據(jù)庫,軟件環(huán)境,硬件環(huán)境)測試用例描述的內(nèi)容:輸入執(zhí)行過程

6、預(yù)期輸出 實(shí)施執(zhí)行階段根據(jù)測試大綱/測試用例/測試腳本進(jìn)行測試(1)根據(jù)測試大綱/測試用例進(jìn)行測試,找出預(yù)期的測試 結(jié)果和實(shí)際測試結(jié)果之間的差異(2)填寫軟件問題報(bào)告(3)確定造成這些差異的原因: 產(chǎn)品有缺陷?規(guī)格說明書有缺陷? 測試環(huán)境和測試下屬部件有缺陷?測試用例設(shè)計(jì)不合理?測試報(bào)告與管理層進(jìn)行溝通的方式 已測試部分占產(chǎn)品多大的百分比?還有什么工作要做? 找到了多少個(gè)問題或不足?測試的發(fā)展趨勢如何? 測試可以結(jié)束了嗎?完成階段本階段的主要工作內(nèi)容: 選擇和保留測試大綱、測試用例、測試結(jié)果、測試工具。 提交最終報(bào)告。收尾工作的意義和重要性: 產(chǎn)品如果升級或功能變更,或維護(hù),只要對保留下來的

7、相關(guān)測試數(shù)只要作相應(yīng)調(diào)整,就能夠進(jìn)行新的測試。單元測試單元測試的主要任務(wù)單元測試的執(zhí)行過程Return單元測試的主要任務(wù)單元測試針對每個(gè)程序的模塊,主要測試5個(gè)方面的問題: 模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、邊界條件、獨(dú)立的路徑和錯(cuò)誤處理。模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)路徑測試出錯(cuò)處理邊界條件單元測試的主要任務(wù)(續(xù))模塊接口這是對模塊接口進(jìn)行的測試,檢查進(jìn)出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進(jìn)行。模塊接口測試至少需要如下的測試項(xiàng)目:(1)調(diào)用所測模塊時(shí)的輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配;(2)所測模塊調(diào)用子模塊時(shí),它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個(gè)數(shù)、屬

8、性、順序上是否匹配;(3)是否修改了只做輸入用的形式參數(shù);(4)調(diào)用標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、順序上是否正確;(5)全局變量的定義在各模塊中是否一致。單元測試的主要任務(wù)(續(xù))局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中,必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性,包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯(cuò)誤。對于局部數(shù)據(jù)結(jié)構(gòu),應(yīng)該在單元測試中注意發(fā)現(xiàn)以下幾類錯(cuò)誤:(1)不正確的或不一致的類型說明。(2)錯(cuò)誤的初始化或默認(rèn)值。(3)錯(cuò)誤的變量名,如拼寫錯(cuò)誤或書寫錯(cuò)誤。(4)下溢、上溢或者地址錯(cuò)誤。單元測試的主要任務(wù)(續(xù))路徑測試在單元測試中,最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計(jì)算錯(cuò)誤、不正確的判

9、定或不正常的控制流而產(chǎn)生的錯(cuò)誤。常見的錯(cuò)誤有: 誤解的或不正確的算術(shù)優(yōu)先級;混合模式的運(yùn)算;錯(cuò)誤的初始化;精確度不夠精確;表達(dá)式的不正確符號表示。針對判定和條件覆蓋,測試用例還要能夠發(fā)現(xiàn)如下錯(cuò)誤: 不同數(shù)據(jù)類型的比較;不正確的邏輯操作或優(yōu)先級;應(yīng)當(dāng)相等的地方由于精確度的錯(cuò)誤而不能相等;不正確的判定或不正確的變量;不正確的或不存在的循環(huán)終止;當(dāng)遇到分支循環(huán)時(shí)不能退出;不適當(dāng)?shù)匦薷难h(huán)變量。單元測試的主要任務(wù)(續(xù))邊界條件邊界測試是單元測試的最后一步,必須采用邊界值分析方法來設(shè)計(jì)測試用例,認(rèn)真仔細(xì)地測試為限制數(shù)據(jù)處理而設(shè)置的邊界處,看模塊是否能夠正常工作。一些可能與邊界有關(guān)的數(shù)據(jù)類型如數(shù)值、字符、

10、位置、數(shù)量、尺寸等,還要注意這些邊界的首個(gè)、最后一個(gè)、最大值、最小值、最長、最短、最高、最低等特征。在邊界條件測試中,應(yīng)設(shè)計(jì)測試用例檢查以下情況:(1)在n次循環(huán)的第0次、1次、n次是否有錯(cuò)誤。(2)運(yùn)算或判斷中取最大值、最小值時(shí)是否有錯(cuò)誤。(3)數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值是否出現(xiàn)錯(cuò)誤。單元測試的主要任務(wù)(續(xù))出錯(cuò)處理測試出錯(cuò)處理的重點(diǎn)是模塊在工作中發(fā)生了錯(cuò)誤,其中的出錯(cuò)處理設(shè)施是否有效。檢驗(yàn)程序中的出錯(cuò)處理可能面對的情況有:(1)對運(yùn)行發(fā)生的錯(cuò)誤描述難以理解。(2)所報(bào)告的錯(cuò)誤與實(shí)際遇到的錯(cuò)誤不一致。(3)出錯(cuò)后,在錯(cuò)誤處理之前就引起系統(tǒng)的干預(yù)。(4)例外條件的處理不正

11、確。(5)提供的錯(cuò)誤信息不足,以至于無法找到錯(cuò)誤的原因。單元測試的執(zhí)行過程何時(shí)進(jìn)行單元測試?單元測試常常是和代碼編寫工作同時(shí)進(jìn)行的,在完成了程序編寫、復(fù)查和語法正確性驗(yàn)證后,就應(yīng)進(jìn)行單元測試用例設(shè)計(jì)。在單元測試時(shí),如果模塊不是獨(dú)立的程序,需要設(shè)置一些輔助測試模塊。輔助測試模塊有兩種:(1)驅(qū)動模塊(Drive) 用來模擬被測試模塊的上一級模塊,相當(dāng)于被測模塊的主程序。它接收數(shù)據(jù),將相關(guān)數(shù)據(jù)傳送給被測模塊,啟動被測模塊,并打印出相應(yīng)的結(jié)果。(2)樁模塊(Stub) 用來模擬被測模塊工作過程中所調(diào)用的模塊。它們一般只進(jìn)行很少的數(shù)據(jù)處理。 驅(qū)動模塊和樁模塊都是額外的開銷,雖然在單元測試中必須編寫,但

12、并不需要作為最終的產(chǎn)品提供給用戶。 單元測試的執(zhí)行過程(續(xù))被測模塊、驅(qū)動模塊和樁模塊共同構(gòu)成了一個(gè)如下圖所示的單元測試的測試環(huán)境:測試用例被測模塊驅(qū)動模塊測試結(jié)果樁模塊1樁模塊2樁模塊3樁模塊n樁模塊 集成測試非增量式測試增量式測試不同集成測試方法的比較回歸測試Return非增量式測試非增量式測試是采用一步到位的方法來構(gòu)造測試: 對所有模塊進(jìn)行個(gè)別的單元測試后,按照程序結(jié)構(gòu)圖將各模塊連接起來,把連接后的程序當(dāng)作一個(gè)整體進(jìn)行測試。 實(shí)例 采用非增量式測試方法進(jìn)行集成測試非增量式測試的缺點(diǎn): 當(dāng)一次集成的模塊較多時(shí),非增量式測試容易出現(xiàn)混亂,因?yàn)闇y試時(shí)可能發(fā)現(xiàn)了許多故障,為每一個(gè)故障定位和糾正非

13、常困難,并且在修正一個(gè)故障的同時(shí),可能又引入了新的故障,新舊故障混雜,很難判定出錯(cuò)的具體原因和位置。 非增量式測試(續(xù)) AS3S4S5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF(1)程序結(jié)構(gòu)圖(3)集成測試示意圖(2)單元測試示意圖增量式測試增量式測試的集成是逐步實(shí)現(xiàn)的: 逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊(或子系統(tǒng))結(jié)合成程序包,再將這些模塊集成為較大系統(tǒng),在集成的過程中邊連接邊測試,以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實(shí)施次序,增量式集成測試又可以分為三種不同的方法: (1)自頂向下增量式測試 (2)自底向上增量式測試 (3)混合增量式測試自

14、頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進(jìn)行的,即模塊集成的順序是首先集成主控模塊(主程序),然后依照控制層次結(jié)構(gòu)向下進(jìn)行集成。從屬于主控模塊的按深度優(yōu)先方式(縱向)或者廣度優(yōu)先方式(橫向)集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成: 首先集成在結(jié)構(gòu)中的一個(gè)主控路徑下的所有模塊,主控路徑的選擇是任意的。 廣度優(yōu)先方式的集成: 首先沿著水平方向,把每一層中所有直接隸屬于上一層的模塊集成起來,直到底層。自頂向下增量式測試(續(xù))集成測試的整個(gè)過程由3個(gè)步驟完成: (1)主控模塊作為測試驅(qū)動器。 (2)根據(jù)集成的方式(深度或廣度),下層的樁模塊一次一次地被替換為真正的模塊。

15、 (3)在每個(gè)模塊被集成時(shí),都必須進(jìn)行單元測試。 重復(fù)第2步,直到整個(gè)系統(tǒng)被測試完成。 實(shí)例 按照廣度優(yōu)先方式進(jìn)行集成測試 實(shí)例 按照深度優(yōu)先方式進(jìn)行集成測試自頂向下增量式測試(續(xù)) 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)先方式自頂向下增量式測試(續(xù)) A B C D E F A S1 S2 S3 A B S2 S3 E A B C S3 E(1)(2)(3)深度優(yōu)先方式(4)自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進(jìn)行的,即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于

16、是從最底層開始集成,對于一個(gè)給定層次的模塊,它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)集成并測試完成,所以不再需要使用樁模塊進(jìn)行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。 實(shí)例 采用自底向上增量式測試方法進(jìn)行集成測試自底向上增量式測試(續(xù)) A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F混合增量式測試混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結(jié)合起來進(jìn)行集成和測試。這樣可以兼具兩者的優(yōu)點(diǎn),而摒棄其缺點(diǎn)。常見的兩種混合增量式測試方式:(1)衍變的自頂向下的增量式測試:基本思想是強(qiáng)化對輸入/輸出模塊和引入新算法模塊的測試,并自底向上集成為功能相對完整且相對獨(dú)立的子系統(tǒng),然后由主模塊開始自頂向下進(jìn)行增量式測試。(2)自底向上-自頂向下的增量式測試:首先對含讀操作的子系統(tǒng)自底向上直至根節(jié)點(diǎn)模塊進(jìn)行集成和測試,然后對含寫操作的子系統(tǒng)做自頂向下的集成與測試。不同集成測試方法的比較1、非增量式測試與增量式測試的比較非增量式測試的方法是先分散測試,然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯(cuò)誤,只會在最后的集成測試時(shí)一下子暴露出來。增量式測試是逐步集成和逐步測試的方法,把可能出現(xiàn)的差錯(cuò)分散暴露出來,便于找出問題和修改。而且一些模塊在逐步集成的測試中,得到了較多次的考驗(yàn),因

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論