軟件測試管理精華

　　軟件經理、項目經理以及用戶對負責模塊的反映;被開發人員拒絕修改，但用戶反饋要修改的缺陷，使用測試工具對測試效率的提高或者對其他測試人員的幫助;

　　三、 測試小組與開發小組的約定：

　　1、缺陷的管理;

　　測試人員與開發人員以TD作為交流的依據，因此必須測試人員與開發人員必須每天瀏覽TD上的缺陷記錄，并根據優先級作為開發員修改的依據：

　　優先級開發工程師(修復)測試工程師(回歸測試)

　　高缺陷狀態為Open后，正常情況應在2個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在3個工作天內完成;在開發修改完成后，正常情況應在1個工作天內完成;如特殊情況，要在備注中注明原因，但也應在2個工作天內完成;

　　中缺陷狀態為Open后，正常情況應在5個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在8個工作天內完成;在開發修改完成后，正常情況應在2個工作天內完成;如特殊情況，要在備注中注明原因，但也應在5個工作天內完成;

　　低缺陷狀態為Open后，正常情況應在10個工作天內修改完成;如特殊情況，要在備注中注明原因，但也應在12個工作天內完成;在開發修改完成后，正常情況應在5個工作天內完成;如特殊情況，要在備注中注明原因，但也應在7個工作天內完成;

　　2、版本的管理：

　　模塊開發初期，兩周提交一次版本;

　　模塊開發中期：一周提交一次版本;

　　模塊開發后期：2到3天提交一次版本;

　　附件三：開發期的界定;

　　提交版本時必須提供本次版本中實現的需求，復雜操作必須提供簡單說明，存在約束的功能必須說明，并確定下次提交版本的時間;

　　提交版本前，必須確保類文件在VSS上是最新的，已check in 的，類文件必須是編譯正常的文件;要明確jar包的目錄，要引用的庫文件;

　　數據庫腳本需要更新時，必須明確提示，并盡可能提供不清空數據的替代方法;

　　3、需求變更及其他事項的處理：

　　當需求規約發生變更時，開發人員應及時用郵件通知相關的測試人員和測試經理，如需求變更多大時，應形成文檔提交;

文章來源于領測軟件測試網 http://www.kjueaiud.com/