本文討論了在一個軟件企業內部如何描述軟件缺陷信息，如何實施缺陷跟蹤管理，以及缺陷跟蹤管理工具的實現原理及設計要領。

　　考察一個典型的軟件開發流程：需求分析→概要設計→詳細設計→程序編碼→系統集成→交付與維護，你會發現此流程中各階段之間的依賴與繼承關系是相當密切的。前一階段形成的方案或產品中正確的部分固然會被后一階段繼承和細化，然而，如果前一階段的方案中出現了錯誤，而測試人員沒有及時介入此階段的質量控制，那么該錯誤也會被后一階段繼承和放大，并順序傳遞下去。如果等到交付與維護階段，錯誤才被發現，那么相關的糾錯工作將成為一件成本高昂而又收效甚微的事情，在某些情況下，甚至會導致整個開發工作的失敗。這并不是危言聳聽。據美國國家標準技術研究院的一份報告顯示，占據世界軟件銷售額85%的大型專用軟件，其開發的失敗率高達70%。

　　因此，在軟件開發流程的每個階段都必須引入軟件測試技術，及早測試，杜絕錯誤的蔓延。然而，測試工作的天性決定了測試人員可能是開發人員總想回避的角色。在測試實踐的早期，當測試人員查出某個缺陷，報告給開發人員時，多數情況下開發人員會象征性表示一下感謝，然后把測試報告撂在一邊，繼續忙手頭的工作。事后到底有沒有修改，誰也不知道。如果測試人員頻繁給同一開發人員報錯或不停地追問缺陷的修改情況，開發人員或許會逐漸喪失好脾氣，出于維護技術權威或其他目的，他會狡辯：這不是錯誤，這是軟件的一個特殊功能。或者說：這不是什么大問題，現在開發進度緊，而且糾正起來也挺麻煩的，等有時間再說吧。于是，不了了之，問題依舊存在。

　　為了規避這種情況的發生，軟件企業必須引入軟件缺陷跟蹤管理機制。測試人員不再需要直接與開發人員接觸，甚至不需要知道開發者是誰，查出錯誤以后，直接報到缺陷跟蹤管理系統就可以了（有些測試團隊是有寫入權限控制的），開發人員做不做修改以及什么時間之前必須完成修改是項目管理部門的事情（當然測試團隊也可以提相關建議）。引入缺陷跟蹤管理機制一方面劃清了各個角色的職責，避免了不必要爭執，另一方面也有助于項目管理部門及時了解軟件產品在生產過程中所處的質量狀況，從而更好地控制產品的質量。

　　軟件缺陷的描述

　　這里首先對“缺陷”和“錯誤”兩個概念做一下區分：缺陷指軟件文檔或程序代碼中存在的數據錯誤、邏輯錯誤、內容遺漏以及內容上的不一致等。缺陷包括錯誤，與bug是同義詞（注：鑒于這是一篇實用性文章，筆者不打算對缺陷、錯誤、bug進行更細致的理論討論）。既然在軟件開發流程的每個階段開發人員都有可能引入缺陷，那么如何來描述一個缺陷呢？下面筆者談談自己的看法。

　　首先，對缺陷的描述應該包含可追蹤信息，如給每個缺陷分配一個缺陷號，每個編號必須是惟一的，可以根據該編號搜索、查看該缺陷的處理情況。

　　其次，對缺陷的描述應該包含缺陷的基本信息。通常缺陷的基本信息包括缺陷狀態、缺陷標題、缺陷嚴重程度、缺陷緊急程度、缺陷提交人、缺陷提交日期、缺陷所屬、缺陷解決人、缺陷解決時間、缺陷解決結果、缺陷處理人、缺陷處理最終時間、缺陷處理結果、缺陷確認人、缺陷確認時間、缺陷確認結果等等。

　　下面筆者簡單解釋一下：缺陷狀態標注了缺陷的待修正、待評審、待驗證、關閉等狀態信息；缺陷標題則簡要地說明缺陷的類型及內容；缺陷嚴重程度是測試人員給出的缺陷嚴重程度估計，可以是致命的、嚴重的、一般的、建議的等; 缺陷緊急程度是測試人員給出的測試處理優先級；缺陷提交人是指發現此缺陷的測試人員，最好附有聯系方式，以方便缺陷處理人員進行確認；缺陷所屬指缺陷所在的模塊或者是缺陷所屬的開發文檔的名稱；缺陷解決人則是指由誰來進行缺陷的解決，明確是需求分析人員、設計人員還是程序編碼人員；缺陷解決時間是項目組負責人返回的缺陷預計處理的時間；缺陷解決結果標明預計缺陷修改后能達到的結果；缺陷確認人是指由誰來確認缺陷已經得到了修正；缺陷確認時間是指缺陷修復的確認工作完成的時間；缺陷確認結果指確認軟件缺陷的修正工作是否有效。

　　以上列出的條目不是必須的，讀者可以根據項目的實際情況進行實施軟件跟蹤管理技術對于企業而言，它的意義在于確保每個被發現的缺陷都能被解決。這里，解決可能是指缺陷被修正，也可能是指項目組成員達成一致的處理意見（如不做處理）。軟件缺陷跟蹤管理過程中所收集到的缺陷數據對評估軟件系統的質量、測試人員的業績、開發人員的業績等提供了量化的參考指標，也為軟件企業進行軟件過程改進提供了必要的案例積累。另外，有些軟件企業還根據缺陷跟蹤管理過程中所獲得的缺陷數目分布趨勢來決定軟件產品的最佳發布時機。

　　剪裁。另外，要引起注意的是上述部分條目不是由測試人員來填寫的，如缺陷解決時間、缺陷解決結果、缺陷處理人等，應該由項目管理人員統籌成本、進度等因素后決定。

　　另外，對缺陷的描述還應該包含缺陷的詳細描述，也就是要對缺陷的特征做出詳細的描述，例如程序代碼中的錯誤，應詳細描述錯誤發生的軟硬件環境，相關輸入輸出數據，出錯時程序的狀態等，以方便編碼人員進行錯誤復現和錯誤定位。又如設計規格說明中的錯誤，則應指明它與高層軟件開發文檔（如需求規格說明）中哪些條款相違背，為什么判為違背，都需要描述清楚，以方便設計人員進一步核實。

　　除此之外，對某些缺陷的描述應該包含必要的附件。有時，某些缺陷可能無法用語言文字表達清楚，如用戶界面出現的一些缺陷。這時，就需要借助于屏幕拷貝等方式來進一步描述缺陷。

　　缺陷跟蹤管理的一般流程

　　缺陷跟蹤管理系統（ Defect Tracking System）是用于集中管理軟件測試過程中所發現缺陷的數據庫程序。利用它便于查找和跟蹤缺陷，因為對于大中型軟件的測試過程而言，報告的缺陷總數可能會有成千上萬個，如果沒有缺陷跟蹤管理系統的支持，要求查找某個錯誤，其難度和效率可想而知。另外，利用該系統還有利于項目組成員間協同工作，缺陷跟蹤管理系統可以作為測試人員、開發人員、項目負責人、缺陷評審人員協同工作的平臺，同時也能保證測試工作的有效性，避免測試人員重復報錯，也便于及時掌握各缺陷的當前狀態，進而完成對應狀態的測試工作。最后它還有利于跟蹤和監控錯誤的處理過程和方法，可以方便地檢查處理方法是否正確，跟蹤處理者的姓名和處理時間，作為工作量的統計和業績考核的參考。

　　其簡單流程如圖所示，該流程涉及測試人員、項目負責人、開發人員、評審員等角色，這些角色的描述以及職責如表所示。圖中提到軟件缺陷的幾個狀態有：初始狀態、待分配狀態、待修正狀態、待驗證狀態、待評審狀態以及最后的關閉狀態。讀者可以根據企業的實際情況，適當調整該流程以取得更高的效率。

　　缺陷跟蹤管理的實現原理

　　軟件缺陷跟蹤管理系統可以通過添加、修改、排序、查尋、存儲操作來管理軟件缺陷。目前市場上已經出現了一些通用缺陷跟蹤管理軟件，這些軟件在功能上各有特點，可以根據實際情況直接購買使用; 也可以根據測試項目的實際需要，開發專用的缺陷跟蹤系統，例如基于Lotus Notes 開發。

　　缺陷跟蹤管理系統在實現技術層面上來看是一個數據庫應用程序。它包括前臺用戶界面、后臺缺陷數據庫以及中間數據處理層。目前，不少缺陷跟蹤管理系統是采用B/S結構來實現的，相應地，采用的編程語言是ASP或JSP。讀者可以根據需要選擇購買商品化的缺陷跟蹤管理工具，或者選擇自行研發軟件缺陷跟蹤管理工具。這類系統的用戶界面所顯示的信息一般應根據用戶的角色不同而略有差異，因為各個角色使用該系統完成的任務各不相同。如測試人員用于報告缺陷或確認缺陷是否可以關閉；開發人員用于了解哪些缺陷需要他去處理以及缺陷經過處理后是否被關閉；而項目負責人需要及時了解當前有哪些新的缺陷，哪些必須及時修正等。另外，不同角色所擁有的數據操作權限也不盡相同。例如開發人員無權通過其用戶界面往數據庫中填寫新的缺陷信息，也無權關閉某個已知缺陷; 而測試人員無權決定分配誰去修正某已知缺陷也無權決定是否要修正某個缺陷。

　　缺陷跟蹤管理系統后臺數據庫的設計建議盡量考慮到不同角色的應用需要，如測試人員可能需要對相關數據表做頻繁的記錄的插入、查詢等操作，軟件開發人員可能對與他相關的記錄非常重視，而對其他記錄不感興趣，而項目負責人員可能對新發現的缺陷數據需要做到及時掌握，這些需求對于數據庫的建表、建立索引都有很大的指導性意義。