軟件測試與質(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)測試和動態(tài)測試 5黑盒測試和白盒測試 5單元測試、集成測試、系統(tǒng)測試和驗收測試 5功能測試和性能測試 6回歸測試和冒煙測試 6軟件測試分類關(guān)系 6軟件配置管理 7軟件測試管理 7組織管理 7計劃管理 8用例管理 9文檔管理 10軟件測試與質(zhì)量控制 教程 2 10概述

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

3、程 27項目說明 28軟件測試與質(zhì)量控制 教程 6 29概述 29自動化測試工具分類 29自動化測試工具一覽 29WinRunner 功能測試工具 31項目說明 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è)計步驟 37實例分析 37軟件測試與質(zhì)量控制教程 8 39概述 39測試報告主要內(nèi)容 39項目說明 40軟件測試與質(zhì)量控制 教程 1概述軟件測

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

5、題， 需要通過軟件測試手段來發(fā)現(xiàn)軟件缺 陷，保證軟件質(zhì)量。軟件測試人員做什么 軟件測試人員的目標(biāo)就是盡可能早的找出軟件缺陷， 并確保其得到修復(fù)。 軟件測 試人員的主要工作包括制定測試計劃、 設(shè)計測試用例、 執(zhí)行測試、 對發(fā)現(xiàn)的缺陷 進(jìn)行跟蹤管理、對測試結(jié)果進(jìn)行分析總結(jié)等內(nèi)容。軟件測試環(huán)境 軟件測試環(huán)境就是軟件運行的平臺，包括軟件、硬件和網(wǎng)絡(luò)。硬件主要包括 PC 機(jī)、筆記本、服務(wù)器、各種PDA終端設(shè)備等。軟件主要是指軟件運行的操作系統(tǒng)， 數(shù)據(jù)庫管理系統(tǒng)，Wet服務(wù)器、瀏覽器等。網(wǎng)絡(luò)主要針對的是 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)品說明書指明不會出現(xiàn)的錯誤；3. 軟件功能超出產(chǎn)品說明書指明范圍；4. 軟件未達(dá)到產(chǎn)品說明書雖未指明但應(yīng)達(dá)到的目標(biāo)；5. 軟件測試人員認(rèn)為軟件難以理解、 不易使用、 運行速度緩慢或者最終用戶認(rèn)為不好什么是測試用例測試用例是測試執(zhí)行的依據(jù)，是指在測試執(zhí)行之前設(shè)計的一套詳細(xì)的測試方案， 包括測試環(huán)境、測試步驟、測試數(shù)據(jù)和期望結(jié)果。軟件測試分類 人們根據(jù)測試目的和測試角度的不同將軟件測試分成眾多的類別。 我們經(jīng)常聽到 諸如靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、單元測試、集成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36、應(yīng)保留其中一個變量，其余的變量取正常值，被保留的變量取邊界和邊界附近的值， 對每個變量重復(fù)進(jìn)行上述取值方法，設(shè)計測試用例。實例分析NextDate函數(shù)包含三個變量：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è)計測試用例。在NextDate函數(shù)中，規(guī)定了變量 mouth和變量day

37、的取值范圍為 K mouthw 12和 K dayw 31,并設(shè)定變量year的取值范 圍為1920W year < 2050。這些就是邊界條件。根據(jù)這些邊界條件設(shè)計的測試用例如 表3.4所示。表3.4 NextDate函數(shù)邊界值測試用例編號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è)計測試用例的方法，它適 合于檢查程序輸入條

39、件的各種組合情況。為什么要用因果圖我們前面介紹的等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考 慮輸入條件的各種組合、輸入條件之間的相互制約關(guān)系。這樣雖然各種輸入條件可 能出錯的情況已經(jīng)測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。但是如果在測試時必須考慮輸入條件的各種組合，則可能的組合數(shù)目將是天文數(shù)字，因此必須考慮采用一種適合于描述多種條件的組合、相應(yīng)產(chǎn)生多個動作的形式來進(jìn) 行測試用例的設(shè)計，這就需要利用因果圖。（2）因果圖使用上圖的簡單符號表示因果關(guān)系， 用圓圈表示節(jié)點，以 直線連接左右節(jié)點。左邊節(jié)點點表示輸入狀態(tài) （原因），右邊節(jié)點表示輸出狀態(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,或可以有任意個輸入；（d）表示與，若C1且C2是1,則ei是1,否則ei是0,與可以有任意個輸入。約束：輸入狀態(tài)（原因）之間或輸出狀態(tài)（結(jié)果）之間存在的某種依賴關(guān)系（圖3.2）。E約束（異）：原因a和b中最多有一個可能為1,即a和b不能同時為1。I約束

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

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

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

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

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

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

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

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

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

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

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

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