深圳市鼎智時代通訊技術****
版權所有（2010~2011）
修訂歷史：
一、 軟體錯誤的常用狀態
新問題(new)：測試中新報告的軟體缺陷；
已分配 (assigned)：被確認並分配給相關開發人員處理；
已解決(resolved)：開發人員已完成修正，等待測試人員驗證；
不處理(wontfix):拒絕修改缺陷或擱置不改；
再開啟(reopende): 修改驗證未改，重新分配修改；
無效的(invalid):不是缺陷
已關閉(closed)：錯誤已被修復；
二、 bug管理的流程
1. 測試人員提交新的bug入庫，錯誤狀態為new。
2. 測試組長驗證錯誤，如果確認是錯誤，分配給相應的開發人員並抄送給軟體專案經理，設定狀態為open。如果不是錯誤，則拒絕，設定為invalid (無效)狀態。
3. 開發人員查詢狀態為open的bug，把bug置為assigned狀態，表明已經開始處理該問題
4. 對於無效bug, 開發人員把狀態置為invalid。
5. 對於普通bug, 開發人員修復bug後，把狀態置為resolved。
6. 對於暫時不能解決的bug, 狀態保留為assigned，並新增相關備註。
7. 對於不能修改或者建議不修改的問題，及時反饋給專案經理，經開會討論決議後，才能置為暫時不修改wontfix
測試人員查詢狀態為fixed的bug，然後驗證bug是否已解決，如解決置bug的狀態為closed，如沒有解決置狀態為reopen。
三、 軟體bug規範
1. 軟體bug提交報告包括頭資訊、簡述、操作步驟和注釋。
a) 頭資訊包括：測試軟體名稱、版本號、嚴重程度、優先程度、測試平台、缺陷或錯誤範圍。要求填寫完整、準確。
b) 簡述是對缺陷或錯誤特徵的簡單描述，可以使用短語或短句，要求簡練、準確，並描述清楚正確的應該是怎麼樣的，現在有什麼錯誤，以及出現機率。
c) 操作步驟是描述該缺陷或錯誤出現的操作順序，要求完整、簡潔、準確。每乙個步驟盡量只記錄乙個操作。結束時寫上出現頻率。
d) 注釋一般是對缺陷或錯誤的附加描述。
e) 對於描述不清楚的問題，可以抓張**說明，對於非必現的問題，需要新增log附件。
2. 每個軟體問題報告只書寫乙個缺陷或錯誤
這樣可以每次只處理乙個確定的錯誤，定位明確，提高效率，也便於修復錯誤後方便的進行驗證。
3. 開發人員解決bug時，需要寫明：
a) bug的原因。
b) bug的修改方法
c) bug可以在哪個版本上進行驗證。
四、 軟體bug流程管理要點
1. 為了保證bug的正確性，需要有豐富測試經驗的測試人員驗證發現的bug是否是真正的bug，書寫的測試步驟是否準確，是否能重複。
2. 每次對bug的處理都要保留處理資訊，包括處理方法，處理意見，bug狀態。
3. 拒絕或延期bug不能由程式設計師單方面決定，應該由專案經理，測試經理和設計經理共同決定。
4. bug修復後必須由報告錯誤的測試人員驗證後，確認已經修復，才能關閉bug。
5. 開發人員應該首先著手自己重現問題，減少對測試人員的依賴
6. 對於某些不能重複的錯誤，加強測試人員與程式設計師的交流，可以請測試人員補充詳細的測試步驟和方法，以及必要的測試log資訊。
7. 軟體專案經理應該加強對bug的關注，對於沒有及時得到處理、長時間沒有解決問題應該進行跟蹤。
8. 普通的研發版本，應該帶上自動記錄log的功能。
9. 無法重現的bug，需要跟蹤三個版本以上才能關閉。
軟體發布管理流程規範
編制 審核 日期 版本 編號 密級 修改歷史 目錄1.目標 4 2.發布流程 4 2.1.補丁發布流程 4 2.2.主版本發布流程 6 2.3.產品實施流程 9 2.4.vss管理流程 10 3.相關資料 11 1 減少交叉溝通。通過將發布過程流程化，使每乙個環節的執行者都非常清楚自己的產入產出，受...
軟體發布管理流程規範
編制 審核 日期 版本 編號 密級 修改歷史 目錄1.目標 4 2.發布流程 4 2.1.補丁發布流程 4 2.2.主版本發布流程 6 2.3.產品實施流程 9 2.4.vss管理流程 10 3.相關資料 11 軟體的發布過程，需要形成有序的良性迴圈。否則，各環節流轉中容易發生相互等待 被動接應的局...
軟體發布管理流程規範
編制 審核 日期 版本 編號 密級 修改歷史 目錄1.目標 4 2.發布流程 4 2.1.補丁發布流程 4 2.2.主版本發布流程 6 2.3.產品實施流程 9 2.4.vss管理流程 10 3.相關資料 11 1 減少交叉溝通。通過將發布過程流程化，使每乙個環節的執行者都非常清楚自己的產入產出，受...