2.2 用戶問題反饋
用戶反饋的問題，屬于軟件質量范圍內的問題，統一提交到測試組中。對用戶反饋的問題，必須執行如下規定：
1. 對確認的缺陷，必須按需求變更、完善系統方式進行分類， OA 問題、業務問題（可細分到子模塊中），并記錄到 XX 項目缺陷 .xls 的表“最新 BUG 報告”中，并上傳到 VSS 上；
2. 測試組通知項目經理，項目經理從 VSS 上取“最新 BUG 報告”（強制要求行為），確認哪些內容是需要修改的，并在“最新 BUG 報告”上填寫修改人，解決時間；對屬 OA 問題，由項目經理整理到“ OA 缺陷提交報告”中，并與電子政務協調修改；
2.3 修改人員管理
為了避免同一個問題反復出現，源代碼在經過多人修改后，無人相信 VSS 的局面，修改過程中必須如下規定：
1. 從 VSS 上獲取用戶最新的運行環境；
2. 對修改內容必須從 VSS 上 check out ；
3. 對不執行 check out 而造成的對他人修改的影響，罰款 100 元作為項目活動經費；
4. 缺陷修改完，必須將所修改的內容 check in 到 VSS 上，制定修改清單，清單中必須說明經編譯后的類文件的路徑；
5. 從新從 VSS 上獲取最新的運行環境，根據修改清單對開發環境進行升級；
6. 將修改清單提交到測試組中；
2.4 測試組測試
1. 在修改內容的文件夾下，建立以修改日期命名的文件夾；在修改結果的文件夾下，建立以修改日期命名的文件夾；
2. 根據清單，從 VSS 上取得相應的文件 ，并將寫上當日修改日志，總的修改日志；
3. 利用 Ant 將 *.java 編譯成 *.class 文件；
4. 將 *.class ，將文件復制到 jar 包及 classess 的目錄下，將其他文件復制到相應目錄下，在修改的修改日期文件下夾應該只有一個 public.war 文件夾， jar 包， * 。 sql 文件，并將寫上當日修改日志，總的修改日志；
5. 從新從 VSS 上獲取最新的運行環境；
6. 根據修改結果步驟，在對內服務器對應的應用上進行升級；
7. 還原數據庫，測試，如有問題，返回修改人員進一步修改，重復上述步驟 ；如開發人員提供的修改清單名稱錯誤超過兩次，罰款 100 元作為項目活動經費；
8. 如無問題，則將修改結果整理到用戶升級文件中，提交給項目經理；
9. 測試組將“最新 BUG 報告”中修改確認正確的缺陷轉到已修改 BUG 報告，并將內容上傳到 VSS 上；
2.5 升級及備份
1. 項目經理收到測試組提交的用戶升級文件后，根據項目作進一步檢查；
2. 項目經理聯系用戶負責人進行升級，填寫升級記錄，并將與用戶交流的電子郵件等上傳到 VSS 上；
3. 升級后，應將用戶環境、數據庫進行備份，如情況不允許，應將對內服務器的對應的環境盡心備份，將部分內容上傳到 VSS 上；用戶環境應是不包括附件外的所有環境；
4. 過一段時間后，與用戶聯系，確認缺陷是否解決；
文章來源于領測軟件測試網 http://www.kjueaiud.com/
