缺陷處理流程缺陷處理流程缺陷處理流程缺陷處理流程編制僅供參考審核批準生效日期地址：電話：傳真:郵編:缺陷處理流程缺陷處理流程缺陷處理流程圖如下：缺陷處理流程圖中判定說明：是否打開缺陷：開發(fā)組長/經理查閱缺陷，確認為缺陷后，指定優(yōu)先級、估計修復日期再指派給相關開發(fā)人員；如果確認為不是缺陷的，注釋中說明理由，予以否決。處理缺陷：開發(fā)處理缺陷；如果缺陷短期內進行修復存在困難，且該缺陷對于功能實現(xiàn)影響不大的，應該給開發(fā)組長/經理說明情況，讓開發(fā)組長/經理與缺陷相關人員協(xié)調后延期處理該缺陷，并在注釋中說明理由，估計修復日期和指明計劃關閉版本。是否關閉：測試人員對回歸通過的缺陷進行關閉；否則重新打開缺陷。并在注釋中說明重新打開理由。缺陷處理流程圖中流程說明：新建缺陷：測試人員（其他人員）根據(jù)缺陷填寫說明，新建缺陷。已否決：對已否決的缺陷，最后由測試發(fā)起會議（形式可以根據(jù)情況而定），找到缺陷相關人員進行確認。如果確認為是無效的缺陷，保持“已否決”狀態(tài)，否則重新打開缺陷，并指派給相關處理人員。（重新）打開：開發(fā)人員應該處理自己手上“打開”和“重新打開”的缺陷。延期處理：開發(fā)組長/經理根據(jù)情況，對缺陷進行延期處理。已經修復：開發(fā)人員處理完缺陷后，把缺陷狀態(tài)改為“已修復”狀態(tài)。并通知測試人員進行回歸?；貧w測試：測試人員對已經修復的缺陷進行回歸。關閉缺陷：測試人員回歸測試通過后，對缺陷進行關閉。為了說明各個角色在缺陷處理流程中的職責，據(jù)測試流程所畫泳道圖如下：如果上面判定和流程中，某一方存在異議的，應及時反饋上級。然后上級根據(jù)缺陷優(yōu)先級、實際情況等，找恰當?shù)臅r間發(fā)起會議（或其他）的方式找到缺陷相關人員進行溝通、協(xié)調和處理。缺陷填寫說明BUG全部提交到QC中（指定域名的指定項目下）?！罢?，用簡單明了的語句說明白你這個BUG，相當于BUG的中心語句。詳細信息填寫規(guī)范：“分配給”，選擇這個BUG所屬模塊是屬于那個研發(fā)人員，并把問題指派給他（如果不知道，就直接提交給該負責人）?！叭毕蓊悇e”，分為5種(參考平臺共享文件《QC操作守則0922》)BUG-功能——功能上的缺陷，如按鈕沒響應，充值不成功，需求上提到的功能沒實現(xiàn)等。BUG-樣式——頁面樣式的缺陷，如界面顏色、字號、排版、圖片大小與所需求不符等。功能建議——新增加的網頁功能性建議。UI建議——對我們網頁的布局、設計、色彩、交互、按鈕、動靜態(tài)效果、字體、文本框、表情、圖片等有關視覺效果和操控便利性方面的建議。課程建議——提出的和課程的學習、播放、內容、課程制作等有關的一切建議。“缺陷主題”，選擇你提交的BUG所屬那個模塊?！绊椖俊边x擇提交問題時測試系統(tǒng)的影響版本?！皣乐爻潭取保譃?個等級1-低：①UI控件不符合界面規(guī)范。②影響UI友好性。③用戶不頻繁使用的功能易用性差。2-中：①用戶需求未實現(xiàn)（不影響用戶完成業(yè)務、用戶使用不頻繁)。注：用戶執(zhí)行刪除操作時系統(tǒng)應彈出確認提示將固定視為用戶需求，無刪除確認提示的缺陷歸屬本類。②用戶需求實現(xiàn)錯誤（不影響用戶完成業(yè)務、用戶使用不頻繁)。③用戶操作過程中系統(tǒng)出現(xiàn)異常報錯，但不影響系統(tǒng)功能的使用。④用戶使用不頻繁的功能，響應時間超出忍耐限度。注：忍耐限度根據(jù)實際軟件系統(tǒng)的特點而定。⑤UI上存在錯誤引導用戶的信息。⑥UI上信息缺失、無法顯示完整或出現(xiàn)亂碼從而給用戶造成疑惑的。⑦用戶頻繁使用的功能易用性差（操作起來麻煩、復雜、效率低）。3-高：①用戶需求未實現(xiàn)（影響到用戶完成業(yè)務）。②用戶需求實現(xiàn)錯誤（影響到用戶完成業(yè)務）。③用戶使用頻繁的功能，響應時間超出忍耐限度（不影響其他功能模塊）。4-非常高：①用戶體驗性非常差，會導致“大量”用戶投訴的。5-緊急：①后臺數(shù)據(jù)受損或丟失。②導致被測軟件響應明顯很慢（假死）、死機、非法退出、崩潰。③與“錢”沾邊的，如充值、購買課程后不能使用、不購買課程也能使用課程等。缺陷“描述”規(guī)范指明當時出這個BUG的現(xiàn)場環(huán)境，示例如下：測試服務器：瀏覽器：IE9、360瀏覽器（兼容模式）指明缺陷所屬模塊或頁面的路徑，示例如下：路徑：/forum把BUG產生的步驟一步一步寫清楚，可以用以下方法寫。（如果一句話就可以說明的BUG，就不必要分步驟了）示例：缺陷重現(xiàn)步驟：1、。。。2、。。。3、。。。4、。。。測試結果：。。。。。。期望結果：。。。。。。另外可以通過上傳截圖或附件，可以進行簡單明了的說明BUG存在，也可作為BUG證據(jù)。 注意：①關于優(yōu)化建議方面的缺陷，根據(jù)實際情況，可以簡化以上的一些步驟。②問題描述簡潔明了，條理清晰，使開發(fā)人員能據(jù)此復現(xiàn)定位問題。③缺陷描述語句，應避免出現(xiàn)錯別字，語病，歧義等。BUG驗證/關閉問題說明當BUG狀態(tài)變?yōu)椤耙研迯汀?，根?jù)回歸清單或測試申請（由開發(fā)提供）進行回歸測試，如果回歸測試后該問題被解決，則關閉該BUG，并在注釋中填寫如下信息： 驗證通過：是 驗證日期：。。。如果回歸測試驗證不通過，則“重新打開”該BUG，并在注釋中填寫明情況。如果出現(xiàn)“延期處理”、“已否決”的缺陷，首先查明原因，如果與研發(fā)不能達成一致的需要及時向上級反饋。