缺陷管理流程

1、Company Confidential Page 1Page 2Doc No:FMZ06-0006 Ver:1.1Company Confidential v 為了幫助項(xiàng)目組成員更好的理解Bug處理過程，提高工作效率,規(guī)范行為準(zhǔn)則；本文檔對各部門項(xiàng)目組成員如何實(shí)施Bug處理過程進(jìn)行了細(xì)化 Notes:如果在公司文檔中發(fā)現(xiàn)有Error，Bug，Defect，PR等字樣，請不要發(fā)生混淆， 這四個(gè)代名詞代表的都是產(chǎn)品缺陷 Page 3Doc No:FMZ06-0006 Ver:1.1Company Confidential 1.參與Bug處理過程之前，我們需要做好哪些準(zhǔn)備工作？2.缺陷狀態(tài)轉(zhuǎn)移圖3

2、.各個(gè)角色的權(quán)限及職責(zé)4. Bug處理過程中都包括哪些子過程？5.每個(gè)子過程都是如何實(shí)施的？6.附錄 Page 4Doc No:FMZ06-0006 Ver:1.1Company Confidential 1.確認(rèn)確認(rèn)PC可以訪問可以訪問Bug管理工具管理工具 BYD使用IBM公司的Clear quest工具管理bug，登陸方式分為Web方式和客戶端方式，這兩種方式都可以采用。 2.確認(rèn)擁有確認(rèn)擁有CQ登陸賬號登陸賬號 每位項(xiàng)目組成員都需要向SCM申請Clear quest工具賬號，SPDM審批即可 3.確認(rèn)確認(rèn)CQ的操作權(quán)限的操作權(quán)限 CQ為bug處理過程中涉及到的角色分配了操作權(quán)限。 如果

3、沒有權(quán)限，請向CM提出申請，CM會根據(jù)申請人的角色開放操作權(quán)限 4.識別工作過程中的相關(guān)人員以及聯(lián)系方式識別工作過程中的相關(guān)人員以及聯(lián)系方式 包括 PDM, Team leader ，F(xiàn)eature owner，Testers，test leader以及SQA 發(fā)生問題時(shí)，電話、當(dāng)面溝通是最有效的溝通方式， Email的作用只是要留證據(jù)和highlight 5.確認(rèn)參與了確認(rèn)參與了Bug管理過程培訓(xùn)管理過程培訓(xùn) QA會為項(xiàng)目組成員培訓(xùn)Bug管理過程，如果是新加入到項(xiàng)目組的工程師且 沒有參加過培訓(xùn)，請聯(lián)系QA Page 5Doc No:FMZ06-0006 Ver:1.1Company Conf

4、idential Action: SubmitAssignOpenResolveReleaseVerifyClosePostponeFailMonitorRejectDuplicateDiscardReopenRe-VerifyRe-rejectRe-duplicateNotes:All actions which are marked by pink color are done by ST.Page 6Doc No:FMZ06-0006 Ver:1.1Company Confidential 角色和職責(zé)角色和職責(zé) RolesSPDMQATest leader &TestersSW

5、TLOwnerSubmitterSubmitAssignPostponeOpenReopenFailResolveReleaseRejectDuplicateMonitorVerifyCloseDiscardRe-rejectRe-duplicateRe-verifyActionsPage 7Doc No:FMZ06-0006 Ver:1.1Company Confidential v提交提交Bug準(zhǔn)備工作（準(zhǔn)備工作（Submit）1.測試人員發(fā)現(xiàn)Bug后，要依照本部門Bug描述模板，將Bug信息填寫完整，選用本部門常用詞進(jìn)行描述，語言盡量簡潔，清晰，完整，不要出現(xiàn)生僻詞； （Bug描述模板是

6、可以根據(jù)項(xiàng)目實(shí)際需求進(jìn)行裁剪的）2.測試組長每天要檢查測試人員提交的Bug list，確認(rèn)每個(gè)Bug的信息是否填寫完整，Bug描述是否清晰，Bug是否有效等3.經(jīng)過測試組長確認(rèn)的Bug，測試人員才可以提交到Clear quest工具中4.Bug的提交要在一個(gè)工作日內(nèi)完成Page 8Doc No:FMZ06-0006 Ver:1.1Company Confidential vCQ中提交中提交Bug的操作過程的操作過程1.測試人員提交Bug時(shí)，需要先選擇Owner department，確認(rèn)是SW的問題，即選SW，HW即選HW，其他同理2.再根據(jù)項(xiàng)目名稱，選擇Project3.其他字段可以不分順序

7、進(jìn)行填寫，標(biāo)識紅色字段為必填項(xiàng)，如果有必填項(xiàng)為空，是不能提交當(dāng)前記錄的4.提交Bug時(shí)填寫的字段注釋如下：Page 9Doc No:FMZ06-0006 Ver:1.1Company Confidential 3. Headline: Bug的概要描述，測試人員要使用能突出Bug失效現(xiàn)象的詞語， 如Freeze，Halt，Restart，function failure等，4.Owner: 選擇PDM或者feature owner.5.Owner_Department: 選擇Bug owner所屬部門,必須首先選擇此字段6.Submitter:系統(tǒng)自動生成為提交人員7.Supplier:測試部

8、門可選，主要是研發(fā)部門使用， 三方bug時(shí)，選擇三方名稱；不是，則空；8.Priority: 解決Bug的優(yōu)先級別（1,2,3,4），具體定義參考附錄“Priority definition”9.Severity:Bug 的嚴(yán)重程度（S,A,B,C,D），具體定義參考附錄“Severity definition”10.SWVersion:發(fā)生Bug的軟件版本11.Project: 項(xiàng)目名稱1. Cust_ID:自動生成 (項(xiàng)目名稱簡寫_P+自定義的連續(xù)ID)2. State: Bug當(dāng)前處理狀態(tài)，參考Bug狀態(tài)遷移圖Page 10Doc No:FMZ06-0006 Ver:1.1Company

9、 Confidential 12.SW_Sub_Version: 軟件版本的補(bǔ)充，用于具體表明同一個(gè)版本不同的軟件(比如不同運(yùn)營商)，同軟件版本組合在一起進(jìn)行使用(內(nèi)容是運(yùn)營商三個(gè)字母的縮寫)13.Platform: 與Project關(guān)聯(lián)，選擇project后自動生成14.HWVersion:發(fā)生Bug的硬件版本15.FoundMethod：Bug的發(fā)現(xiàn)途徑，具體定義參考附錄“FoundMethod definition”16.MEVersion: SW測試部門和SW部門可選，主要是PV,HW&ME部門使用； 發(fā)生Bug的結(jié)構(gòu)版本17.Repeatable：Bug發(fā)生頻率，具體定義參考

10、附錄“Frequency definition”18.ModuleName:發(fā)生Bug的模塊19.DueDate:研發(fā)部門使用；標(biāo)識計(jì)劃解決Bug的日期 20.SubModule:測試部門可選，發(fā)生 Bug的子模塊，與Module關(guān)聯(lián)Page 11Doc No:FMZ06-0006 Ver:1.1Company Confidential 21. Tested_Times:測試次數(shù)/樣機(jī)數(shù)量22. Failed_Times:失效次數(shù)/樣機(jī)數(shù)量23. FailRatio:失效比率（自動生成）24. Mobile_No：發(fā)生Bug的手機(jī)編號（測試手機(jī)的唯一標(biāo)識，不是測試卡的號碼）25.Custome

11、r Defect ID：BTC代替客戶提交Bug時(shí)必填，記錄客戶的Bug ID26. Testcase_ID：提交時(shí)根據(jù)測試類型可選Mark Y , need fill in when submit and verify. If mark N, can fill in optionally when submitand verify.If found method is certification test, Testers need to mark certification type in “headline” field Page 12Doc No:FMZ06-0006 Ver:1.1C

12、ompany Confidential 27. Company：提交Bug人員所在公司(如果是客戶要求BTC提交,則填寫客戶公司名稱)30. Description：Bug的具體描述，包括前題條件，發(fā)生步驟，實(shí)際結(jié)果，預(yù)期結(jié)果，測試人員的聯(lián)系方式等重要信息31. Attachment：測試人員可以將Bug log信息，測試圖片，鈴聲等信息作為附件上 傳到CQ中，作為研發(fā)人員復(fù)現(xiàn)、分析Bug的參考28.Bug type：發(fā)現(xiàn)bug類型(Degrade/New/Missed)29.PeerReview：代碼評審的ID，開發(fā)必填Page 13Doc No:FMZ06-0006 Ver:1.1Comp

13、any Confidential v 分配分配Bug操作指南（操作指南（Assign）SPDM需要每天查詢owner為自己的Bug，確認(rèn)bug是否屬于本部門。如果是，根據(jù)Bug的實(shí)際描述分配給TL/Feature owner，重新定義Bug解決優(yōu)先級別以及計(jì)劃解決Bug的due date；如果不是，需要和HPDM溝通確認(rèn)后再修改owner department為HW/ME分配任務(wù)要在一個(gè)工作日內(nèi)完成，QA會抽查沒有及時(shí)被分配的bug并進(jìn)行highlightSW部門要定義每個(gè)feature的owner，便于PDM識別feature owner以及供測試人員溝通bug使用TL/Feature ow

14、ner確認(rèn)是組/feature內(nèi)的bug后，通過modify Owner字段，最后將bug分配給實(shí)際的責(zé)任人（Real owner）分配過程中如出現(xiàn)轉(zhuǎn)Bug、Reject Bug，Duplicate Bug的需求，申請人首先要和關(guān)聯(lián)人員進(jìn)行充分溝通，達(dá)成一致后發(fā)出正式郵件向項(xiàng)目管理層申請并將郵件內(nèi)容通過modify notes字段填寫到CQ中 1）溝通）溝通Feature/Team間轉(zhuǎn)bug：Feature owner之間的溝通Reject bug：Owner、testers、requirement、SPDM,TL之間的溝通Duplicate bug：Owner, testers, SPDM,

15、TL之間的溝通Page 14Doc No:FMZ06-0006 Ver:1.1Company Confidential vCQ中中assign Bug的操作過程的操作過程1.PDM在assign bug時(shí)，CQ會自動清空owner、priority字段，需要PDM重新定義2.如果PDM判定此記錄為三方bug，則需要在supplier字段中選擇三方名稱（PDM根據(jù)項(xiàng)目三方列表，可以向CM提出添加supplier list到CQ中）3.Due date的選擇需要符合release plan4.如果是交叉bug，測試人員識別的module name不夠準(zhǔn)確，PDM是可以在 assign的時(shí)候進(jìn)行修改

16、的5.需要必填carrier字段，標(biāo)識Bug在哪些版本上存在(通常用于指明不同的運(yùn)營商) Page 15Doc No:FMZ06-0006 Ver:1.1Company Confidential v 分析分析Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Open）Owner一定要在發(fā)生bug的版本上復(fù)現(xiàn)bug，而且要嚴(yán)格按照bug的發(fā)現(xiàn)步驟和環(huán)境 對于bug描述不清或不完整，需要修改的情形，owner和測試溝通清楚，由testers或者test leader進(jìn)行修改 有些bug會有附件，一定要查看attachment處是否有附件，供分析bug使用在分析的過程中，要將所有的分析結(jié)果通過modify notes字

17、段添加到CQ中，包括：做了哪些驗(yàn)證Debug過程、方式和結(jié)果原因分析如果確認(rèn)bug是自己的，需要在三天之內(nèi)open bug，同時(shí)需要將最初始的分析結(jié)果（root cause）記錄在analysis 字段中6. Owner要有時(shí)間觀念：PDM預(yù)先給定一個(gè)Due Date 如果有問題，可以反饋回來；并給出合理的理由 如果沒有問題，就按照這個(gè)時(shí)間計(jì)劃發(fā)布版本； 任何delay都是不允許的；即使是他人問題導(dǎo)致，也要在due date到來前和PDM 溝通原因，才可被接受7. PDM對于Owner提出的要求要做出積極響應(yīng)，實(shí)時(shí)關(guān)注bug的解決情況， 如果發(fā)現(xiàn)會有delay，要及時(shí)和owner溝通，采取措施

18、幫助owner盡量避免發(fā)生delayPage 16Doc No:FMZ06-0006 Ver:1.1Company Confidential 8.Owner必須保證填寫的分析是有效的。不該出現(xiàn)的分析如下：不該出現(xiàn)的分析如下：v在我的板子/手機(jī)上沒有發(fā)現(xiàn)Action: 用和測試工程師一樣的環(huán)境復(fù)現(xiàn)v新的版本中這個(gè)問題沒了Action: 查到root causev不是我的問題Action: 查到是誰的問題，并和他確認(rèn)v我覺得應(yīng)該這樣做（或者：XXX要求我這么做）Action: 需求都以DOORS中baselined的需求為準(zhǔn)，有變化需走需求變更v三天之內(nèi)沒有找出原因，填寫“正在分析中”，“空格”等

19、無效信息Action: 向架構(gòu)和相關(guān)模塊負(fù)責(zé)人申請會審，尋求技術(shù)幫助，找到root cause后再open bugPage 17Doc No:FMZ06-0006 Ver:1.1Company Confidential v CQ中中Open Bug的操作過程的操作過程1.Owner必填analysis字段：Bug的分析描述，包括Bug解決分析、驗(yàn)證結(jié)果分析以及一些備注信息2.必填carrier字段，owner根據(jù)對bug的分析，可以修改PDM給出的carrier list3.如果是三方bug， 則需要在supplier字段中選擇三方名稱Page 18Doc No:FMZ06-0006 Ver:

20、1.1Company Confidential v Reject Bug的準(zhǔn)備工作的準(zhǔn)備工作1.Owner要明確reject的原則，才可以向PDM或TL申請reject bug 1）Bug描述的現(xiàn)象能夠重現(xiàn) 2）經(jīng)確認(rèn)（確認(rèn)方式：Submitter，UI, requirement owner，SPDM，TL一起確認(rèn)）存在以下問題：該現(xiàn)象屬于符合規(guī)范、標(biāo)準(zhǔn)或行業(yè)慣例正?，F(xiàn)象測試條件本身存在問題該bug不屬于合理范圍內(nèi)的修改，比如baselined的需求定義以外的一些額外的功能等；3）必須征求submitter的意見，把root cause說清楚，得到認(rèn)同即可向PDM或TL提出申請2.在rejec

21、t過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁Page 19Doc No:FMZ06-0006 Ver:1.1Company Confidential v CQ中中reject Bug的操作過程的操作過程1. PDM或TL必填analysis字段，填寫經(jīng)大家同意的reject理由,將bug置為rejected狀態(tài)Page 20Doc No:FMZ06-0006 Ver:1.1Company Confidential v Duplicate Bug的準(zhǔn)備工作的準(zhǔn)備工作1.Owner要明確duplicate的原則，才可以向PDM或TL申請duplicate bug 1）Bug描述的現(xiàn)象能夠重現(xiàn) 2）必須是

22、兩個(gè)或多個(gè)bugs的操作路徑和表現(xiàn)結(jié)果均一致。 保留先提交的bug，將后提交的一個(gè)或多個(gè)bugs置為duplicated， 并將先提交的bug Cust ID號記錄在后面被duplicated掉的bugs上何謂“操作路徑”一致？兩個(gè)或多個(gè)bugs的所有操作步驟均一致，錯(cuò)誤表現(xiàn)也一致兩個(gè)或多個(gè)bugs入口不一樣，但后面的操作步驟和表現(xiàn)結(jié)果均一致，比如：Bug1：步驟1，步驟2，步驟3，步驟4，步驟5Bug2：步驟1，步驟2，步驟3，步驟4，步驟5這兩個(gè)bugs前2步不同，但錯(cuò)誤發(fā)生在步驟3/4/5中，而且錯(cuò)誤表現(xiàn)也一樣，我們可以認(rèn)為“操作路徑” 一致3）對bugs之間的“操作路徑”和“表現(xiàn)結(jié)果”

23、一致的認(rèn)定，必須征求submitter的意見，把root cause說清楚，得到認(rèn)同即可向PDM或TL提出申請Page 21Doc No:FMZ06-0006 Ver:1.1Company Confidential 在duplicate過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁v CQ中中duplicate Bug的操作過程的操作過程 Duplicate bug時(shí)，PDM或TL可以根據(jù)保留的bug carrier信息，填寫被duplicated掉的bug carrier字段 填寫保留的Bug Cust ID到Duplicate_ID字段中 將duplicate的原因記錄在notes字段中Page 2

24、2Doc No:FMZ06-0006 Ver:1.1Company Confidential v 延遲解決延遲解決Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Postpone）1.Owner要明確postpone的原則，才可以向PDM申請postpone bug 1）經(jīng)過分析（open）后，發(fā)現(xiàn)當(dāng)前不具備解決條件的缺陷，例如:平臺限制軟件架構(gòu)限制第三方限制Bug不會對用戶使用產(chǎn)生負(fù)作用，但Bug的修改會帶來負(fù)面的風(fēng)險(xiǎn)和更多的問題 2）一個(gè)bug被fail多次，PDM評估后認(rèn)可bug不會對項(xiàng)目產(chǎn)生block2.要發(fā)正式郵件向PDM申請，抄送給Test leader，Submitter，TL，SQA3.郵件的收

25、件人以及抄送人全部同意后，PDM才可postpone bug4.QA會抽查postponed bugs，如果發(fā)現(xiàn)理由不合理，可以將bug 重新打開v CQ中中postpone Bug的操作過程的操作過程1.PDM要將合理的postpone 理由填寫到notes字段中Page 23Doc No:FMZ06-0006 Ver:1.1Company Confidential v 監(jiān)控監(jiān)控Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Monitor）1. 對于復(fù)現(xiàn)率低的bug，如果發(fā)生以下情況，Owner可以向PDM或TL申請monitor bug； 1）分析（open）bug時(shí)，Owner無法復(fù)現(xiàn)bug 2）Res

26、olve bug時(shí)，Owner無法確定bug是否在分支上被解決了 3）Release bug時(shí)，Owner無法確定bug是否在集成版本上被解決了2. 在申請之前： 1）Owner必須將試圖復(fù)現(xiàn)bug的操作，重現(xiàn)次數(shù)等信息記錄在notes字段 中；在重現(xiàn)bug的時(shí)候一定要在發(fā)現(xiàn)bug的版本上驗(yàn)證：在當(dāng)前版本沒有發(fā)現(xiàn)bug，不代表該bug不存在在模擬器上驗(yàn)證，無效2）對于not must的bug，需要測試100次以上 3）如果這個(gè)Bug是很難復(fù)現(xiàn)，但測試已經(jīng)提供了必要的Log文件，則測試 不負(fù)責(zé)復(fù)現(xiàn) ；如果owner經(jīng)過多次驗(yàn)證仍然不能復(fù)現(xiàn)的bug，可以向 PDM申請專項(xiàng)測試 4）專項(xiàng)測試的次數(shù)定

27、義原則為：申請測試次數(shù)為50的倍數(shù)且不少于Fail_total值的分母 5）如果成功復(fù)現(xiàn)bug，測試人員需要及時(shí)通知owner并試圖抓取trace信息以便分析解決 Page 24Doc No:FMZ06-0006 Ver:1.1Company Confidential 3. Owner需要發(fā)正式郵件向PDM或TL申請，并抄送給Test leader，Submitter，SQA4. 郵件的收件人以及抄送人全部同意后，PDM或TL才可monitor bug 對于復(fù)現(xiàn)率低的bug，在verify bug時(shí)，測試人員無法確定bug是否在正式發(fā)布的版本 上被解決了，也可以monitor bug 所有被m

28、onitor的bug，需要由測試人員在后續(xù)的三個(gè)版本中（不包括當(dāng)前版本）進(jìn)行驗(yàn)證；成功復(fù)現(xiàn)則fail掉 bug；如果沒有復(fù)現(xiàn)，測試leader在與SPDM確認(rèn)后，可以將bug verify 掉；如果有客戶，需要在verify之前得到客戶的確認(rèn)監(jiān)控過程中，測試人員需要通過modify的方式，將每個(gè)版本的復(fù)現(xiàn)結(jié)果記錄在CQ(包括測試的版本以及測試的次數(shù)，復(fù)現(xiàn)的次數(shù)等等）v CQ中中monitor Bug的操作過程的操作過程1.如果bug在沒有release之前被monitor，PDM需要必填Released SW version和 Released HW version字段，給測試人員在后續(xù)三個(gè)版

29、本中復(fù)現(xiàn)bug提供參考版本2.PDM需要將monitor的理由必填到notes字段中Page 25Doc No:FMZ06-0006 Ver:1.1Company Confidential v 重新打開重新打開Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Reopen）1.當(dāng)測試人員不同意reject或duplicate bug，可以在得到研發(fā)人員同意后reopen bug2.Owner在release時(shí)，發(fā)現(xiàn)bug仍然存在，需要將bug reopen3.當(dāng)延遲解決的bug具備解決條件后，Owner，PDM，TL都可以將bug reopen4.當(dāng)QA認(rèn)為postpone bug原因不合理時(shí)，可以將bug re

30、openv CQ中中reopen Bug的操作過程的操作過程1.可以修改可以修改carrier字段字段2.將將reopen的原因填寫在的原因填寫在analysis字段字段中中Page 26Doc No:FMZ06-0006 Ver:1.1Company Confidential v 解決解決Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Resolve） 在對Bug產(chǎn)生的原因進(jìn)行細(xì)致分析后，Owner需要確認(rèn)bug 初步的解決方案 在分支上實(shí)施解決方案后，進(jìn)行單元測試以及代碼評審活動。 單元測試通過后，需要在peer review 工具中提交申請并組織正式評審會議 1）評審?fù)ㄟ^后，owner將要合并的分支提交給

31、軟件集成工程師（SW build engineer），將狀態(tài)設(shè)置為resolved 并填寫通過驗(yàn)證的解決方案； 2）評審沒有通過，owner需要修改評審issue直到評審?fù)ㄟ^為止v CQ中中resolve Bug的操作過程的操作過程1.Owner在resolve bug時(shí)，可以修改carrier字段的信息2.將通過驗(yàn)證的解決方案（solution）記錄在analysis字段中3.選擇Bug發(fā)生原因分類，填寫在Defect_Cause_Analysis字段中，具體分類參考“Defect Cause Analysis4.還需要選擇對應(yīng)的peer review ID。Peer Review ID字段

32、添加了勾選框; 1）當(dāng)該框被勾上，列出已被Verify或Close的Peer Review ID list； 2）未勾上，則反列出Submitted、Failed或Resolved狀態(tài)的Peer Review ID listPage 27Doc No:FMZ06-0006 Ver:1.1Company Confidential v 發(fā)布發(fā)布Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Release） 軟件集成工程師（SW build engineer）將提交的分支進(jìn)行集成，并在軟件內(nèi)部發(fā)布此版本 Owner要在發(fā)布的軟件上進(jìn)行驗(yàn)證 1）如果驗(yàn)證通過，在軟件集成工程師提交的軟件發(fā)布計(jì)劃確認(rèn)單上進(jìn)行確認(rèn)，在確認(rèn)

33、后的一個(gè)工作日內(nèi)將bug release并填寫發(fā)布版本號 2）如果驗(yàn)證發(fā)現(xiàn)Bug仍然存在，owner需要將bug重新打開（reopen），再次分析bug并找出新的solution3.驗(yàn)證及release工作需要在版本發(fā)布后的一個(gè)工作日內(nèi)完成v CQ中中release Bug的操作過程的操作過程1.Owner在release bug時(shí)，可以修改carrier和Defect_Cause_Analysis字段的信息2.將通過集成驗(yàn)證的最終解決方案記錄在analysis字段中3.將通過集成驗(yàn)證的SW和HW版本號記錄在Released SW version和 Released HW version字段中

34、4.將通過集成驗(yàn)證的分支填寫在SW_Formal_Branch字段中Page 28Doc No:FMZ06-0006 Ver:1.1Company Confidential v 驗(yàn)證驗(yàn)證Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Verify）1.驗(yàn)證驗(yàn)證released bug 1）測試人員（一般是submitter）要在開發(fā)人員填寫的SW和HW發(fā)布版本號 上對released bug進(jìn)行驗(yàn)證 2）如果發(fā)布版本號不是最新版本，測試人員需要在最新的版本上進(jìn)行驗(yàn)證2.驗(yàn)證驗(yàn)證rejected & duplicated bug 1）在verify rejected或duplicated bug時(shí)，需要檢

35、查reject和duplicate的理由是否和溝通的結(jié)果一致，duplicate ID是否填寫正確，確認(rèn)沒有問題后再verify bug 2）如果之前研發(fā)人員沒有和測試人員溝通，當(dāng)測試人員不認(rèn)同bug的處理時(shí)，可以將bug重新reopenNotes：Released bugs的驗(yàn)證工作需要在版本正式發(fā)布后的一個(gè)工作日內(nèi)完成Page 29Doc No:FMZ06-0006 Ver:1.1Company Confidential v CQ中中verify Bug的操作過程的操作過程1.在分析中填寫驗(yàn)證概率、驗(yàn)證人、驗(yàn)證結(jié)果2.對某些需要驗(yàn)證報(bào)告的bug，則需要提交驗(yàn)證報(bào)告作為附件。3.如果驗(yàn)證通過

36、，verify bug 并填寫SW和HW驗(yàn)證版本號4.如果驗(yàn)證不通過，bug仍然存在，測試人員需要和owner溝通確認(rèn)后，再將bug fail掉Page 30Doc No:FMZ06-0006 Ver:1.1Company Confidential v Fail Bug的準(zhǔn)備工作的準(zhǔn)備工作1.測試人員驗(yàn)證released bug時(shí)，發(fā)現(xiàn)bug仍然存在，需要將bug fail掉2.QA抽查verify掉的bug時(shí)，發(fā)現(xiàn)bug仍然存在，需要將bug fail掉3.被Monitor掉的bug，測試人員在監(jiān)控三個(gè)版本的過程中，如果復(fù)現(xiàn)成功，需要將bug fail掉4.在fail之前都要和研發(fā)人員溝通確

37、認(rèn)后再執(zhí)行操作v CQ中中fail Bug的操作過程的操作過程1.可以修改carrier字段2.測試人員或QA需要在analysis字段中填寫驗(yàn)證不成功的原因說明（包括驗(yàn)證概率、驗(yàn)證人、驗(yàn)證結(jié)果、驗(yàn)證不成功具體原因描述）Page 31Doc No:FMZ06-0006 Ver:1.1Company Confidential v 關(guān)閉關(guān)閉/丟棄丟棄Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Closed/Discard）QA要對verify掉的bug進(jìn)行關(guān)閉和丟棄。 1)當(dāng)close type為released，則close bug; 2)當(dāng)close type為rejected和duplicated，則di

38、scard bug;流程方面，關(guān)閉和丟棄bug時(shí)，QA需要檢查Bug信息是否填寫完整，信息是否有效？是否符合流程定義？產(chǎn)品方面：對于有效bug，QA還需要抽查verify掉的bug，是否真的被解決了；如果沒有，可以fail 掉bug；關(guān)閉/丟棄bug的工作需要在bug被verify掉后的一個(gè)工作日內(nèi)完成v CQ中中close/discard Bug的操作過程的操作過程1.直接在CQ中執(zhí)行close/discard操作即可Page 32Doc No:FMZ06-0006 Ver:1.1Company Confidential SeverityDefinition of SeverityS-Fat

39、alSeverity issue, e.g. .hurt body or lost customer info.The Software system crash and cant resume by oneselfA-SeriousCustomer data lost but can resumeSW system crash but can resumeAffect customer operation badly like the often use function have high failure rate reset, freeze, mess up, confusion scr

40、een, function failureThe function problem can not resume that will affect phone used The serious ME problem that maybe affect used function Most customers will return itB-ModerateCustomer often use function have low failure rate reset, freeze, mess up, confusion screen, function failureIt cant accor

41、d with performance requirementThe function problem can resume that will affect phone used The appearance of ME part is not good but it wont affect phone used Critical customer will return itC-MinorSystem function target implement basically, SW function accord with requirement basically, but have a l

42、ittle difference with UI SpecThe ME part disabled but can resume and slight appearance problems The problems that Most customers could tolerance or can be ignoreD-SuggestionInterface display accords with requests but the consumer use uncomfortably or use interface unkindly. Page 33Doc No:FMZ06-0006

43、Ver:1.1Company Confidential PriorityDefinition of Priority1-Resolve Immediately Resolve defect on current. If defect is not resolved, release is not acceptable.2-Give High Attention Resolve defect as soon as possible. Must be solved before next release.3- Normal QueueDefect needs to be resolved within 2 next releases.4-Low PriorityDefect needs to be resolved within 3 next releases.Page