【正文】 織和通訊：缺乏用戶參與，職責(zé)不明確、管理失敗等； ★ 硬件：硬件配置不對、缺乏、或處理器缺陷導(dǎo)致算術(shù)精度丟失，內(nèi)存溢出等； ★ 軟件：軟件設(shè)置不對、缺乏，或操作系統(tǒng)錯誤導(dǎo)致無法釋放資源，工具軟件的錯誤，編譯器的錯誤等； ★ 工作環(huán)境：組織機構(gòu)調(diào)整，預(yù)算改變，工作環(huán)境惡劣。軟件缺陷的生命周期分為簡單的軟件缺陷生命周期和復(fù)雜的軟件缺陷生命周期。 發(fā)現(xiàn) —— 〉 打開 —— 〉 修復(fù) —— 〉 關(guān)閉。 2． 復(fù)雜的軟件缺陷生命周期 復(fù)雜的軟件缺陷生命周期 打開一個軟件缺陷： ★ 對軟件缺陷進行 bug審查，是程序員代碼問題還是設(shè)計問題？ ★ 是立即修改還是可以延期修改？ ●審查決定軟件缺陷是否應(yīng)該修改； ●審查可能認(rèn)定軟件缺陷應(yīng)該在將來的同一時間考慮修改，但是在該版本軟件中不修改。 缺陷生命周期過程是測試員、程序員、管理者一起參與、協(xié)同測試工作的過程。 16． 2． 2 軟件缺陷生命狀態(tài)的定義 每一個軟件缺陷都有 6個生命狀態(tài)：打開（ Open）、缺陷修改（ Working）、缺陷驗證（ Verify）、缺陷刪除（ Cancel）、缺陷關(guān)閉（ Close）、缺陷延期（ Defer）。 ? 軟件缺陷的生命周期示意圖如圖 161所示。 2．缺陷生命狀態(tài)的控制與轉(zhuǎn)換 （ 1）當(dāng)測試員報告一個缺陷，程序員接受打開（ Open）態(tài)的缺陷，缺陷生命周期開始，為打開態(tài)； ★ 打開態(tài) — 〉 缺陷修改態(tài) — 〉 缺陷驗證態(tài) — 〉 打開態(tài) /缺陷關(guān)閉態(tài) /缺陷刪除態(tài)； ★ 程序員接受打開態(tài)的缺陷，修改中可將其置為缺陷修改態(tài)、修改完畢可置為缺陷驗證態(tài)； ★ 測試員驗證缺陷驗證態(tài)的缺陷，確認(rèn)修改結(jié)果正確，可將打開態(tài)置為缺陷關(guān)閉態(tài)；確認(rèn)不是缺陷，可將打開態(tài)置為缺陷刪除態(tài)；認(rèn)修改結(jié)果不正確，可以將缺陷驗證態(tài)置為打開態(tài)，要求程序員重新修改；打開態(tài)缺陷關(guān)閉態(tài) /缺陷刪除態(tài)。 （ 3）管理者確認(rèn)缺陷需延期修改或追蹤，可將打開態(tài)缺陷置為缺陷延期態(tài)； 此外，終結(jié)態(tài)必要時可以重新打開： ● 在適當(dāng)?shù)臅r候，管理者可將缺陷延期態(tài)改為打開態(tài)，要求程序員修改； ● 在復(fù)查缺陷處理結(jié)果時，發(fā)現(xiàn)缺陷關(guān)閉態(tài)或缺陷刪除態(tài)的處理有誤，測試員可以將缺陷關(guān)閉或缺陷刪除態(tài)重新置為打開態(tài)，要求程序員重新修改； 一般在測試初期，活動態(tài)的缺陷數(shù)會急劇上升，隨著程序員、測試員的處理逐漸轉(zhuǎn)為終結(jié)態(tài)。 軟件缺陷的跟蹤管理 16． 3． 1 軟件缺陷測試報告 軟件中不可能沒有缺陷，發(fā)現(xiàn)很多的缺陷對于測試工作來說，是件很正常的事。 1．報告軟件缺陷的原則 （ 1）盡快報告軟件缺陷 （ 2）有效地描述軟件缺陷 有效的軟件缺陷描述要求如下： ★ 簡單與短小； ★ 明確指明錯誤類型； ★ 單一； ★ 使用 IT業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法。 3．跟蹤軟件缺陷手工報告記錄 顯然，在軟件測試工作中，每個測試用例的結(jié)果都必須進行記錄。如果測試是采用手工記錄和跟蹤軟件缺陷，那么有關(guān)軟件缺陷的信息可以直接記錄在相應(yīng)的文檔中。 4． IEEE軟件缺陷報告模板 ANS/IEEE829— 1998標(biāo)準(zhǔn)定義了一個稱為軟件缺陷報告的文檔，用于報告“在測試期間發(fā)生的任何異常事件”。 16． 3． 2 缺陷類別 缺陷類別劃分為 5類： A 類、 B 類、 C類、 D 類、 E 類。 ★ 數(shù)據(jù)庫發(fā)生死鎖； ★ 數(shù)據(jù)庫設(shè)計未達(dá)到范式的要求或需求規(guī)格說明的水平； ★ 數(shù)據(jù)功能實現(xiàn)錯誤； ★ 與數(shù)據(jù)庫連接錯誤； ★ 數(shù)據(jù)通訊錯誤。 ★ 因錯誤操作迫使程序中斷。 3． C 類 C類是由操作界面引起的錯誤。 4． D類 D類是由界面不規(guī)范引起的錯誤。 5． E類 E類是由遺漏部分功能引起的錯誤 ★ 實現(xiàn)功能與需求不相吻合。 1．缺陷的分離 缺陷分離的方法主要有： ★ 確保所有的測試步驟都被記錄（記錄每一個測試步驟、每一件工作）； ★ 注意時間和運行條件上的因素（查找時間依賴和競爭條件的問題 (slow軟盤、 quick硬盤、時間發(fā)生次序 )； ★ 注意軟件的邊界條件、內(nèi)存容量和數(shù)據(jù)溢出的問題； ★ 注意事件發(fā)生次序?qū)е碌能浖毕荩? ★ 考慮資源依賴性和內(nèi)存、網(wǎng)絡(luò)、硬件共享的相互作用； ★ 注意系統(tǒng)的壓力條件； ★ 不能忽視硬件。 2．缺陷的重現(xiàn) 缺陷的重現(xiàn)要采取繁雜的步驟才能再現(xiàn)，或者根本無法再現(xiàn)。因為開發(fā)人員熟悉代碼，因此看到癥狀、測試用例步驟和分離問題的過程時，可能得到查找軟件缺陷的線索。如果軟件測試人員盡最大努力分離軟件缺陷，也無法表達(dá)準(zhǔn)確的再現(xiàn)步驟，那么仍然需要記錄和報告軟件缺陷。 16． 3． 4軟件缺陷跟蹤系統(tǒng) 軟件缺陷跟蹤系統(tǒng)（ Bug Tracking System）是用于記錄、跟蹤、并歸類處理軟件開發(fā)過程出現(xiàn)的 Bug 和硬件系統(tǒng)中存在的缺陷（ defect）。目的是：保持進度、保證質(zhì)量，提高整個機構(gòu)的生產(chǎn)效率。 1．軟件缺陷跟蹤系統(tǒng)常用的功能要求 ★ 缺陷跟蹤管理系統(tǒng)應(yīng)采用 B/S結(jié)構(gòu)； ★ 采用標(biāo)準(zhǔn)技術(shù)，基于網(wǎng)絡(luò)，多功能，快速，可靠，好用性好； ★ 無需在用戶終端機器上裝任何附加軟件，可從網(wǎng)絡(luò)上任何地方通過 HTTP 或 SMTP 聯(lián)接； ★ 支持網(wǎng)頁界面，內(nèi)部網(wǎng)和外部網(wǎng)的用戶均可使用； ★ 支持各種數(shù)據(jù)庫系統(tǒng)，基于 SQL92 標(biāo)準(zhǔn)，使用開放型數(shù)據(jù)庫設(shè)計，可升級； ★ 可設(shè)置性和多用途 ,不僅可用做 Bug 跟蹤系統(tǒng)，而且可用做集成服務(wù)臺熱線流程管理； ★ 支持各種自定域數(shù)據(jù)類型，表格欄目可根據(jù)需要添加和刪減； ★ 頁面可做個性化調(diào)整，如添加公司標(biāo)志等； ★ 可同時支持多個項目，設(shè)置訪問權(quán)限，自我注冊； ★ 可設(shè)置基于表格欄目域的多層次權(quán)限； ★ 自定義工作流程（對每個項目）； ★ 自動或手動分配任務(wù)負(fù)責(zé)人； ★ 可一次附加多個任何類型的文件； ★ 支持直接屏幕抓圖（ Screen capture）； ★ 具有自動自定義電子郵件通知功能； ★ 可通過電子郵件和文檔版本管理軟件 (CVS, Perforce) 集成； ★ 圖表報告，高級搜索，自定義常用搜索； ★ 全面且易讀的記錄和修改歷史； ★ 快速排序和導(dǎo)出（ export)； ★ 支持目錄服務(wù) (LDAP/Active Directory) 集成 ； ★ 具有自定義電子郵件提醒催單功能 (Reminder)； ★ 方便的基于網(wǎng)絡(luò)的系統(tǒng)管理。國內(nèi)外已出現(xiàn)了一批質(zhì)量較好的缺陷管理工具，其中比較有代表性的有： ★ 開源軟件 Bugzilla、 jira； ★ Compuware公司的 TrackRecord ； ★ Rational公司的 ClearQuest； ★ 北京航空航天大學(xué)的 QAMonitor； ★ 上海微創(chuàng)軟件有限公司的 BMS等。 16． 4 軟件測試的評估 軟件測試的主要評測方法包括測試覆蓋評估、質(zhì)量評估、缺陷評估和性能測試評估。 ? 覆蓋指標(biāo)提供了 測試的完全程度如何？ 這一問題的答案。簡而言之，測試覆蓋是就需求（基于需求的）或代碼的設(shè)計 /實施標(biāo)準(zhǔn)（基于代碼的）而言的完全程度的評估，如用例的核實（基于需求的）或所有代碼行的執(zhí)行（基于代碼的）。并在測試生命周期的各階段（里程碑）提供測試覆蓋的標(biāo)識（如基于需求的、已計劃的、已實施的、已執(zhí)行的成功測試覆蓋）。 RfT 是測試需求 (Requiremen