《軟件測(cè)試流程》 - 副本

1、整理課件軟件測(cè)試基礎(chǔ)教程杜文潔 景秀麗 主編中國水利水電出版社整理課件第三章 軟件測(cè)試流程第三章 軟件測(cè)試流程3.1 軟件測(cè)試的復(fù)雜性與經(jīng)濟(jì)性分析3.2 軟件測(cè)試的流程3.3 單元測(cè)試3.4 集成測(cè)試3.5 確認(rèn)測(cè)試3.6 系統(tǒng)測(cè)試3.7 驗(yàn)收測(cè)試習(xí)題 整理課件本章概要第三章 軟件測(cè)試流程軟件測(cè)試的復(fù)雜性和經(jīng)濟(jì)性軟件測(cè)試的相關(guān)流程：單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試等基本測(cè)試階段。整理課件3.1 軟件測(cè)試的復(fù)雜性與經(jīng)濟(jì)性分析第三章 軟件測(cè)試流程 人們?cè)趯?duì)軟件工程開發(fā)的常規(guī)認(rèn)識(shí)中，認(rèn)為開發(fā)程序是一個(gè)復(fù)雜而困難的過程，需要花費(fèi)大量的人力、物力和時(shí)間，而測(cè)試一個(gè)程序則比較容易，不需要花

2、費(fèi)太多的精力。這其實(shí)是人們對(duì)軟件工程開發(fā)過程理解上的一個(gè)誤區(qū)。在實(shí)際的軟件開發(fā)過程中，作為現(xiàn)代軟件開發(fā)工業(yè)一個(gè)非常重要的組成部分，軟件測(cè)試正扮演著越來越重要的角色。隨著軟件規(guī)模的不斷擴(kuò)大，如何在有限的條件下對(duì)被開發(fā)軟件進(jìn)行有效的測(cè)試正成為軟件工程中一個(gè)非常關(guān)鍵的課題。整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流程設(shè)計(jì)測(cè)試用例是一項(xiàng)細(xì)致并且需要具備高度技巧的工作，稍有不慎就會(huì)顧此失彼，發(fā)生不應(yīng)有的疏漏。下面分析了容易出現(xiàn)問題的根源。(1) 完全測(cè)試是不現(xiàn)實(shí)的在實(shí)際的軟件測(cè)試工作中，不論采用什么方法，由于軟件測(cè)試情況數(shù)量極其巨大，都不可能進(jìn)行完全徹底的測(cè)試。所謂徹底測(cè)試，就是讓被測(cè)程序在

3、一切可能的輸入情況下全部執(zhí)行一遍。通常也稱這種測(cè)試為“窮舉測(cè)試”。窮舉測(cè)試會(huì)引起以下幾種問題： 輸入量太大； 輸出結(jié)果太多； 軟件執(zhí)行路徑太多； 說明書存在主觀性。整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流程E.W.Dijkstra的一句名言對(duì)測(cè)試的不徹底性作了很好的注解：“程序測(cè)試只能證明錯(cuò)誤的存在，但不能證明錯(cuò)誤的不存在”。由于窮舉測(cè)試工作量太大，實(shí)踐上行不通，這就注定了一切實(shí)際測(cè)試都是不徹底的，也就不能夠保證被測(cè)試程序在理論上不存在遺留的錯(cuò)誤。整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流程(2) 軟件測(cè)試是有風(fēng)險(xiǎn)的窮舉測(cè)試的不可行性使得大多數(shù)軟件在進(jìn)行測(cè)試的時(shí)候只能

4、采取非窮舉測(cè)試，這又意味著一種冒險(xiǎn)。比如在使用Microsoft Office工具中的Word時(shí)，可以作這樣的一個(gè)測(cè)試：新建一個(gè)Word文檔；在文檔中輸入漢字 “胡”；設(shè)置其字體屬性為“隸書”，字號(hào)為初號(hào)，效果為“ 空心”；將頁面的顯示比例設(shè)為“500%”。這時(shí)在“胡”字的內(nèi)部會(huì)出現(xiàn)“胡萬進(jìn)印”四個(gè)字。類似問題在實(shí)際測(cè)試中如果不使用窮舉測(cè)試是很難發(fā)現(xiàn)的，而如果在軟件投入市場時(shí)才發(fā)現(xiàn)則修復(fù)代價(jià)就會(huì)非常高。這就會(huì)產(chǎn)生一個(gè)矛盾：軟件測(cè)試員不能做到完全的測(cè)試，不完全測(cè)試又不能證明軟件的百分之百的可靠。那么如何在這兩者的矛盾中找到一個(gè)相對(duì)的平衡點(diǎn)呢？整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流

5、程如圖3-1所示的最優(yōu)測(cè)試量示意圖可以觀察到，當(dāng)軟件缺陷降低到某一數(shù)值后，隨著測(cè)試從量的不斷上升軟件缺陷并沒有明顯地下降。這是軟件測(cè)試工作中需要注意的重要問題。如何把測(cè)試數(shù)據(jù)量巨大的軟件測(cè)試減少到可以控制的范圍，如何針對(duì)風(fēng)險(xiǎn)做出最明智的選擇是軟件測(cè)試人員必須能夠把握的關(guān)鍵問題。圖3-1的最優(yōu)測(cè)試量示意圖說明了發(fā)現(xiàn)軟件缺陷數(shù)量和測(cè)試量之間的關(guān)系，隨著測(cè)試量的增加，測(cè)試成本將呈幾何數(shù)級(jí)上升，而軟件缺陷降低到某一數(shù)值之后將沒有明顯的變化，最優(yōu)測(cè)量值就是這兩條曲線的交點(diǎn)。整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流程圖3-1 最優(yōu)測(cè)試量示意圖整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)

6、試流程(3) 殺蟲劑現(xiàn)象1990年，Boris Beizer在其編著的Software Testing Techniques（第二版）中提到了“殺蟲劑怪事”一詞，同一種測(cè)試工具或方法用于測(cè)試同一類軟件越多，則被測(cè)試軟件對(duì)測(cè)試的免疫力就越強(qiáng)。這與農(nóng)藥殺蟲是一樣的，老用一種農(nóng)藥，則害蟲就有了免疫力，農(nóng)藥就失去了作用。由于軟件開發(fā)人員在開發(fā)過程中可能碰見各種各樣的主客觀因素，再加上不可預(yù)見的突發(fā)性事件，所以再優(yōu)秀的軟件測(cè)試員采用一種測(cè)試方法或者工具也不可能檢測(cè)出所有的缺陷。為了克服被測(cè)試軟件的免疫力，軟件測(cè)試員必須不斷編寫新的測(cè)試程序，對(duì)程序的各個(gè)部分進(jìn)行不斷地測(cè)試，以避免被測(cè)試軟件對(duì)單一的測(cè)試程序

7、具有免疫力而使軟件缺陷不被發(fā)現(xiàn)。這就對(duì)軟件測(cè)試人員的素質(zhì)提出了很高的要求。整理課件3.1.1 軟件測(cè)試的復(fù)雜性第三章 軟件測(cè)試流程(4) 缺陷的不確定性在軟件測(cè)試中還有一個(gè)讓人不容易判斷的現(xiàn)象是缺陷的不確定性。即并不是所有的軟件缺陷都需要被修復(fù)。對(duì)于究竟什么才算是軟件缺陷是一個(gè)很難把握的標(biāo)準(zhǔn)，在任何一本軟件測(cè)試的書中都只能給出一個(gè)籠統(tǒng)的定義。實(shí)際測(cè)試中需要把這一定義根據(jù)具體的被測(cè)對(duì)象明確化。即使這樣，具體的測(cè)試人員對(duì)軟件系統(tǒng)的理解不同，還是會(huì)出現(xiàn)不同的標(biāo)準(zhǔn)。整理課件3.1.2 軟件測(cè)試的經(jīng)濟(jì)性第三章 軟件測(cè)試流程軟件測(cè)試的經(jīng)濟(jì)性有兩方面體現(xiàn)：一是體現(xiàn)在測(cè)試工作在整個(gè)項(xiàng)目開發(fā)過程中的重要地位；二

8、是體現(xiàn)在應(yīng)該按照什么樣的原則進(jìn)行測(cè)試，以實(shí)現(xiàn)測(cè)試成本與測(cè)試效果的統(tǒng)一。軟件工程的總目標(biāo)是充分利用有限的人力和物力資源，高效率、高質(zhì)量地完成測(cè)試。結(jié)合3.1.1節(jié)關(guān)于窮舉測(cè)試具有不可行性，就可以理解為什么要在測(cè)試量與測(cè)試成本的曲線中選取最優(yōu)測(cè)試點(diǎn)。整理課件3.1.3 軟件測(cè)試的充分性準(zhǔn)則第三章 軟件測(cè)試流程軟件測(cè)試的充分性準(zhǔn)則有以下幾點(diǎn)：對(duì)任何軟件都存在有限的充分測(cè)試集合； 當(dāng)一個(gè)測(cè)試的數(shù)據(jù)集合對(duì)于一個(gè)被測(cè)的軟件系統(tǒng)的測(cè)試是充分的，那么再多增加一些測(cè)試數(shù)據(jù)仍然是充分的。這一特性稱為軟件測(cè)試的單調(diào)性；即使對(duì)軟件所有成分都進(jìn)行了充分的測(cè)試，也并不意味著整個(gè)軟件的測(cè)試已經(jīng)充分了。這一特性稱為軟件測(cè)試的

9、非復(fù)合性；即使對(duì)一個(gè)軟件系統(tǒng)整體的測(cè)試是充分的，也并不意味著軟件系統(tǒng)中各個(gè)成分都已經(jīng)充分地得到了測(cè)試。這個(gè)特性稱為軟件測(cè)試的非分解性；軟件測(cè)試的充分性與軟件的需求、軟件的實(shí)現(xiàn)都相關(guān)；軟件測(cè)試的數(shù)據(jù)量正比于軟件的復(fù)雜度。這一特性稱為軟件測(cè)試的復(fù)雜性；隨著測(cè)試次數(shù)的增加，檢查出軟件缺陷的幾率隨之不斷減少。軟件測(cè)試具有回報(bào)遞減率。整理課件3.1.4 軟件測(cè)試的誤區(qū)第三章 軟件測(cè)試流程隨著軟件產(chǎn)業(yè)工業(yè)化、模塊化地發(fā)展，在軟件開發(fā)組中軟件測(cè)試人員的重要性也不斷地突出。在國外，很多著名企業(yè)早已對(duì)軟件測(cè)試工作十分重視。比如著名的微軟公司，其軟件測(cè)試人員與開發(fā)人員的比例已經(jīng)達(dá)到2:1。可見軟件測(cè)試對(duì)于一個(gè)軟件

10、開發(fā)項(xiàng)目的成功與否具有十分重要的意義。但是在實(shí)際的項(xiàng)目開發(fā)與管理中仍然存在很多管理上或者技術(shù)上的誤區(qū)：(1) 期望用測(cè)試自動(dòng)化代替大部分人工勞動(dòng)(2) 忽視需求階段的參與(3) 軟件測(cè)試是技術(shù)要求不高的崗位整理課件3.2 軟件測(cè)試的流程第三章 軟件測(cè)試流程1軟件開發(fā)的V模型軟件測(cè)試是有階段性的，而軟件測(cè)試的流程與軟件設(shè)計(jì)周期究竟是什么樣的關(guān)系呢？關(guān)于軟件開發(fā)流程的V模型是一個(gè)廣為人知的模型,如圖3-2所示。在V模型中，從左到右描述了基本的開發(fā)過程和測(cè)試行為，為軟件的開發(fā)人員和測(cè)試管理者提供了一個(gè)極為簡單的框架。V模型的價(jià)值在于它非常明確地標(biāo)明了測(cè)試過程中存在的不同級(jí)別，并且清楚地描述了這些測(cè)試

11、階段和開發(fā)過程期間各階段的對(duì)應(yīng)關(guān)系。在V模型中各個(gè)測(cè)試階段的執(zhí)行流程是：單元測(cè)試是基于代碼的測(cè)試，最初由開發(fā)人員執(zhí)行，以驗(yàn)證其可執(zhí)行程序代碼的各個(gè)部分是否已達(dá)到了預(yù)期的功能要求；集成測(cè)試驗(yàn)證了兩個(gè)或多個(gè)單元之間的集成是否正確，并且有針對(duì)性地對(duì)詳細(xì)設(shè)計(jì)中所定義的各單元之間的接口進(jìn)行檢查；在單元測(cè)試和集成測(cè)試完成之后，系統(tǒng)測(cè)試開始用客戶環(huán)境模擬系統(tǒng)的運(yùn)行，以驗(yàn)證系統(tǒng)是否達(dá)到了在概要設(shè)計(jì)中所定義的功能和性能；最后，當(dāng)技術(shù)部門完成了所有測(cè)試工作，由業(yè)務(wù)專家或用戶進(jìn)行驗(yàn)收測(cè)試，以確保產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。圖3-2描繪出了各個(gè)測(cè)試環(huán)節(jié)在整個(gè)軟件測(cè)試工作中的相互聯(lián)系與制約關(guān)系。整理課件3.2 軟件

12、測(cè)試的流程第三章 軟件測(cè)試流程圖3-2 V模型示意圖整理課件3.2 軟件測(cè)試的流程第三章 軟件測(cè)試流程2軟件測(cè)試過程軟件測(cè)試過程按各測(cè)試階段的先后順序可分為單元測(cè)試、集成測(cè)試、確認(rèn)（有效性）測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收（用戶）測(cè)試5個(gè)階段，如圖3-3所示。(1) 單元測(cè)試：測(cè)試執(zhí)行的開始階段。測(cè)試對(duì)象是每個(gè)單元。測(cè)試目的是保證每個(gè)模塊或組件能正常工作。單元測(cè)試主要采用白盒測(cè)試方法，檢測(cè)程序的內(nèi)部結(jié)構(gòu)。(2) 集成測(cè)試：也稱組裝測(cè)試。在單元測(cè)試基礎(chǔ)上，對(duì)已測(cè)試過的模塊進(jìn)行組裝，進(jìn)行集成測(cè)試。測(cè)試目的是檢驗(yàn)與接口有關(guān)的模塊之間的問題。集成測(cè)試主要采用黑盒測(cè)試方法。(3) 確認(rèn)測(cè)試：也稱有效性測(cè)試。在完成集

13、成測(cè)試后，驗(yàn)證軟件的功能和性能及其他特性是否符合用戶要求。測(cè)試目的是保證系統(tǒng)能夠按照用戶預(yù)定的要求工作。確認(rèn)測(cè)試通常采用黑盒測(cè)試方法。(4) 系統(tǒng)測(cè)試：在完成確認(rèn)測(cè)試后，為了檢驗(yàn)它能否與實(shí)際環(huán)境（如軟硬件平臺(tái)、數(shù)據(jù)和人員等）協(xié)調(diào)工作，還需要進(jìn)行系統(tǒng)測(cè)試?？梢哉f，系統(tǒng)測(cè)試之后，軟件產(chǎn)品基本滿足開發(fā)要求。(5) 驗(yàn)收測(cè)試：測(cè)試過程的最后一個(gè)階段。驗(yàn)收測(cè)試主要突出用戶的作用，同時(shí)軟件開發(fā)人員也應(yīng)該參與進(jìn)去。整理課件3.2 軟件測(cè)試的流程第三章 軟件測(cè)試流程軟件測(cè)試階段的輸入信息包括兩類： 軟件配置：指測(cè)試對(duì)象。通常包括需求說明書、設(shè)計(jì)說明書和被測(cè)試的源程序等； 測(cè)試配置：通常包括測(cè)試計(jì)劃、測(cè)試步驟、

14、測(cè)試用例以及具體實(shí)施測(cè)試的測(cè)試程序、測(cè)試工具等。對(duì)測(cè)試結(jié)果與預(yù)期的結(jié)果進(jìn)行比較以后，即可判斷是否存在錯(cuò)誤，決定是否進(jìn)入排錯(cuò)階段，進(jìn)行調(diào)試任務(wù)。對(duì)修改以后的程序要進(jìn)行重新測(cè)試，因?yàn)樾薷目赡軙?huì)帶來新的問題。通常根據(jù)出錯(cuò)的情況得到出錯(cuò)率來預(yù)估被測(cè)軟件的可靠性，這將對(duì)軟件運(yùn)行后的維護(hù)工作有重要價(jià)值。整理課件3.2 軟件測(cè)試的流程第三章 軟件測(cè)試流程圖3-3 測(cè)試各階段示意圖整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程1單元測(cè)試的定義單元測(cè)試（Unit Testing）是對(duì)軟件基本組成單元進(jìn)行的測(cè)試。單元測(cè)試的對(duì)象是軟件設(shè)計(jì)的最小單位模塊。很多人將單元的概念誤解為一個(gè)具體函數(shù)或一個(gè)類的方法，這種理解并不

15、準(zhǔn)確。作為一個(gè)最小的單元應(yīng)該有明確的功能定義、性能定義和接口定義，而且可以清晰地與其他單元區(qū)分開來。一個(gè)菜單、一個(gè)顯示界面或者能夠獨(dú)立完成的具體功能都可以是一個(gè)單元。從某種意義上單元的概念已經(jīng)擴(kuò)展為組件（component）。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程2單元測(cè)試的目標(biāo)單元測(cè)試的主要目標(biāo)是確保各單元模塊被正確地編碼。單元測(cè)試除了保證測(cè)試代碼的功能性，還需要保證代碼在結(jié)構(gòu)上具有可靠性和健全性，并且能夠在所有條件下正確響應(yīng)。進(jìn)行全面的單元測(cè)試，可以減少應(yīng)用級(jí)別所需的工作量，并且徹底減少系統(tǒng)產(chǎn)生錯(cuò)誤的可能性。如果手動(dòng)執(zhí)行，單元測(cè)試可能需要大量的工作，自動(dòng)化測(cè)試會(huì)提高測(cè)試效率。整理課件

16、3.3 單元測(cè)試第三章 軟件測(cè)試流程3單元測(cè)試的內(nèi)容單元測(cè)試的主要內(nèi)容有：模塊接口測(cè)試；局部數(shù)據(jù)結(jié)構(gòu)測(cè)試；獨(dú)立路徑測(cè)試；錯(cuò)誤處理測(cè)試；邊界條件測(cè)試。如圖3-4所示，這些測(cè)試都作用于模塊，共同完成單元測(cè)試任務(wù)。模塊接口測(cè)試：對(duì)通過被測(cè)模塊的數(shù)據(jù)流進(jìn)行測(cè)試。為此，對(duì)模塊接口，包括參數(shù)表、調(diào)用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入/輸出操作都必須檢查。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程局部數(shù)據(jù)結(jié)構(gòu)測(cè)試：設(shè)計(jì)測(cè)試用例檢查數(shù)據(jù)類型說明、初始化、默認(rèn)值等方面的問題，還要查清全程數(shù)據(jù)對(duì)模塊的影響。獨(dú)立路徑測(cè)試：選擇適當(dāng)?shù)臏y(cè)試用例，對(duì)模塊中重要的執(zhí)行路徑進(jìn)行測(cè)試。基本路徑測(cè)試和循環(huán)測(cè)試可以發(fā)現(xiàn)大量的路徑錯(cuò)

17、誤，是最常用且最有效的測(cè)試技術(shù)。錯(cuò)誤處理測(cè)試：檢查模塊的錯(cuò)誤處理功能是否包含有錯(cuò)誤或缺陷。例如，是否拒絕不合理的輸入；出錯(cuò)的描述是否難以理解、是否對(duì)錯(cuò)誤定位有誤、是否出錯(cuò)原因報(bào)告有誤、是否對(duì)錯(cuò)誤條件的處理不正確；在對(duì)錯(cuò)誤處理之前錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等。邊界條件測(cè)試：要特別注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性。對(duì)這些地方要仔細(xì)地選擇測(cè)試用例，認(rèn)真加以測(cè)試。此外，如果對(duì)模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測(cè)試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。這類信息對(duì)進(jìn)行性能評(píng)價(jià)是十分有用的。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程4單元測(cè)試

18、的步驟通常單元測(cè)試在編碼階段進(jìn)行。當(dāng)源程序代碼編制完成，經(jīng)過評(píng)審和驗(yàn)證，確認(rèn)沒有語法錯(cuò)誤之后，就開始進(jìn)行單元測(cè)試的測(cè)試用例設(shè)計(jì)。利用設(shè)計(jì)文檔，設(shè)計(jì)可以驗(yàn)證程序功能、找出程序錯(cuò)誤的多個(gè)測(cè)試用例。對(duì)于每一組輸入，應(yīng)有預(yù)期的正確結(jié)果。模塊接口測(cè)試中的被測(cè)模塊并不是一個(gè)獨(dú)立的程序，在考慮測(cè)試模塊時(shí)，同時(shí)要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測(cè)模塊相關(guān)聯(lián)的模塊。這些輔助模塊可分為兩種：(1) 驅(qū)動(dòng)模塊（driver）：相當(dāng)于被測(cè)模塊的主程序。它接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測(cè)模塊，最后輸出實(shí)測(cè)結(jié)果。(2) 樁模塊（stub）：用以代替被測(cè)模塊調(diào)用的子模塊。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子

19、模塊所有功能都帶進(jìn)來，但不允許什么事情也不做。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程被測(cè)模塊、與它相關(guān)的驅(qū)動(dòng)模塊以及樁模塊共同構(gòu)成了一個(gè)“測(cè)試環(huán)境”，如圖3-5所示。如果一個(gè)模塊要完成多種功能，并且以程序包或?qū)ο箢惖男问匠霈F(xiàn)，例如Ada中的包，MODULA中的模塊，C+中的類，這時(shí)可以將模塊看成由幾個(gè)小程序組成。對(duì)其中的每個(gè)小程序先進(jìn)行單元測(cè)試要做的工作，對(duì)關(guān)鍵模塊還要做性能測(cè)試。對(duì)支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進(jìn)行互聯(lián)測(cè)試。有人把這種情況特別稱為模塊測(cè)試，以區(qū)別單元測(cè)試。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程圖3-4 單元測(cè)試任務(wù)整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程5采

20、用單元測(cè)試的原因程序員編寫代碼時(shí)，一定會(huì)反復(fù)調(diào)試保證其能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會(huì)愿意交付給自己的老板。但代碼通過編譯，只是說明了它的語法正確，程序員卻無法保證它的語義也一定正確。沒有任何人可以輕易承諾這段代碼的行為一定是正確的。單元測(cè)試這時(shí)會(huì)為此做出保證。編寫單元測(cè)試就是用來驗(yàn)證這段代碼的行為是否與軟件開發(fā)人員期望的一致。有了單元測(cè)試，程序員可以自信的交付自己的代碼，而沒有任何的后顧之憂。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程圖3-5 單元測(cè)試環(huán)境整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程通過單元測(cè)試，測(cè)試人員可以驗(yàn)證開發(fā)人員所編寫的代碼是按照先前設(shè)想的方式進(jìn)

21、行的，輸出結(jié)果符合預(yù)期值，這就實(shí)現(xiàn)了單元測(cè)試的目的。與后面的測(cè)試相比，單元測(cè)試創(chuàng)建簡單，維護(hù)容易，并且可以更方便的進(jìn)行重復(fù)。實(shí)用軟件度量（Capers Jones，McGraw-Hill 1991）列出了準(zhǔn)備測(cè)試、執(zhí)行測(cè)試和修改缺陷所花費(fèi)的時(shí)間（以一個(gè)功能點(diǎn)為基準(zhǔn)），這些測(cè)試顯示出了單元測(cè)試的成本效率大約是集成測(cè)試的兩倍、系統(tǒng)測(cè)試的三倍，如圖3-6所示。術(shù)語域測(cè)試是指軟件在投入使用后，針對(duì)某個(gè)領(lǐng)域所作的所有測(cè)試活動(dòng)。整理課件3.3 單元測(cè)試第三章 軟件測(cè)試流程圖3-6 各測(cè)試階段發(fā)現(xiàn)缺陷的耗時(shí)整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程1集成測(cè)試的定義在完成單元測(cè)試的基礎(chǔ)上，需要將所有模塊按照

22、設(shè)計(jì)要求組裝成為系統(tǒng)。這時(shí)需要考慮以下問題：在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；單個(gè)模塊的誤差累積起來，是否會(huì)放大，從而達(dá)到不能接受的程度；單個(gè)模塊的錯(cuò)誤是否會(huì)導(dǎo)致數(shù)據(jù)庫錯(cuò)誤。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程集成測(cè)試（Integration Testing）是介于單元測(cè)試和系統(tǒng)測(cè)試之間的過渡階段，與軟件開發(fā)計(jì)劃中的軟件概要設(shè)計(jì)階段相對(duì)應(yīng)，是單元測(cè)試的擴(kuò)展和延伸。集成測(cè)試的定義是根據(jù)實(shí)際情況對(duì)程序模塊采用適當(dāng)?shù)募蓽y(cè)試策略組裝起來，對(duì)系統(tǒng)的

23、接口以及集成后的功能進(jìn)行正確校驗(yàn)的測(cè)試工作。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程2集成測(cè)試的層次軟件的開發(fā)過程是一個(gè)從需求分析到概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)以及編碼實(shí)現(xiàn)的逐步細(xì)化的過程，那么單元測(cè)試到集成測(cè)試再到系統(tǒng)測(cè)試就是一個(gè)逆向求證的過程。集成測(cè)試內(nèi)部對(duì)于傳統(tǒng)軟件和面向?qū)ο蟮膽?yīng)用系統(tǒng)有兩種層次的劃分。對(duì)于傳統(tǒng)軟件來講，可以把集成測(cè)試劃分為三個(gè)層次：模塊內(nèi)集成測(cè)試；子系統(tǒng)內(nèi)集成測(cè)試；子系統(tǒng)間集成測(cè)試。對(duì)于面向?qū)ο蟮膽?yīng)用系統(tǒng)來說，可以把集成測(cè)試分為兩個(gè)階段：類內(nèi)集成測(cè)試；類間集成測(cè)試。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程3集成測(cè)試的模式選擇什么方式把模塊組裝起來形成一個(gè)可運(yùn)行的系統(tǒng)，直接

24、影響到模塊測(cè)試用例的形式、所用測(cè)試工具的類型、模塊編號(hào)的次序和測(cè)試的次序、生成測(cè)試用例的費(fèi)用和調(diào)試的費(fèi)用。集成測(cè)試模式是軟件集成測(cè)試中的策略體現(xiàn)，其重要性是明顯的，直接關(guān)系到軟件測(cè)試的效率、結(jié)果等，一般是根據(jù)軟件的具體情況來決定采用哪種模式。通常，把模塊組裝成為系統(tǒng)的測(cè)試方式有兩種：一次性集成測(cè)試方式（No-Incremental Integration）一次性集成測(cè)試方式也稱作非增值式集成測(cè)試。先分別測(cè)試每個(gè)模塊，再把所有模塊按設(shè)計(jì)要求放在一起結(jié)合成所需要實(shí)現(xiàn)的程序。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程如圖3-7是所示按照一次性集成測(cè)試方式的實(shí)例。如圖3-7（a）所示表示的是整個(gè)系統(tǒng)

25、結(jié)構(gòu)，共包含6個(gè)模塊。具體測(cè)試過程如下： 如圖3-7（b）所示，為模塊B配備驅(qū)動(dòng)模塊D1，來模擬模塊A對(duì)B的調(diào)用。為模塊B配備樁模塊S1，來模擬模塊E被B調(diào)用。對(duì)模塊B進(jìn)行單元測(cè)試； 如圖3-7（d）所示，為模塊D配備驅(qū)動(dòng)模塊D3，來模擬模塊A對(duì)D的調(diào)用。為模塊D配備樁模塊S2，來模擬模塊F被D調(diào)用。對(duì)模塊D進(jìn)行單元測(cè)試； 如圖3-7（c）、圖3-7（e）、圖3-7（f）所示，為模塊C、E、F分別配備驅(qū)動(dòng)模塊D2、D4、D5。對(duì)模塊C、E、F分別進(jìn)行單元測(cè)試； 如圖3-7（g）表示，為主模塊A配備三個(gè)樁模塊S3、S4、S5。對(duì)模塊A進(jìn)行單元測(cè)試； 在將模塊A、B、C、D、E分別進(jìn)行了單元測(cè)試之

26、后，再一次性進(jìn)行集成測(cè)試； 測(cè)試結(jié)束。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程圖3-7 一次性集成測(cè)試方式整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程增值式集成測(cè)試方式把下一個(gè)要測(cè)試的模塊同已經(jīng)測(cè)好的模塊結(jié)合起來進(jìn)行測(cè)試，測(cè)試完畢，再把下一個(gè)應(yīng)該測(cè)試的模塊結(jié)合進(jìn)來繼續(xù)進(jìn)行測(cè)試。在組裝的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。通過增值逐步組裝成為預(yù)先要求的軟件系統(tǒng)。增值式集成測(cè)試方式有三種： 自頂向下增值測(cè)試方式（Top-down Integration）主控模塊作為測(cè)試驅(qū)動(dòng)，所有與主控模塊直接相連的模塊作為樁模塊；根據(jù)集成的方式（深度或廣度），每次用一個(gè)模塊把從屬的樁模塊替換成真正

27、的模塊；在每個(gè)模塊被集成時(shí)，都必須已經(jīng)進(jìn)行了單元測(cè)試；進(jìn)行回歸測(cè)試以確定集成新模塊后沒有引入錯(cuò)誤。這種組裝方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿著控制層次自頂向下進(jìn)行組裝。自頂向下的增值方式在測(cè)試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能。整理課件如圖3-8所示表示的是按照深度優(yōu)先方式遍歷的自頂向下增值的集成測(cè)試實(shí)例。具體測(cè)試過程如下： 在樹狀結(jié)構(gòu)圖中，按照先左后右的順序確定模塊集成路線； 如圖3-8（a）所示，先對(duì)頂層的主模塊A進(jìn)行單元測(cè)試。就是對(duì)模塊A配以樁模塊S1、S2和S3，用來模擬它所實(shí)際調(diào)用的模塊B、C、D，然后進(jìn)行測(cè)試； 如圖3-8

28、（b）所示，用實(shí)際模塊B替換掉樁模塊S1，與模塊A連接，再對(duì)模塊B配以樁模塊S4，用來模擬模塊B對(duì)E的調(diào)用，然后進(jìn)行測(cè)試； 圖3-8（c）是將模塊E替換掉樁模塊S4并與模塊B相連，然后進(jìn)行測(cè)試； 判斷模塊E沒有葉子結(jié)點(diǎn)，也就是說以A為根結(jié)點(diǎn)的樹狀結(jié)構(gòu)圖中的最左側(cè)分支深度遍歷結(jié)束。轉(zhuǎn)向下一個(gè)分支； 圖3-8（d）所示，模塊C替換掉樁模塊S2，連到模塊A上，然后進(jìn)行測(cè)試； 判斷模塊C沒有樁模塊，轉(zhuǎn)到樹狀結(jié)構(gòu)圖的最后一個(gè)分支； 如圖3-8（e）所示,模塊D替換掉樁模塊S3，連到模塊A上，同時(shí)給模塊D配以樁模塊S5，來模擬其對(duì)模塊F的調(diào)用。然后進(jìn)行測(cè)試； 如圖3-8（f）所示，去掉樁模塊S5，替換成實(shí)

29、際模塊F連接到模塊D上，然后進(jìn)行測(cè)試； 對(duì)樹狀結(jié)構(gòu)圖進(jìn)行了完全測(cè)試，測(cè)試結(jié)束。3.4 集成測(cè)試第三章 軟件測(cè)試流程整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程圖3-8 自頂向下增值測(cè)試方式整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程 自底向上增值測(cè)試方式（Bottom-up Integration）組裝從最底層的模塊開始，組合成一個(gè)構(gòu)件，用以完成指定的軟件子功能。編制驅(qū)動(dòng)程序，協(xié)調(diào)測(cè)試用例的輸入與輸出；測(cè)試集成后的構(gòu)件；按程序結(jié)構(gòu)向上組裝測(cè)試后的構(gòu)件，同時(shí)除掉驅(qū)動(dòng)程序。這種組裝的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始組裝和測(cè)試。因?yàn)槟K是自底向上進(jìn)行組裝，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包

30、括子模塊的所有下屬模塊）已經(jīng)組裝并測(cè)試完成，所以不再需要樁模塊。在模塊的測(cè)試過程中如果需要從子模塊得到信息時(shí)可以直接運(yùn)行子模塊獲得。如圖3-9表示的是按照自底向上增值的集成測(cè)試?yán)?。首先，?duì)處于樹狀結(jié)構(gòu)圖中葉子結(jié)點(diǎn)位置的模塊E、C、F進(jìn)行單元測(cè)試，如圖3-9（a）、圖3-9（b）和圖3-9（c）所示，分別配以驅(qū)動(dòng)模塊D1、D2和D3，用來模擬模塊B、模塊A和模塊D對(duì)它們的調(diào)用。然后，如圖3-9（d）和圖3-9（e）所示，去掉驅(qū)動(dòng)模塊D1和D3，替換成模塊B和D分別與模塊E和F相連，并且設(shè)立驅(qū)動(dòng)模塊D4和D5進(jìn)行局部集成測(cè)試。最后，如圖3-9（f）所示，對(duì)整個(gè)系統(tǒng)結(jié)構(gòu)進(jìn)行集成測(cè)試。整理課件3.4

31、 集成測(cè)試第三章 軟件測(cè)試流程圖3-9 自底向上增值測(cè)試方式整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程 混合增值測(cè)試方式（Modified Top-down Integration）自頂向下增值的方式和自底向上增值的方式各有優(yōu)缺點(diǎn)。自頂向下增值方式的缺點(diǎn)是需要建立樁模塊。要使樁模塊能夠模擬實(shí)際子模塊的功能是十分困難的，同時(shí)涉及復(fù)雜算法。真正輸入輸出的模塊處在底層，它們是最容易出問題的模塊，并且直到組裝和測(cè)試的后期才遇到這些模塊，一旦發(fā)現(xiàn)問題，會(huì)導(dǎo)致過多的回歸測(cè)試。自頂向下增值方式的優(yōu)點(diǎn)是能夠較早地發(fā)現(xiàn)在主要控制方面存在問題。自底向上增值方式的缺點(diǎn)是“程序一直未能作為一個(gè)實(shí)體存在，直到最后一個(gè)

32、模塊加上去后才形成一個(gè)實(shí)體”。就是說，在自底向上組裝和測(cè)試的過程中，對(duì)主要的控制直到最后才接觸到。自底向上增值方式的優(yōu)點(diǎn)是不需要樁模塊，建立驅(qū)動(dòng)模塊一般比建立樁模塊容易，同時(shí)由于涉及到復(fù)雜算法和真正輸入輸出的模塊最先得到組裝和測(cè)試，可以把最容易出問題的部分在早期解決。此外自底向上增值的方式可以實(shí)施多個(gè)模塊的并行測(cè)試。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程有鑒于此，通常是把以上兩種方式結(jié)合起來進(jìn)行組裝和測(cè)試。 改進(jìn)的自頂向下增值測(cè)試：基本思想是強(qiáng)化對(duì)輸入輸出模塊和引入新算法模塊的測(cè)試，并自底向上組裝成為功能相當(dāng)完整且相對(duì)獨(dú)立的子系統(tǒng)，然后由主模塊開始自頂向下進(jìn)行增值測(cè)試； 自底向上自頂向下

33、的增值測(cè)試（混和法）：首先對(duì)含讀操作的子系統(tǒng)自底向上直至根結(jié)點(diǎn)模塊進(jìn)行組裝和測(cè)試，然后對(duì)含寫操作的子系統(tǒng)做自頂向下的組裝與測(cè)試； 回歸測(cè)試：這種方式采取自頂向下的方式測(cè)試被修改的模塊及其子模塊，然后將這一部分視為子系統(tǒng)，再自底向上測(cè)試，以檢查該子系統(tǒng)與其上級(jí)模塊的接口是否適配。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程一次性集成測(cè)試方式與增值式集成測(cè)試方式的比較 增值式集成方式需要編寫的軟件較多，工作量較大，花費(fèi)的時(shí)間較多。一次性集成方式的工作量較?。?增值式集成方式發(fā)現(xiàn)問題的時(shí)間比一次性集成方式早； 增值式集成方式比一次性集成方式更容易判斷出問題的所在，因?yàn)槌霈F(xiàn)的問題往往和最后加進(jìn)來的模塊

34、有關(guān)； 增值式集成方式測(cè)試的更為徹底； 使用一次性集成方式可以多個(gè)模塊并行測(cè)試。這兩種模式各有利弊，在時(shí)間條件允許的情況下采用增值式集成測(cè)試方式有一定的優(yōu)勢(shì)。整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程集成測(cè)試的組織和實(shí)施 集成測(cè)試是一種正規(guī)測(cè)試過程，必須精心計(jì)劃，并與單元測(cè)試的完成時(shí)間協(xié)調(diào)起來。在制定測(cè)試計(jì)劃時(shí)，應(yīng)考慮如下因素： 是采用何種系統(tǒng)組裝方法來進(jìn)行組裝測(cè)試； 組裝測(cè)試過程中連接各個(gè)模塊的順序； 模塊代碼編制和測(cè)試進(jìn)度是否與組裝測(cè)試的順序一致； 測(cè)試過程中是否需要專門的硬件設(shè)備。（5）集成測(cè)試完成的標(biāo)志判定集成測(cè)試過程是否完成，可按以下幾個(gè)方面檢查： 成功地執(zhí)行了測(cè)試計(jì)劃中規(guī)定的所有

35、集成測(cè)試； 修正了所發(fā)現(xiàn)的錯(cuò)誤； 測(cè)試結(jié)果通過了專門小組的評(píng)審。 整理課件3.4 集成測(cè)試第三章 軟件測(cè)試流程（6）采用集成測(cè)試的原因所有的軟件項(xiàng)目都不能擺脫系統(tǒng)集成這個(gè)階段。不管采用什么開發(fā)模式，具體的開發(fā)工作總得從一個(gè)一個(gè)的軟件單元做起，軟件單元只有經(jīng)過集成才能形成一個(gè)有機(jī)的整體。整理課件3.5 確認(rèn)測(cè)試第三章 軟件測(cè)試流程1確認(rèn)測(cè)試的定義確認(rèn)測(cè)試最簡明、最嚴(yán)格的解釋是檢驗(yàn)所開發(fā)的軟件是否能按用戶提出的要求運(yùn)行。若能達(dá)到這一要求，則認(rèn)為開發(fā)的軟件是合格的。因而有的軟件開發(fā)部門把確認(rèn)測(cè)試稱為合格性測(cè)試(Qualification Testing)。確認(rèn)測(cè)試又稱為有效性測(cè)試。它的任務(wù)是驗(yàn)證軟件

36、的功能和性能及其特性是否與客戶的要求一致。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明中已經(jīng)明確規(guī)定。確認(rèn)測(cè)試階段工作如圖3-10所示：整理課件3.5 確認(rèn)測(cè)試第三章 軟件測(cè)試流程圖3-10 確認(rèn)測(cè)試階段的工作整理課件3.5 確認(rèn)測(cè)試第三章 軟件測(cè)試流程2確認(rèn)測(cè)試的準(zhǔn)則經(jīng)過確認(rèn)測(cè)試，應(yīng)該為已開發(fā)的軟件做出結(jié)論性評(píng)價(jià)。這不外乎是以下兩種情況之一： 經(jīng)過檢驗(yàn)的軟件功能、性能及其他要求均已滿足需求規(guī)格說明書的規(guī)定，因而可被接受，視為是合格的軟件； 經(jīng)過檢驗(yàn)發(fā)現(xiàn)與需求說明書有相當(dāng)?shù)钠x，得到一個(gè)各項(xiàng)缺陷的清單。對(duì)于第二種情況，往往很難在交付期以前把發(fā)現(xiàn)的問題糾正過來。這就需要開發(fā)部門和客戶進(jìn)行協(xié)商，找出解

37、決的辦法。整理課件3.5 確認(rèn)測(cè)試第三章 軟件測(cè)試流程3進(jìn)行確認(rèn)測(cè)試確認(rèn)測(cè)試是在模擬的環(huán)境（可能是就是開發(fā)的環(huán)境）下，運(yùn)用黑盒測(cè)試的方法，驗(yàn)證所測(cè)試件是否滿足需求規(guī)格說明書列出的需求。4確認(rèn)測(cè)試的結(jié)果在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，所有的測(cè)試結(jié)果可以分為兩類： 測(cè)試結(jié)果與預(yù)期的結(jié)果相符。說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受； 測(cè)試結(jié)果與預(yù)期的結(jié)果不符。說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。通過與用戶的協(xié)商，解決所發(fā)現(xiàn)的缺陷和錯(cuò)誤。確認(rèn)測(cè)試應(yīng)交付的文檔有：確認(rèn)測(cè)試分析報(bào)告、最終的用戶手冊(cè)和操作手冊(cè)、項(xiàng)目開發(fā)總結(jié)報(bào)告

38、。整理課件3.5 確認(rèn)測(cè)試第三章 軟件測(cè)試流程5軟件配置審查軟件配置審查是確認(rèn)測(cè)試過程的重要環(huán)節(jié)。其的目的是保證軟件配置的所有成分都齊全，各方面的質(zhì)量都符合要求，具備維護(hù)階段所必需的細(xì)資料并且已經(jīng)編排好分類的目錄。除了按合同規(guī)定的內(nèi)容和要求，由工人審查軟件配置之外，在確認(rèn)測(cè)試的過程，應(yīng)當(dāng)嚴(yán)格遵守用戶手冊(cè)和操作手冊(cè)中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。必須仔細(xì)記錄發(fā)現(xiàn)的遺漏和錯(cuò)誤，并且適當(dāng)?shù)匮a(bǔ)充和改正。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程1系統(tǒng)測(cè)試的定義在軟件的各類測(cè)試中，系統(tǒng)測(cè)試是最接近于人們的日常測(cè)試實(shí)踐。它是將已經(jīng)集成好的軟件系統(tǒng)，作為整個(gè)計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與

39、計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程2系統(tǒng)測(cè)試的流程系統(tǒng)測(cè)試流程如圖3-11所示。由于系統(tǒng)測(cè)試的目的是驗(yàn)證最終軟件系統(tǒng)是否滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)，所以在完成產(chǎn)品需求和系統(tǒng)設(shè)計(jì)文檔之后，系統(tǒng)測(cè)試小組就可以提前開始制定測(cè)試計(jì)劃和設(shè)計(jì)測(cè)試用例，不必等到集成測(cè)試階段結(jié)束。這樣可以提高系統(tǒng)測(cè)試的效率。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程圖3-11 系統(tǒng)測(cè)試流程整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程3系統(tǒng)測(cè)試的目標(biāo)確保系統(tǒng)測(cè)試的活動(dòng)是按計(jì)劃進(jìn)行的；驗(yàn)

40、證軟件產(chǎn)品是否與系統(tǒng)需求用例不相符合或與之矛盾；建立完善的系統(tǒng)測(cè)試缺陷記錄跟蹤庫；確保軟件系統(tǒng)測(cè)試活動(dòng)及其結(jié)果及時(shí)通知相關(guān)小組和個(gè)人。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程4系統(tǒng)測(cè)試的方針為項(xiàng)目指定一個(gè)測(cè)試工程師負(fù)責(zé)貫徹和執(zhí)行系統(tǒng)測(cè)試活動(dòng)；測(cè)試組向各事業(yè)部總經(jīng)理/項(xiàng)目經(jīng)理報(bào)告系統(tǒng)測(cè)試的執(zhí)行狀況；系統(tǒng)測(cè)試活動(dòng)遵循文檔化的標(biāo)準(zhǔn)和過程；向外部用戶提供經(jīng)系統(tǒng)測(cè)試驗(yàn)收通過的項(xiàng)目；建立相應(yīng)項(xiàng)目的（BUG）缺陷庫，用于系統(tǒng)測(cè)試階段項(xiàng)目不同生命周期的缺陷記錄和缺陷狀態(tài)跟蹤；定期對(duì)系統(tǒng)測(cè)試活動(dòng)及結(jié)果進(jìn)行評(píng)估，向各事業(yè)部經(jīng)理/項(xiàng)目辦總監(jiān)/項(xiàng)目經(jīng)理匯報(bào)項(xiàng)目的產(chǎn)品質(zhì)量信息及數(shù)據(jù)。整理課件3.6 系統(tǒng)測(cè)試第三章

41、軟件測(cè)試流程5系統(tǒng)測(cè)試的設(shè)計(jì) 為了保證系統(tǒng)測(cè)試質(zhì)量，必須在測(cè)試設(shè)計(jì)階段就對(duì)系統(tǒng)進(jìn)行嚴(yán)密的測(cè)試設(shè)計(jì)。這就需要在測(cè)試設(shè)計(jì)中，從多方面考慮系統(tǒng)規(guī)格的實(shí)現(xiàn)情況。通常需要從以下幾個(gè)層次來進(jìn)行設(shè)計(jì)：用戶層、應(yīng)用層、功能層、子系統(tǒng)層、協(xié)議層。 整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程6幾種常見的系統(tǒng)測(cè)試方法(1) 恢復(fù)測(cè)試也叫容錯(cuò)測(cè)試，用來檢查系統(tǒng)的容錯(cuò)能力。通常若計(jì)算機(jī)系統(tǒng)出現(xiàn)錯(cuò)誤，就必須在一定時(shí)間內(nèi)從錯(cuò)誤中恢復(fù)過來，修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)?；謴?fù)測(cè)試是通過各種手段，讓軟件強(qiáng)制性地出錯(cuò)，使其不能正常工作，從而檢驗(yàn)系統(tǒng)的恢復(fù)能力。對(duì)于自動(dòng)恢復(fù)系統(tǒng)，即由系統(tǒng)自身完成恢復(fù)工作，則應(yīng)該檢驗(yàn)重新初始化、檢查點(diǎn)、數(shù)

42、據(jù)恢復(fù)和重新啟動(dòng)等機(jī)制的正確性。對(duì)于人工干預(yù)恢復(fù)系統(tǒng)，要評(píng)估平均修復(fù)時(shí)間是否在可接受的范圍。(2) 安全測(cè)試安全測(cè)試的目的在于檢查系統(tǒng)對(duì)外界非法入侵的防范能力。在安全測(cè)試過程中，測(cè)試者扮演著非法入侵者，采用各種手段試圖突破防線，攻擊系統(tǒng)。例如，測(cè)試者可以嘗試通過外部的手段來破譯系統(tǒng)的密碼，或者可以有目的地引發(fā)系統(tǒng)錯(cuò)誤，試圖在系統(tǒng)恢復(fù)過程中侵入系統(tǒng)等。系統(tǒng)的安全測(cè)試要設(shè)置一些測(cè)試用例試圖突破系統(tǒng)的安全保密防線，用來查找系統(tǒng)的安全保密的漏洞。系統(tǒng)安全測(cè)試的準(zhǔn)則是讓非法侵入者攻擊系統(tǒng)的代價(jià)大于保護(hù)系統(tǒng)安全的價(jià)值。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程(3) 強(qiáng)度測(cè)試也稱壓力測(cè)試、負(fù)載測(cè)試。強(qiáng)度

43、測(cè)試是要破壞程序，檢測(cè)非正常的情況系統(tǒng)的負(fù)載能力。強(qiáng)度測(cè)試模擬實(shí)際情況下的軟硬件環(huán)境和用戶使用過程的系統(tǒng)負(fù)荷，長時(shí)間或超負(fù)荷地運(yùn)行測(cè)試軟件來測(cè)試系統(tǒng)，以檢驗(yàn)系統(tǒng)能力的最高限度，從而了解系統(tǒng)的可靠性、穩(wěn)定性等。例如，將輸入的數(shù)據(jù)值提高一個(gè)或幾個(gè)數(shù)量級(jí)來測(cè)試輸入功能的響應(yīng)等。實(shí)際上，強(qiáng)度測(cè)試就是在一些特定情況下所做的敏感測(cè)試。比如數(shù)學(xué)算法中，在一個(gè)有效的數(shù)據(jù)范圍內(nèi)定義一個(gè)極小范圍的數(shù)據(jù)區(qū)間，這個(gè)數(shù)據(jù)區(qū)間中的數(shù)據(jù)本應(yīng)該是合理的，但往往又可能會(huì)引發(fā)異常的狀況或是引起錯(cuò)誤的運(yùn)行，導(dǎo)致程序的不穩(wěn)定性。敏感測(cè)試就是為了發(fā)現(xiàn)這種在有效的輸入數(shù)據(jù)區(qū)域內(nèi)可能會(huì)引發(fā)不穩(wěn)定性或者引起錯(cuò)誤運(yùn)行的數(shù)據(jù)集合和組合。(4)

44、性能測(cè)試性能測(cè)試用來測(cè)試軟件在系統(tǒng)運(yùn)行時(shí)的性能表現(xiàn)，比如運(yùn)行速度、系統(tǒng)資源占有或響應(yīng)時(shí)間等情況。對(duì)于實(shí)時(shí)系統(tǒng)或嵌入式系統(tǒng)，若只能滿足功能需求而不能滿足性能需求，是不能被接受的。性能測(cè)試可以在測(cè)試過程的任意階段進(jìn)行，例如，在單元層，一個(gè)獨(dú)立的模塊也可以運(yùn)用白盒測(cè)試方法進(jìn)行性能評(píng)估。但是，只有當(dāng)一個(gè)系統(tǒng)的所有部分都集成后，才能檢測(cè)此系統(tǒng)的真正性能。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程(5) 容量測(cè)試容量測(cè)試是指在系統(tǒng)正常運(yùn)行的范圍內(nèi)測(cè)定系統(tǒng)能夠處理的數(shù)據(jù)容量，測(cè)試系統(tǒng)承受超額數(shù)據(jù)容量的能力。系統(tǒng)容量必須滿足用戶需求，如果不能滿足實(shí)際要求，必須努力改進(jìn)，尋求解決辦法。暫時(shí)無法解決的需要在產(chǎn)品

45、說明書中給予說明。(6) 正確性測(cè)試正確性測(cè)試是為了檢測(cè)軟件的各項(xiàng)功能是否符合產(chǎn)品規(guī)格說明的要求。軟件的正確性與否關(guān)系著軟件的質(zhì)量好壞，所以非常重要。正確性測(cè)試的總體思路是設(shè)計(jì)一些邏輯正確的輸入值，檢查運(yùn)行結(jié)果是不是期望值。正確性測(cè)試主要有兩種方法，一個(gè)是枚舉法，另一個(gè)是邊界值法。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程 (7) 可靠性測(cè)試可靠性測(cè)試是從驗(yàn)證的角度出發(fā)，檢驗(yàn)系統(tǒng)的可靠性是否達(dá)到預(yù)期的目標(biāo)，同時(shí)給出當(dāng)前系統(tǒng)可能的可靠性增長情況?？煽啃詼y(cè)試需要從用戶角度出發(fā)，模擬用戶實(shí)際使用系統(tǒng)的情況，設(shè)計(jì)出系統(tǒng)的可操作視圖。(8) 兼容性測(cè)試現(xiàn)今，客戶對(duì)各個(gè)開發(fā)商和各種軟件之間相互兼容、共享

46、數(shù)據(jù)的能力要求越來越高，所以對(duì)于軟件兼容性的測(cè)試就非常重要。軟件兼容性測(cè)試是檢測(cè)各軟件之間能否正常地交互、共享信息，能否正確地和軟件合作完成數(shù)據(jù)處理。從而保障軟件能夠按照客戶期望的標(biāo)準(zhǔn)進(jìn)行交互，多個(gè)軟件共同完成指定的任務(wù)。整理課件3.6 系統(tǒng)測(cè)試第三章 軟件測(cè)試流程(9) Web網(wǎng)站測(cè)試Web網(wǎng)站測(cè)試是面向因特網(wǎng)Web頁面的測(cè)試。眾所周知，因特網(wǎng)網(wǎng)頁是由文字、圖形、聲音、視頻和超級(jí)鏈接等組成的文檔。網(wǎng)絡(luò)客戶端用戶通過在瀏覽器中的操作，搜索瀏覽所需要的信息資源。針對(duì)Web網(wǎng)站這一特定類型軟件的測(cè)試，包含了許多測(cè)試技術(shù)，如功能測(cè)試、壓力/負(fù)載測(cè)試、配置測(cè)試、兼容性測(cè)試、安全性測(cè)試等。黑盒測(cè)試、白盒

47、測(cè)試、靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試都有可能被采用。整理課件3.7 驗(yàn)收測(cè)試第三章 軟件測(cè)試流程1驗(yàn)收測(cè)試的定義驗(yàn)收測(cè)試（Acceptance Testing）是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求的那樣工作。通過綜合測(cè)試之后，軟件已完全組裝起來，接口方面的錯(cuò)誤也已排除，軟件測(cè)試的最后一步驗(yàn)收測(cè)試即可開始。驗(yàn)收測(cè)試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗(yàn)收測(cè)試是檢驗(yàn)軟件產(chǎn)品質(zhì)量的最后一道工序。驗(yàn)收測(cè)試通常更突出客戶的作用，同時(shí)軟件開發(fā)人員也有一定的參與。如何組織好驗(yàn)收測(cè)試并不是一件容易的事。以下對(duì)驗(yàn)收測(cè)試的任務(wù)、目標(biāo)以及驗(yàn)收測(cè)試的組織管理給出詳細(xì)介紹。整理課件3.7 驗(yàn)收測(cè)試第三章 軟件測(cè)試流程2驗(yàn)收測(cè)試的內(nèi)容軟件驗(yàn)收測(cè)試應(yīng)完成的工作內(nèi)容如下：要明確驗(yàn)收項(xiàng)目，規(guī)定驗(yàn)收測(cè)試通過的標(biāo)準(zhǔn)；確定測(cè)試方法；決定驗(yàn)收測(cè)試的組織機(jī)構(gòu)和可利用的資源；選定測(cè)試結(jié)果分析方法；指定驗(yàn)收測(cè)試計(jì)劃并進(jìn)行評(píng)審；設(shè)計(jì)驗(yàn)收測(cè)試所用的測(cè)試用例；審查驗(yàn)