軟件測試與質(zhì)量控制教程1

1、軟件工程軟件測試與質(zhì)量控制教程1-8全集舒文靜選取日期在此處鍵入文檔摘要。摘要通常為文檔內(nèi)容的簡短概括。在此處鍵入文檔摘要。摘要 通常為文檔內(nèi)容的簡短概括。目錄軟件測試與質(zhì)量控制 教程 1 3概述 3什么是軟件測試 4為什么要做軟件測試 4軟件測試人員做什么 4軟件測試環(huán)境 4軟件缺陷有哪些 4什么是測試用例 5軟件測試分類 5靜態(tài)測試和動(dòng)態(tài)測試 5黑盒測試和白盒測試 5單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試 5功能測試和性能測試 6回歸測試和冒煙測試 6軟件測試分類關(guān)系 6軟件配置管理 7軟件測試管理 7組織管理 7計(jì)劃管理 8用例管理 9文檔管理 10軟件測試與質(zhì)量控制 教程 2 10概述

2、 10測試需求概念 10測試需求分析工作步驟 11小結(jié) 11項(xiàng)目說明 11軟件測試與質(zhì)量控制 教程 3 11概述 11測試計(jì)劃主要內(nèi)容 12項(xiàng)目說明 13軟件測試與質(zhì)量控制 教程 4 14概述 14黑盒測試方法 14等價(jià)類劃分法 14劃分步驟 14劃分方法 15等價(jià)類劃分法測試用例設(shè)計(jì)原則 15實(shí)例分析 15邊界值分析法 16確定邊界 17邊界值分析法測試用例設(shè)計(jì)原則 17實(shí)例分析 17因果圖法 18為什么要用因果圖 18因果圖符號(hào)和概念 19實(shí)例分析 20錯(cuò)誤推測法 23不同測試方法選擇原則 23項(xiàng)目說明 24軟件測試與質(zhì)量控制 教程 5 24概述 24缺陷分類 24缺陷描述 25缺陷處理流

3、程 27項(xiàng)目說明 28軟件測試與質(zhì)量控制 教程 6 29概述 29自動(dòng)化測試工具分類 29自動(dòng)化測試工具一覽 29WinRunner 功能測試工具 31項(xiàng)目說明 32軟件測試與質(zhì)量控制教程 7 33概述 33代碼檢查 33白盒測試方法 33邏輯覆蓋法 33語句覆蓋 34判定覆蓋 34條件覆蓋 34判定條件覆蓋 34條件組合覆蓋 34路徑覆蓋 34各種邏輯覆蓋之間關(guān)系 34基本路徑法 35控制流圖 35復(fù)合條件分解 36環(huán)形復(fù)雜度 36基本路徑法測試用例設(shè)計(jì)步驟 37實(shí)例分析 37軟件測試與質(zhì)量控制教程 8 39概述 39測試報(bào)告主要內(nèi)容 39項(xiàng)目說明 40軟件測試與質(zhì)量控制 教程 1概述軟件測

4、試是 IT 行業(yè)的一項(xiàng)職業(yè)性活動(dòng)。對(duì)應(yīng)的工作崗位有軟件測試工程師、測 試經(jīng)理等崗位， 另外軟件開發(fā)工程師也需要掌握單元測試的有關(guān)內(nèi)容。 軟件測試 過程伴隨軟件開發(fā)過程始終。 作為一名職業(yè)軟件測試人員， 有必要對(duì)軟件測試的 基礎(chǔ)知識(shí)有所了解。什么是軟件測試軟件測試就是發(fā)現(xiàn)并指出軟件中存在缺陷的過程。 這里所說的軟件既包括運(yùn)行程 序也包括軟件設(shè)計(jì)開發(fā)過程中產(chǎn)生的需求、 設(shè)計(jì)等相關(guān)文檔以及編碼過程中產(chǎn)生 的源程序代碼。為什么要做軟件測試傳統(tǒng)行業(yè)都有質(zhì)量檢查環(huán)節(jié)， 對(duì)生產(chǎn)出來的產(chǎn)品進(jìn)行質(zhì)量檢驗(yàn)， 以確保生產(chǎn)出的 產(chǎn)品是合格的。軟件產(chǎn)品的質(zhì)量檢驗(yàn)是通過軟件測試來完成的。軟件設(shè)計(jì)開發(fā)過程中可能會(huì)出現(xiàn)很多問

5、題， 需要通過軟件測試手段來發(fā)現(xiàn)軟件缺 陷，保證軟件質(zhì)量。軟件測試人員做什么 軟件測試人員的目標(biāo)就是盡可能早的找出軟件缺陷， 并確保其得到修復(fù)。 軟件測 試人員的主要工作包括制定測試計(jì)劃、 設(shè)計(jì)測試用例、 執(zhí)行測試、 對(duì)發(fā)現(xiàn)的缺陷 進(jìn)行跟蹤管理、對(duì)測試結(jié)果進(jìn)行分析總結(jié)等內(nèi)容。軟件測試環(huán)境 軟件測試環(huán)境就是軟件運(yùn)行的平臺(tái)，包括軟件、硬件和網(wǎng)絡(luò)。硬件主要包括 PC 機(jī)、筆記本、服務(wù)器、各種PDA終端設(shè)備等。軟件主要是指軟件運(yùn)行的操作系統(tǒng)， 數(shù)據(jù)庫管理系統(tǒng)，Wet服務(wù)器、瀏覽器等。網(wǎng)絡(luò)主要針對(duì)的是 C/S結(jié)構(gòu)和B/S結(jié) 構(gòu)的軟件所使用的網(wǎng)絡(luò)設(shè)備情況 （類型、速度等 ） 。軟件缺陷有哪些軟件出現(xiàn)的故障

6、我們一般叫軟件缺陷， 符合以下 5 條規(guī)則的情況都可以稱為軟件 缺陷：1. 軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能；2. 軟件出現(xiàn)了產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤；3. 軟件功能超出產(chǎn)品說明書指明范圍；4. 軟件未達(dá)到產(chǎn)品說明書雖未指明但應(yīng)達(dá)到的目標(biāo)；5. 軟件測試人員認(rèn)為軟件難以理解、 不易使用、 運(yùn)行速度緩慢或者最終用戶認(rèn)為不好什么是測試用例測試用例是測試執(zhí)行的依據(jù)，是指在測試執(zhí)行之前設(shè)計(jì)的一套詳細(xì)的測試方案， 包括測試環(huán)境、測試步驟、測試數(shù)據(jù)和期望結(jié)果。軟件測試分類 人們根據(jù)測試目的和測試角度的不同將軟件測試分成眾多的類別。 我們經(jīng)常聽到 諸如靜態(tài)測試、動(dòng)態(tài)測試、黑盒測試、白盒測試、單元測試、集成

7、測試等名詞。 作為一名軟件測試人員，我們有必要了解這些軟件測試分類的具體內(nèi)容。靜態(tài)測試和動(dòng)態(tài)測試 軟件測試按照是否需要運(yùn)行程序可以分為靜態(tài)測試和動(dòng)態(tài)測試。 靜態(tài)測試是指不實(shí)際運(yùn)行被測軟件， 只是靜態(tài)地檢查程序界面、 文檔和源程序代 碼中可能存在的錯(cuò)誤的過程。 其中代碼測試主要測試源代碼是否符合相應(yīng)的標(biāo)準(zhǔn) 和規(guī)范；界面測試主要測試軟件的實(shí)際界面與需求中的說明是否相符； 文檔測試 主要測試用戶使用手冊(cè)和需求說明是否真正符合用戶的實(shí)際需求。動(dòng)態(tài)測試是指實(shí)際運(yùn)行被測軟件， 輸入相應(yīng)的測試數(shù)據(jù)， 檢查實(shí)際輸出結(jié)果和預(yù) 期結(jié)果是否相符的過程。黑盒測試和白盒測試 軟件測試按照是否需要了解程序內(nèi)部結(jié)構(gòu)可以分為

8、黑盒測試和白盒測試。 黑盒測試是指把被測軟件當(dāng)作是一個(gè)黑盒子， 測試人員不需要知道盒子里面的結(jié) 構(gòu)，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果，設(shè)計(jì)相應(yīng)測試用例測試軟件的過程。 白盒測試是相對(duì)黑盒測試來說的。 是指把被測軟件當(dāng)作是一個(gè)透明盒子， 測試人 員需要知道被測軟件的程序結(jié)構(gòu)，然后設(shè)計(jì)相應(yīng)測試用例測試軟件的過程。 黑盒測試和白盒測試都有相應(yīng)的測試用例設(shè)計(jì)方法，后續(xù)我們將進(jìn)行詳細(xì)介紹。 單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試 軟件測試按測試階段可以分為單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試。 單元測試是指對(duì)軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。 最小可測試單元可以 是函數(shù) （面向過程程序 ） ，也可以

9、是類 （ 面向?qū)ο蟪绦?） ，需要根據(jù)實(shí)際情況具體 分析。單元測試在編碼完成程序編譯之后執(zhí)行， 一般由軟件開發(fā)人員完成。 單元 測試依據(jù)程序的源代碼和詳細(xì)設(shè)計(jì)文檔， 主要采用白盒測試方法， 先檢查代碼編 寫規(guī)范性（靜態(tài)測試） ，然后運(yùn)行代碼， 檢查實(shí)際運(yùn)行結(jié)果 （動(dòng)態(tài)測試） 。單元測試 一般需要編寫測試程序?qū)Τ绦蚰K進(jìn)行測試。集成測試是單元測試的下一階段， 是指將通過測試的單元模塊組裝成系統(tǒng)或子系 統(tǒng)，再進(jìn)行測試， 主要測試不同模塊的接口部分。 集成測試的目的是檢查各個(gè)單 元模塊集成在一起后是否能正常運(yùn)行。 集成測試在單元測試完成后執(zhí)行， 一般由 軟件開發(fā)人員和軟件測試人員共同完成。 集成測試

10、依據(jù)單元測試的模塊和概要設(shè) 計(jì)文檔，采用白盒和黑盒測試方法。 集成測試可以采用增量和非增量兩種方式進(jìn) 行。增量式集成是指按照一定次序 （自頂至下或自底向上 ）逐步集成程序， 這種測 試方式需要編寫測試程序。 非增量式集成是指一次性把所有程序模塊集成為一個(gè) 完整系統(tǒng)，這種測試方式不需要編寫測試程序。系統(tǒng)測試是集成測試的下一階段，是指將整個(gè)軟件系統(tǒng)看作一個(gè)整體進(jìn)行測試， 包括功能測試、 性能測試以及軟件所運(yùn)行的軟硬件環(huán)境兼容性測試等內(nèi)容。 系統(tǒng) 測試在集成測試完成后執(zhí)行， 由軟件測試人員完成。 系統(tǒng)測試主要依據(jù)軟件需求 文檔，采用黑盒測試方法。 先測試系統(tǒng)的功能是否滿足需求， 然后測試系統(tǒng)的性 能

11、是否滿足需求，最后測試系統(tǒng)在不同軟硬件環(huán)境中的兼容性。驗(yàn)收測試在系統(tǒng)測試完成后執(zhí)行， 測試內(nèi)容包含系統(tǒng)測試的內(nèi)容， 另外還包括對(duì) 用戶文檔的測試。驗(yàn)收測試的測試人員以用戶為主。功能測試和性能測試軟件測試按測試內(nèi)容可以分為功能測試和性能測試。功能測試是黑盒測試的一個(gè)方面，主要檢查待測軟件的功能是否滿足用戶的需 求。功能測試可以細(xì)分為邏輯功能測試、界面測試、易用性測試、安裝測試和兼 容性測試等內(nèi)容。功能測試可以使用自動(dòng)化測試工具進(jìn)行。后續(xù)第 13 章將介紹 WinRunner功能測試開發(fā)內(nèi)容。性能測試是黑盒測試的另一個(gè)方面， 主要檢查待測軟件的性能是否滿足用戶的需 求。性能測試可以細(xì)分為一般性能測

12、試、 穩(wěn)定性測試、 負(fù)載測試和壓力測試等內(nèi) 容。性能測試一般使用自動(dòng)化測試工具進(jìn)行?；貧w測試和冒煙測試回歸測試和冒煙測試是兩個(gè)不相干的概念，我們單獨(dú)描述。 回歸測試是指測試過程中對(duì)軟件的新版本進(jìn)行測試時(shí)， 重復(fù)執(zhí)行上一個(gè)版本測試 時(shí)的測試用例?；貧w測試在集成測試階段進(jìn)行。冒煙測試是指在對(duì)一個(gè)軟件新版本進(jìn)行系統(tǒng)大規(guī)模的測試之前， 先驗(yàn)證一下軟件 的基本功能是否實(shí)現(xiàn)，是否具備可測性。冒煙測試一般在系統(tǒng)測試之前進(jìn)行。 軟件測試分類關(guān)系 »f5ASr B 1£ A1 111功褻 試試1 試'JIM前面我們對(duì)常見的軟件測試分類進(jìn)行了簡單介紹。 這么多的測試分類，看上去很 復(fù)雜

13、，實(shí)際上只是分類角度有所不同。同一種測試，按照不同角度劃分，可以屬 于不同的測試分類。下圖描述了這些測試分類之間的關(guān)系。!L_J了辭 的構(gòu) 3”r%JS A軟件配置管理在一個(gè)實(shí)際的軟件開發(fā)項(xiàng)目中，軟件開發(fā)過程產(chǎn)生的各種產(chǎn)品必須納入軟件配置 管理范圍。軟件測試人員在測試過程中往往需要對(duì)各種開發(fā)測試產(chǎn)品（文檔、代碼等）進(jìn)行各種配置管理操作，例如從配置庫獲取配置項(xiàng)，將創(chuàng)建的測試產(chǎn)品添 加到配置庫等操作。軟件測試管理軟件測試管理就是以測試項(xiàng)目為管理對(duì)象，通過一個(gè)臨時(shí)性的專門的測試組織， 運(yùn)用專門的軟件測試知識(shí)、技能、工具和方法，對(duì)測試項(xiàng)目進(jìn)行計(jì)劃、組織、執(zhí) 行和控制，并在時(shí)間成本、軟件測試質(zhì)量等方面進(jìn)

14、行分析和管理活動(dòng)。軟件測試 管理貫穿整個(gè)測試項(xiàng)目的生命周期，是對(duì)測試項(xiàng)目的全過程進(jìn)行管理。組織管理測試項(xiàng)目成功完成的關(guān)鍵因素之一就是要有高素質(zhì)的軟件測試人員，并將他們有效地組織起來，分工合作，形成一支精干的隊(duì)伍，使他們發(fā)揮出最大的工作效率。測試的組織與人員管理就是對(duì)測試項(xiàng)目相關(guān)人員在組織形式、 人員組成與職責(zé)方 面所做的規(guī)劃和安排。組織結(jié)構(gòu)是指用一定的模式對(duì)責(zé)任、 權(quán)威和關(guān)系進(jìn)行安排， 直至通過這種結(jié)構(gòu)發(fā) 揮功能。進(jìn)行軟件測試的測試組織結(jié)構(gòu)形式很多， 目前常見的測試組織結(jié)構(gòu)有獨(dú)立的測試 小組和集成的測試小組兩種形式。1. 獨(dú)立測試小組2. 集成測試小組獨(dú)立的測試小組，即主要工作是進(jìn)行測試的小組

15、， 他們專門從事軟件的測試工作。 測試組設(shè)組長一名， 負(fù)責(zé)整個(gè)測試的計(jì)劃、 組織工作。 測試組的其他成員由具有 一定的分析、 設(shè)計(jì)和測試經(jīng)驗(yàn)的專業(yè)人員組成， 人數(shù)根據(jù)具體情況可多可少， 一 般35人為宜。測試組長與開發(fā)組長在項(xiàng)目中的地位是同級(jí)、平等的關(guān)系。集成測試小組是將測試與基本設(shè)計(jì)因素組合起來， 構(gòu)成的測試組織結(jié)構(gòu)。 這是與 獨(dú)立測試有關(guān)的一種集成測試組織形式， 即集成測試小組是由需要向同一個(gè)項(xiàng)目 經(jīng)理匯報(bào)工作的測試人員和開發(fā)人員組成。計(jì)劃管理測試計(jì)劃就是描述所有要完成的測試工作， 包括被測試項(xiàng)目的背景、 目標(biāo)、范圍、 方式、資源、進(jìn)度安排、測試組織，以及與測試有關(guān)的風(fēng)險(xiǎn)等方面。測試計(jì)劃制

16、定及管理的主要工作內(nèi)容如下：1. 結(jié)合已批準(zhǔn)的軟件系統(tǒng)測試需求及所使用的測試工具， 測試負(fù)責(zé)人與項(xiàng)目 經(jīng)理協(xié)商， 逐步確定測試項(xiàng)目的測試目標(biāo)、 范圍、粒度（ 覆蓋標(biāo)準(zhǔn) ） 以及測 試方案 （ 包括各個(gè)測試階段的出入口準(zhǔn)則的協(xié)商 ） ，在初步估計(jì)測試項(xiàng)目規(guī) 模及工作量的基礎(chǔ)上，協(xié)助測試項(xiàng)目開發(fā)計(jì)劃書的可行性；2. 基于項(xiàng)目的系統(tǒng)功能集成方案及系統(tǒng)版本發(fā)布計(jì)劃， 配合項(xiàng)目經(jīng)理逐步 細(xì)化項(xiàng)目計(jì)劃中的階段小版本創(chuàng)建和發(fā)布里程碑點(diǎn)， 并逐步細(xì)化測試方案 及測試規(guī)模估計(jì)；3. 策劃測試實(shí)施前準(zhǔn)備內(nèi)容、資源安排 （ 包括人員分配，進(jìn)度安排等，尤其 要留有合理的測試Bug用例管理時(shí)間），細(xì)化項(xiàng)目測試計(jì)劃相關(guān)內(nèi)

17、容；4. 測試負(fù)責(zé)人必要時(shí)還須與項(xiàng)目經(jīng)理根據(jù)項(xiàng)目特性， 確定系統(tǒng)冒煙測試的范 圍，粒度以及入口接受標(biāo)準(zhǔn)等內(nèi)容，細(xì)化項(xiàng)目測試方案相關(guān)內(nèi)容；5. 形成系統(tǒng)測試計(jì)劃書 （ 可包括單元、 集成、系統(tǒng)階段 ） 并提交評(píng)審， 按項(xiàng)目 評(píng)審規(guī)程執(zhí)行；6. 當(dāng)項(xiàng)目開發(fā)計(jì)劃或測試需求發(fā)生變更時(shí)，按配置管理過程執(zhí)行。 用例管理 測試用例及管理的工作任務(wù)是根據(jù)批準(zhǔn)的測試需求及方案， 策劃測試過程執(zhí)行依 據(jù)，確保測試范圍有效并正確。測試用例設(shè)計(jì)及管理的主要工作內(nèi)容如下： 用例設(shè)計(jì)：1. 參與需求評(píng)審， 正確理解系統(tǒng)需求并確認(rèn)需求的可測性， 獲取測試項(xiàng)目 需求；2. 根據(jù)批準(zhǔn)的測試項(xiàng)目需求， 測試目標(biāo)的邏輯實(shí)現(xiàn)和約束，

18、 測試工具及其測 試環(huán)境等限制條件， 確定系統(tǒng)的測試中自動(dòng)和手動(dòng)測試的范圍， 并分別編 寫系統(tǒng)測試用例；3. 參與系統(tǒng)設(shè)計(jì)， 協(xié)助驗(yàn)證系統(tǒng)體系結(jié)構(gòu)及其邏輯實(shí)現(xiàn)層次的合理性， 功能 模塊間的內(nèi)部及其接口的正確性， 結(jié)合系統(tǒng)功能集成方案， 編寫集成測試 用例；4. 測試負(fù)責(zé)人或項(xiàng)目經(jīng)理需針對(duì)系統(tǒng)體系結(jié)構(gòu)設(shè)計(jì)方案、系統(tǒng)功能集成方 案、系統(tǒng)版本發(fā)布計(jì)劃以及項(xiàng)目開發(fā)計(jì)劃等內(nèi)容， 組織編寫創(chuàng)建腳本和冒 煙測試用例；5. 測試負(fù)責(zé)人或項(xiàng)目經(jīng)理負(fù)責(zé)基于系統(tǒng)的詳細(xì)設(shè)計(jì)， 確定單元測試范圍和粒 度，有效路徑和值域等，組織單元測試中自動(dòng)和手動(dòng)測試用例的編寫；6. 測試負(fù)責(zé)人或項(xiàng)目經(jīng)理負(fù)責(zé)按測試用例編寫要求、 需求跟

19、蹤矩陣表完成 編寫符合性和需求覆蓋性、 有效性、 完整性檢查， 并參照項(xiàng)目評(píng)審規(guī)程實(shí) 施評(píng)審活動(dòng)；7. 當(dāng)項(xiàng)目測試需求發(fā)生變更時(shí)，按配置管理過程執(zhí)行。 用例管理：1. 測試負(fù)責(zé)人或項(xiàng)目經(jīng)理負(fù)責(zé)進(jìn)行階段測試用例的實(shí)施、 跟蹤及用例統(tǒng)計(jì)分 析工作，及時(shí)改進(jìn)測試用例管理活動(dòng)；2. 測試負(fù)責(zé)人或項(xiàng)目經(jīng)理實(shí)時(shí)或定期根據(jù) Bug 數(shù)據(jù)、狀態(tài)和測試用例執(zhí)行 情況進(jìn)行分析，以確定是否需要對(duì)目前測試的模塊新增設(shè)計(jì)新的測試用 例：a) 對(duì)不穩(wěn)定的模塊， 測試負(fù)責(zé)人負(fù)責(zé)與項(xiàng)目經(jīng)理多次討論確定測試范圍、 粒度和執(zhí)行方案等，并制定測試人員完成新增測試用例的編寫；b) 對(duì)極其不穩(wěn)定或未能達(dá)到測試入口標(biāo)準(zhǔn)的模塊，則要求退回

20、開發(fā)部重 新開發(fā)；3. 由測試負(fù)責(zé)人和項(xiàng)目經(jīng)理負(fù)責(zé)進(jìn)行測試用例的完整性和有效性檢查后，組織討論新增測試用例，批準(zhǔn)后由測試人員或開發(fā)人員執(zhí)行；文檔管理測試文檔是對(duì)要執(zhí)行的軟件測試及測試的結(jié)果進(jìn)行描述、定義、規(guī)定和報(bào)告的任何書面或圖示信息。由于軟件測試是一個(gè)很復(fù)雜的過程，同時(shí)也涉及到軟件開發(fā) 中其他一些階段的工作，因此，必須把對(duì)軟件測試的要求、規(guī)劃、測試過程等有 關(guān)信息和測試的結(jié)果，以及對(duì)測試結(jié)果的分析、評(píng)價(jià)，以正式的文檔形式給出。測試文檔對(duì)于測試階段工作的指導(dǎo)與評(píng)價(jià)作用更是非常明顯的。 需要特別指出的 是，在已開發(fā)的軟件投入運(yùn)行的維護(hù)階段， 常常還要進(jìn)行再測試或回歸測試， 這 時(shí)還會(huì)用到測試文檔

21、。測試文檔的編寫是測試管理的一個(gè)重要組成部分。根據(jù)測試文檔所起的不同作用，通常把它分成兩類，即前置作業(yè)文檔和后置作業(yè) 文檔。測試計(jì)劃及測試用例的文檔屬于前置作業(yè)文檔。 后置作業(yè)文檔是在測試 完成后提交的，主要包括軟件缺陷報(bào)告和分析總結(jié)報(bào)告。軟件測試與質(zhì)量控制教程2概述測試需求分析是軟件測試工作的首要工作任務(wù)，該項(xiàng)工作任務(wù)在項(xiàng)目開發(fā)階段需求 分析基本完成時(shí)切入。測試組人員需要參與開發(fā)項(xiàng)目的需求評(píng)審，確定項(xiàng)目的測試 需求。測試需求分析的工作產(chǎn)品是測試需求文檔。測試需求概念確切地講，所謂的測試需求就是在項(xiàng)目中要測試什么。我們?cè)跍y試活動(dòng)中，首先需 要明確測試需求(What)，才能決定怎么測(How)，

22、測試時(shí)間(When),需要多少人(Who)， 測試的環(huán)境是什么(Where)，測試中需要的技能、工具以及相應(yīng)的背景知識(shí)，測試中 可能遇到的風(fēng)險(xiǎn)等等，以上所有的內(nèi)容結(jié)合起來就構(gòu)成了測試計(jì)劃的基本要素。而 測試需求是測試計(jì)劃的基礎(chǔ)與重點(diǎn)。就像軟件的需求一樣，測試需求根據(jù)不同的公司環(huán)境，不同的專業(yè)水平，不同的要求，詳細(xì)程度也是不同的。但是，對(duì)于一個(gè)全 新的項(xiàng)目或者產(chǎn)品，測試需求力求詳細(xì)明確，以避免測試遺漏與誤解。測試需求，簡單理解就是測試人員要對(duì)哪些點(diǎn)進(jìn)行測試。測試需求的內(nèi)容由軟件測 試人員根據(jù)用戶需求說明書和開發(fā)設(shè)計(jì)說明書整理編寫。依據(jù)軟件需求規(guī)格說明書 中相關(guān)內(nèi)容，將系統(tǒng)要實(shí)現(xiàn)的功能點(diǎn)羅列出來，

23、測試需求就是這些羅列出來的功能 點(diǎn)。測試需求分析工作步驟我們來總結(jié)一下測試需求分析的一般步驟：1. 閱讀需求規(guī)格說明書，找出與指定功能相關(guān)的描述內(nèi)容。2. 列出描述內(nèi)容中所有直接提及要實(shí)現(xiàn)的功能點(diǎn)3. 根據(jù)說明書內(nèi)容，查找是否存在文檔中未提及但是需要達(dá)到的功能點(diǎn)，有則 列出來4. 將列出的內(nèi)容整理成測試需求文檔小結(jié)測試需求分析工作是一個(gè)細(xì)致活，需要測試人員有足夠的耐心和細(xì)心，對(duì)功能點(diǎn)的 羅列不能太粗，要盡量具體、完整。根據(jù)羅列的功能點(diǎn)整理測試需求列表時(shí)，一般 來說功能點(diǎn)與測試點(diǎn)是一對(duì)一的關(guān)系。但是可以根據(jù)實(shí)際情況進(jìn)行適當(dāng)?shù)臍w納合并 或整理細(xì)化。總的來說測試需求列表不能太籠統(tǒng)，要具體、詳細(xì)、可測

24、試。這是測 試需求分析工作中要重點(diǎn)注意的。項(xiàng)目說明測試需求分析項(xiàng)目主要教學(xué)生理解分析軟件需求說明文檔，整理獲得測試需求，編 寫測試需求文檔，為制定測試計(jì)劃做好準(zhǔn)備。學(xué)生要求完成以下工作任務(wù)： 分析ATM 模擬系統(tǒng)軟件需求說明書，整理系統(tǒng)的功能測試需求，編寫測試需求文檔。項(xiàng)目的 工作場景一般是企業(yè)的各個(gè)項(xiàng)目組或者獨(dú)立的測試部門。項(xiàng)目目的主要是培養(yǎng)學(xué)生 準(zhǔn)確獲取測試需求的能力。該項(xiàng)目能為測試員、測試工程師、測試經(jīng)理這些崗位的 相關(guān)工作提供幫助。軟件測試與質(zhì)量控制教程3概述 測試計(jì)劃制定就是根據(jù)之前確認(rèn)的測試需求，確定項(xiàng)目測試階段的目標(biāo)和策略，確 保測試工作有序、有效進(jìn)行。測試計(jì)劃的制定工作一般由測

25、試經(jīng)理牽頭執(zhí)行，一般 測試人員只是協(xié)助工作。測試計(jì)劃主要內(nèi)容(1) 測試環(huán)境確保項(xiàng)目測試環(huán)境符合測試要求，減少嚴(yán)重影響測試結(jié)果的真實(shí)性和正確性風(fēng)險(xiǎn)。 包括：硬件環(huán)境：指測試必需的服務(wù)器、客戶端、網(wǎng)絡(luò)連接設(shè)備，以及打印機(jī)/掃描儀等輔助硬件設(shè)備所構(gòu)成的環(huán)境；軟件環(huán)境：指被測軟件運(yùn)行時(shí)的操作系統(tǒng)、數(shù)據(jù)庫及其他應(yīng)用軟件構(gòu)成的環(huán)境，包 括版本及補(bǔ)丁號(hào)。在實(shí)際測試中，可遵循下列原則：1) 符合軟件運(yùn)行的最低要求，首先要保證能支撐軟件正常運(yùn)行；2) 選用比較普及的操作系統(tǒng)和軟件平臺(tái)。3) 營造相對(duì)簡單、獨(dú)立的測試環(huán)境。4) 無毒的環(huán)境。利用有效的正版殺毒軟件檢測測試環(huán)境以確保其沒有病毒。測試工具：指測試過程

26、使用的所有測試工具、測試管理工具等，包括工具名、版本、 生產(chǎn)廠商、用途。(2) 測試方案對(duì)測試階段進(jìn)行劃分，說明各測試階段的目標(biāo)、工作內(nèi)容、管理方法、采用的樣式、 出口標(biāo)準(zhǔn)、停止標(biāo)準(zhǔn)、選取測試用例的原則等。(3) 測試需求列出每一項(xiàng)測試需求名稱、內(nèi)容、目的。(4) 測試優(yōu)先級(jí)說明測試階段或測試項(xiàng)的優(yōu)先順序和測試的重點(diǎn)內(nèi)容。(5) 測試機(jī)構(gòu)及人員測試機(jī)構(gòu)名稱、測試組成員和職責(zé)。進(jìn)度說明各測試階段活動(dòng)的詳細(xì)時(shí)間、人員、工作量安排，包括計(jì)劃、管理、測試、 熟悉環(huán)境和工具、準(zhǔn)備輸入數(shù)據(jù)、校驗(yàn)輸出結(jié)果等時(shí)間。測試階測試活動(dòng)計(jì)劃開始時(shí)間計(jì)劃開始時(shí)間測試人員預(yù)計(jì)工作量備注段(人天數(shù))(7)問題響應(yīng)要求問題分

27、類問題嚴(yán)重程度響應(yīng)時(shí)間立即解決程序錯(cuò)誤，影響繼續(xù)測試高度關(guān)注問題嚴(yán)重普通排隊(duì)一般問題低優(yōu)先級(jí)建議性問題(8)測試風(fēng)險(xiǎn)預(yù)估序號(hào)風(fēng)險(xiǎn)內(nèi)容描述優(yōu)先級(jí)影像度(1)概率(P)緩解策略(9)測試風(fēng)險(xiǎn)管理說明風(fēng)險(xiǎn)管理的責(zé)任人，風(fēng)險(xiǎn)跟蹤與管理的周期、方法等。(10)評(píng)價(jià)說明所選擇的測試用例能檢查的范圍及局限性。說明用來判斷測試工作是否能通過的評(píng)價(jià)尺度，如合理的輸出結(jié)果的類型，量值范 圍等。描述測試完成后應(yīng)提交的文檔。如：測試計(jì)劃書、測試用例、測試問題報(bào)告、測試 分析報(bào)告等。項(xiàng)目說明制定測試計(jì)劃項(xiàng)目主要教學(xué)生修改整理已有的測試計(jì)劃草稿文檔，對(duì)完成的測試計(jì) 劃文檔進(jìn)行評(píng)審，形成基線，納入軟件配置管理。整個(gè)項(xiàng)目分成

28、兩個(gè)模塊完成，模 塊一為編寫測試計(jì)劃書，模塊二為測試計(jì)劃評(píng)審。要求學(xué)生完成以下工作任務(wù)：按 要求修改補(bǔ)充已有的測試計(jì)劃草稿文檔內(nèi)容，為測試計(jì)劃評(píng)審準(zhǔn)備評(píng)審文檔，分角 色參與測試計(jì)劃評(píng)審工作，將評(píng)審后的文檔形成基線，納入配置庫管理。項(xiàng)目的工 作場景一般是企業(yè)的各個(gè)項(xiàng)目組或者獨(dú)立的測試部門。項(xiàng)目目的主要是培養(yǎng)學(xué)生對(duì)測試過程的整體把握能力，讓學(xué)生熟悉項(xiàng)目評(píng)審環(huán)節(jié)的各項(xiàng)工作。該項(xiàng)目能為測試 經(jīng)理、測試員、測試工程師、 SQA和SCM這些崗位的相關(guān)工作提供幫助。軟件測試與質(zhì)量控制教程4概述在測試執(zhí)行之前，測試人員需要設(shè)計(jì)一套詳細(xì)的測試方案，測試方案的核心內(nèi)容就 是測試用例，測試用例是測試執(zhí)行的最小單位，

29、一般包括測試環(huán)境、測試步驟、測 試數(shù)據(jù)和預(yù)期結(jié)果幾部分的內(nèi)容。 測試用例設(shè)計(jì)是軟件測試活動(dòng)最重要的工作之一。根據(jù)測試階段的不同，測試用例設(shè)計(jì)又分為單元測試用例設(shè)計(jì)、集成測試用例設(shè)計(jì) 以及系統(tǒng)測試用例設(shè)計(jì)等多項(xiàng)內(nèi)容。本課程主要關(guān)注的是集成測試用例設(shè)計(jì)和系統(tǒng) 測試用例設(shè)計(jì)中的功能測試用例設(shè)計(jì)內(nèi)容。其他測試用例設(shè)計(jì)內(nèi)容會(huì)放在后續(xù)的軟 件綜合項(xiàng)目開發(fā)課程中學(xué)習(xí)。黑盒測試方法黑盒測試方法用來設(shè)計(jì)系統(tǒng)測試用例。常用的黑盒測試方法有等價(jià)類劃分法、邊界值分析法、因果圖法、決策表法、正交 實(shí)驗(yàn)法、錯(cuò)誤推測法等等價(jià)類劃分法我們都知道，最理想的測試方法是窮舉測試，即測試所有可能的情況。但是在實(shí)際 工作中由于數(shù)據(jù)量較

30、大或者數(shù)據(jù)域本身就是無窮的而無法進(jìn)行窮舉測試。這時(shí)候我 們一般考慮對(duì)輸入數(shù)據(jù)的范圍進(jìn)行有限劃分，從每個(gè)劃分類別中選取一個(gè)有代表性 的測試數(shù)據(jù)進(jìn)行測試，就等同于對(duì)這個(gè)劃分類別的其他數(shù)據(jù)進(jìn)行測試。等價(jià)類劃分法是一種黑盒測試方法。等價(jià)類是指某個(gè)輸入域的子集，在該子集中， 各個(gè)輸入數(shù)據(jù)對(duì)于揭露軟件中的錯(cuò)誤都是等效的。等價(jià)類可以分為有效等價(jià)類和無 效等價(jià)類。其中有效等價(jià)類是符合需求規(guī)格說明書的合理輸入數(shù)據(jù)集合，無效 等價(jià)類是不符合需求規(guī)格說明書的無意義的輸入數(shù)據(jù)集合。劃分步驟等價(jià)類劃分可以按以下步驟進(jìn)行：（1）先考慮輸入數(shù)據(jù)的數(shù)據(jù)類型（合法類型和非法類型）；再考慮數(shù)據(jù)范圍（合法類型中的有效區(qū)間和無效區(qū)間

31、）；(3) 用表格方法列舉所有的等價(jià)類，為每一個(gè)等價(jià)類編號(hào)。劃分方法常見的等價(jià)類劃分方法有以下幾種情況：(1) 在輸入條件規(guī)定了取值范圍或值的個(gè)數(shù)的情況下，則可以確立一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類。(2) 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了"必須如何"的條件的情況下，可確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。(3) 在輸入條件是一個(gè)布爾量的情況下，可確定一個(gè)有效等價(jià)類和一 個(gè)無效等價(jià)類。(4) 在規(guī)定了輸入數(shù)據(jù)的一組值(假定 n個(gè))，并且程序要對(duì)每一個(gè) 輸入值分別處理的情況下，可確立n個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類。(5) 在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個(gè)有

32、效等 價(jià)類(符合規(guī)則)和若干個(gè)無效等價(jià)類(從不同角度違反規(guī)則)。(6) 在確知已劃分的等價(jià)類中各元素在程序處理中的方式不同的情 況下，則應(yīng)再將該等價(jià)類進(jìn)一步的劃分為更小的等價(jià)類。等價(jià)類劃分法測試用例設(shè)計(jì)原則用等價(jià)類劃分法設(shè)計(jì)測試用例應(yīng)該遵循以下原則：(1) 設(shè)計(jì)一個(gè)新的測試用例，使其盡可能多地覆蓋尚未被覆蓋地有效 等價(jià)類,重復(fù)這一步，直到所有的有效等價(jià)類都被覆蓋為止；(2) 設(shè)計(jì)一個(gè)新的測試用例，使其僅覆蓋一個(gè)尚未被覆蓋的無效等價(jià)類,重復(fù)這一步，直到所有的無效等價(jià)類都被覆蓋為止。實(shí)例分析設(shè)有一個(gè)檔案管理系統(tǒng)，要求用戶輸入以年月表示的日期。假設(shè)日期限定在2013年1月2113年12月，并規(guī)定日期

33、由6位數(shù)字字符組成，前4位表示年，后2位表 示月?，F(xiàn)用等價(jià)類劃分法設(shè)計(jì)測試用例，來測試程序的"日期檢查功能"。(1)劃分等價(jià)類并編號(hào)，等價(jià)類劃分的結(jié)果如表3.1所示。表3.1等價(jià)類列表輸入條件有效等價(jià)類編號(hào)無效等價(jià)類編號(hào)日期的類型及長 度6位數(shù)字字符1有非數(shù)字字符2少于6位數(shù) 字字符3多于6位數(shù)字字符4年份范圍在20132113之間5小于20136大于21137月份范圍在0112之間8等于009大于1210(2)設(shè)計(jì)測試用例，以便覆蓋所有的有效等價(jià)類在表中列出了3個(gè)有效等價(jià)類，編號(hào)分別為1、5、8,設(shè)計(jì)的測試用例如下：表3.2 有效等價(jià)類測試用例測試數(shù)據(jù)期望結(jié)果覆蓋的有效等

34、價(jià)類201309輸入有效1、5、8(3)為每一個(gè)無效等價(jià)類設(shè)計(jì)一個(gè)測試用例，設(shè)計(jì)結(jié)果如下:表3.3 無效等價(jià)類測試用例測試數(shù)據(jù)期望結(jié)果覆蓋的無效等價(jià)類13June無效輸入22013無效輸入3無效輸入4201212無效輸入6211401無效輸入7201500無效輸入9201314無效輸入10邊界值分析法長期的測試工作經(jīng)驗(yàn)告訴我們，大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上，而 不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對(duì)各種邊界情況設(shè)計(jì)測試用例，可以查出 更多的錯(cuò)誤。邊界值分析法就是對(duì)輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。通常邊界 值分析法是作為對(duì)等價(jià)類劃分法的補(bǔ)充，這種情況下，其測試用例來自等

35、價(jià)類的邊 界。確定邊界使用邊界值分析方法設(shè)計(jì)測試用例，首先應(yīng)確定邊界情況。通常輸入和輸出等價(jià)類 的邊界，就是應(yīng)著重測試的邊界情況。應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊 界的值作為測試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù)。常見的邊界值有以下幾種情況：(1) 對(duì)16-bit的整數(shù)而言 32767禾口 -32768 是邊界。(2) 屏幕上光標(biāo)在最左上、最右下位置。(3) 報(bào)表的第一行和最后一行。(4) 數(shù)組元素的第一個(gè)和最后一個(gè)。(5) 循環(huán)的第 0次、第 1次和倒數(shù)第2次、最后一次。邊界值分析法測試用例設(shè)計(jì)原則用邊界值分析法設(shè)計(jì)測試用例應(yīng)遵循以下原則：對(duì)于一個(gè)含有n個(gè)變量的程序，

36、應(yīng)保留其中一個(gè)變量，其余的變量取正常值，被保留的變量取邊界和邊界附近的值， 對(duì)每個(gè)變量重復(fù)進(jìn)行上述取值方法，設(shè)計(jì)測試用例。實(shí)例分析NextDate函數(shù)包含三個(gè)變量：mon th、day和year，函數(shù)的輸出為輸入日期后一天 的日期。例如，輸入為2013年9月9日，貝V函數(shù)的輸出為2013年9月10日。要求 輸入變量 mon th、day和year均為整數(shù)值，并且滿足下列條件：(1) 1 < mon th< 12(2) K day < 311920<year< 2050下面我們用邊界值分析法來設(shè)計(jì)測試用例。在NextDate函數(shù)中，規(guī)定了變量 mouth和變量day

37、的取值范圍為 K mouthw 12和 K dayw 31,并設(shè)定變量year的取值范 圍為1920W year < 2050。這些就是邊界條件。根據(jù)這些邊界條件設(shè)計(jì)的測試用例如 表3.4所示。表3.4 NextDate函數(shù)邊界值測試用例編號(hào)mouthdayyear預(yù)期輸出Testi6151919year超出范圍Test261519201920.6.16Test361519211921.6.16Test461519751975.6.16Test561520492049.6.16Test661520502050.6.16Test76152051year超出范圍Test86-12001day

38、超出131Test96120012001.6.2Test106220012001.6.3Testll63020012001.7.1Test126312001輸入日期超界Test136322001day超出131Test14-1152001Mouth 超出1 12Test1511520012001.1.16Test1621520012001.2.16Test17111520012001.11.16Test18121520012001.12.16Test1913152001Mouth 超出1 12因果圖法因果圖是一種利用圖解法分析輸入的各種組合情況，從而設(shè)計(jì)測試用例的方法，它適 合于檢查程序輸入條

39、件的各種組合情況。為什么要用因果圖我們前面介紹的等價(jià)類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考 慮輸入條件的各種組合、輸入條件之間的相互制約關(guān)系。這樣雖然各種輸入條件可 能出錯(cuò)的情況已經(jīng)測試到了，但多個(gè)輸入條件組合起來可能出錯(cuò)的情況卻被忽視了。但是如果在測試時(shí)必須考慮輸入條件的各種組合，則可能的組合數(shù)目將是天文數(shù)字，因此必須考慮采用一種適合于描述多種條件的組合、相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來進(jìn) 行測試用例的設(shè)計(jì)，這就需要利用因果圖。（2）因果圖使用上圖的簡單符號(hào)表示因果關(guān)系， 用圓圈表示節(jié)點(diǎn)，以 直線連接左右節(jié)點(diǎn)。左邊節(jié)點(diǎn)點(diǎn)表示輸入狀態(tài) （原因），右邊節(jié)點(diǎn)表示輸出狀態(tài)（結(jié) 果）。（3）般

40、用Ci表示原因，ei表示結(jié)果，Ci和ei的取值都是0或者 1， 0表示某種狀態(tài)不出現(xiàn)，1表示某種狀態(tài)出現(xiàn)。因果圖概念（1）關(guān)系：原因和結(jié)果之間存在如下關(guān)系（圖3.1）。（a）表示恒等，若Ci=1，則ei=1，否則ei=0 ；（b）表示非，若 Ci=1，貝V ei=0，否則ei=1 ；（c）表示或，若C1或C2或C3是1,則ei是1,否則ei是0,或可以有任意個(gè)輸入；（d）表示與，若C1且C2是1,則ei是1,否則ei是0,與可以有任意個(gè)輸入。約束：輸入狀態(tài)（原因）之間或輸出狀態(tài)（結(jié)果）之間存在的某種依賴關(guān)系（圖3.2）。E約束（異）：原因a和b中最多有一個(gè)可能為1,即a和b不能同時(shí)為1。I約束

41、（或）：原因a、b和c中至少有一個(gè)必須是1,即a、b和c不能同時(shí)為0。O約束（唯一）：原因a和b必須有一個(gè)，且僅有一個(gè)為1。R約束（要求）：原因a是1時(shí)，b必須是1，即不可能a是1時(shí)b是0。要求強(qiáng)制圖3.2 約束關(guān)系實(shí)例分析假設(shè)有一個(gè)中國象棋的軟件程序，我們需要測試棋子【馬】的走法。下面我們采用 因果圖來設(shè)計(jì)測試用例。(1)首先我們分析一下中國象棋中的走馬規(guī)則：a) 如果落點(diǎn)在棋盤外，則不移動(dòng)棋子；b) 如果落點(diǎn)與起點(diǎn)不構(gòu)成日字型，則不移動(dòng)棋子；c) 如果落點(diǎn)處有自己方棋子，則不移動(dòng)棋子；d) 如果在落點(diǎn)方向的鄰近交叉點(diǎn)有棋子(絆馬腿)，則不移動(dòng) 棋子；e) 如果不屬于a-d條，且落點(diǎn)處無棋子

42、，則移動(dòng)棋子；f) 如果不屬于a-d條，且落點(diǎn)處為對(duì)方棋子(非老將)，則移 動(dòng)棋子并除去對(duì)方棋子；g) 如果不屬于a-d條，且落點(diǎn)處為對(duì)方老將，則移動(dòng)棋子，并 提示戰(zhàn)勝對(duì)方，游戲結(jié)束。根據(jù)分析情況，我們得到以下原因和結(jié)果，如表3.5所示表3.5中國象棋走馬程序分析編號(hào)原因編號(hào)結(jié)果C1落點(diǎn)在棋盤上el不移動(dòng)棋子C2落點(diǎn)與起點(diǎn)構(gòu)成日字e2移動(dòng)棋子C3洛點(diǎn)方向的鄰近交叉點(diǎn)無棋子e3移動(dòng)棋子，并除去對(duì)方棋子C4落點(diǎn)處為自己方棋子e4移動(dòng)棋子，并提示戰(zhàn)勝對(duì)方,結(jié)束游 戲C5落點(diǎn)處無棋子C6落點(diǎn)處為對(duì)方棋子(非老將)C7落點(diǎn)處為對(duì)方老將接下來我們畫出中國象棋走馬規(guī)則因果圖圖3.3 因果圖，其中10表示中間

43、節(jié)點(diǎn)(3)然后根據(jù)因果圖得到判斷表(分成兩個(gè)表)表3.6 決策表(1)序號(hào)12345678910111213141516原 因C10101010101010101C20011001100110011C30000111100001111C40000000011111111結(jié)果100000000100000000el1111111011111111表3.7 決策表序號(hào)123456789'0111213141516原 因100101010101010101C50011001100110011C60000111100001111C70000000011111111結(jié)果e20010000e300

44、00100e40000001注：1、第2表中部分列被合并表示不可能發(fā)生的現(xiàn)象；2、通過中間節(jié)點(diǎn)將用例的判定表簡化為兩個(gè)小表。減少工作量。（4）根據(jù)判定表寫測試用例表表3.8 中國象棋走馬測試用例編號(hào)輸入條件操作步驟期望輸岀Test1條件a-d不成立，移動(dòng)馬，落點(diǎn)是對(duì)方 老將1、點(diǎn)擊自方馬；2、點(diǎn)擊對(duì)方老將。移動(dòng)棋子并提示戰(zhàn)勝 對(duì)方。Test2條件a-d不成立，移動(dòng)馬，落點(diǎn)是對(duì)方 棋子（非老將）1、點(diǎn)擊自方馬；2、點(diǎn)擊對(duì)方棋子。移動(dòng)棋子并除去對(duì)方 棋子。Test3條件a-d不成立，移動(dòng)馬，落點(diǎn)無棋子1、點(diǎn)擊自方馬；2、點(diǎn)擊無棋子的落點(diǎn)。移動(dòng)棋子。Test4絆馬腿，落點(diǎn)為對(duì)方老將1、點(diǎn)擊自方馬；2

45、、點(diǎn)擊對(duì)方老將。不移動(dòng)棋子。Test5絆馬腿，落點(diǎn)為對(duì)方棋子（非老將）1、點(diǎn)擊自方馬；2、點(diǎn)擊對(duì)方棋子。不移動(dòng)棋子。Test6絆馬腿，落點(diǎn)無棋子1、點(diǎn)擊自方馬；2、點(diǎn)擊無棋子落點(diǎn)。不移動(dòng)棋子。錯(cuò)誤推測法是指在測試程序時(shí)，人們可以根據(jù)經(jīng)驗(yàn)或直覺推測程序中可能存在的各 種錯(cuò)誤，從而有針對(duì)性地編寫檢查這些錯(cuò)誤的測試用例的方法。錯(cuò)誤推測方法的基本思想：列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊 情況，根據(jù)他們選擇測試用例。例如，在單元測試時(shí)曾列出的許多在模塊中常見的 錯(cuò)誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等，這些就是經(jīng)驗(yàn)的總結(jié)。還有，輸入數(shù)據(jù) 和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行。

46、這些都是容易發(fā)生 錯(cuò)誤的情況。可選擇這些情況下的例子作為測試用例。不同測試方法選擇原則除了上述幾種常用的黑盒測試方法外，還有一些黑盒測試方法，如決策表法、正交 試驗(yàn)法、流程分析法和狀態(tài)遷移圖法等，這里就不一一介紹了。通常，在確定測試方法時(shí)，應(yīng)遵循以下原則：1. 根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定測試等級(jí)和測試重點(diǎn)。2. 認(rèn)真選擇測試策略，以便能盡可能少的使用測試用例，發(fā)現(xiàn)盡可能多的程序錯(cuò)誤 因?yàn)橐淮瓮暾能浖y試過后，如果程序中遺留的錯(cuò)誤過多并且嚴(yán)重，則表明該次 測試是不足的，而測試不足則意味著讓用戶承擔(dān)隱藏錯(cuò)誤帶來的危險(xiǎn)，但測試過度 又會(huì)帶來資源的浪費(fèi)。因此測試需要找到一個(gè)平衡

47、點(diǎn)。3. 通常在確定測試策略時(shí)，有以下 5條參考原則：(1) 在任何情況下都必須采用邊界值分析法。 這種方法設(shè)計(jì)出的測試用例發(fā)現(xiàn)程序錯(cuò) 誤的能力最強(qiáng)。(2) 必要時(shí)采用等價(jià)類劃分法補(bǔ)充測試用例。(3) 采用錯(cuò)誤推斷法再追加測試用例。(4) 對(duì)照程序邏輯，檢查已設(shè)計(jì)出的測試用例的邏輯覆蓋程度。如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，則應(yīng)當(dāng)再補(bǔ)充更多的測試用例。(5) 如果程序的功能說明中含有輸入條件的組合情況，則應(yīng)一開始就選用因果圖法。項(xiàng)目說明測試用例設(shè)計(jì)項(xiàng)目主要教學(xué)生運(yùn)用黑盒測試方法對(duì)待測試項(xiàng)目進(jìn)行功能測試用例設(shè) 計(jì)，編寫測試用例文檔，對(duì)測試用例進(jìn)行評(píng)審，形成基線，納入軟件配置管理。整 個(gè)項(xiàng)目分為四個(gè)模塊

48、完成，模塊一為黑盒測試方法，模塊二為功能測試用例設(shè)計(jì)， 模塊三為編寫測試用例文檔，模塊四為測試用例評(píng)審。學(xué)生要求完成以下工作任務(wù)： 運(yùn)用黑盒測試方法設(shè)計(jì) ATM模擬系統(tǒng)的功能測試用例，編寫測試用例文檔，為測試 用例評(píng)審準(zhǔn)備評(píng)審文檔，分角色參與測試用例評(píng)審工作，將評(píng)審后的文檔形成基線， 納入配置庫管理。項(xiàng)目的工作場景一般是企業(yè)的各個(gè)項(xiàng)目組或者獨(dú)立的測試部門。 該項(xiàng)目能為測試員、測試工程師、測試經(jīng)理、SQA和SCM這些崗位的相關(guān)工作提供幫助。軟件測試與質(zhì)量控制教程5概述缺陷跟蹤管理是軟件測試工作的一個(gè)重要部分， 軟件測試的目的是為了盡早發(fā)現(xiàn) 軟件系統(tǒng)中的缺陷，因此，對(duì)缺陷進(jìn)行跟蹤管理，確保每個(gè)被發(fā)

49、現(xiàn)的缺陷都能夠 及時(shí)得到處理是軟件測試工作的一項(xiàng)重要內(nèi)容。缺陷分類軟件缺陷分類的原因在于給出 Bug的嚴(yán)重級(jí)別，判定修復(fù)的優(yōu)先級(jí)?？梢园凑?Bug的嚴(yán)重級(jí)別分類。表4.1缺陷分類表級(jí)別說明1類Bug：致命錯(cuò)誤(1) 需求說明書中的功能未實(shí)現(xiàn)；(2) 由于系統(tǒng)崩潰、死機(jī)、非法退出、死循環(huán)、 數(shù)據(jù)庫異常、通訊異常、文件操作異常等原因造成功能不能 實(shí)現(xiàn)，并且不能通過其他方法實(shí)現(xiàn)。2類Bug：嚴(yán)重錯(cuò)(1)重要功能基本能實(shí)現(xiàn)，但系統(tǒng)不穩(wěn)定、會(huì)誤導(dǎo)致數(shù)據(jù)破壞丟失、(2)他方法可以實(shí)現(xiàn)。run-time error錯(cuò)誤等；重要功能不能按正常操作實(shí)現(xiàn)，但通過其次要功能不能正常實(shí)現(xiàn)；(2)義、含義不一致)；操作

50、界面錯(cuò)誤(包括數(shù)據(jù)窗口內(nèi)列名定打印內(nèi)容、格式錯(cuò)誤；(4)簡單的輸入限制未放在前臺(tái)進(jìn)行控制；3類Bug： 般錯(cuò)誤刪除操作未給出提示；數(shù)據(jù)庫表中有過多的空子段；因錯(cuò)誤操作迫使程序中斷；(8)系統(tǒng)找不到規(guī)律的時(shí)好時(shí)壞；(9)性等約束條件。數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)則、缺省值未加完整最好能改進(jìn)的：(1)界面不規(guī)范；(2)輔助說明描述不清楚；4類Bug：細(xì)微錯(cuò)(3)輸入輸出不規(guī)范；誤(4)長操作未給用戶提示；(5)提示窗口文字未采用行業(yè)術(shù)語；(6)可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志。(1)可以作為下一個(gè)版本的改進(jìn)；5類Bug：改進(jìn)建 議(2)暫不作為修訂內(nèi)容。缺陷描述對(duì)缺陷的描述應(yīng)該包含以下的內(nèi)容:表4.2

51、 缺陷描述內(nèi)容說明內(nèi)容描述 項(xiàng)說明是否 必填可追蹤信息缺陷ID唯一的缺陷ID，可以根據(jù)該ID追蹤缺陷，一 般就是測試用例的編號(hào)是缺陷基本信息缺陷 狀態(tài)缺陷的狀態(tài)，分為“待分配”、“待修正”、“待驗(yàn)證”、“待評(píng)審”、“關(guān)閉”是缺陷 標(biāo)題描述缺陷的標(biāo)題是缺陷 嚴(yán)重 程度描述缺陷的嚴(yán)重程度，一般分為“致命”、“嚴(yán) 重”、“一般”、“建議”四種是缺陷 緊急 程度描述缺陷的緊急程度，從1-4, 1是優(yōu)先級(jí)最 高的等級(jí)，4是優(yōu)先級(jí)最低的等級(jí)是缺陷 提交 人缺陷提交人的名字（郵件地址）是缺陷 提交 時(shí)間缺陷提交的時(shí)間是缺陷 所屬 項(xiàng)目/模塊缺陷所屬的項(xiàng)目和模塊，最好能較精確的定位 至模塊是缺陷 指定 解決

52、人缺陷指定的解決人，在缺陷“提交”狀態(tài)為空， 在缺陷“分發(fā)”狀態(tài)下由項(xiàng)目經(jīng)理指定相關(guān)開 發(fā)人員修改是缺陷 指定 解決 時(shí)間項(xiàng)目經(jīng)理指定的開發(fā)人員修改此缺陷的deadli ne是缺陷 處理 人最終處理缺陷的處理人是缺陷 處理 結(jié)果 描述對(duì)處理結(jié)果的描述，如果對(duì)代碼進(jìn)行了修改， 要求在此處體現(xiàn)出修改是缺陷 處理 時(shí)間缺陷處理的時(shí)間是缺陷 驗(yàn)證 人對(duì)被處理缺陷驗(yàn)證的驗(yàn)證人是缺陷 驗(yàn)證 結(jié)果 描述對(duì)驗(yàn)證結(jié)果的描述（通過、不通過）是缺陷 驗(yàn)證 時(shí)間對(duì)缺陷驗(yàn)證的時(shí)間是缺陷詳細(xì)描述缺陷 詳細(xì) 描述對(duì)缺陷的詳細(xì)描述；之所以把這項(xiàng)單獨(dú)列出 來，是因?yàn)閷?duì)缺陷描述的詳細(xì)程度直接影響開 發(fā)人員對(duì)缺陷的修改，描述應(yīng)該盡可能詳細(xì)。是測試環(huán)境說明測試 環(huán)境 說明對(duì)測試環(huán)境的描述是必要的附件必要 的附 件對(duì)于某些文字很難表達(dá)清楚的缺陷，使用圖片 等附件是必要的否缺陷處理流程缺陷處理流程中的角色