軟件測試過程中，最基本的任務莫過缺陷管理，如果沒有發現缺陷，也無法報告軟件缺陷，消除缺陷也無從談起。隨著對缺陷管理的日益重視，越來越多的測試工具已經為我們發現軟件中的缺陷打開了方便之門，那么，我們應該如何正確使用工具進行軟件測試工作中缺陷的發現和匯報，有效的提升IT系統質量呢？
第一步：規劃缺陷管理流程
實踐證明，只有展開全面徹底地規劃，才能讓缺陷匯報和解決流程提供有價值
的信息，使IT流程合理化。以下部分所描述的步驟是在創建匯報流程、定義缺陷安
全等級、記錄缺陷狀態和跟蹤所有修改的過程中會被采用的一些步驟。
發現“缺陷”
通過使用測試工具，在SDLC（軟件開發生命周期）中未被發現的所有和項目有
關的差異及問題都將匯報到管理工具中。美科利TestDirector針對不同的差異，清
晰的定義了NEW、OPEN、CLOSED等級別。當工具中開放了一個新的缺陷問題，我們
就要陸續開始登錄缺陷報告、定義缺陷安全等級、描述缺陷、指派相關人員展開最
初的調查、將差異轉交給相關的測試主管等工作。
缺陷解決會議
召開缺陷解決會議能確保所有缺陷都能涉及并得到有效解決。這種定期會議由
來自開發、項目管理、產品管理、和項目相關的業務團隊代表及測試主管共同參加
，就缺陷問題展開討論。測試主管在會議期間對測試工具進行信息更新，會議的中
心議題是對缺陷報告進行審核。有了測試工具提升的完備的報告，我們就可以依據
其嚴重程度和狀態情況，選擇處理的優先權
缺陷修復
缺陷解決會議后，缺陷將被分配給合適的小組主管，以便著手解決。這些小組
包括：開發小組、環境支持小組，或是業務團隊。通過管理工具對任務進行合理分
配，能更為高效地解決缺陷問題。
重復測試缺陷
被修復缺陷如果在環境缺陷中沒有代碼變更，將馬上展開重復測試，并立即關
閉。需要代碼變更的缺陷修復會涵蓋在一個版本打包中，從而展開重復測試，接著
將根據測試結果或者關閉缺陷，或者將缺陷重新開放。
第二步：定義缺陷狀態
每個缺陷都有一個狀態顯示，會在整個測試周期中得到隨時地更新。每次當缺
陷狀態有了更新，評論信息就會加入到缺陷的R&D評論欄中。測試工具中的缺陷狀
態一般會有以下幾種：
New：默認值，測試分析人員輸入一個新的缺陷時，其狀態為“New”。
Open：測試主管將缺陷狀態從“New”改為“Open”，并在一定的時間內（根據
缺陷嚴重程度）更新R&D評論信息，接著指派給適合的小組。
Fixed：當缺陷被修復并通過了聯合測試，開發人員將缺陷狀態從“Open”改為
“Fixed”。缺陷修復的周期取決于缺陷的嚴重程度。
Ready for Retest：當缺陷已經修復，并在一個build中完成了系統測試和識別
，項目/產品/發布經理將缺陷狀態更新為“Ready to Retest”。
On Hold：當該缺陷由于其它缺陷的阻礙而無法在build中實施重復測試時，測試
分析人員將缺陷狀態從“Ready to Retest”更新成“On Hold”。
Closed：當缺陷在一個新建的應用中完成了重復測試，測試分析人員就將狀態從
“Ready to Retest”改為“Closed”。
Reopen當缺陷重復測試失敗，測試分析人員將狀態從“Ready to Retest”更新
為“Reopen”。當以前已經關閉的缺陷又在測試過程中出現時，測試分析人員將把
狀態從“Closed”改為“Reopen”。
第三步：用戶操作的狀態修改
通過對測試工具所允許的狀態變更操作，可以為實現便捷的學習曲線和鞏固一
種優化的工作流程提供幫助。狀態變更包括：
根據適合的變更控制流程所進行的任何系統變更。
在進行修復操作之后，未通過測試或某個測試部分根據需要展開重復測試。
在流程中的任何時段，項目經理、系統分析人員、開發人員和測試工作人員可以
使用測試工具來恢復保存在存儲器中的所有缺陷狀態等。
最后：將新的流程配置到測試自動化工具中
最后，當所有流程都得到了及時改進后。我們就把一個雜亂無序的流程打造成
為一個有著杰出運作表現的項目，具有完備的信息記錄；可重復的流程；可衡量的
成果；和一個改進程序。正確地運用軟件去創建缺陷解決流程，實現開發環節中使
用的手動流程自動化，以創建穩固的測試計劃及測試組合。
功能強大的美科利TestDirector通過一個獨立的、基于Web的應用來支持整個測試
流程，包括需求管理；規劃、創建、安排和執行測試；缺陷管理；項目狀態分析等
。同時，它還可與行業中廣泛使用的第三方應用相集成，有效保護企業現有解決方
案上的投資。有了可以在無人操作情況下自動地、24X7不間斷運作的測試工具，我
們就能很好地達到提升IT系統質量，增強系統效益的目標。
