第二章軟件測試過程與測試模型

1、軟件軟件測試測試技術(shù)技術(shù)Te s t i n g AND Developing軟件測試過程與測試模型廣東嶺南職業(yè)技術(shù)學(xué)院軟件技術(shù)教研室李文彪上節(jié)回顧 軟件可靠性 缺陷的定義及特征 缺陷的主要原因 軟件測試的目的 缺陷修復(fù)的代價 軟件質(zhì)量SQA、SQC、軟件測試之間的關(guān)系第2章 軟件測試過程與測試模型 學(xué)習(xí)目標(biāo)（1）掌握軟件開發(fā)過程及主要的開發(fā)模型（2）掌握軟件測試過程（3）了解測試模型（4）了解測試?yán)砟?.1軟件開發(fā)過程相關(guān)知識2.1.1 軟件產(chǎn)品的組成（了解） 1、軟件產(chǎn)品需要各種開發(fā)投入圖1-5 獲得軟件產(chǎn)品的工作示意圖產(chǎn)品說明書、產(chǎn)品審查、設(shè)計文檔、進度計劃、上一版本信息反饋、商業(yè)競爭對

2、手的同類軟件產(chǎn)品情況、客戶調(diào)查、易用性數(shù)據(jù)、觀察與感受說明書開發(fā)過程軟件產(chǎn)品的組成（續(xù)） 2、客戶需求 客戶需求包括對客戶調(diào)查所收集的詳細信息、以前軟件的使用情況及存在的問題、競爭對手的軟件產(chǎn)品信息等等。通過分析客戶需求，可以確定將要開發(fā)的軟件產(chǎn)品應(yīng)該具有哪些功能。 3、產(chǎn)品說明 產(chǎn)品說明書的作用就是對客戶需求信息進行綜合描述，并包括用戶沒有提出、但軟件產(chǎn)品本身必須要實現(xiàn)的要求，從而針對產(chǎn)品進行定義并確定其功能。軟件產(chǎn)品的組成（續(xù)）4、設(shè)計文檔 構(gòu)架。即產(chǎn)生描述軟件整體設(shè)計的文檔，包括軟件所有主要部分的描述以及相互間的交互方式。 數(shù)據(jù)流示意圖。表示數(shù)據(jù)在程序中如何流動的正規(guī)示意圖。通常由圓圈和

3、線條組成，所以也稱為泡泡圖。 狀態(tài)變化示意圖。將軟件分解為基本狀態(tài)或者條件的另一種正規(guī)示意圖，表示不同狀態(tài)之間的變化的方式。 流程圖。用圖形描述程序邏輯的最常用方式之一。根據(jù)詳細的流程圖編寫程序代碼簡單方便。 注釋代碼。代碼注釋是便于維護代碼的程序員掌握代碼的內(nèi)容和執(zhí)行方式。軟件產(chǎn)品的組成（續(xù)）5、測試文檔一般測試文檔所包含的內(nèi)容： 測試計劃。描述用于驗證軟件是否符合產(chǎn)品說明書和客戶需求的整體方案。 測試用例。依據(jù)測試的項目，并描述驗證軟件的詳細步驟。 軟件測試報告。描述依據(jù)測試用例找出的問題，通常提交測試報告。 歸納、統(tǒng)計和總結(jié)。采用圖表、表格和報告等形式來描述整個測試過程。 軟件產(chǎn)品的組成

4、（續(xù)）6、開發(fā)進度表 軟件項目的開發(fā)進度通常使用Gantt圖表來進行描述。7、軟件產(chǎn)品組成的其他部分（1）程序代碼 （2）幫助文件 （3）用戶手冊（4）樣本和示例 （5）標(biāo)簽 （6）產(chǎn)品支持信息（7）圖表和標(biāo)志 （8）錯誤信息 （9）廣告與宣傳材料（10）軟件的安裝 （11）軟件說明文件（12）測試錯誤提示信息 2.1.2 軟件開發(fā)項目組 項目管理經(jīng)理：全程負責(zé)整個軟件項目的開發(fā)。 系統(tǒng)設(shè)計師：設(shè)計整個系統(tǒng)構(gòu)架或軟件構(gòu)思。 程序員：負責(zé)設(shè)計、編寫程序，并修改軟件中的缺陷。 軟件測試員/測試師：負責(zé)找出并報告軟件產(chǎn)品的問題，與開發(fā)組密切合作，進行測試并報告發(fā)現(xiàn)的問題。 技術(shù)制作、用戶助手、用戶培

5、訓(xùn)員、手冊編寫和文件檔案專員：負責(zé)編寫軟件產(chǎn)品附帶的文件和聯(lián)機文檔 。 結(jié)構(gòu)管理和制作人員：負責(zé)將程序員編寫的全部文檔資料合并成一個軟件包 。 軟件開發(fā)過程軟件開發(fā)過程 一個軟件的開發(fā)階段大體包括如下五個階段： （1）需求分析； （2）概要設(shè)計； （3）詳細設(shè)計； （4）軟件編碼； （5）軟件測試； （6）軟件運行與維護。 圖2-1 軟件的開發(fā)過程 （1）需求分析 （2）概要設(shè)計 （3）詳細設(shè)計 （4）軟件編碼 項目評審 項目評審 項目評審 （6）軟件維護 （5）軟件測試 需求分析報告 概要設(shè)計報告 詳細設(shè)計報告 源代碼 測試文檔 需求分析。這個階段的任務(wù)是對用戶的要求進行分析和綜合，確定軟件

6、的基本目標(biāo)和邏輯功能要求，解決系統(tǒng)”做什么”的問題，并寫出軟件需求規(guī)格說明書。該份文件資料是軟件工程中最重要的文件，是用正式文檔準(zhǔn)確地記錄對目標(biāo)系統(tǒng)的需求，是用戶和軟件開發(fā)人員之間共同約定和開發(fā)的基礎(chǔ)。 概要設(shè)計。這個階段的主要任務(wù)是解決系統(tǒng)”怎么做”的問題。概要設(shè)計決定軟件系統(tǒng)的總體結(jié)構(gòu)即模塊結(jié)構(gòu)，并給出模塊的相互調(diào)用關(guān)系、模塊間傳遞的數(shù)據(jù)及每個模塊的功能說明。這個階段的文檔資料是軟件結(jié)構(gòu)圖和模塊功能說明。 詳細設(shè)計。這個階段的任務(wù)是把每個模塊內(nèi)部過程的描述具體化，也就是回答”應(yīng)該怎樣具體地實現(xiàn)這個系統(tǒng)”。該階段的任務(wù)并不是編寫程序，而是設(shè)計出程序的詳細規(guī)格說明書。該規(guī)格說明書類似于其他工程

7、領(lǐng)域使用的工程藍圖。 軟件編碼。這個階段的主要任務(wù)是程序員根據(jù)軟件詳細規(guī)格說明書，寫出正確的、容易理解和維護的程序模塊。程序員要選取一種適當(dāng)?shù)某绦蛟O(shè)計語言，把詳細設(shè)計的結(jié)果翻譯成用選定語言書寫的程序，并進行單元測試，仔細測試編寫的每一個模塊。 軟件測試。主要任務(wù)是發(fā)現(xiàn)和排除錯誤，也就是對軟件系統(tǒng)進行從上到下全面的測試和檢驗，看它是否符合軟件總體設(shè)計方案規(guī)定的功能要求。在此期間，要提出測試標(biāo)準(zhǔn)，制定測試計劃，確定測試方法。通過對軟件測試結(jié)果的分析可以預(yù)測軟件的可靠性；反之，根據(jù)軟件可靠性的要求，也可以決定測試和調(diào)試過程什么時候可以結(jié)束。同時還必須寫出軟件測試報告。 軟件維護。軟件維護是軟件生命周

8、期中最漫長的階段。維護的目的是使得軟件持久地滿足用戶需要并長期為用戶服務(wù)。具體地說，當(dāng)軟件在使用過程中發(fā)現(xiàn)錯誤時應(yīng)該加以改正；當(dāng)環(huán)境改變時應(yīng)該修改軟件以適應(yīng)新的環(huán)境；當(dāng)用戶有新的要求時應(yīng)該及時修改或擴充軟件以滿足用戶的新需求。 軟件的維護一般包括改正性維護、適應(yīng)性維護、完善性維護和預(yù)防性維護等四個方面。 2.1.3 軟件開發(fā)模式1、大棒開發(fā)法 源于能量爆發(fā)創(chuàng)造宇宙，萬物都由能量和物質(zhì)積聚而成的理論，但如果不是遵循某種正確的排列和組合，形成的將不是預(yù)先期望的事物。大棒模式與上述理論一樣：一大堆能量（這里指開發(fā)軟件所需的人力和物力）放在一起，巨大的能量進行釋放，通常的結(jié)果可能是產(chǎn)生了優(yōu)秀的軟件產(chǎn)品

9、或成為一堆“廢品”（不成功的軟件）。 優(yōu)點：思路簡單， 通?？赡苁情_發(fā)者的“突發(fā)奇想” 缺點：開發(fā)過程是非工程化的，隨意性大 關(guān)于測試：有的較簡單，有的則非常困難軟件開發(fā)模式（續(xù)）2、邊寫邊改法 采用邊寫邊改法的軟件開發(fā)通常只是有了比較粗略的想法就開始進行簡單的設(shè)計、然后進行較長的反復(fù)編寫、測試與修復(fù)這樣一個循環(huán)的過程。在認為無法更精細的描述軟件產(chǎn)品要求時，就發(fā)布產(chǎn)品。 優(yōu)點：能夠較為迅速的展現(xiàn)成果，適合需要快速制作而且用完就扔的小項目，如示范程序、演示程序等。 缺點：其編碼和測試可能將是長期的循環(huán)往復(fù)的過程。 軟件開發(fā)模式（續(xù)）產(chǎn)品說明書代碼編制、測試、修復(fù) 最終產(chǎn)品軟件開發(fā)模式（續(xù)）3、瀑

10、布法 瀑布模式是將軟件生命周期的各項活動，規(guī)定為按照固定順序相連的若干個階段性工作，形如瀑布流水，最終得到軟件產(chǎn)品。 優(yōu)點：易于理解；調(diào)研開發(fā)的階段性；強調(diào)早期計劃及需求調(diào)查；確定何時能夠交付產(chǎn)品及何時進行評審與測試。 缺點：需求調(diào)查分析只進行一次，不能適應(yīng)需求變化；順序的開發(fā)流程，使得開發(fā)中的經(jīng)驗教訓(xùn)不能反饋到該項目的開發(fā)中去；不能反映出軟件開發(fā)過程的反復(fù)與迭代性；沒有包含任何類型的風(fēng)險評估；開發(fā)中出現(xiàn)的問題直到開發(fā)后期才能夠顯露，因此失去及早糾正的機會。軟件開發(fā)模式（續(xù)）問題定義分析研究需求分析軟件設(shè)計編碼測試維護定義階段開發(fā)階段維護階段軟件開發(fā)模式（續(xù)） 4、快速原型法 根據(jù)客戶需求在較

11、短的時間內(nèi)解決用戶最迫切解決的問題，完成可演示的產(chǎn)品。這個產(chǎn)品只實現(xiàn)最重要功能，在得到用戶的更加明確的需求之后，原型將丟棄。需求分析原型開發(fā)原型評價最終設(shè)計系統(tǒng)實現(xiàn)用戶反饋圖1-8 快速原型開發(fā)模式軟件開發(fā)模式（續(xù)）5、螺旋模式法 螺旋模式是瀑布模式與邊寫邊改演化模式相結(jié)合，并加入風(fēng)險評估所建立的軟件開發(fā)模式。 主要思想是在開始時不必詳細定義所有細節(jié)，而是從小開始，定義重要功能，盡量實現(xiàn)，接受客戶反饋，進入下一階段，并重復(fù)上述過程，直到獲得最終產(chǎn)品。 每一螺旋（開發(fā)階段）包括5個步驟：確定目標(biāo)，選擇方案和限制條件。 對方案風(fēng)險進行評估，并能解決風(fēng)險。 進行本階段的開發(fā)和測試。 計劃下一階段。

12、確定進入下階段的方法。 優(yōu)點：嚴(yán)格的全過程風(fēng)險管理；強調(diào)各開發(fā)階段的質(zhì)量；提供機會評估項目是否有價值繼續(xù)下去。軟件開發(fā)模式（續(xù)）圖1-9 螺旋開發(fā)模式詳細設(shè)計風(fēng)險分析評估方案累計成本提交線制定計劃原型1原型2原型3可運行原型風(fēng)險分析風(fēng)險分析需求計劃開發(fā)計劃集成與測試軟件需求軟件產(chǎn)品設(shè)計需求確定設(shè)計確定實現(xiàn)編碼單元測試集成測試驗收測試其他開發(fā)方法 RUP模型 IPD流程 敏捷開發(fā)2.2軟件測試過程軟件測試過程 在實施軟件測試過程中，按照測試階段進行的。 在實施軟件測試前首先要寫出軟件測試計劃書，此計劃書可以作為測試工程師在實施測試過程中的指導(dǎo)書，它指出了測試范圍、測試方法、通過標(biāo)準(zhǔn)、停測標(biāo)準(zhǔn)（測

13、試通過標(biāo)準(zhǔn)）等。 各測試階段的先后順序可分為單元測試、集成測試、確認（有效性）測試、系統(tǒng)測試和驗收（用戶）測試五個階段。 軟件測試過程軟件測試過程（續(xù)） 1 單元測試 目的:檢測程序模塊中有無故障存在 對象:軟件設(shè)計的最小單位，與程序設(shè)計和編程實現(xiàn)關(guān)系密切 2 集成測試 目的:發(fā)現(xiàn)與接口有關(guān)的模塊之間的問題 方法：非增式集成測試法和增式集成測試法軟件測試過程（續(xù)） 2 集成測試 非增式集成測試法1.對每一個模塊進行單元測試2.在此基礎(chǔ)上按程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當(dāng)作一個整體進行測試 增式集成測試法不斷地把待測模塊連接到已測模塊集(或其子集)上，對待測模塊進行測試，直到最后一個

14、模塊測試完畢軟件測試過程（續(xù)） 3 確認測試 目的：對軟件產(chǎn)品進行評估以確定其是否滿足軟件需求的過程 4 系統(tǒng)測試 目的：針對系統(tǒng)中各個組成部分進行的綜合性檢驗，證明系統(tǒng)的性能 測試人員要求： 系統(tǒng)開發(fā)人員不能進行系統(tǒng)測試。 系統(tǒng)開發(fā)組織不能負責(zé)系統(tǒng)測試。軟件測試過程（續(xù)）5 驗收測試 目的：向用戶表明所開發(fā)的軟件系統(tǒng)能夠像用戶所預(yù)定的那樣工作 主要任務(wù)： 明確規(guī)定驗收測試通過的標(biāo)準(zhǔn)； 確定驗收測試方法； 確定驗收測試的組織和可利用的資源； 確定測試結(jié)果的分析方法； 制定驗收測試計劃并進行評審； 設(shè)計驗收測試的測試用例； 審查驗收測試的準(zhǔn)備工作； 執(zhí)行驗收測試； 分析測試結(jié)果，決定是否通過驗收

15、。 在編碼之后首先進行的測試是單元測試。 這個工作的角色是程序員（而不是測試工程師），主要是找出程序的各個模塊編碼和詳細設(shè)計說明書的缺陷。 集成測試是把軟件模塊組裝在一塊，驗證各個軟件模塊的接口之間是否能夠進行協(xié)作工作。例如，IC卡校園一卡通系統(tǒng)的子系統(tǒng)-卡機房管理系統(tǒng)。此系統(tǒng)分為12個子模塊。 圖 2-3 IC卡校園一卡通系統(tǒng)示意圖 通過集成測試之后，接口方面的錯誤也已排除，確認測試即可開始。 確認測試應(yīng)檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標(biāo)準(zhǔn)。確認測試的目的是檢查軟件系統(tǒng)是否達到用戶需求。 確認測試的結(jié)果有兩種可能，一種是功能和性能指標(biāo)滿足軟件需求說明的要求，用

16、戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴(yán)重錯誤和偏差一般很難在預(yù)定的工期內(nèi)改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。 確認測試之后即可開始系統(tǒng)測試。 系統(tǒng)測試是按照系統(tǒng)需求搭建系統(tǒng)環(huán)境（包括軟件環(huán)境和硬件環(huán)境），在整個環(huán)境中測試系統(tǒng)是否具有安全性、易用性等。 在“IC卡校園一卡通系統(tǒng)”中， 集成測試已經(jīng)解決了軟件模塊協(xié)調(diào)工作的問題，而系統(tǒng)測試考慮的是整個系統(tǒng)的問題。 例如：（1） 系統(tǒng)測試要檢查IC卡在POS 機（下位機）上消費后是否在服務(wù)器（上位機）的數(shù)據(jù)庫記錄中有所顯示。例如：卡的余額50元，消費了20元后，數(shù)據(jù)庫中記錄的余 額

17、是否是30元。（2）是否刷卡成功？（3）在服務(wù)器中的總黑名單和每臺POS 機上的黑名單分布是否一致？（4）數(shù)據(jù)網(wǎng)絡(luò)、財務(wù)網(wǎng)絡(luò)和管理網(wǎng)絡(luò)之間的通信接口是否可靠？（5）管理網(wǎng)絡(luò)中的前置機數(shù)據(jù)和數(shù)據(jù)中心服務(wù)器的數(shù)據(jù)交換通信接口是否順暢？等一系列測試問題均應(yīng)該在系統(tǒng)測試中進行考慮。 圖2-4 IC卡校園一卡通系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)圖 2.3實際的軟件測試工作流程2.3.1制定測試計劃1、制定計劃 本階段的主要工作內(nèi)容 對需求規(guī)格說明書的仔細研究 將要測試的產(chǎn)品分解成可獨立測試的單元 為每個測試單元確定采用的測試技術(shù) 為測試的下一個階段及其活動制定計劃 制定計劃包括： （1）概要測試計劃 （2）詳細測試計劃制定測

18、試計劃（續(xù)）2、測試大綱（用例） 測試大綱是軟件測試的依據(jù)，包括測試項目、測試步驟、測試完成的標(biāo)準(zhǔn)。 測試大綱的本質(zhì) 從測試的角度對被測對象的功能和各種特性的細化和展開。 測試大綱的好處 保證測試功能不被遺漏，也不被重復(fù)測試 合理安排測試人員 使得軟件測試不依賴于個人制定測試計劃（續(xù)）3、軟件測試報告 軟件測試報告是軟件測試過程中最重要的文檔，它的內(nèi)容包括： 記錄問題發(fā)生的環(huán)境 如：各種資源的配置情況 記錄問題的再現(xiàn)步驟 記錄問題性質(zhì)的說明 記錄問題的處理進程 問題處理進程從一定角度上反映測試的進程和被測軟件的質(zhì)量狀況以及改善過程。2.3.2 測試執(zhí)行過程 1、測試執(zhí)行過程的三個階段（1）初測

19、期 測試主要功能和關(guān)鍵的執(zhí)行路徑，排除主要障礙。（2）細測期 依據(jù)測試計劃和測試大綱、測試用例，逐一測試大大小小的功能、方方面面的特性、性能、用戶界面、兼容性、可用性等等；預(yù)期可發(fā)現(xiàn)大量不同性質(zhì)、不同嚴(yán)重程度的錯誤和問題。（3）回歸測試期 系統(tǒng)已達到穩(wěn)定，在一輪測試中發(fā)現(xiàn)的錯誤已十分有限；復(fù)查已知錯誤的糾正情況，確認未引發(fā)任何新的錯誤時，終結(jié)回歸測試。測試執(zhí)行過程（續(xù)）圖1-13 三個測試期階段圖示初測期功能凍結(jié)代碼凍結(jié)回歸測試期細測期02040608010012014016012345678910 11 12 13 14 15 16 17 18 19出錯數(shù)時間測試執(zhí)行過程（續(xù)）2、集成測試過

20、程中的兩個重要里程碑 在集成測試過程中的兩個重要的里程碑是功能凍結(jié)和代碼凍結(jié)的確定。這兩個里程碑界定出回歸測試期的起止界限。 功能凍結(jié)(Function/Feature Freeze) 經(jīng)過測試，符合設(shè)計要求，確認系統(tǒng)功能和其他特性均不再做任何改變。 代碼凍結(jié)(Code Freeze) 理論上，在無錯誤時凍結(jié)程序代碼，但實際上，代碼凍結(jié)只標(biāo)志系統(tǒng)的當(dāng)前版本的質(zhì)量已達到預(yù)期的要求，凍結(jié)程序的源代碼，不再對其做任何修改。這個里程碑是設(shè)置在軟件通過最終回歸測試之后。測試完成階段 本階段主要工作： 選擇和保留測試用例、測試結(jié)果、測試工具 提交最終測試報告2.4 軟件測試與軟件開發(fā)的關(guān)系正規(guī)的軟件開發(fā)過

21、程一般包括六個階段，即： 第一階段 計劃 第二階段 需求分析 第三階段 設(shè)計 第四階段 程序編寫 第五階段 測試 第六階段 運行和/維護 這六個階段構(gòu)成了軟件的生存周期。 軟件開發(fā)與軟件測試的關(guān)系圖1-10軟件測試與軟件開發(fā)過程的關(guān)系需求分析說明書詳細設(shè)計說明書源程序代碼單元測試集成測試確認測試概要設(shè)計說明書 項目規(guī)劃階段：負責(zé)整個測試階段的監(jiān)控。 需求分析階段：確定測試需求分析，制定系統(tǒng)測試計劃。測試需求分析是指產(chǎn)品生存周期中測試所需的資源、配置、各階段評審?fù)ㄟ^的標(biāo)準(zhǔn)等。 概要設(shè)計和詳細設(shè)計階段：制定集成測試計劃和單元測試計劃。 編碼階段：由開發(fā)人員進行自己負責(zé)部分的測試代碼。在項目較大時，

22、由專人進行編碼階段的測試任務(wù)。 測試階段（單元、集成、系統(tǒng)測試）：依據(jù)測試代碼進行測試，并提交相應(yīng)的測試狀態(tài)報告和測試結(jié)束報告。軟件測試在軟件開發(fā)中的作用 軟件測試與軟件開發(fā)并行特征2.5 2.5 測試過程模型測試過程模型 測試過程模型：V模型、W模型、H模型、X模型。 這些模型將測試活動進行了抽象，并與開發(fā)活動有機的進行了結(jié)合，是測試過程管理的重要參考依據(jù)。 2.5.1 模型模型 V模型最早是由Paul Rook20世紀(jì)80年代后期提出的一種模型，旨在改進軟件開發(fā)的效率和效果。模型反映出了測試活動與分析設(shè)計活動的關(guān)系。 在圖2-5中，從左到右描述了基本的開發(fā)過程和測試行為，非常明確的標(biāo)注了測

23、試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。圖2-5軟件測試V模型特點：非常明確地表明了測試的不同級別，清晰地展示了軟件測試與開發(fā)之間的關(guān)系 從圖2-5 可以看出： 單元測試的目標(biāo)是：檢測代碼的開發(fā)是否符合詳細設(shè)計的要求。 集成測試的目標(biāo)是： 檢測此前測試過的各組成部分是否能完好地結(jié)合到一起，檢測開發(fā)是否符合概要設(shè)計的要求。 系統(tǒng)測試的目標(biāo)是： 檢測已集成在一起的產(chǎn)品是否符合需求分析與系統(tǒng)規(guī)格說明書的要求。 驗收測試則檢測產(chǎn)品是否符合最終用戶的需求。 在V模型中存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，

24、而忽視了測試活動對需求分析、系統(tǒng)設(shè)計等活動的驗證和確認的功能。 2.5.2 模型模型 W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程。在W模型中，測試與開發(fā)是同步進行的，有利于盡早地全面的發(fā)現(xiàn)問題。 在V模型中增加軟件各開發(fā)階段應(yīng)同步進行的測試，被演化為一種W模型，因為實際上開發(fā)是V模型，測試也是與此相并行的V模型?；凇氨M早地和不斷地進行軟件測試”的原則，在軟件的需求和設(shè)計階段的測試活動應(yīng)遵循IEEE std1012-1998軟件驗證和確認(V&V)的原則。 但W模型也存在局限性。在W模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一

25、階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。 圖2-6軟件測試W模型 W模型2.5.3 H模型模型 H模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準(zhǔn)備活動和測試執(zhí)行活動清晰地體現(xiàn)出來。2.5.3 H模型模型圖2-7軟件測試H模型 圖2-7僅僅演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”。圖中標(biāo)注的其他流程可以是任意的開發(fā)流程。例如，設(shè)計流程或編碼流程。 只要測試條件成熟了，準(zhǔn)備工作也完成了，測試執(zhí)行活動就可以開始進行了。 H模型揭示了如下道理： 1）軟件測試不僅僅指測試的執(zhí)行

26、，還包括很多其他的活動。 2）軟件測試準(zhǔn)備和測試執(zhí)行分離。軟件測試是一個獨立的流程，貫 穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行。 3）軟件測試要盡早準(zhǔn)備，盡早執(zhí)行。 4）軟件測試是根據(jù)被測產(chǎn)品的不同而分層次進行的。不同層次的測試活動可以是按照某個次序先后進行的，但也可能是跌代進行的。采用H模型的好處是：1，有利于測試的分工，從而降低成本，提高效率。 由于H模型強調(diào)軟件測試準(zhǔn)備和測試執(zhí)行分離。準(zhǔn)備階段和執(zhí)行階段有不同的測試活動。例如，測試準(zhǔn)備活動包括： 測試需求分析、測試計劃、測試分析、測試編碼、測試驗證等等，而測試執(zhí)行活動包括：測試運行、測試報告、測試分析等等。 準(zhǔn)備階段和執(zhí)行階段有不同的工

27、作側(cè)重點，不同的測試活動也需要不同的知識和技能。 測試的設(shè)計人員比執(zhí)行人員有更高的能力要求，不同的崗位可以聘用不同的人員。所以，軟件測試分工帶來的第一個直接好處就是降低人力成本。 2、 有利于了解測試投入的重要性，從而得到測試效益的公平評價。 長期以來，軟件測試工作有個“測試怪圈”：測試經(jīng)理總是抱怨測試上投入不夠，測試人員要么被看作是“無所事事”，要么被看作“忙而無功”；而管理層則因為測試上的投入看不到明顯的效益而拒絕加大投入；更糟糕的是，用戶在投訴軟件的質(zhì)量問題，組織的聲譽和利潤都每況愈下。 從效益上講，H模型并不能扭轉(zhuǎn)這種局面，但它有助于跟蹤測試投入的流向 。 2.5.4. 2.5.4.

28、前置測試前置測試 前置測試是一個將測試和開發(fā)緊密結(jié)合的模型，該模型提供了前置測試是一個將測試和開發(fā)緊密結(jié)合的模型，該模型提供了輕松的方式，可以使你的項目加快速度。輕松的方式，可以使你的項目加快速度。圖2-8 前置測試模型 從圖2-8我們可以看出前置測試模型有如下特點： （1）開發(fā)和測試相結(jié)合 。 前置測試將測試和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼-測試-編碼-測試的方式來體現(xiàn)。 圖 2-9 給出了雙方交叉工作的內(nèi)容。 （2）對每一個交付內(nèi)容進行測試。 每一個交付的開發(fā)結(jié)果都必須通過一定的方式進行測試。源程序代碼并不是唯一需要測試的內(nèi)容。要測試的對象包括可行性報告、業(yè)務(wù)需求說明，以及系統(tǒng)設(shè)計文檔

29、等（在確認測試中進行）。這同V模型中開發(fā)和測試的對應(yīng)關(guān)系是相一致的，并且在其基礎(chǔ)上有所擴展，變得更為明確。 （3）在設(shè)計階段進行測試計劃和測試設(shè)計。 設(shè)計階段（見第2階段）是做測試計劃和測試設(shè)計的最好時機。很多組織要么根本不做測試計劃和測試設(shè)計，要么在即將開始執(zhí)行測試之前才飛快地完成測試計劃和設(shè)計。在這種情況下，測試只是驗證了程序的正確性，而不是驗證整個系統(tǒng)本該實現(xiàn)的東西。 另外，前置測試還提示我們應(yīng)增加靜態(tài)審查，以及獨立的QA（質(zhì)量保證）測試。 （4）保持驗收測試和技術(shù)測試保持相互獨立 驗收測試應(yīng)該獨立于技術(shù)測試，這樣可以提供雙重的保險，以保證設(shè)計及程序編碼能夠符合最終用戶的需求。驗收測試既

30、可以在實施階段的第一步來執(zhí)行，也可以在開發(fā)階段的最后一步執(zhí)行。 前置測試模型提倡驗收測試和技術(shù)測試沿循2條不同的路線來進行，每條路線分別地驗證系統(tǒng)是否能夠如預(yù)期的設(shè)想進行正常工作。這樣，當(dāng)單獨設(shè)計好的驗收測試完成了系統(tǒng)的驗證, 我們即可確信這是一個正確的系統(tǒng)。 （5）開發(fā)和測試反復(fù)交替 在項目中從很多方面可以看到變更的發(fā)生，例如需要重新訪問前一階段的內(nèi)容，或者地跟蹤并糾正以前提交的內(nèi)容，排除多余的成分，以及增加新的功能等等。開發(fā)和測試需要一起反復(fù)交替地執(zhí)行（見第3階段）。模型并沒有明確指出參與的系統(tǒng)部分的大小。這一點和V模型中所提供的內(nèi)容相似。不同的是，前置測試模型對反復(fù)和交替進行了非常明確的

31、描述。 （6）發(fā)現(xiàn)內(nèi)在的價值 前置測試能給需要使用測試技術(shù)的開發(fā)人員、測試人員、項目經(jīng)理和用戶等帶來很多不同于傳統(tǒng)方法的內(nèi)在的價值。 前置測試用較低的成本來及早發(fā)現(xiàn)錯誤，并且充分強調(diào)了測試對確保系統(tǒng)的高質(zhì)量的重要意義。 通常情況下，開發(fā)人員會將測試工作視為阻礙其按期完成開發(fā)進度的額外的負擔(dān)。然而，當(dāng)我們提前定義好該如何對程序進行測試以后，我們會發(fā)現(xiàn)開發(fā)人員將節(jié)省至少20%的時間。雖然開發(fā)人員很少意識到他們的時間是如何分配的，也許他們只是感覺到有一大塊時間從重新修改中節(jié)省下來可用來進行其它的開發(fā)。 前置測試定義了如何在編碼之前對程序進行測試設(shè)計，開發(fā)人員一旦體會到其中的價值，就會對其表現(xiàn)出特別的

32、欣賞。前置方法不僅能節(jié)省時間，而且可以減少那些令他們十分厭惡的重復(fù)工作。 2.6 測試?yán)砟顪y試?yán)砟?.盡早測試 “盡早測試”是從W模型中抽象出來的理念。開始測試的時間點并不是在代碼編寫完成之后才開展的工作，其實測試與開發(fā)是兩個相互依存的并行的過程，測試活動在開發(fā)活動的前期已經(jīng)開展。 據(jù)美國軟件質(zhì)量安全中心2000年對美國一百家知名的軟件廠商統(tǒng)計，得出這樣一個結(jié)論：軟件缺陷在開發(fā)前期發(fā)現(xiàn)比在開發(fā)后期發(fā)現(xiàn)資金，人力上節(jié)約90%；軟件缺陷在推向市場前發(fā)現(xiàn)比在推出后發(fā)現(xiàn)資金，人力上節(jié)約90%。所以說軟件的缺陷應(yīng)該盡早發(fā)現(xiàn)。 2.全面測試 軟件是程序、數(shù)據(jù)和文檔的集合，那么對軟件進行測試，就不僅僅是對程

33、序的測試，還應(yīng)包括軟件“副產(chǎn)品”的“全面測試”，這是W模型中一個重要的思想。需求文檔、設(shè)計文檔作為軟件的階段性產(chǎn)品，直接影響到軟件的質(zhì)量。階段產(chǎn)品質(zhì)量是軟件質(zhì)量的量的積累，不能把握這些階段產(chǎn)品的質(zhì)量將導(dǎo)致最終軟件質(zhì)量的不可控。 “全面測試”包含兩層含義：第一，對軟件的所有產(chǎn)品進行全面的測試，包括需求、設(shè)計文檔，代碼，用戶文檔等等。第二，軟件開發(fā)及測試人員（有時包括用戶）全面的參與到測試工作中，例如對需求的驗證和確認活動，就需要開發(fā)、測試及用戶的全面參與，畢竟測試活動并不僅僅是保證軟件運行正確，同時還要保證軟件滿足了用戶的需求。3.全過程測試 “全過程測試”包含兩層含義： 1. 測試人員要充分關(guān)注開發(fā)過程，對開發(fā)過程的各種變化及時做出響應(yīng)。例如開發(fā)進度的調(diào)整可能會引起測試進度及測試策略的調(diào)整，需求的變更會影響到測試的執(zhí)行等等 2. 測試人員要對測試的全過程進行全程的跟蹤，例如建立完善的度量與分析機制，通過對自身過程的度量，及時了解過程信息，調(diào)整測試策略。 “全過程測試”有助于及時應(yīng)對項目變化，降低測試風(fēng)險。同時對測試過程的度量與分析也有助于把握測試過程，調(diào)整測試策略，便于測試過程的改進。 4.獨立的、迭代的測試 前面我們說的“軟件測試與軟件開發(fā)是