《軟件測試?yán)碚摶A(chǔ)》PPT課件.pptx

1、第1章 軟件測試?yán)碚摶A(chǔ),目錄,軟件測試的由來 軟件測試的定義 軟件測試的目的 軟件測試的原則 軟件測試的對象 軟件測試的分類 軟件測試流程 軟件測試工作階段,軟件測試的由來,調(diào)試 在已知錯誤的情況下，對軟件程序代碼做出的一系列檢查，校正的過程。 測試 在未知錯誤的情況下，檢查程序代碼是否有問題的過程。 區(qū)分：軟件測試從軟件質(zhì)量保證的角度來檢查程序代碼是否有誤，而調(diào)試是為了解決當(dāng)前已知的錯誤，調(diào)試活動無法替代軟件測試活動。,軟件測試的定義,軟件測試就是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。 軟件測試應(yīng)該是對軟件形成過程的文檔，數(shù)據(jù)以及程序進(jìn)行的測試,而不僅是對程序進(jìn)行的

2、測試。 60%以上的軟件錯誤并不是程序錯誤,而是分析和設(shè)計的錯誤,提倡軟件全生命周期測試的理念。,軟件測試的目的,基于不同的立場，存在著兩種完全不同的測試目的： 用戶角度：希望軟件測試暴露軟件中隱藏的錯誤和缺陷，已考慮是否接受產(chǎn)品。 軟件開發(fā)者角度：希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證被測軟件已正確的實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。,軟件測試的原則,軟件測試的原則： 所有的軟件測試都應(yīng)追溯到用戶需求。 應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件測試者的座右銘。 完全測試是不可能的，測試需要終止。 測試無法顯示軟件潛在的缺陷。也就是說測試只能證明軟件存在錯誤而不能證明軟

3、件沒有錯誤。,軟件測試的對象,用戶要求 用戶： 我要什么？,運行結(jié)果 計算機： 程序運行得到的結(jié)果,需求說明書 分析員： 我可以提供什么？,源程序 程序員： 我要讓計算機怎么做,設(shè)計說明書 設(shè)計員： 我要讓軟件做什么？,相符嗎？,理解正確性 表達(dá)正確性,理解正確性 設(shè)計正確性 表達(dá)正確性,理解正確性 編碼正確性,運行正確性 輸入正確性,軟件測試的分類,一般的，我們將軟件測試活動分為以下幾類： 從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分： 黑盒測試 白盒測試 灰盒測試 從是否執(zhí)行程序的角度劃分： 靜態(tài)測試 動態(tài)測試 從是否使用自動化測試工具劃分： 手動測試 自動測試,軟件測試分類 黑盒測試,黑盒

4、測試又叫功能測試、數(shù)據(jù)驅(qū)動測試或基于需求規(guī)格說明書的功能測試。該測試類別注重于測試軟件的功能性需求。 測試工程師無需了解程序代碼的內(nèi)部構(gòu)造，完全模擬軟件產(chǎn)品的最終端用戶使用該軟件，檢查軟件產(chǎn)品是否達(dá)到了用戶的需求。 黑盒測試能更好的從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。,軟件測試分類 白盒測試,白盒測試又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序代碼內(nèi)部構(gòu)成的測試。 白盒測試需要測試工程師深入考查程序代碼的內(nèi)部結(jié)構(gòu)、邏輯設(shè)計等。 對于白盒測試工程師來說，軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)是敞開的。,軟件測試分類 灰盒測試,灰盒測試介于白盒和黑盒測試之間。 灰盒測試一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需

5、要考慮程序代碼的內(nèi)部結(jié)構(gòu)。 通俗地講，灰盒測試就是白加黑。,軟件測試分類 靜態(tài)測試,靜態(tài)測試，顧名思義，就是靜態(tài)的、不執(zhí)行被測對象程序代碼而尋找缺陷的過程。 通俗地講，靜態(tài)測試就是用眼睛看，閱讀程序代碼，文檔資料等，與需求規(guī)格說明書中的客戶需求進(jìn)行比較，找出程序代碼中設(shè)計不合理，以及文檔資料有錯誤的地方。 在進(jìn)行靜態(tài)測試時可采用一些代碼走查工具，如QA C+、C+ Test等。,軟件測試分類 動態(tài)測試,實際的執(zhí)行被測對象的程序代碼，輸入實現(xiàn)設(shè)計好的測試用例，檢查程序代碼運行得到的結(jié)果與測試用例中設(shè)計的預(yù)期結(jié)果之間是否有差異，判定實際結(jié)果與預(yù)測結(jié)果是否一致。 動態(tài)測試有四部分組成：設(shè)計測試用例、

6、執(zhí)行測試用例、分析比較輸出結(jié)果、輸出測試報告。,軟件測試分類 手動測試,它是測試人員設(shè)計測試用例并執(zhí)行測試用例，然后根據(jù)實際的結(jié)果去和預(yù)期的結(jié)果相比較并記錄測試結(jié)果，最終輸出測試報告的測試活動。 可充分發(fā)揮測試工程師的主觀能動性，將其智力體現(xiàn)在測試工作中，能發(fā)現(xiàn)許多的缺陷，但同時又有一定的局限性和單調(diào)枯燥性。,軟件測試分類 自動化測試,定義 利用測試工具，模擬用戶業(yè)務(wù)使用流程，讓他們自動運行來查找缺陷。 優(yōu)點 快、廣泛、可重復(fù)性工作 缺點 只可檢查比較主要的問題，如崩潰、死機，無法發(fā)現(xiàn)一般的日常錯誤。編寫腳本工作量也很大，有時會超過手動測試時間。 我們要根據(jù)實際情況選擇或者不選擇測試工具，選擇

7、使用何種測試工具，不能為了實用工具而可以的去使用工具。,軟件測試流程,軟件測試雖然是軟件生命周期的一個獨立階段，但測試工作卻滲透到從分析、設(shè)計直到編程的各個階段中。 需求測試、單元測試、集成測試、系統(tǒng)測試、性能測試、用戶測試、回歸測試,需求測試,在許多失敗的項目中，70%85%的返工是由于需求方面的錯誤所導(dǎo)致的，因此我們必須在項目的源頭（需求）就開始測試。 對被測軟件的需求規(guī)格說明書、概要設(shè)計文檔、詳細(xì)設(shè)計文檔、數(shù)據(jù)庫設(shè)計文檔等文檔資料進(jìn)行查閱，重點檢查需求規(guī)格說明書中是否存在描述不準(zhǔn)確、需求定義模糊、需求用例不正確、語言存在二義性等等問題。,單元測試,又稱模塊測試，就是對程序代碼中最小的涉及

8、模塊單元進(jìn)行測試。 在單元測試中我們主要采用靜態(tài)測試與動態(tài)測試相結(jié)合的辦法。 單元測試要求需要幾年的代碼編寫經(jīng)驗，并且要十分熟悉當(dāng)前的被測系統(tǒng)，以及該系統(tǒng)是否與其他系統(tǒng)的接口關(guān)聯(lián)情況。 單元測試在編碼階段占據(jù)非常重要的地位。 可以降低編碼的錯誤率，提高編碼質(zhì)量,集成測試,又稱組裝測試，是將軟件產(chǎn)品各個模塊組裝起來，檢查接口是否存在問題，以及組裝后的整體功能、性能表現(xiàn)。 一般可采用非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進(jìn)行測試，利用以黑盒測試為主，白盒測試為輔的測試方法進(jìn)行測試。 主要解決各個組成但源代碼是否符合開發(fā)規(guī)范、接口是否存在問題，整體功能有無錯誤

9、、界面是否符合設(shè)計規(guī)范、性能是否滿足用戶需求等。,系統(tǒng)測試,將通過集成測試的軟件部署到某種較為復(fù)雜的計算機用戶環(huán)境進(jìn)行測試。 目的：通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。 這個階段主要進(jìn)行的是安裝卸載測試、兼容性測試、功能確認(rèn)測試、安全測試等。 采用黑盒測試法，主要考察被測軟件的功能與性能表現(xiàn)。,性能測試,性能測試要求被測軟件在業(yè)務(wù)處理速度、處理能力和所耗用的硬件系統(tǒng)資源比率滿足用戶的需求。 不要嘗試用手動方式進(jìn)行性能測試，應(yīng)當(dāng)編寫一段相應(yīng)的程序或者使用專門的工具進(jìn)行，如利用LoadRunner自動化性能測試工具。 性能測試相對難度較大，要求測試人員掌握編程語

10、言，精通業(yè)務(wù)流程，擁有深厚的項目經(jīng)驗。,用戶測試,可稱為用戶確認(rèn)測試。 正式驗收前，需要用戶對本系統(tǒng)做出一個評價，用戶可對交付的系統(tǒng)做測試，并將測試結(jié)果反饋回來，進(jìn)行修改、分析。 用戶測試環(huán)節(jié)是被測試軟件首次作為正式的系統(tǒng)交友用戶使用，用戶會根據(jù)他們的實際使用情況進(jìn)行測試、使用，并提出實際使用過程中的問題。 用戶測試是軟件生產(chǎn)流程中的最后質(zhì)檢關(guān)。,回歸測試,回歸測試是經(jīng)過一段時間以后再回過頭來對以前修復(fù)過的Bug重新進(jìn)行測試，看該Bug是否會重新出現(xiàn)。 有些時候可采用自動化測試工具來進(jìn)行回歸測試，如利用QTP。 一般情況下，都由測試工程師手動的執(zhí)行以前的測試用例，來檢查用例通過情況。,軟件測試

11、工作階段,計劃與設(shè)計階段 實施測試階段 測試總結(jié)階段,計劃與設(shè)計階段-立項會議,由工程技術(shù)委員會召開立項會議，會議主要對項目的可行性進(jìn)行分析，并且確定項目經(jīng)理及項目測試組長。,計劃與設(shè)計階段-需求評審,注： 1需求定義基本完成，此時應(yīng)在評審會議召開之前發(fā)給測試團(tuán)隊，預(yù)留時間給測試相關(guān)人員熟悉、理解。 2測試部參與人員由測試部經(jīng)理指定，主要由測試組長、測試設(shè)計等人員組成（還應(yīng)包括配置管理人員、質(zhì)量保證人員）。,計劃與設(shè)計階段-測試工作啟動,在正式測試任務(wù)下達(dá)前，開發(fā)團(tuán)隊?wèi)?yīng)在項目（產(chǎn)品）開發(fā)計劃完成后及時向測試團(tuán)隊下達(dá)預(yù)通知，告之較為確切的測試日期，提供當(dāng)前最新的相關(guān)資料。部門經(jīng)理和測試組長組建測

12、試小組，并視具體情況決定是否需要調(diào)整人力、時間安排、測試環(huán)境等其它資源。測試小組成員可預(yù)先熟悉必要的項目（產(chǎn)品）資料。,計劃與設(shè)計階段-測試設(shè)計階段-設(shè)計測試計劃,針對需求分析文檔和項目開發(fā)計劃文檔測試完成后，測試組需要編寫測試計劃文檔、制定測試測略及預(yù)估測試過程中的風(fēng)險，并設(shè)計出合理的規(guī)避風(fēng)險的策略，為后續(xù)的測試工作提供直接的指導(dǎo)。,計劃與設(shè)計階段-測試設(shè)計階段-設(shè)計測試用例,在需求分析文檔確立基線以后，測試組需要針對項目的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標(biāo)準(zhǔn)。,計劃與設(shè)計階段-設(shè)計內(nèi)容評審,測試計劃及測試用例的設(shè)計工作完成后，需通知項目組相關(guān)成員召開評審會議。在這之前需要將待評審的內(nèi)容發(fā)給相關(guān)人員熟悉和理解。,實施測試階段-測試交接,實施測試階段-實施測試-按計劃進(jìn)行測試,實施測試用例將花費測試組大部分時間，這些工作都是建立在前期很多計劃工作的基礎(chǔ)上。,實施測試階段-實施測試-提交階段性報告,在約定的測試周期完成之后，測試組長需要總結(jié)此次測試的結(jié)果，編寫階段性測試報告。,實施測試階段-回歸測試,在每輪測試結(jié)束之后，由測試組重新拷貝修改后的最新版本，進(jìn)行回歸測試。,實施測試階段-同行審查,測試總結(jié)階段-測試總結(jié)報告,在回歸測試結(jié)束之后，測試組長將要編寫測試總結(jié)報告，對測試進(jìn)行總結(jié)，并且提交給