SRT-VAS-SOP-09VAS缺陷管理規(guī)范

1、 B/2版 VAS缺陷管理規(guī)范 文件編號(hào)：SRT-VAS-SOP-09VAS缺陷管理規(guī)范 B/2版文件編號(hào)： SRT-VAS-SOP-09 編 制： 胡悅瑾、陳鵑、李慧敏 審 核： 鄭曉燕 批 準(zhǔn)： Fred 受控狀態(tài)： 受控 分 發(fā) 號(hào)： 2011年06月27日 發(fā)布 2011年06月27日 實(shí)施 修 訂 頁(yè) 編號(hào)修訂內(nèi)容簡(jiǎn)述修訂日期修訂后版本號(hào)修訂人審核人批準(zhǔn)人1在用系統(tǒng)問(wèn)題反饋的BUG處理流程，專門(mén)增加流程圖表示。 增加：測(cè)試階段的分類描述。 重要的流轉(zhuǎn)環(huán)節(jié)，增加文字說(shuō)明以強(qiáng)調(diào)2006.03.15A/1欒燕飛 吳慧麗劉小琴呂凡2增加缺陷狀態(tài)，修改角色名稱2009.06.18B胡悅瑾申屠哲

2、泱鄭曉燕31、修改角色名稱；2、測(cè)試階段分類調(diào)整，升級(jí)測(cè)試適用流程更改；3、修改流程圖，調(diào)整優(yōu)化各狀態(tài)流轉(zhuǎn)過(guò)程：調(diào)整Modify、Commit、Rejected、Delay、Audit及Tracing等狀態(tài)順序；調(diào)整工程錄入TD時(shí)通知步驟的操作；調(diào)整測(cè)試驗(yàn)證Common bug的步驟順序；增加Rejected流程中，PM關(guān)閉BUG的步驟。2010.09.20B/1胡悅瑾、陳鵑鄭曉燕Fred41、增加BUG狀態(tài)定義解釋2、優(yōu)化升級(jí)測(cè)試及在用系統(tǒng)BUG流程圖：a)取消需求人員在TD中的權(quán)限b)取消PM從“Commit>Unrelease”和“Modify>Fixed”的狀態(tài)3、細(xì)化內(nèi)部

3、測(cè)試BUG流程圖和升級(jí)測(cè)試及在用系統(tǒng)BUG流程圖各環(huán)節(jié)步驟內(nèi)容，并按角色對(duì)操作步驟進(jìn)行分類標(biāo)識(shí)2011.06.16B/2胡悅瑾、陳鵑、李慧敏鄭曉燕Fred 2/9 杭州世導(dǎo)科技有限公司 B/2 VAS缺陷管理規(guī)范 文件編號(hào)：SRT-VAS-SOP-091. BUG類型 Bug Type 描述 編碼錯(cuò)誤功能實(shí)現(xiàn)過(guò)程有錯(cuò)誤。 設(shè)計(jì)錯(cuò)誤實(shí)現(xiàn)需求功能的設(shè)計(jì)有錯(cuò)誤 界面錯(cuò)誤界面美觀性、友好性、合理性。如界面提示信息，控件名稱，大小等 數(shù)據(jù)庫(kù)錯(cuò)誤所有數(shù)據(jù)庫(kù)錯(cuò)誤。包括字段定義、數(shù)據(jù)、數(shù)據(jù)庫(kù)連接錯(cuò)誤等 邏輯錯(cuò)誤包括業(yè)務(wù)邏輯、數(shù)據(jù)邏輯。如：業(yè)務(wù)之間的關(guān)聯(lián)及數(shù)據(jù)流的正確性。對(duì)輸入信息的正確性、合法性等判斷問(wèn)題。

4、功能錯(cuò)誤功能未實(shí)現(xiàn)或?qū)崿F(xiàn)錯(cuò)誤。 合理建議一些建議，如：功能、界面等各方面 組件錯(cuò)誤組件功能錯(cuò)誤，返回提示信息錯(cuò)誤，或無(wú)提示信息等問(wèn)題 性能優(yōu)化系統(tǒng)承受壓力、負(fù)載的能力，系統(tǒng)響應(yīng)速度等不理想，或影響正常操作?？刹僮餍杂脩舨僮骱?jiǎn)便性方面的錯(cuò)誤。 2. BUG狀態(tài) Bug Status 描述 Open待開(kāi)發(fā)修改的問(wèn)題 Modify開(kāi)發(fā)正在修改問(wèn)題 Commit問(wèn)題已經(jīng)處理，并已上傳配置庫(kù)，等待測(cè)試驗(yàn)證 Unrelease在測(cè)試環(huán)境下，問(wèn)題已驗(yàn)證通過(guò)，待升級(jí)后現(xiàn)場(chǎng)驗(yàn)證；或內(nèi)部因環(huán)境、資源問(wèn)題無(wú)法驗(yàn)證，需要等發(fā)布至現(xiàn)場(chǎng)后由現(xiàn)場(chǎng)工程直接驗(yàn)證 Fixed問(wèn)題已發(fā)布到現(xiàn)場(chǎng)，待現(xiàn)場(chǎng)驗(yàn)證 Closed驗(yàn)證后問(wèn)題已

5、解決 Reopen問(wèn)題仍存在，需要開(kāi)發(fā)繼續(xù)解決 Audit開(kāi)發(fā)與工程/測(cè)試有爭(zhēng)議，需要PM判斷解決；或問(wèn)題需由PM關(guān)閉 Rejected問(wèn)題被拒絕（開(kāi)發(fā)認(rèn)為不是問(wèn)題，或者錄入的問(wèn)題不符合規(guī)范，開(kāi)發(fā)無(wú)法處理問(wèn)題）Delay問(wèn)題需延遲解決（至少每個(gè)月反饋一次問(wèn)題的處理狀態(tài)） Tracing問(wèn)題需跟蹤解決（開(kāi)發(fā)/工程至少每個(gè)月反饋一次問(wèn)題的跟蹤狀態(tài)）3. BUG嚴(yán)重級(jí) Bug Severity 描述 災(zāi)難性嚴(yán)重危及系統(tǒng)正常工作。 嚴(yán)重嚴(yán)重影響系統(tǒng)要求或基本功能的實(shí)現(xiàn)。 一般基本功能已實(shí)現(xiàn)，但存在邏輯等類型的錯(cuò)誤。 微小不影響系統(tǒng)運(yùn)行及功能實(shí)現(xiàn)方面的錯(cuò)誤。有關(guān)一些建議性的BUG。 4. BUG優(yōu)先級(jí)

6、Bug Priority 描述 高立即修正。缺陷已危及系統(tǒng)的穩(wěn)定性，影響功能正常運(yùn)行 中盡快修正。缺陷不影響系統(tǒng)正常運(yùn)行，部分功能邏輯修改，或需求變更后功能更改等。 低短期內(nèi)修正。不影響系統(tǒng)運(yùn)行和功能實(shí)現(xiàn)，如：界面修改，提示信息變更等。 穩(wěn)定階段解決允許等到程序穩(wěn)定或上線以后再修正。該判斷應(yīng)由BUG審計(jì)人員定義，并得到認(rèn)可。 下一版本解決允許等到一下版本升級(jí)時(shí)解決。該判斷應(yīng)由BUG審計(jì)人員定義，并得到認(rèn)可。 5. 測(cè)試階段 Test Stage 描述 集成測(cè)試 在公司測(cè)試環(huán)境下，按集成測(cè)試策略進(jìn)行的測(cè)試。（一般為業(yè)務(wù)開(kāi)發(fā)階段，由公司組織的內(nèi)部測(cè)試）（包括需求變更、升級(jí)前相關(guān)測(cè)試：此兩類測(cè)試需要

7、在測(cè)試前明確測(cè)試范圍/策略） 確認(rèn)測(cè)試 在公司測(cè)試環(huán)境下，按確認(rèn)測(cè)試策略進(jìn)行的測(cè)試。（一般為集成測(cè)試以后，由公司組織的內(nèi)部驗(yàn)收測(cè)試） 系統(tǒng)測(cè)試 在用戶真實(shí)的系統(tǒng)環(huán)境下，進(jìn)行的測(cè)試。（一般為系統(tǒng)剛加載時(shí)，連接真實(shí)環(huán)境組織的集成測(cè)試或確認(rèn)測(cè)試） 升級(jí)測(cè)試 系統(tǒng)進(jìn)行試商用階段，系統(tǒng)實(shí)施升級(jí)后，在用戶真實(shí)的系統(tǒng)環(huán)境下，對(duì)升級(jí)功能進(jìn)行驗(yàn)證的測(cè)試。 用戶驗(yàn)收測(cè)試 在商用以前，由用戶參與的驗(yàn)收測(cè)試。 在用系統(tǒng)問(wèn)題反饋 系統(tǒng)進(jìn)入試商用、商用階段（不包括升級(jí)測(cè)試），發(fā)現(xiàn)的在運(yùn)行系統(tǒng)BUG。 6. 內(nèi)部測(cè)試階段BUG處理過(guò)程 （以下測(cè)試階段適用本流程：集成測(cè)試、確認(rèn)測(cè)試、系統(tǒng)測(cè)試、用戶驗(yàn)收測(cè)試。） 7. 升級(jí)測(cè)試

8、及在用系統(tǒng)問(wèn)題反饋BUG處理過(guò)程 （以下測(cè)試階段適用本流程：升級(jí)測(cè)試、在用系統(tǒng)問(wèn)題反饋） 8. BUG處理注意事項(xiàng) 1) 所有的BUG必須錄入TD管理： a) PM或開(kāi)發(fā)人員在受理BUG時(shí)，非緊急的問(wèn)題必須看到TD的記錄以后才受理，否則不應(yīng)受理。 b) 對(duì)于在用系統(tǒng)的問(wèn)題反饋，統(tǒng)一由系統(tǒng)維護(hù)工程師錄入、通知、跟蹤、驗(yàn)證修正結(jié)果、回復(fù)問(wèn)題反饋人員。 c) 在用系統(tǒng)問(wèn)題錄入TD的同時(shí)，若為緊急問(wèn)題，要求工程師第一時(shí)間郵件通知開(kāi)發(fā)PM、QA、QC等人。d) 需求人員、PM等反饋在用系統(tǒng)問(wèn)題時(shí)，發(fā)送系統(tǒng)維護(hù)工程師的同時(shí)要求抄收QA等人員。以便于質(zhì)量管理部跟蹤及判斷此類問(wèn)題現(xiàn)場(chǎng)系統(tǒng)維護(hù)工程師是否有及時(shí)錄

9、入TD。 e) 所有的在用系統(tǒng)問(wèn)題反饋，公司內(nèi)部測(cè)試人員需在開(kāi)發(fā)環(huán)境或現(xiàn)場(chǎng)環(huán)境上進(jìn)行通用驗(yàn)證，明確是否為通用版本的BUG，并在TD的Common Bug、CB_Validate By 、Comment中做好選擇及注釋說(shuō)明。供PM在各工程點(diǎn)業(yè)務(wù)升級(jí)時(shí)整理升級(jí)內(nèi)容所用。同時(shí)通過(guò)此方式來(lái)提高測(cè)試、測(cè)試文檔的質(zhì)量。 2) 在用系統(tǒng)反饋的問(wèn)題處理期限的約定： a) 緊急的問(wèn)題要求當(dāng)時(shí)就處理及回復(fù)。 b) 非緊急的要求PM、開(kāi)發(fā)人員在3個(gè)工作日以內(nèi)受理，受理不代表必須馬上解決，但要求在TD寫(xiě)明受理意見(jiàn)及計(jì)劃受理時(shí)間。 c) COMMIT的問(wèn)題測(cè)試人員必須在3個(gè)工作日以內(nèi)完成驗(yàn)證。3) BUG處理的注意事項(xiàng)

10、： a) 測(cè)試人員、開(kāi)發(fā)人員、系統(tǒng)維護(hù)工程師都應(yīng)及時(shí)跟蹤自己所負(fù)責(zé)的BUG，包括BUG STATUS的更新、COMMENT中的注釋、每個(gè)環(huán)節(jié)處理完成后的提醒通知。（當(dāng)BUG成批處理、驗(yàn)證時(shí)，建議統(tǒng)一郵件通知，同時(shí)建議啟用TD的郵件發(fā)送功能。） b) Delay、Tracing的BUG要求負(fù)責(zé)人每個(gè)月至少跟蹤一次，并將跟蹤意見(jiàn)填寫(xiě)于COMMENT中。 c) TEST STAGE為集成測(cè)試、確認(rèn)測(cè)試、升級(jí)測(cè)試、系統(tǒng)測(cè)試、用戶驗(yàn)收測(cè)試時(shí)，BUG的處理時(shí)限由PM把握，把握原則為不影響、不耽擱測(cè)試進(jìn)度、不影響產(chǎn)品發(fā)布期限。 d) 質(zhì)量管理部根據(jù)BUG審計(jì)制度，定期審計(jì)BUG的處理情況。對(duì)于不符合的，納入

11、QA審計(jì)。 9. TD規(guī)劃說(shuō)明： 1) TD Project規(guī)劃： a) TD Project按照業(yè)務(wù)劃分，對(duì)各工程點(diǎn)現(xiàn)場(chǎng)環(huán)境測(cè)試發(fā)現(xiàn)的BUG也統(tǒng)一按業(yè)務(wù)錄入TD，以字段“Test Area”來(lái)標(biāo)明每個(gè)BUG是在哪個(gè)測(cè)試環(huán)境下發(fā)現(xiàn)的。 b) 增加字段“Common Bug”，公司測(cè)試人員對(duì)在用系統(tǒng)問(wèn)題反饋問(wèn)題進(jìn)行驗(yàn)證后，填寫(xiě)此字段，標(biāo)識(shí)是否為通用版本的BUG，狀態(tài)包括：Yes、No、All Release。同時(shí)要求填寫(xiě)注釋說(shuō)明。 c) 每次升級(jí)以后，若通用版本中的BUG已升級(jí)處理，PM應(yīng)在COMMENT中做注釋說(shuō)明。 2) TD用戶設(shè)置： a) 分PM、測(cè)試、開(kāi)發(fā)、工程等用戶組。每個(gè)用戶組有不

12、同的權(quán)限。 3) TD常用字段表： 序號(hào) 字段名稱 說(shuō)明 1.Test Area Bug所在的地點(diǎn) 2.ACCESS Type Bug所在的模塊 3.Subiect Bug所在的子模塊 4.Status 狀態(tài) 5.Test Stage 測(cè)試階段 6.Bug Type Bug種類 7.Severity Bug的嚴(yán)重程度 8.Priority Bug的優(yōu)先級(jí) 9.Assigned To Bug的負(fù)責(zé)人 10.Detected By Bug提出人 11.Detected on Date Bug提出的日期12.Validate By Bug是誰(shuí)驗(yàn)證通過(guò)的 13.Validate Date Bug的驗(yàn)證日期 14.Agreed 驗(yàn)證人是否同意該問(wèn)題的關(guān)閉 15.Common Bug 該問(wèn)題是否是通用版本中都存在，（YES or NO） 該問(wèn)題是否已經(jīng)發(fā)布到所有地區(qū)（All Release）16.CB_ Validate By 該問(wèn)題是誰(shuí)驗(yàn)證是否為通用版本的 4) TD限制條件： a) 每個(gè)工程點(diǎn)只能看