缺陷級別定義和優(yōu)先級定義

1、附件一：缺陷級別定義和優(yōu)先級定義1、缺陷級別定義缺陷嚴重級別缺陷描述備注very low風(fēng)格不統(tǒng)一，包括相近流程的頁面布局相異，相問 的問題點提示信息相異，但對用戶的使用方法和使 用習(xí)慣不造成影響（需求中明確的風(fēng)格要求除外）對齊方式，包括文字對齊，貝面排列項一致UI需求建議，主要是關(guān)于頁面的布局方式和顯示格 式lowUI錯誤，包括貝面的描述顯示錯誤 （和需求中描述 的信息不一致，"明顯的錯誤），字體錯誤，以及 模板的顯示錯誤等錯誤定位及信息提示不準確，包括錯誤判斷的順序， 出錯后信息提示錯誤 （包括出現(xiàn)后臺信息），錯誤出 現(xiàn)的光標定位設(shè)計違反用戶使用習(xí)慣，影響用戶的使用方法和使 用習(xí)

2、慣部署文檔描述錯誤，增加部署難度簡單的業(yè)務(wù)功能實現(xiàn)錯誤，包括默認顯示內(nèi)容錯誤， 查詢列表初始查詢條件錯誤和查詢匹配錯誤特殊字符處理錯誤，包括："； <> 等特殊字符頁面輸入限制錯誤，包括輸入長度，輸入字符限制， 特殊輸入要求判斷，圖片上傳限制錯誤和文件上傳 限制錯誤等一般需求建議問題，主要是從用戶使用的角度出發(fā)，對 A 些需求的邊緣條件提出合理的處理方法，如，某功能模塊的查詢條件設(shè)計不合理，建議增加和刪 除相應(yīng)的查詢條件按鈕設(shè)計遺漏，包括不同條件下的顯示內(nèi)容，提交 后按鈕灰顯等Medium部署文檔錯誤，導(dǎo)致部署失敗缺陷嚴重級別缺陷描述備注業(yè)務(wù)流程對應(yīng)的功能未實現(xiàn)， 但是有

3、替代方法解決， 不影響實際的使用數(shù)據(jù)庫建庫（或升級）腳本錯誤，遺失表或字段，影響系統(tǒng)的正常運行存儲過程不能正常執(zhí)行對應(yīng)的設(shè)計功能性能和壓力測試中，在大數(shù)據(jù)量和并發(fā)壓力大時，系統(tǒng)處理緩慢、網(wǎng)絡(luò)異常及少量數(shù)據(jù)丟失（低于0.5%）等情況需求遺漏，造成功能設(shè)計上的缺陷，如，設(shè)計2和2兩個數(shù)計算得到 4的所有方法，只設(shè)計了加，并未設(shè)計乘JMS問步出錯，主要為問步了不該問步的內(nèi)容，或同步調(diào)用時少同步了部分內(nèi)容High業(yè)務(wù)流程對應(yīng)的功能未實現(xiàn)，且無替代方法貝面出現(xiàn)編譯錯誤或 404貝面性能和壓力測試中，大數(shù)據(jù)量和并發(fā)壓力大時，系統(tǒng)停止處理或大量數(shù)據(jù)丟失（大于0.5%）配置項設(shè)計錯誤，無法正常配置，或配置后，

4、測試 中出現(xiàn)與配置相關(guān)的錯誤JMS聯(lián)動出錯，包括出現(xiàn)丟包，數(shù)據(jù)傳輸失敗，數(shù) 據(jù)阻塞，處理異常等FTP傳輸失敗數(shù)據(jù)鏈接未釋放需求設(shè)計不合理，導(dǎo)致該項功能只能在有限條件下運行，如，設(shè)計了 3條路上山，但是實際只有一條 可以上與其它網(wǎng)元的接口，調(diào)用或提供錯誤（驗證到數(shù)據(jù) 庫、日志和模擬器級別）Very high正常的用戶操作，導(dǎo)致系統(tǒng)崩潰JMS、FTP異常停機，導(dǎo)致系統(tǒng)無法聯(lián)動數(shù)據(jù)庫鏈接異常中斷2、缺陷優(yōu)先級定義缺陷優(yōu)先級別缺陷描述備注low嚴重級別為very low ,使用率低嚴重級別為low,使用率低，且非主要流程使用率見需求分析Medium嚴重級別為 very low ,使用卒中或局嚴重級別為

5、low,使用率中嚴重級別為Medium,使用率為低High嚴重級別為low ,使用率局嚴重級別為Medium,使用率中嚴重級別為High ,使用率低Very high嚴重級別為Medium,使用率局嚴重級別為High ,使用率低或中嚴重級別為Very High ,使用率低Urgent嚴重級別為Very High ,使用率中或高嚴重級別為High ,使用率高注：當(dāng)缺陷被Reopen時，建議通過有效途徑通知相關(guān)人員，特別是嚴重級別為 high和 view high 。3、缺陷報告規(guī)范在項目執(zhí)行階段，發(fā)現(xiàn)的所有問題都需要提交缺陷管理庫一CQ中相應(yīng)的Project庫中，主要包括軟件需求、開發(fā)程序缺陷、

6、各種需要審核的文檔等方 面的內(nèi)容；缺陷報告的填寫，需要將問題的重現(xiàn)步驟寫清晰，建議安1、2、3.形式提交,且缺陷的相關(guān)外部測試條件需要說明詳細，缺陷標題要簡明、 扼要，不要用過于籠統(tǒng)和模糊的語言加以描述， 根據(jù)需要適當(dāng)?shù)膶⒊霈F(xiàn)的場景、 日志等信息以 附件形式提交； 對于缺陷的回歸，應(yīng)在 CQ中的Comments中注明回歸的版本號，并依據(jù)問題 的嚴重級別對回歸的結(jié)果做相應(yīng)的描述。具體的缺陷提交流程如下（針對測試人員）在缺陷的管理中， 對于新增的Rejected和Suspend的缺陷，需要定期時常整理確 認，對于未經(jīng)項目經(jīng)理、開發(fā)組長、測試組長和產(chǎn)品經(jīng)理確認的缺陷，開發(fā)人員無權(quán) Rejected/

7、Suspend，同時對于達成共識的Rejected缺陷一定要將意見寫入CQ庫中的comments,M于Suspend狀態(tài)的缺陷，建議要注明由于什么原因被刮起，在什么時間 和條件下在處理等信息。在測試任務(wù)完成以后，缺陷庫中的缺陷狀態(tài)應(yīng)只以三種狀態(tài)存在：Closed、經(jīng)過確認并達成共識的 Rejected/Suspendo4、缺陷跟蹤測試人員對其發(fā)現(xiàn)的缺陷有義務(wù)和責(zé)任進行全程的跟蹤。從缺陷的提交一直到缺陷的關(guān)閉，在這一整套的過程中，測試人員應(yīng)該一絲不茍的進行把關(guān)，不要讓錯誤輕易的從手邊遛走。要定期的向開發(fā)組通報缺陷狀態(tài)，同時及時的更新缺陷庫中缺陷的狀態(tài)。在一定的條件和時間內(nèi)，還要對以關(guān)閉的缺陷做回

8、歸測試。制定有效而可行的回歸測試時間表，盡可能的減少由回歸測試間隙產(chǎn)生的測試逃逸。5、缺陷分析對于缺陷數(shù)據(jù)庫，測試人員應(yīng)該經(jīng)常維護更新，并對缺陷的狀態(tài)，數(shù)量，分布 等狀態(tài)做統(tǒng)計分析。為開發(fā)組提供一些必要的信息。對測試人員而言，統(tǒng)計包括以下步驟：收集和分類缺陷信息。嘗試對每個缺陷的形成原因（例如，不符合規(guī)約、設(shè)計錯誤、違背標準、與客 戶通信不利等）進行追溯。（此方面的最終定位需要與相關(guān)的開發(fā)人員進行確 認。）使用Pareto規(guī)則（80%的缺陷的20%成因有可能可以追溯到），將這20% （少 數(shù)重要的）分離出來。簡單而言，Paret。原則暗示著測試發(fā)現(xiàn)的錯誤中的80%很可能起源與程序模塊中的20%。當(dāng)然，問題在于如何孤立這些有疑點的模塊并進行徹底的測試。一旦標出少數(shù)幾個重要的原因，就可以開始糾正引起缺陷