第四章 軟件測(cè)試過程,4.1 軟件測(cè)試階段 4.2 軟件測(cè)試生命周期和軟件測(cè)試的流程 4.3 軟件測(cè)試步驟 4.4 單元測(cè)試(模塊測(cè)試、邏輯測(cè)試、結(jié)構(gòu)測(cè)試) 4.5 集成測(cè)試(組裝測(cè)試、聯(lián)合測(cè)試) 4.6 系統(tǒng)測(cè)試本章小結(jié),軟件測(cè)試貫穿于整個(gè)軟件生命周期，是對(duì)軟件產(chǎn)品(包括階段性產(chǎn)品)進(jìn)行驗(yàn)證和確認(rèn)的全過程。測(cè)試工作滲透到從分析、設(shè)計(jì)、編程、使用等生命周期的各個(gè)階段中。本章簡(jiǎn)單介紹軟件測(cè)試的過程和步驟。,軟件開發(fā)經(jīng)過制定計(jì)劃、需求分析、設(shè)計(jì)階段之后，就進(jìn)入編程階段。程序中的Bug，并不一定由編碼所引起，很可能是由詳細(xì)設(shè)計(jì)、概要設(shè)計(jì)階段，甚至是由需求分析階段的問題引起，即使針對(duì)源程序進(jìn)行測(cè)試，所發(fā)現(xiàn)Bug的根源也可能在軟件開發(fā)前期的各個(gè)階段。定位、解決、排除Bug也可能需要追溯到前期的工作。因此，測(cè)試應(yīng)貫穿于軟件定義和開發(fā)的整個(gè)生命周期中。,4.1 軟件測(cè)試階段,1軟件測(cè)試的工作流程 測(cè)試的工作流程與公司的整體工作流程、項(xiàng)目的測(cè)試要求等因素相關(guān)。圖4.1為軟件測(cè)試的一般工作流程。從圖4.1可以看出軟件測(cè)試經(jīng)歷了5個(gè)過程。,圖4.1 軟件測(cè)試的工作流程,2測(cè)試過程中的數(shù)據(jù) 測(cè)試過程中所用的數(shù)據(jù)可分為正常數(shù)據(jù)、錯(cuò)誤數(shù)據(jù)和邊緣數(shù)據(jù)： (1) 正常數(shù)據(jù)：在測(cè)試中所用的正常數(shù)據(jù)的量是最大的，而且也是最關(guān)鍵的。人們要從中提取出一些具有高度代表性的數(shù)據(jù)作為測(cè)試數(shù)據(jù)，以減少測(cè)試時(shí)間。 (2) 錯(cuò)誤數(shù)據(jù)：錯(cuò)誤數(shù)據(jù)是編寫與程序輸入規(guī)范不符的數(shù)據(jù)，從而檢測(cè)程序輸入、篩選、錯(cuò)誤處理等程序的分支。,(3) 邊緣數(shù)據(jù)：介于正常數(shù)據(jù)和錯(cuò)誤數(shù)據(jù)之間的一種數(shù)據(jù)。它可以針對(duì)某一種編程語(yǔ)言、編程環(huán)境或特定的數(shù)據(jù)庫(kù)而專門設(shè)定。如若使用SQL Server數(shù)據(jù)庫(kù)，則可把SQL Server關(guān)鍵字(如：; AS;Join等)設(shè)為邊緣數(shù)據(jù)。其他邊緣數(shù)據(jù)如：HTML的HTML ; 等關(guān)鍵字以及空格、負(fù)數(shù)、超長(zhǎng)字符等。邊緣數(shù)據(jù)要靠測(cè)試人員的豐富經(jīng)驗(yàn)來制訂。,3測(cè)試過程中的信息流 圖4.2為測(cè)試過程中的信息流。其中， 軟件配置：軟件需求規(guī)格說明、軟件設(shè)計(jì)規(guī)格說明、源代碼等。 測(cè)試配置：測(cè)試計(jì)劃、測(cè)試用例、測(cè)試程序等。 測(cè)試工具：測(cè)試數(shù)據(jù)自動(dòng)生成程序、靜態(tài)分析程序、動(dòng)態(tài)分析程序、測(cè)試結(jié)果分析程序以及驅(qū)動(dòng)測(cè)試的測(cè)試數(shù)據(jù)庫(kù)等。 測(cè)試結(jié)果分析：比較實(shí)測(cè)結(jié)果與預(yù)期結(jié)果，評(píng)價(jià)Bug是否發(fā)生。,排錯(cuò)(調(diào)試)：對(duì)已經(jīng)發(fā)現(xiàn)的Bug進(jìn)行Bug定位和確定出錯(cuò)性質(zhì)，并改正這些Bug，同時(shí)修改相關(guān)的文檔。 回歸測(cè)試：修正Bug后再測(cè)試，直到通過測(cè)試為止。 可靠性：通過收集和分析測(cè)試結(jié)果數(shù)據(jù)，對(duì)軟件建立可靠性模型。利用可靠性分析評(píng)價(jià)軟件質(zhì)量，即軟件的質(zhì)量和可靠性達(dá)到可以接受的程度。 如果測(cè)試發(fā)現(xiàn)不了Bug，就可以肯定測(cè)試配置考慮得不夠細(xì)致充分，Bug仍然潛伏在軟件中，則所做的測(cè)試不足以發(fā)現(xiàn)嚴(yán)重的Bug。,圖4.2 測(cè)試信息流,4測(cè)試階段劃分 按照測(cè)試流程，將測(cè)試工作劃分為計(jì)劃(指進(jìn)行測(cè)試計(jì)劃)、設(shè)計(jì)(指進(jìn)行測(cè)試設(shè)計(jì))和執(zhí)行(含評(píng)價(jià)、執(zhí)行測(cè)試并判別結(jié)果、評(píng)價(jià)測(cè)試效果和被測(cè)試軟件)等幾個(gè)階段。 可以從三個(gè)不同的角度將測(cè)試劃分為多個(gè)階段： (1) 面向測(cè)試操作類型的劃分：調(diào)試、集成、確認(rèn)、驗(yàn)證、組裝、驗(yàn)收、操作等。 (2) 面向測(cè)試對(duì)象粒度的劃分：語(yǔ)句、結(jié)構(gòu)、單元、部件、配置項(xiàng)、子系統(tǒng)、系統(tǒng)、大系統(tǒng)等。 (3) 面向測(cè)試實(shí)施者的劃分：開發(fā)者、測(cè)試者、驗(yàn)收者、使用者等。,每個(gè)測(cè)試階段一般都要經(jīng)歷以下步驟：測(cè)試需求分析、測(cè)試過程設(shè)計(jì)、測(cè)試實(shí)現(xiàn)和實(shí)施、測(cè)試評(píng)價(jià)、測(cè)試維護(hù)。詳細(xì)敘述如下： 測(cè)試需求分析：測(cè)試需求是整個(gè)測(cè)試過程的基礎(chǔ)，主要確定測(cè)試對(duì)象以及測(cè)試工作的范圍和作用。 測(cè)試過程設(shè)計(jì)：包括測(cè)試計(jì)劃、測(cè)試策略制定、測(cè)試時(shí)間安排、測(cè)試用例編寫等。 測(cè)試實(shí)現(xiàn)：包括配置環(huán)境、制作新的版本、培訓(xùn)測(cè)試人員等。, 測(cè)試實(shí)施：已經(jīng)按照測(cè)試計(jì)劃進(jìn)行展開，如手工測(cè)試、自動(dòng)化測(cè)試等。 測(cè)試評(píng)價(jià)：對(duì)版本測(cè)試覆蓋率、測(cè)試質(zhì)量、人員測(cè)試工作以及前期的一些工作制定情況進(jìn)行評(píng)價(jià)、評(píng)估。 測(cè)試維護(hù)：對(duì)測(cè)試用例庫(kù)、測(cè)試腳本、Bug庫(kù)等進(jìn)行維護(hù)、保證延續(xù)性等。 測(cè)試工作的組織與管理：制定測(cè)試策略、測(cè)試計(jì)劃，確認(rèn)所采用的測(cè)試方法與規(guī)范、控制測(cè)試進(jìn)度、管理測(cè)試資源。 測(cè)試工作的實(shí)施：編制符合標(biāo)準(zhǔn)的測(cè)試文檔，搭建測(cè)試環(huán)境，開發(fā)測(cè)試腳本，與開發(fā)組織協(xié)作實(shí)現(xiàn)各階段的測(cè)試活動(dòng)。,5角色和職責(zé) 1) 測(cè)試設(shè)計(jì)員 制定和維護(hù)測(cè)試計(jì)劃。 設(shè)計(jì)測(cè)試用例及測(cè)試過程。 評(píng)估測(cè)試，生成測(cè)試分析報(bào)告。 2) 測(cè)試員 執(zhí)行集成測(cè)試和系統(tǒng)測(cè)試。 記錄測(cè)試結(jié)果。,3) 設(shè)計(jì)員：設(shè)計(jì)測(cè)試需要的驅(qū)動(dòng)程序和穩(wěn)定樁。 4) 編碼員 編寫測(cè)試驅(qū)動(dòng)程序和穩(wěn)定樁。 執(zhí)行單元測(cè)試。 6軟件測(cè)試的基本活動(dòng) 軟件測(cè)試是一個(gè)極為復(fù)雜的工作，通常包括以下基本測(cè)試活動(dòng)： 擬定測(cè)試計(jì)劃和編制測(cè)試大綱。, 確定和建立必要的測(cè)試環(huán)境。 設(shè)計(jì)和生成測(cè)試用例，按照所寫的測(cè)試用例，編寫測(cè)試腳本。 根據(jù)測(cè)試對(duì)象和目的，構(gòu)造測(cè)試用例集合。 運(yùn)行測(cè)試腳本或手工按測(cè)試用例進(jìn)行。 記錄測(cè)試結(jié)果。 結(jié)果比較分析，找出軟件Bug。 跟蹤和管理軟件Bug。 將軟件Bug記錄到Bug數(shù)據(jù)庫(kù)，清楚描述該Bug。 驗(yàn)證被處理的軟件Bug，并進(jìn)行回歸測(cè)試。, 對(duì)測(cè)試過程進(jìn)行管理，保證測(cè)試工作執(zhí)行的準(zhǔn)確性，實(shí)現(xiàn)資源調(diào)撥和相關(guān)合作方的協(xié)調(diào)，對(duì)測(cè)試中的問題進(jìn)行全程跟蹤。 生成測(cè)試報(bào)告。,7軟件測(cè)試的主要過程 一般軟件測(cè)試的主要過程為計(jì)劃配置開發(fā)測(cè)試執(zhí)行。其中， 配置：指軟、硬件資源的設(shè)置。 開發(fā)：指構(gòu)造或配置測(cè)試工具、創(chuàng)建測(cè)試套件和測(cè)試方案庫(kù)、準(zhǔn)備適當(dāng)?shù)膱?bào)告工具并記錄測(cè)試系統(tǒng)如何運(yùn)行。 測(cè)試執(zhí)行：指進(jìn)行測(cè)試、記錄測(cè)試條件和Bug以及報(bào)告結(jié)果。,8動(dòng)態(tài)測(cè)試的一般過程 軟件動(dòng)態(tài)測(cè)試的一般過程如圖4.3。其中，測(cè)試過程有兩類輸入：軟件配置和測(cè)試配置。 軟件配置包括軟件需求規(guī)約、設(shè)計(jì)規(guī)約、源代碼等。 測(cè)試配置包括測(cè)試計(jì)劃、測(cè)試用例、測(cè)試工具等。最核心的過程是生成測(cè)試用例、運(yùn)行程序(測(cè)試)和驗(yàn)證程序的運(yùn)行結(jié)果(評(píng)估)。,圖4.3 軟件動(dòng)態(tài)測(cè)試過程示意圖,一般而言，軟件測(cè)試的全過程指測(cè)試工作從項(xiàng)目確立時(shí)就開始，貫穿于軟件生命周期，前后要經(jīng)過以下主要過程： 需求分析測(cè)試計(jì)劃測(cè)試設(shè)計(jì)測(cè)試場(chǎng)景設(shè)計(jì)測(cè)試執(zhí)行測(cè)試報(bào)告Bug管理評(píng)估RTM軟件系統(tǒng)組成總結(jié)和維護(hù) 說明： (1) 以上流程各過程并未包含測(cè)試過程的全部，如根據(jù)實(shí)際情況還可以實(shí)施一些測(cè)試計(jì)劃評(píng)審、用例評(píng)審、測(cè)試培訓(xùn)等。在軟件正式發(fā)行后，還需要進(jìn)行一些后續(xù)維護(hù)測(cè)試等。當(dāng)遇到一些嚴(yán)重Bug時(shí)，需要召開審查會(huì)等。,(2) 以上各過程并不是獨(dú)立的，實(shí)際工作千變?nèi)f化，各過程之間有一些交織、重疊在所難免，如編寫測(cè)試用例的同時(shí)就可以進(jìn)行測(cè)試環(huán)境的搭建工作，當(dāng)然也可能由于一些需求不清楚而重新進(jìn)行需求分析等。在實(shí)際測(cè)試過程中要做到具體問題具體分析、具體解決。 (3) 一般而言，需求分析、測(cè)試用例編寫、測(cè)試環(huán)境搭建、測(cè)試執(zhí)行等屬于測(cè)試開發(fā)人員工作范疇，而測(cè)試執(zhí)行以及Bug提交等屬于普通測(cè)試人員的工作范疇，測(cè)試負(fù)責(zé)人負(fù)責(zé)整個(gè)測(cè)試各個(gè)過程的Bug的跟蹤、測(cè)試實(shí)施和管理等。,下面詳細(xì)介紹軟件測(cè)試的全過程。 1) 需求調(diào)研、分析 一般而言，需求分析包括軟件功能需求分析、測(cè)試環(huán)境需求分析、測(cè)試資源需求分析等，其中最基本的是軟件功能需求分析。經(jīng)過需求調(diào)研分析后編寫需求規(guī)格說明書，它是整個(gè)開發(fā)過程的基線。當(dāng)系統(tǒng)分析員完成了需求分析，他將提交需求規(guī)格說明書。測(cè)試人員根據(jù)在需求調(diào)研階段獲取的對(duì)需求的理解審查整個(gè)文檔，檢查文檔是否覆蓋了所有需求。,2) 測(cè)試計(jì)劃 測(cè)試計(jì)劃一般由測(cè)試負(fù)責(zé)人來編寫。測(cè)試計(jì)劃的依據(jù)主要由項(xiàng)目開發(fā)計(jì)劃和測(cè)試需求分析結(jié)果而制定。測(cè)試過程與整個(gè)軟件開發(fā)過程基本上是平行進(jìn)行。測(cè)試計(jì)劃早在需求分析階段就應(yīng)開始制定。其他相關(guān)工作，包括測(cè)試大綱的制定、測(cè)試數(shù)據(jù)的生成、測(cè)試工具的選擇和開發(fā)等也應(yīng)在測(cè)試階段之前進(jìn)行。充分的準(zhǔn)備工作可以有效克服測(cè)試的盲目性，縮短測(cè)試周期，提高測(cè)試效率，并且可以起到開發(fā)文檔與測(cè)試文檔互查的作用。,3) 測(cè)試設(shè)計(jì) 測(cè)試設(shè)計(jì)主要包括測(cè)試大綱、審查設(shè)計(jì)文檔、測(cè)試用例編寫： (1) 測(cè)試大綱。測(cè)試大綱是測(cè)試的依據(jù)，它明確、詳盡規(guī)定了在測(cè)試中針對(duì)系統(tǒng)的每一項(xiàng)功能或特性所必須完成的基本測(cè)試項(xiàng)目和測(cè)試完成的標(biāo)準(zhǔn)。無論是自動(dòng)測(cè)試還是手動(dòng)測(cè)試，都必須滿足測(cè)試大綱的要求。 (2) 審查設(shè)計(jì)文檔。在系統(tǒng)設(shè)計(jì)階段，測(cè)試人員要理解系統(tǒng)是怎樣實(shí)現(xiàn)的。這個(gè)階段的開發(fā)文檔包括概要設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、功能說明以及詳細(xì)設(shè)計(jì)等。測(cè)試人員審查這些文檔，檢查這些計(jì)劃與設(shè)計(jì)是否合理。如果不合理，問題在哪里、怎樣改進(jìn)等。,(3) 設(shè)計(jì)和生成測(cè)試用例。在計(jì)劃測(cè)試時(shí)，需要將整個(gè)系統(tǒng)分解。正確劃分子系統(tǒng)可以降低測(cè)試的復(fù)雜性，減少重復(fù)與冗余，更加方便設(shè)計(jì)測(cè)試用例。 設(shè)計(jì)測(cè)試用例是一件非常細(xì)致的工作。通常每個(gè)用例需要包括：序號(hào)和標(biāo)題、用例說明、測(cè)試優(yōu)先級(jí)、測(cè)試輸入及測(cè)試步驟、期望輸出與實(shí)際輸出(當(dāng)執(zhí)行測(cè)試時(shí)，它被用來記錄測(cè)試的結(jié)果)。測(cè)試用例設(shè)計(jì)要考慮以下幾點(diǎn)：覆蓋率(要達(dá)到最大覆蓋軟件系統(tǒng)功能的功能點(diǎn))、數(shù)量(一個(gè)多于半年的開發(fā)周期，用例不得少于4000個(gè))、使用管理工具軟件等。,4) 測(cè)試場(chǎng)景設(shè)計(jì) 測(cè)試場(chǎng)景設(shè)計(jì)主要是測(cè)試環(huán)境問題。測(cè)試環(huán)境對(duì)測(cè)試很重要，為了測(cè)試軟件，人們可能根據(jù)不同的需求使用很多不同的測(cè)試環(huán)境。有些測(cè)試環(huán)境人們可以搭建，有些環(huán)境人們無法搭建或者搭建的成本很高。不同軟件產(chǎn)品對(duì)測(cè)試環(huán)境有著不同的要求，符合要求的測(cè)試環(huán)境能夠幫助人們準(zhǔn)確的找出軟件Bug，并且做出正確的判斷。 測(cè)試環(huán)境是一個(gè)確定、可以明確說明的條件，不同的測(cè)試環(huán)境可以得出對(duì)同一軟件的不同測(cè)試結(jié)果，這說明測(cè)試并不完全是客觀的行為，任何一個(gè)測(cè)試的結(jié)果都是建立在一定的測(cè)試環(huán)境之上。,測(cè)試環(huán)境中特別需要明確說明的是測(cè)試人員的水平，包括專業(yè)上、計(jì)算機(jī)操作的能力以及與被測(cè)試程序的關(guān)系，這種說明還要在評(píng)測(cè)人員對(duì)評(píng)測(cè)對(duì)象做出的判斷的權(quán)值上有所體現(xiàn)。這就要求測(cè)試機(jī)構(gòu)建立測(cè)試人員檔案庫(kù)，并對(duì)其參與測(cè)試的工作業(yè)績(jī)不斷做出評(píng)價(jià)。 測(cè)試計(jì)劃是可以變動(dòng)的。一份計(jì)劃做得再好，當(dāng)實(shí)際實(shí)施時(shí)就會(huì)發(fā)現(xiàn)往往很難按照原有計(jì)劃開展。如在軟件開發(fā)過程中資源匱乏、人員流動(dòng)等都會(huì)對(duì)測(cè)試過程和測(cè)試結(jié)果造成一定的影響。所以，就要求測(cè)試負(fù)責(zé)人能夠從宏觀上來實(shí)時(shí)調(diào)控和修改測(cè)試計(jì)劃。,5) 測(cè)試實(shí)施、執(zhí)行 當(dāng)以上的準(zhǔn)備工作完成后，系統(tǒng)開發(fā)也進(jìn)入到尾期。測(cè)試人員可以根據(jù)前面的測(cè)試計(jì)劃和測(cè)試用例逐個(gè)實(shí)施測(cè)試。每一個(gè)獨(dú)立的軟件部分要接受單元測(cè)試，若干個(gè)部分組合起來接受集成測(cè)試。當(dāng)所有的軟件產(chǎn)品完成后要接受系統(tǒng)測(cè)試，系統(tǒng)測(cè)試是保證整個(gè)系統(tǒng)符合用戶需求。而性能測(cè)試也是必不可少的，保證軟件的各個(gè)部分滿足需求的性能標(biāo)準(zhǔn)。 測(cè)試執(zhí)行階段是由一系列不同的測(cè)試類型的執(zhí)行過程組成，每種測(cè)試類型都有其具體的測(cè)試目標(biāo)和支持技術(shù)，,每種測(cè)試類型都只側(cè)重于對(duì)測(cè)試目標(biāo)的一個(gè)或多個(gè)特征、或?qū)傩赃M(jìn)行測(cè)試，準(zhǔn)確的測(cè)試類型可以給測(cè)試帶來事半功倍的效果。具體的測(cè)試實(shí)施過程分為四個(gè)階段：?jiǎn)卧獪y(cè)試集成測(cè)試系統(tǒng)測(cè)試出廠測(cè)試，其中每個(gè)階段還要進(jìn)行回歸測(cè)試等。 從測(cè)試的角度而言，實(shí)施測(cè)試包括一個(gè)量和度的問題，也就是測(cè)試范圍和測(cè)試程度的問題。比如一個(gè)版本需要測(cè)試哪些方面？每個(gè)方面要測(cè)試到什么程度等？,從管理的角度而言，在有限的時(shí)間、有限人員甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來開展測(cè)試。還要考慮以下問題： 當(dāng)測(cè)試人員執(zhí)行測(cè)試不到位、測(cè)試不認(rèn)真時(shí)該如何解決？ 怎樣提高測(cè)試效率； 根據(jù)版本的不同特點(diǎn)是只做驗(yàn)證測(cè)試還是采取冒煙測(cè)試，或是系統(tǒng)全面測(cè)試？ 當(dāng)測(cè)試過程中遇到一些偶然性、隨機(jī)性問題該怎樣處理？ 當(dāng)版本中出現(xiàn)很多新問題時(shí)該怎樣對(duì)待？ 測(cè)試停止標(biāo)準(zhǔn)是什么？,總之，測(cè)試執(zhí)行過程中可能會(huì)遇到很多復(fù)雜的問題，要具體問題具體解決。 6) 測(cè)試記錄 生成測(cè)試報(bào)告，即Bug記錄，分為軟件Bug報(bào)告和測(cè)試結(jié)果報(bào)告。一般測(cè)試Bug報(bào)告中要包含對(duì)項(xiàng)目的概述、測(cè)試的功能點(diǎn)(可以目錄形式列出)、Bug在功能點(diǎn)的分布(可用柱狀或餅狀圖表示)、Bug按嚴(yán)重等級(jí)劃分的百分比，以及是否通過本次測(cè)試的結(jié)論。,Bug記錄一般包括兩方面：由誰提交和Bug描述。一般而言，Bug都是誰測(cè)試誰提交。當(dāng)然有些公司為了保證所提交Bug的質(zhì)量，還會(huì)在提交前進(jìn)行Bug評(píng)估，以確保所提交的Bug的準(zhǔn)確性。Bug記錄格式見表4.1。,表4.1 Bug記錄格式,在實(shí)際提交Bug時(shí)可以根據(jù)實(shí)際情況進(jìn)行補(bǔ)充，如可以附上圖片、log文件等。另外，一個(gè)版本測(cè)試完畢還要根據(jù)測(cè)試情況給出測(cè)試報(bào)告。,7) Bug管理、測(cè)試維護(hù)和軟件評(píng)估 (1) Bug管理：很多公司都利用Bug管理工具來進(jìn)行管理。常見Bug管理工具有Test Director、Bugfree等。 (2) 測(cè)試維護(hù)。由于實(shí)際測(cè)試的不完全性，當(dāng)軟件正式發(fā)布后，客戶發(fā)現(xiàn)的問題需要修改，修改后需要進(jìn)行回歸測(cè)試，再次對(duì)軟件進(jìn)行測(cè)試、評(píng)估、發(fā)布。 (3) 軟件評(píng)估。軟件評(píng)估指軟件經(jīng)過一輪又一輪測(cè)試后，確認(rèn)軟件無重大問題或者問題很少的情況下，,對(duì)準(zhǔn)備發(fā)給客戶的軟件進(jìn)行評(píng)估，以確定是否能夠發(fā)行給客戶或投放市場(chǎng)。軟件評(píng)估小組一般由項(xiàng)目負(fù)責(zé)人、營(yíng)銷人員、部門經(jīng)理等組成，也可能由客戶指定的第三方人員組成。 主要的三類評(píng)估： 測(cè)試工作估計(jì)。測(cè)試工作估計(jì)包括對(duì)工作量、資源和成本的估計(jì)。估計(jì)一般使用類比法、經(jīng)驗(yàn)法、模型法等。項(xiàng)目負(fù)責(zé)人可以根據(jù)被測(cè)試軟件的需求規(guī)格說明或者詳細(xì)設(shè)計(jì)計(jì)劃，進(jìn)行工作量估計(jì)。也可以根據(jù)選用的測(cè)試方法、測(cè)試環(huán)境、被測(cè)試軟件的工作特性以及對(duì)工作量的估計(jì)提出資源需求。, 設(shè)計(jì)評(píng)審。從測(cè)試的視角看，設(shè)計(jì)評(píng)審非常重要，通過全面評(píng)審軟件設(shè)計(jì)內(nèi)容，可以在軟件開發(fā)的早期發(fā)現(xiàn)一些潛在與性能和安全性有關(guān)的Bug。如果這些Bug在編程階段才被發(fā)現(xiàn)，則修正Bug耗費(fèi)的時(shí)間將比設(shè)計(jì)階段修改Bug長(zhǎng)得多。 實(shí)現(xiàn)代碼評(píng)審。在實(shí)現(xiàn)代碼評(píng)審階段，從詳細(xì)測(cè)試計(jì)劃文檔中執(zhí)行測(cè)試用例，對(duì)軟件的代碼進(jìn)行審閱，這是單元測(cè)試的重要步驟。通過代碼評(píng)審，可以在軟件開發(fā)的早期發(fā)現(xiàn)Bug。,(4) 測(cè)試系統(tǒng)組成。讓軟件測(cè)試趨于規(guī)范建立測(cè)試管理體系。測(cè)試系統(tǒng)主要由下面六個(gè)相互關(guān)聯(lián)、相互作用的過程組成：測(cè)試規(guī)劃、測(cè)試設(shè)計(jì)、測(cè)試實(shí)施、配置管理、資源管理、測(cè)試管理。測(cè)試實(shí)施階段是由一系列的測(cè)試周期組成。在每個(gè)測(cè)試周期中，測(cè) 試工程師將依據(jù)預(yù)先編制好的測(cè)試方案和準(zhǔn)備好的測(cè)試用例，對(duì)被測(cè)試軟件進(jìn)行完整測(cè)試。 (5) 測(cè)試總結(jié)。每個(gè)版本有各自的測(cè)試總結(jié)，每個(gè)階段有各自的測(cè)試總結(jié)。,當(dāng)項(xiàng)目完成后，一般要對(duì)整個(gè)項(xiàng)目作回顧總結(jié)，檢查有哪些做得不足的地方，有哪些經(jīng)驗(yàn)可以對(duì)今后的測(cè)試工作起借鑒作用等。測(cè)試總結(jié)沒有嚴(yán)格格式和字?jǐn)?shù)限制等。 (6) 測(cè)試維護(hù)。由于測(cè)試的不完全性，當(dāng)軟件正式發(fā)布后，客戶在使用過程中，難免遇到一些問題，有的甚至是嚴(yán)重性的問題，這就需要修改有關(guān)問題，修改后需要再次對(duì)軟件進(jìn)行測(cè)試、評(píng)估、發(fā)布，這個(gè)過程就是測(cè)試維護(hù)。,9. 測(cè)試與軟件開發(fā)各階段的關(guān)系 軟件開發(fā)過程是一個(gè)自頂向下、逐步細(xì)化的過程。軟件計(jì)劃階段定義軟件作用域。軟件需求分析建立軟件信息域、功能和性能需求、約束等。軟件設(shè)計(jì)是把設(shè)計(jì)結(jié)果用某種程序設(shè)計(jì)語(yǔ)言轉(zhuǎn)換成程序代碼。測(cè)試過程是依相反順序安排的自底向上，逐步集成的過程(見圖4.4)。,圖4.4 軟件測(cè)試與軟件開發(fā)各階段之間的關(guān)系,軟件測(cè)試在軟件生存周期中橫跨兩個(gè)階段： (1) 通常在編寫完成每一個(gè)模塊之后就對(duì)它進(jìn)行必要的軟件測(cè)試(即單元測(cè)試)，編碼和單元測(cè)試屬于軟件生存期中的同一個(gè)階段；,4.2 軟件測(cè)試生命周期和軟件測(cè)試的流程,(2) 在結(jié)束這個(gè)階段后對(duì)軟件系統(tǒng)還要進(jìn)行各種綜合測(cè)試，這是軟件生存期的另一個(gè)獨(dú)立階段，即軟件測(cè)試階段。,4.2.1 軟件測(cè)試的生命周期 軟件測(cè)試生命周期歸納為7個(gè)階段：計(jì)劃、分析、設(shè)計(jì)、構(gòu)建、周期測(cè)試、測(cè)試與實(shí)施以及實(shí)施后期。 1計(jì)劃(即產(chǎn)品定義階段) 高層次的測(cè)試計(jì)劃(包含多重測(cè)試周期)。 質(zhì)量保證計(jì)劃(質(zhì)量目標(biāo)，測(cè)試標(biāo)準(zhǔn)等)。 確定計(jì)劃評(píng)審的時(shí)間。 報(bào)告問題過程。 確定問題的分類。 確定項(xiàng)目質(zhì)量度量。, 確定驗(yàn)收標(biāo)準(zhǔn)提供給質(zhì)量保證員和用戶。 確定衡量標(biāo)準(zhǔn)，如Bug數(shù)量/嚴(yán)重程度和Bug起源等。 建立應(yīng)用程序測(cè)試數(shù)據(jù)庫(kù)。 開始制定項(xiàng)目整體測(cè)試時(shí)間表(包括時(shí)間、資源等)。 評(píng)審產(chǎn)品定義文檔，在文檔中加入質(zhì)量保證標(biāo)準(zhǔn)，作為工程改善進(jìn)程的一部分。 數(shù)據(jù)庫(kù)管理所有測(cè)試用例，包括手工方面或自動(dòng)化方面。 大約每月要花費(fèi)510小時(shí)。,2分析(外部文檔階段) 根據(jù)業(yè)務(wù)需求開發(fā)功能驗(yàn)證矩陣。 制定測(cè)試用例格式，包括估計(jì)時(shí)間和分配優(yōu)先級(jí)等。 制定測(cè)試周期矩陣與時(shí)間線。 根據(jù)功能驗(yàn)證矩陣開始編寫測(cè)試用例。 根據(jù)業(yè)務(wù)需求，計(jì)劃測(cè)試用例基準(zhǔn)數(shù)據(jù)。 確定用于自動(dòng)化測(cè)試的測(cè)試用例。 自動(dòng)化團(tuán)隊(duì)開始在測(cè)試工具中創(chuàng)建變量文件和高層次的測(cè)試腳本。 為自動(dòng)化系統(tǒng)中的跟蹤組件設(shè)置路徑和自動(dòng)化引導(dǎo)。, 界定壓力和性能測(cè)試的范疇。 按照每個(gè)測(cè)試用例的數(shù)據(jù)，要求開始建立基準(zhǔn)數(shù)據(jù)庫(kù)。 定義維護(hù)基準(zhǔn)數(shù)據(jù)庫(kù)的過程，即備份、恢復(fù)、驗(yàn)證。 建立反饋機(jī)制并錄入文檔。 規(guī)劃項(xiàng)目所需的測(cè)試周期數(shù)和回歸測(cè)試次數(shù)。 文檔復(fù)查，如功能設(shè)計(jì)文檔、業(yè)務(wù)需求文檔、產(chǎn)品規(guī)格說明書、產(chǎn)品外部文檔等。, 審查測(cè)試環(huán)境和實(shí)驗(yàn)室，前端與后端系統(tǒng)都要審查。 準(zhǔn)備使用McCabe工具，以支持白盒測(cè)試中代碼的研發(fā)和復(fù)雜性分析。 必需階段審查外部文件。 該文檔中加入質(zhì)量保證標(biāo)準(zhǔn)，作為工程改善進(jìn)程的一部分。 根據(jù)群體執(zhí)行反饋編寫測(cè)試用例。 開始研制測(cè)試用例估計(jì)數(shù)目、每個(gè)用例的執(zhí)行時(shí)間和用例是否自動(dòng)化這些方面度量。, 為每個(gè)測(cè)試用例確定基準(zhǔn)數(shù)據(jù)。 大約每月要花25小時(shí)。,3設(shè)計(jì)(即文檔架構(gòu)階段) 根據(jù)變更修改測(cè)試計(jì)劃。 修改測(cè)試周期矩陣和時(shí)間線。 核實(shí)測(cè)試計(jì)劃和用例用到的數(shù)據(jù)并輸入到數(shù)據(jù)庫(kù)。 修改功能驗(yàn)證矩陣。 繼續(xù)編寫測(cè)試用例，根據(jù)變化添加新的用例。 規(guī)范自動(dòng)化測(cè)試和多用戶測(cè)試的細(xì)節(jié)。 挑選出一套用于自動(dòng)化測(cè)試的測(cè)試用例，并且把這些用例腳本化。, 規(guī)范壓力測(cè)試和性能測(cè)試的細(xì)節(jié)。 最終確定測(cè)試周期。根據(jù)測(cè)試用例的估計(jì)時(shí)間和優(yōu)先權(quán)確定每個(gè)周期所用的測(cè)試用例數(shù)。 制定風(fēng)險(xiǎn)評(píng)估標(biāo)準(zhǔn)。 最終確定的測(cè)試計(jì)劃。 估計(jì)單元測(cè)試所需資源。 必需階段，審查架構(gòu)文件。 該文檔中加入質(zhì)量保證標(biāo)準(zhǔn)，作為工程改善進(jìn)程的一部分。, 確定要進(jìn)行編碼的實(shí)際組件或模塊。 定義單元測(cè)試標(biāo)準(zhǔn)，通過/失敗準(zhǔn)則等。 列出所有要進(jìn)行單元測(cè)試的模塊。 單元測(cè)試報(bào)告，報(bào)告進(jìn)行單元測(cè)試后的模塊質(zhì)量如何，白盒測(cè)試和黑盒測(cè)試都要包括輸入/輸出數(shù)據(jù)和所有決定點(diǎn)。,4構(gòu)建(單元測(cè)試階段) 完成所有計(jì)劃。 完成測(cè)試周期矩陣和時(shí)間線。 完成所有測(cè)試用例。 完成第一套自動(dòng)化測(cè)試用例的測(cè)試腳本。 完成壓力和性能測(cè)試的計(jì)劃。 開始?jí)毫托阅軠y(cè)試。 McCabe工具支持：提供度量。 測(cè)試自動(dòng)化測(cè)試系統(tǒng)，并修復(fù)Bug。 運(yùn)行質(zhì)量保證驗(yàn)收測(cè)試套件，以確保軟件已經(jīng)可以交給中心測(cè)試。,5周期測(cè)試/Bug修正(重復(fù)/系統(tǒng)測(cè)試階段) 測(cè)試周期一，執(zhí)行第一套的測(cè)試用例(包括前端和后端)。 報(bào)告Bug。 Bug審核。 根據(jù)需求修改、增加測(cè)試用例。 測(cè)試周期二、測(cè)試周期三等。,6測(cè)試和實(shí)施(代碼凍結(jié)階段) 執(zhí)行所有前端測(cè)試用例：人工和自動(dòng)化。 執(zhí)行所有后端測(cè)試用例：人工和自動(dòng)化。 執(zhí)行所有壓力和性能測(cè)試。 提供對(duì)正在進(jìn)行的Bug跟蹤度量。 提供對(duì)正在進(jìn)行的復(fù)雜性和設(shè)計(jì)的度量。 更新測(cè)試用例和測(cè)試計(jì)劃的估計(jì)時(shí)間。 文件測(cè)試周期，回歸測(cè)試，并更新相應(yīng)文檔。,7實(shí)施后期 召開實(shí)施后評(píng)估會(huì)議以回顧整項(xiàng)工程。 準(zhǔn)備最終的Bug報(bào)告和相關(guān)度量。 制定戰(zhàn)略以防止類似的問題在今后的項(xiàng)目中重復(fù)出現(xiàn)。 創(chuàng)建如何改進(jìn)流程的計(jì)劃目標(biāo)和里程碑，使用McCabe工具制作最后的報(bào)道和分析。自動(dòng)化測(cè)試組： 審查測(cè)試用例以評(píng)估其他可用于自動(dòng)化回歸測(cè)試的用例； 清理自動(dòng)化測(cè)試用例和變量； 審查自動(dòng)化測(cè)試和手工測(cè)試結(jié)果的整合過程； 測(cè)試實(shí)驗(yàn)室和測(cè)試環(huán)境-清理測(cè)試環(huán)境，標(biāo)記和存檔用過測(cè)試用例和數(shù)據(jù)，恢復(fù)測(cè)試儀器到原始狀態(tài)等。,4.2.2 軟件測(cè)試的流程 軟件測(cè)試是一個(gè)涉及軟件開發(fā)周期各階段的很多活動(dòng)，其過程是循環(huán)的、周而復(fù)始的，并不是單一、有順次的。它的大致流程如下： 測(cè)試之初(原始狀態(tài))測(cè)試需求測(cè)試設(shè)計(jì)測(cè)試設(shè)計(jì)故障管理測(cè)試計(jì)劃測(cè)試復(fù)查測(cè)試執(zhí)行測(cè)試報(bào)告單元測(cè)試自動(dòng)化測(cè)試性能測(cè)試提高測(cè)試技能總結(jié)回到起點(diǎn)。 為了詳細(xì)說明軟件的測(cè)試過程，圖4.5給出了軟件開發(fā)和處理整個(gè)流程。,圖4.5 軟件開發(fā)和處理流程,在軟件測(cè)試的整個(gè)流程中，每個(gè)階段都很重要。 下面3個(gè)圖都是描述軟件測(cè)試的生命周期流程圖。其中，圖4.6(a)為傳統(tǒng)的軟件測(cè)試生命周期，直到編碼結(jié)束以后才開始測(cè)試活動(dòng)；圖4.6(b)為傳統(tǒng)并行的軟件測(cè)試生命周期，執(zhí)行測(cè)試在編碼之后開始，測(cè)試計(jì)劃和設(shè)計(jì)與開發(fā)同步；圖4.7為軟件測(cè)試生命周期的全過程。,圖4.6 測(cè)試生命周期,圖4.7 軟件測(cè)試生命周期的全過程,測(cè)試時(shí)，每執(zhí)行一次“輸入”，就要根據(jù)軟件的可靠性需求，對(duì)被測(cè)系統(tǒng)所表現(xiàn)出的“狀態(tài)”是否符合預(yù)期的“狀態(tài)”做出判斷。 軟件測(cè)試可以分為若干步驟(或階段)。,4.3 軟件測(cè)試步驟,1按流程順序?qū)⑵浞譃?個(gè)步驟 (1) 文檔、代碼測(cè)試：由項(xiàng)目小組完成； (2) 單元測(cè)試：由項(xiàng)目小組完成； (3) 集成測(cè)試：由項(xiàng)目小組完成； (4) 系統(tǒng)測(cè)試：由專業(yè)測(cè)試小組完成； (5) 驗(yàn)收測(cè)試：由用戶和開發(fā)商共同完成； (6) 安裝維護(hù)：由用戶和開發(fā)商共同完成。 這幾個(gè)步驟完全逆向檢測(cè)了軟件開發(fā)的各個(gè)階段。文檔代碼測(cè)試是對(duì)軟件文檔和代碼進(jìn)行檢查和審閱，,此測(cè)試應(yīng)貫穿于整個(gè)軟件開發(fā)生命周期中，尤其在開發(fā)早期，其作用比較顯著。單元測(cè)試主要測(cè)試程序代碼；集成測(cè)試主要對(duì)設(shè)計(jì)檢測(cè)；系統(tǒng)測(cè)試主要測(cè)試軟件功能；驗(yàn)收測(cè)試主要對(duì)用戶需求檢測(cè)。但是，每個(gè)測(cè)試階段仍要對(duì)其他測(cè)試階段的測(cè)試內(nèi)容加以測(cè)試，只是測(cè)試重點(diǎn)不同。 軟件項(xiàng)目一開始，測(cè)試就開始了，從產(chǎn)品的需求分析審查到最后的驗(yàn)收測(cè)試、安裝測(cè)試結(jié)束，整個(gè)測(cè)試過程的步驟如圖4.8所示。,圖4.8 軟件測(cè)試步驟,2測(cè)試過程的螺旋圖表示 由于測(cè)試貫穿于軟件整個(gè)開發(fā)生命周期中，而且測(cè)試的各個(gè)階段是交叉的，為了說明測(cè)試過程，可以把軟件開發(fā)與測(cè)試過程表示成一個(gè)螺旋圖，如圖4.9所示。,圖4.9 軟件開發(fā)與測(cè)試全過程,3測(cè)試過程的一般表示 從螺旋線圖上可以把測(cè)試階段從系統(tǒng)中分離開來分析研究。用螺旋線表明的測(cè)試過程可以分成4個(gè)階段：?jiǎn)卧獪y(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試，見圖4.10。,圖4.10 軟件測(cè)試的4個(gè)階段,首先分別完成每個(gè)單元(模塊)的測(cè)試任務(wù)，以確保每個(gè)模塊能正常工作。單元測(cè)試大量地采用白盒測(cè)試方法，盡可能發(fā)現(xiàn)模塊內(nèi)部的程序Bug。 然后，把已測(cè)試過的模塊組裝起來，進(jìn)行集成測(cè)試。其目的在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。這時(shí)較多的采用黑盒測(cè)試方法來設(shè)計(jì)測(cè)試用例。 完成集成測(cè)試后，要對(duì)開發(fā)工作初期制定的確認(rèn)準(zhǔn)則進(jìn)行檢驗(yàn)。確認(rèn)測(cè)試是檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段，通常均采用黑盒測(cè)試方法。,完成確認(rèn)測(cè)試后，給出合格的軟件產(chǎn)品。但為了檢驗(yàn)它能否與系統(tǒng)的其他部分(如硬件、數(shù)據(jù)庫(kù)及操作人員)協(xié)調(diào)工作，還需要進(jìn)行系統(tǒng)測(cè)試。,4不同測(cè)試過程的代價(jià) 很多研究成果表明，無論何時(shí)做出修改都要進(jìn)行完整的回歸軟件測(cè)試，在軟件生命周期中盡早地對(duì)軟件產(chǎn)品進(jìn)行軟件測(cè)試將使效率和質(zhì)量得到最好的保證。Bug發(fā)現(xiàn)的越晚，修改它所需的費(fèi)用就越高，因此應(yīng)該盡可能早的查找和修改Bug。美國(guó)質(zhì)量保證研究所對(duì)軟件測(cè)試的研究結(jié)果表明，越早發(fā)現(xiàn)軟件中存在的Bug，開發(fā)費(fèi)用就越低；在編碼后修改軟件Bug的成本是編碼前的10倍；在產(chǎn)品交付后修改軟件Bug的成本是交付前的10倍。圖4.11為不同測(cè)試階段軟件測(cè)試的代價(jià)。,圖4.11 不同測(cè)試階段的軟件測(cè)試費(fèi)用,圖4.11摘自實(shí)用軟件度量，1991，它列出了準(zhǔn)備軟件測(cè)試、執(zhí)行軟件測(cè)試和修改Bug所花費(fèi)的時(shí)間(以一個(gè)功能點(diǎn)為基準(zhǔn))，這些數(shù)據(jù)顯示：?jiǎn)卧獪y(cè)試的成本效率大約是集成測(cè)試的兩倍，是系統(tǒng)測(cè)試的三倍(參見條形圖)。域軟件測(cè)試意思是在軟件投入使用后，針對(duì)某個(gè)領(lǐng)域所作的所有軟件測(cè)試活動(dòng)。圖4.11說明盡可能早的排除盡可能多的Bug可以減少后期階段軟件測(cè)試的費(fèi)用。,5測(cè)試過程的總體流程圖及不同階段的流程圖 按測(cè)試執(zhí)行階段劃分主要包括：?jiǎn)卧獪y(cè)試、集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、業(yè)務(wù)測(cè)試、壓力測(cè)試、性能測(cè)試、安裝測(cè)試、驗(yàn)收測(cè)試等。其中，單元測(cè)試著重于軟件以源代碼形式實(shí)現(xiàn)的各個(gè)單元；集成測(cè)試著重于對(duì)軟件的體系結(jié)構(gòu)的設(shè)計(jì)和構(gòu)造；系統(tǒng)測(cè)試著重于把軟件、硬件和其他的系統(tǒng)元素集成在一起，根據(jù)軟件需求說明對(duì)已經(jīng)建造好的系統(tǒng)進(jìn)行測(cè)試；回歸測(cè)試著重于軟件的更改、更新后的測(cè)試。這四種測(cè)試是軟件全生命周期持續(xù)不斷的事情，而不是一個(gè)階段性的事情，并且要把測(cè)試概念的外延進(jìn)一步擴(kuò)大。,圖4.12為測(cè)試執(zhí)行階段總體流程圖，特別集成測(cè)試和系統(tǒng)測(cè)試的反饋意見可能導(dǎo)致設(shè)計(jì)文檔(需求或數(shù)據(jù)庫(kù))的修改。圖4.13為需求階段流程圖，圖4.14為設(shè)計(jì)編碼階段流程圖。其他階段的流程圖類似，這里就不介紹了。,圖4.12 軟件測(cè)試工作總體流程,圖4.13 需求階段流程圖,圖4.14 設(shè)計(jì)編碼階段工作流程,下面按照軟件測(cè)試步驟，對(duì)單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試作進(jìn)一步說明。,單元測(cè)試的要點(diǎn)是進(jìn)行單元模塊所有數(shù)據(jù)項(xiàng)的正確性、完善性測(cè)試，主要關(guān)注模塊的算法細(xì)節(jié)和模塊接口間流動(dòng)的數(shù)據(jù)。單元測(cè)試可看作是編碼工作的一部分，應(yīng)該由程序員完成。一般以白盒測(cè)試為主，輔以黑盒測(cè)試。單元級(jí)測(cè)試易于發(fā)現(xiàn)程序的Bug，易于達(dá)到完全代碼覆蓋率，減少測(cè)試費(fèi)用與開發(fā)時(shí)間。,4.4 單元測(cè)試(模塊測(cè)試、邏輯測(cè)試、結(jié)構(gòu)測(cè)試),單元測(cè)試需求所確定的是單元測(cè)試的內(nèi)容，根據(jù)概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)和軟件單元獲取。進(jìn)行單元測(cè)試主要采用編程人員之間相互交叉測(cè)試，因?yàn)橥ǔ＞幊倘藛T比較容易發(fā)現(xiàn)其他人員編寫代碼中的Bug，所以必須采用交叉測(cè)試。,1測(cè)試單元 測(cè)試單元定義是一個(gè)包括一個(gè)或多個(gè)計(jì)算機(jī)程序模塊及相應(yīng)控制數(shù)據(jù)(如表格)、調(diào)用過程、操作過程的模塊集合，且該集合成員滿足下面條件： 所有模塊屬于同一個(gè)計(jì)算機(jī)程序系統(tǒng)。 集合中至少有一個(gè)模塊(新的或改變過的模塊)尚未完成單元測(cè)試。 所有模塊及相應(yīng)數(shù)據(jù)和過程的集合是一個(gè)測(cè)試過程的唯一對(duì)象。,2單元測(cè)試定義 為了更清晰的了解單元測(cè)試，在單元測(cè)試前，先要明白以下幾個(gè)問題： 單元測(cè)試的目標(biāo)：確保模塊被正確地編碼。 由誰去做：通常由程序人員測(cè)試。 怎樣去測(cè)試：功能測(cè)試可以用黑盒測(cè)試方法，代碼測(cè)試可用白盒測(cè)試方法。 什么時(shí)候可以停止：當(dāng)程序員感到代碼沒有Bug時(shí)。 記錄：通常沒有記錄，人們?cè)谇宄陨蠁栴}后就可以編寫測(cè)試用例了。,單元測(cè)試是針對(duì)軟件設(shè)計(jì)中用源代碼實(shí)現(xiàn)的每一個(gè)基本單元程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能，它所測(cè)試的內(nèi)容包括單元的內(nèi)部結(jié)構(gòu)(如邏輯和數(shù)據(jù)流)以及單元的功能和行為。目的在于發(fā)現(xiàn)各個(gè)模塊內(nèi)部可能存在的各種Bug。單元測(cè)試需要從程序內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，多個(gè)模塊可以平行、獨(dú)立地進(jìn)行測(cè)試。,3單元測(cè)試采取的方法 單元測(cè)試一般運(yùn)用白盒測(cè)試(控制流、數(shù)據(jù)流測(cè)試)，以路徑覆蓋為最佳測(cè)試準(zhǔn)則，驗(yàn)證單元實(shí)現(xiàn)的功能，而不需要知道程序是如何實(shí)現(xiàn)它們；有時(shí)也采用黑盒測(cè)試(等價(jià)類劃分、因果圖、邊值分析)等多種測(cè)試技術(shù)。黑盒測(cè)試關(guān)注的是單元的輸入與輸出，不是白盒測(cè)試的替代品，而是輔助白盒測(cè)試發(fā)現(xiàn)其他類型的Bug。,4單元測(cè)試要解決的問題 進(jìn)行單元測(cè)試是為了證明這段代碼的行為和人們期望是否一致。單元測(cè)試在程序編碼中就已經(jīng)進(jìn)行。其內(nèi)容包括：設(shè)計(jì)測(cè)試用例要測(cè)試哪幾方面的問題，針對(duì)這幾方面問題各自測(cè)試什么內(nèi)容、測(cè)試的具體步驟、實(shí)用測(cè)試策略。,圖4.15 單元測(cè)試,通常單元測(cè)試由編碼人員自己來完成，因而有人認(rèn)為編碼與單元測(cè)試合為一個(gè)開發(fā)階段。單元測(cè)試大多從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例，即多采用白盒測(cè)試。多個(gè)程序單元可以并行地獨(dú)立開展測(cè)試工作。下面介紹單元測(cè)試要解決的問題和單元測(cè)試的步驟。 單元測(cè)試是要針對(duì)每個(gè)模塊的程序，解決以下五個(gè)問題，見圖4.15。,(1) 模塊接口測(cè)試：模塊接口測(cè)試是單元測(cè)試的基礎(chǔ)，只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測(cè)試才有意義。在開始單元測(cè)試時(shí)，應(yīng)對(duì)通過被測(cè)試模塊的數(shù)據(jù)流進(jìn)行測(cè)試。在模塊接口測(cè)試時(shí)，進(jìn)行內(nèi)外存交換時(shí)要考慮下列問題： 文件屬性是否正確。 OPEN與CLOSE語(yǔ)句是否正確。 緩沖區(qū)容量與記錄長(zhǎng)度是否匹配。 在進(jìn)行讀寫操作之前是否打開了文件。 在結(jié)束文件處理時(shí)是否關(guān)閉了文件。, 正文書寫/輸入錯(cuò)誤。 I/O的Bug是否檢查并做了處理。 (2) 局部數(shù)據(jù)結(jié)構(gòu)測(cè)試：在模塊工作過程中，其內(nèi)部的數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯(cuò)誤。主要檢查： 不正確或不一致的數(shù)據(jù)類型說明。 使用尚未賦值或尚未初始化的變量。 上、下溢出或地址Bug。 錯(cuò)誤的初始值或錯(cuò)誤的缺省值。 變量名拼寫B(tài)ug或書寫B(tài)ug。 全局?jǐn)?shù)據(jù)對(duì)模塊的影響。,(3) 路徑測(cè)試：路徑條件指模塊的運(yùn)行能否做到滿足特定的邏輯覆蓋。 在單元測(cè)試中，最主要的測(cè)試是針對(duì)路徑的測(cè)試。測(cè)試用例必須能夠發(fā)現(xiàn)由于計(jì)算錯(cuò)誤、不正確的判定或不正常的控制流等產(chǎn)生的Bug。單元測(cè)試中常見的Bug有： 誤解的或不正確的算術(shù)優(yōu)先級(jí)。 混合模式的運(yùn)算Bug。 錯(cuò)誤的初始化。 精確度不夠精確。 表達(dá)式的不正確符號(hào)表示。,針對(duì)判定和條件覆蓋，設(shè)計(jì)測(cè)試用例要能夠發(fā)現(xiàn)如下Bug： 不同數(shù)據(jù)類型的比較。 不正確的邏輯操作或優(yōu)先級(jí)。 應(yīng)當(dāng)相等的地方由于精確度的Bug而不能相等。 正確的判定或不正確的變量。 不正確或不存在的循環(huán)終止。 當(dāng)遇到分支循環(huán)時(shí)不能退出。 不適當(dāng)?shù)男薷难h(huán)變量。 給出三點(diǎn)建議： 選擇適當(dāng)?shù)臏y(cè)試用例，對(duì)模塊中重要的執(zhí)行路徑進(jìn)行測(cè)試。, 應(yīng)設(shè)計(jì)測(cè)試用例查找由錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的Bug。 對(duì)基本執(zhí)行路徑和循環(huán)進(jìn)行測(cè)試可以發(fā)現(xiàn)大量的路徑Bug。 (4) Bug處理：在測(cè)試中，Bug處理的重點(diǎn)是模塊在工作中發(fā)生了Bug，其中的Bug處理方法是否有效。檢驗(yàn)程序中的Bug處理可能面對(duì)的情況有： 對(duì)運(yùn)行發(fā)生的Bug描述難以理解。 所報(bào)告的Bug與實(shí)際遇到的Bug不一致。 出錯(cuò)后，在Bug處理之前就引起系統(tǒng)的干預(yù)。 對(duì)錯(cuò)誤條件的處理正確與否。, 提供的Bug信息不足，以至于無法找到Bug的原因。 出錯(cuò)的描述是否能夠?qū)ug定位。 (5) 邊界測(cè)試：邊界測(cè)試是單元測(cè)試的最后一步，采用邊界值分析法來設(shè)計(jì)測(cè)試用例，認(rèn)真仔細(xì)地在為限制數(shù)據(jù)處理而設(shè)置的邊界處進(jìn)行測(cè)試，看模塊是否能夠正常工作。 一些可能與邊界有關(guān)的數(shù)據(jù)類型，如數(shù)值、字符、位置、數(shù)量、尺寸等，還要注意這些邊界的首個(gè)、最后一個(gè)、最大值、最小值、最長(zhǎng)、最短、最高、最低、等于、大于或小于確定的比較值。對(duì)這些地方要仔細(xì)地選擇測(cè)試用例，認(rèn)真加以測(cè)試。,在邊界條件測(cè)試中，應(yīng)設(shè)計(jì)測(cè)試用例檢查以下情況： 在n次循環(huán)的第0次、第1次、第n次是否有Bug。 運(yùn)算或判斷中取最大值、最小值時(shí)是否有Bug。 數(shù)據(jù)流、控制流中等于、大于、小于確定的比較值是否出現(xiàn)Bug。 如果對(duì)模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測(cè)試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。,5單元測(cè)試環(huán)境 由于被測(cè)模塊并不是一個(gè)獨(dú)立可運(yùn)行的程序，因此需要構(gòu)造該模塊的測(cè)試環(huán)境，要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與所測(cè)模塊相聯(lián)系的其他模塊。這些輔助模塊分為兩種: (1) 驅(qū)動(dòng)模塊：用以模擬被測(cè)模塊的上級(jí)模塊。相當(dāng)于被測(cè)模塊的主程序，它接收測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測(cè)模塊，最后再輸出實(shí)測(cè)結(jié)果。 (2) 樁模塊(存根模塊)：用以代替所測(cè)模塊工作過程中調(diào)用的子模塊，,由被測(cè)模塊調(diào)用，它們僅作很少的數(shù)據(jù)處理，例如打印入口和返回，以便檢驗(yàn)被測(cè)模塊與其下級(jí)模塊的接口。樁模塊可以做少量的數(shù)據(jù)操作，不需要把子模塊所有功能都帶進(jìn)來，但不允許什么事情也不做。被測(cè)模塊、與它相關(guān)的驅(qū)動(dòng)模塊和樁模塊共同構(gòu)成了一個(gè)“測(cè)試環(huán)境”，如圖4.16所示。 圖4.16中設(shè)置了一個(gè)驅(qū)動(dòng)模塊和3個(gè)樁模塊。驅(qū)動(dòng)模塊在單元測(cè)試中接受測(cè)試數(shù)據(jù)，把相關(guān)數(shù)據(jù)傳送給被測(cè)模塊，啟動(dòng)被測(cè)模塊，并打印出相應(yīng)的結(jié)果。,圖4.16 單元測(cè)試工作環(huán)境,6單元測(cè)試步驟 單元測(cè)試步驟見圖4.17和表4.2。其中圖4.17(b)是采用白盒測(cè)試時(shí)的工作流程圖。,圖4.17 單元測(cè)試步驟,表4.2 單元測(cè)試步驟描述,7單元測(cè)試階段的主要數(shù)據(jù)流 在每個(gè)階段，每個(gè)基本活動(dòng)都有其自身的輸入集和輸出集，其內(nèi)容由一系列任務(wù)組成。所有活動(dòng)的輸出集應(yīng)當(dāng)包含足夠的信息來創(chuàng)建至少以下兩個(gè)文件：測(cè)試設(shè)計(jì)說明和測(cè)試總結(jié)報(bào)告。圖4.18為單元測(cè)試階段的數(shù)據(jù)流。,圖4.18 單元測(cè)試階段的主要數(shù)據(jù)流,8執(zhí)行單元測(cè)試 編程人員進(jìn)行單元測(cè)試主要采用程序員之間交叉測(cè)試，因?yàn)橥ǔ＞幋a人員比較容易發(fā)現(xiàn)其他人員編寫代碼中的Bug，所以必須采用交叉測(cè)試。軟件測(cè)試工作由產(chǎn)品評(píng)測(cè)部擔(dān)任，需要項(xiàng)目組相關(guān)人員配合完成。 在模塊中應(yīng)對(duì)每一條獨(dú)立執(zhí)行路徑進(jìn)行測(cè)試，單元測(cè)試的基本任務(wù)是保證模塊中每條語(yǔ)句至少執(zhí)行一次。此時(shí)設(shè)計(jì)測(cè)試用例是為了發(fā)現(xiàn)因錯(cuò)誤計(jì)算、不正確的比較和不適當(dāng)?shù)目刂屏髟斐傻腂ug。此時(shí)基本路徑測(cè)試和循環(huán)測(cè)試是最常用且最有效的測(cè)試技術(shù)。,在單元測(cè)試過程中，一般認(rèn)為單元測(cè)試應(yīng)緊接在編碼后，當(dāng)源程序編制完成并通過復(fù)審和編譯檢查，便可開始單元測(cè)試。測(cè)試用例的設(shè)計(jì)應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計(jì)信息選取測(cè)試數(shù)據(jù)，將增大發(fā)現(xiàn)各類Bug的可能性。在確定測(cè)試用例的同時(shí)，應(yīng)給出期望結(jié)果。,9單元測(cè)試產(chǎn)生的工件清單 工件清單包括：軟件單元測(cè)試計(jì)劃、單元測(cè)試用例、測(cè)試過程、測(cè)試腳本、測(cè)試日志、測(cè)試評(píng)估摘要等。,10單元測(cè)試人員職責(zé) 軟件測(cè)試工作由產(chǎn)品評(píng)測(cè)部擔(dān)任，需要項(xiàng)目組相關(guān)人員配合完成。測(cè)試人員及其職責(zé)見表4.3。,表4.3 測(cè)試人員職責(zé),11單元測(cè)試中測(cè)試工具的選擇 在結(jié)構(gòu)化程序編程中，測(cè)試的對(duì)象主要是函數(shù)或者子程序過程；在面向?qū)ο蟮木幊讨?，如Java/C+等語(yǔ)言，測(cè)試的對(duì)象可能是類，也可能是類的成員函數(shù)，或者是被典型定義的一個(gè)菜單、屏幕顯示界面或者對(duì)話框等等。由于單元測(cè)試的本質(zhì)是針對(duì)代碼進(jìn)行測(cè)試，所以，不同語(yǔ)言的程序需要選擇適合本身的單元測(cè)試工具。其實(shí)，有很多測(cè)試工具都支持單元測(cè)試。,如果能借助這些工具，可以極大地減少工作量，減少測(cè)試的盲目性，提高單元測(cè)試的覆蓋率和準(zhǔn)確度。例如針對(duì)C和C+ 代碼，Logiscope、C+ Test、QA C+ 及Klocwork等測(cè)試工具可以很好地滿足測(cè)試要求；對(duì)于匯編語(yǔ)言，可以用AsmTester單元測(cè)試工具；對(duì)于Java 語(yǔ)言的單元測(cè)試過程，可以借助Junit單元測(cè)試包來完成。,在實(shí)際中，軟件的每個(gè)模塊都能單獨(dú)工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是模塊相互調(diào)用時(shí)接口會(huì)引入許多新問題。如數(shù)據(jù)經(jīng)過接口可能丟失；一個(gè)模塊對(duì)另一模塊可能造成不應(yīng)有的影響；,4.5 集成測(cè)試(組裝測(cè)試、聯(lián)合測(cè)試),幾個(gè)子功能組合起來不能實(shí)現(xiàn)主功能；誤差不斷積累達(dá)到不可接受的程度；全局?jǐn)?shù)據(jù)結(jié)構(gòu)出現(xiàn)Bug等。解決的辦法是在每個(gè)模塊完成單元測(cè)試后，需要按照設(shè)計(jì)時(shí)做出的結(jié)構(gòu)圖，把它們連接起來，將所有模塊按照設(shè)計(jì)要求組裝成系統(tǒng)，進(jìn)行集成測(cè)試。,1集成測(cè)試概念 集成測(cè)試是將已測(cè)試過的所有模塊按設(shè)計(jì)要求(如根據(jù)結(jié)構(gòu)圖)集成為子系統(tǒng)或系統(tǒng)，主要對(duì)與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進(jìn)行測(cè)試，以檢驗(yàn)總體設(shè)計(jì)中各模塊之間的接口設(shè)計(jì)問題、模塊之間的相互影響、上層模塊存在的各種差錯(cuò)及全局?jǐn)?shù)據(jù)結(jié)構(gòu)對(duì)系統(tǒng)的影響等方面，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的Bug，最終構(gòu)成要求的軟件系統(tǒng)。由于單元測(cè)試不能窮盡，單元測(cè)試又會(huì)引入新Bug，單元測(cè)試后肯定會(huì)隱藏Bug，集成一般不可能一次成功，必須經(jīng)測(cè)試后才能成功。,實(shí)踐表明，一些模塊雖然能夠單獨(dú)的工作，但并不能保證集成起來也能正常工作。程序在某些局部反映不出來的Bug，在全局上很可能暴露出來，影響功能的實(shí)現(xiàn)。 在集成測(cè)試中需要考慮的問題是： (1) 在把各個(gè)模塊連接起來時(shí)，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失； (2) 一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；,(3) 各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能； (4) 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題； (5) 單個(gè)模塊的誤差累積起來，是否會(huì)放大，是否到了不能接受的程度。 在單元測(cè)試的同時(shí)可進(jìn)行集成測(cè)試，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的Bug，最終構(gòu)成要求的軟件系統(tǒng)。,2所采取的方法 集成測(cè)試主要采用黑盒測(cè)試中的等價(jià)類劃分、邊值分析，白盒測(cè)試中的數(shù)據(jù)流測(cè)試、域測(cè)試、調(diào)用、覆蓋等測(cè)試技術(shù)。集成測(cè)試的策略指進(jìn)行單元組裝的方法和步驟。集成測(cè)試的策略分為一次集成測(cè)試和漸增式集成測(cè)試。 1) 一次性集成方式 一次性集成方式是一種非增式組裝方式(又稱為整體拼裝)。在配備輔助模塊的條件下，對(duì)所有模塊進(jìn)行單元測(cè)試。然后，把所有模塊組裝在一起進(jìn)行測(cè)試，最終得到滿足要求的軟件系統(tǒng)。一次性集成過程見圖4.19。,圖4.19 一次性集成測(cè)試過程示意圖,2) 漸增式集成方式(也稱為增式集成) 增式集成測(cè)試與一次性集成測(cè)試方式有所不同。它的集成是逐步實(shí)現(xiàn)的，集成測(cè)試也是逐步完成的。首先對(duì)每個(gè)模塊進(jìn)行模塊測(cè)試，然后將這些模塊逐步組裝成較大的系統(tǒng)。在集成的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的Bug，通過增量逐步組裝成為要求的軟件系統(tǒng)。 一次性集成測(cè)試方法是先分散測(cè)試，再集中起來一次完成集成測(cè)試。如果在模塊的接口處存在差錯(cuò)，只會(huì)在最后的集成時(shí)一下子暴露出來。,與此相反，增式集成測(cè)試的逐步集成和逐步測(cè)試的辦法，把可能出現(xiàn)的差錯(cuò)分散暴露出來，便于找出問題和修改。其次，增式集成測(cè)試使用了較少的輔助模塊，也就減少了輔助性測(cè)試工作。并且一些模塊在逐步集成的測(cè)試中，得到了較為頻繁的考驗(yàn)，因而可能取得較好的測(cè)試效果?？偟恼f來，增式集成測(cè)試比一次性集成測(cè)試具有一定的優(yōu)越性。 漸增式集成測(cè)試可按不同的次序?qū)嵤?，分為自底向上、自頂向下和混合漸增式測(cè)試。,3) 自頂向下測(cè)試 自頂向下增式測(cè)試表示逐步集成和逐步測(cè)試是按結(jié)構(gòu)圖自上而下進(jìn)行的。這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進(jìn)行組裝。在測(cè)試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件 功能。圖4.20為按深度方向組裝的例子。,圖4.20 按深度方向組裝測(cè)試示意圖,4) 自底向上的漸增式 這種集成方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測(cè)試。因?yàn)槟K是自底向上進(jìn)行組裝，對(duì)于一個(gè)給定層次的模塊，它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測(cè)試完成，所以不再需要樁模塊。在模塊的測(cè)試過程中需要從子模塊得到的信息可以通過直接運(yùn)行子模塊得到(見圖4.21)。,圖4.21 自底向上漸增式測(cè)試示意圖,自頂向下增量的方式和自底向上增量的方式各有優(yōu)缺點(diǎn)。一般來說，一種方式的優(yōu)點(diǎn)可能是另一種方式的缺點(diǎn)。,5) 混合漸增式測(cè)試 即衍變的自頂向下的增量測(cè)試：首先對(duì)輸入/輸出模塊和引入新算法模塊進(jìn)行測(cè)試；然后自底向上組裝成功能相當(dāng)完整且相對(duì)獨(dú)立的子系統(tǒng)；再由主模塊開始自頂向下進(jìn)行增量測(cè)試。,3集成測(cè)試需求 集成測(cè)試需求所確定的是對(duì)某一集成測(cè)試版本的測(cè)試內(nèi)容，即測(cè)試的具體對(duì)象。集成測(cè)試需求主要來源于設(shè)計(jì)模型和集成構(gòu)件計(jì)劃，歸納如下： (1) 集成測(cè)試版本應(yīng)分析其類協(xié)作與消息序列，從而找出該測(cè)試版本的外部接口。 (2) 由集成測(cè)試版本的外部接口確定集成測(cè)試用例。 (3) 測(cè)試用例應(yīng)覆蓋工作版本每一外部接口的所有消息流序列。 集成測(cè)試著重于集成版本的外部接口的行為。因此，測(cè)試需求應(yīng)具有可觀測(cè)、可測(cè)評(píng)性。,注意：一個(gè)外部接口和測(cè)試用例的關(guān)系是多對(duì)多，部分集成工作版本的測(cè)試需求可映射到系統(tǒng)測(cè)試需求，因此對(duì)這些集成測(cè)試用例可采用重用系統(tǒng)測(cè)試用例技術(shù)。,4集成測(cè)試步驟 集成測(cè)試步驟見表4.4。,表4.4 集成測(cè)試步驟,5集成測(cè)試全過程和流程圖 集成測(cè)試用圖來描述：圖4.22和圖4.23分別為集成測(cè)試的全過程和流程圖。,圖4.22 集成測(cè)試全過程,圖4.23 集成測(cè)試流程圖,6集成測(cè)試產(chǎn)生的工件清單 軟件集成測(cè)試計(jì)劃； 集成測(cè)試用例； 測(cè)試過程； 測(cè)試腳本和測(cè)試日志； 測(cè)試評(píng)估摘要。,系統(tǒng)測(cè)試是在實(shí)際使用環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列綜合全面的組裝測(cè)試和確認(rèn)測(cè)試，對(duì)系統(tǒng)的準(zhǔn)確性及完整性等方面進(jìn)行測(cè)試。具體來說就是把已經(jīng)經(jīng)過確認(rèn)的軟件產(chǎn)品放入整個(gè)實(shí)際的計(jì)算機(jī)系統(tǒng)中，與其他系統(tǒng)成分，包括計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)、支持軟件、數(shù)據(jù)、使用人員等其他元素，甚至還可能包括受計(jì)算機(jī)控制的執(zhí)行機(jī)構(gòu)結(jié)合在一起，進(jìn)行系統(tǒng)的各種安裝測(cè)試、功能測(cè)試、確認(rèn)測(cè)試等相結(jié)合的綜合測(cè)試。,4.6 系 統(tǒng) 測(cè) 試,下面給出系統(tǒng)測(cè)試進(jìn)入條件。 (1) 具有軟件技術(shù)規(guī)格書、軟件需求規(guī)格說明、軟件設(shè)計(jì)文檔、用戶手冊(cè)、操作手冊(cè)及單元測(cè)試、軟部件測(cè)試、配置項(xiàng)測(cè)試的測(cè)試用例、測(cè)試報(bào)告和全部軟件問題報(bào)告。 (2) 配置項(xiàng)必須通過測(cè)試，所有軟件配置項(xiàng)納入配置管理。 (3) 有經(jīng)過審批并納入系統(tǒng)試驗(yàn)大綱的測(cè)試用例。 系統(tǒng)測(cè)試的測(cè)試人員由測(cè)試組成員(質(zhì)量保證人員)或測(cè)試組成員與用戶共同組成。,系統(tǒng)測(cè)試在整個(gè)系統(tǒng)開發(fā)完成，即將交付用戶使用前進(jìn)行。在這一階段，完全采用黑盒法對(duì)整個(gè)系統(tǒng)進(jìn)行測(cè)試。軟件在系統(tǒng)中畢竟占有相當(dāng)重要的位置，軟件的質(zhì)量如何，軟件的測(cè)試工作進(jìn)行得是否扎實(shí)與能否順利、成功地完成系統(tǒng)測(cè)試密切相關(guān)。系統(tǒng)測(cè)試實(shí)際上是針對(duì)系統(tǒng)中各個(gè)小的組成部分進(jìn)行的綜合性檢驗(yàn)。盡管每一個(gè)檢驗(yàn)有著特定的目標(biāo)，然而所有的檢測(cè)工作都要驗(yàn)證系統(tǒng)中每個(gè)部分均已得到正確集成，并能完成指定的功能。 系統(tǒng)測(cè)試過程如下： 制訂系統(tǒng)測(cè)試計(jì)劃設(shè)計(jì)系統(tǒng)