缺陷管理流程課件

Bug處理過程實施細(xì)則Bug處理過程實施細(xì)則目的為了幫助項目組成員更好的理解Bug處理過程，提高工作效率,規(guī)范行為準(zhǔn)則；本文檔對各部門項目組成員如何實施Bug處理過程進(jìn)行了細(xì)化

Notes:如果在公司文檔中發(fā)現(xiàn)有Error，Bug，Defect，PR等字樣，請不要發(fā)生混淆，這四個代名詞代表的都是產(chǎn)品缺陷

目的為了幫助項目組成員更好的理解Bug處理過程，提高工作效率內(nèi)容1.參與Bug處理過程之前，我們需要做好哪些準(zhǔn)備工作？2.缺陷狀態(tài)轉(zhuǎn)移圖3.各個角色的權(quán)限及職責(zé)4.Bug處理過程中都包括哪些子過程？5.每個子過程都是如何實施的？6.附錄

內(nèi)容參與Bug處理過程準(zhǔn)備工作1.確認(rèn)PC可以訪問Bug管理工具

BYD使用IBM公司的Clearquest工具管理bug，登陸方式分為Web方式和客戶端方式，這兩種方式都可以采用。2.確認(rèn)擁有CQ登陸賬號每位項目組成員都需要向SCM申請Clearquest工具賬號，SPDM審批即可

3.確認(rèn)CQ的操作權(quán)限

CQ為bug處理過程中涉及到的角色分配了操作權(quán)限。如果沒有權(quán)限，請向CM提出申請，CM會根據(jù)申請人的角色開放操作權(quán)限

4.識別工作過程中的相關(guān)人員以及聯(lián)系方式包括PDM,Teamleader，F(xiàn)eatureowner，Testers，testleader以及SQA

發(fā)生問題時，電話、當(dāng)面溝通是最有效的溝通方式，

Email的作用只是要留證據(jù)和highlight5.確認(rèn)參與了Bug管理過程培訓(xùn)

QA會為項目組成員培訓(xùn)Bug管理過程，如果是新加入到項目組的工程師且沒有參加過培訓(xùn)，請聯(lián)系QA

參與Bug處理過程準(zhǔn)備工作缺陷跟蹤流程—狀態(tài)轉(zhuǎn)移圖Action:

SubmitAssignOpenResolveReleaseVerifyClosePostponeFailMonitorRejectDuplicateDiscardReopenRe-VerifyRe-rejectRe-duplicateNotes:AllactionswhicharemarkedbypinkcoloraredonebyST.缺陷跟蹤流程—狀態(tài)轉(zhuǎn)移圖Action:角色和職責(zé)RolesSPDMQATestleader&TestersSWTLOwnerSubmitterSubmitüüüüüüAssignü

ü

Postponeü

Open

ü

ReopenüüüüüFail

üü

üResolve

ü

Release

ü

Rejectü

ü

Duplicateü

ü

Monitorü

üü

üVerify

ü

üClose

ü

Discard

ü

Re-reject

ü

Re-duplicate

ü

Re-verify

ü

Actions角色和職責(zé)RolesSPDMQATestleadBug處理過程實施基本原則提交Bug準(zhǔn)備工作（Submit）1.測試人員發(fā)現(xiàn)Bug后，要依照本部門Bug描述模板，將Bug信息填寫完整，選用本部門常用詞進(jìn)行描述，語言盡量簡潔，清晰，完整，不要出現(xiàn)生僻詞；

（Bug描述模板是可以根據(jù)項目實際需求進(jìn)行裁剪的）2.測試組長每天要檢查測試人員提交的Buglist，確認(rèn)每個Bug的信息是否填寫完整，Bug描述是否清晰，Bug是否有效等3.經(jīng)過測試組長確認(rèn)的Bug，測試人員才可以提交到Clearquest工具中4.Bug的提交要在一個工作日內(nèi)完成Bug處理過程實施基本原則提交Bug準(zhǔn)備工作（Submit）Bug處理過程實施基本原則CQ中提交Bug的操作過程1.測試人員提交Bug時，需要先選擇Ownerdepartment，確認(rèn)是SW的問題，即選SW，HW即選HW，其他同理2.再根據(jù)項目名稱，選擇Project3.其他字段可以不分順序進(jìn)行填寫，標(biāo)識紅色字段為必填項，如果有必填項為空，是不能提交當(dāng)前記錄的4.提交Bug時填寫的字段注釋如下：Bug處理過程實施基本原則Bug處理過程實施基本原則3.Headline:Bug的概要描述，測試人員要使用能突出Bug失效現(xiàn)象的詞語，如Freeze，Halt，Restart，functionfailure等，4.Owner:

選擇PDM或者featureowner.5.Owner_Department:選擇Bugowner所屬部門,必須首先選擇此字段6.Submitter:系統(tǒng)自動生成為提交人員7.Supplier:測試部門可選，主要是研發(fā)部門使用，三方bug時，選擇三方名稱；不是，則空；8.Priority:解決Bug的優(yōu)先級別（1,2,3,4），具體定義參考附錄“Prioritydefinition”9.Severity:Bug的嚴(yán)重程度（S,A,B,C,D），具體定義參考附錄“Severitydefinition”10.SWVersion:發(fā)生Bug的軟件版本11.Project:項目名稱1.Cust_ID:自動生成(項目名稱簡寫_P+自定義的連續(xù)ID)2.State:Bug當(dāng)前處理狀態(tài)，參考Bug狀態(tài)遷移圖Bug處理過程實施基本原則3.Headline:BugBug處理過程實施基本原則12.SW_Sub_Version:

軟件版本的補充，用于具體表明同一個版本不同的軟件(比如不同運營商)，同軟件版本組合在一起進(jìn)行使用(內(nèi)容是運營商三個字母的縮寫)13.Platform:與Project關(guān)聯(lián)，選擇project后自動生成14.HWVersion:發(fā)生Bug的硬件版本15.FoundMethod：Bug的發(fā)現(xiàn)途徑，具體定義參考附錄“FoundMethoddefinition”16.MEVersion:SW測試部門和SW部門可選，主要是PV,HW&ME部門使用；發(fā)生Bug的結(jié)構(gòu)版本17.Repeatable：Bug發(fā)生頻率，具體定義參考附錄“Frequencydefinition”18.ModuleName:發(fā)生Bug的模塊19.DueDate:研發(fā)部門使用；標(biāo)識計劃解決Bug的日期

20.SubModule:測試部門可選，發(fā)生Bug的子模塊，與Module關(guān)聯(lián)Bug處理過程實施基本原則12.SW_Sub_VersionBug處理過程實施基本原則21.Tested_Times:測試次數(shù)/樣機數(shù)量22.Failed_Times:失效次數(shù)/樣機數(shù)量23.FailRatio:失效比率（自動生成）24.Mobile_No：發(fā)生Bug的手機編號（測試手機的唯一標(biāo)識，不是測試卡的號碼）25.CustomerDefectID：BTC代替客戶提交Bug時必填，記錄客戶的BugID26.Testcase_ID：提交時根據(jù)測試類型可選Mark"Y",needfillinwhensubmitandverify.Ifmark"N",canfillinoptionallywhensubmitandverify.Iffoundmethodiscertificationtest,Testersneedtomarkcertificationtypein“headline”field

Bug處理過程實施基本原則21.Tested_Times:Bug處理過程實施基本原則27.Company：提交Bug人員所在公司(如果是客戶要求BTC提交,則填寫客戶公司名稱)30.Description：Bug的具體描述，包括前題條件，發(fā)生步驟，實際結(jié)果，預(yù)期結(jié)果，測試人員的聯(lián)系方式等重要信息31.Attachment：測試人員可以將Buglog信息，測試圖片，鈴聲等信息作為附件上傳到CQ中，作為研發(fā)人員復(fù)現(xiàn)、分析Bug的參考28.Bugtype：發(fā)現(xiàn)bug類型(Degrade/New/Missed)29.PeerReview：代碼評審的ID，開發(fā)必填Bug處理過程實施基本原則27.Company：提交BuBug處理過程實施基本原則分配Bug操作指南（Assign）SPDM需要每天查詢owner為自己的Bug，確認(rèn)bug是否屬于本部門。如果是，根據(jù)Bug的實際描述分配給TL/Featureowner，重新定義Bug解決優(yōu)先級別以及計劃解決Bug的duedate；如果不是，需要和HPDM溝通確認(rèn)后再修改ownerdepartment為HW/ME分配任務(wù)要在一個工作日內(nèi)完成，QA會抽查沒有及時被分配的bug并進(jìn)行highlightSW部門要定義每個feature的owner，便于PDM識別featureowner以及供測試人員溝通bug使用TL/Featureowner確認(rèn)是組/feature內(nèi)的bug后，通過modifyOwner字段，最后將bug分配給實際的責(zé)任人（Realowner）分配過程中如出現(xiàn)轉(zhuǎn)Bug、RejectBug，DuplicateBug的需求，申請人首先要和關(guān)聯(lián)人員進(jìn)行充分溝通，達(dá)成一致后發(fā)出正式郵件向項目管理層申請并將郵件內(nèi)容通過modifynotes字段填寫到CQ中

1）溝通Feature/Team間轉(zhuǎn)bug：Featureowner之間的溝通Rejectbug：Owner、testers、requirement、SPDM,TL之間的溝通Duplicatebug：Owner,testers,SPDM,TL之間的溝通Bug處理過程實施基本原則分配Bug操作指南（Assign）Bug處理過程實施基本原則CQ中assignBug的操作過程1.PDM在assignbug時，CQ會自動清空owner、priority字段，需要PDM重新定義2.如果PDM判定此記錄為三方bug，則需要在supplier字段中選擇三方名稱（PDM根據(jù)項目三方列表，可以向CM提出添加supplierlist到CQ中）3.Duedate的選擇需要符合releaseplan4.如果是交叉bug，測試人員識別的modulename不夠準(zhǔn)確，PDM是可以在

assign的時候進(jìn)行修改的5.需要必填carrier字段，標(biāo)識Bug在哪些版本上存在(通常用于指明不同的運營商)

Bug處理過程實施基本原則CQ中assignBug的操作過Bug處理過程實施基本原則分析Bug的準(zhǔn)備工作（Open）Owner一定要在發(fā)生bug的版本上復(fù)現(xiàn)bug，而且要嚴(yán)格按照bug的發(fā)現(xiàn)步驟和環(huán)境對于bug描述不清或不完整，需要修改的情形，owner和測試溝通清楚，由testers或者testleader進(jìn)行修改有些bug會有附件，一定要查看attachment處是否有附件，供分析bug使用在分析的過程中，要將所有的分析結(jié)果通過modifynotes字段添加到CQ中，包括：做了哪些驗證Debug過程、方式和結(jié)果原因分析如果確認(rèn)bug是自己的，需要在三天之內(nèi)openbug，同時需要將最初始的分析結(jié)果（rootcause）記錄在analysis字段中6.Owner要有時間觀念：PDM預(yù)先給定一個DueDate

如果有問題，可以反饋回來；并給出合理的理由如果沒有問題，就按照這個時間計劃發(fā)布版本；

任何delay都是不允許的；即使是他人問題導(dǎo)致，也要在duedate到來前和PDM溝通原因，才可被接受7.PDM對于Owner提出的要求要做出積極響應(yīng)，實時關(guān)注bug的解決情況，如果發(fā)現(xiàn)會有delay，要及時和owner溝通，采取措施幫助owner盡量避免發(fā)生delayBug處理過程實施基本原則分析Bug的準(zhǔn)備工作（Open）Bug處理過程實施基本原則8.Owner必須保證填寫的分析是有效的。不該出現(xiàn)的分析如下：在我的板子/手機上沒有發(fā)現(xiàn)Action:用和測試工程師一樣的環(huán)境復(fù)現(xiàn)新的版本中這個問題沒了Action:查到rootcause不是我的問題Action:查到是誰的問題，并和他確認(rèn)我覺得應(yīng)該這樣做（或者：XXX要求我這么做）Action:需求都以DOORS中baselined的需求為準(zhǔn)，有變化需走需求變更三天之內(nèi)沒有找出原因，填寫“正在分析中”，“空格”等無效信息Action:向架構(gòu)和相關(guān)模塊負(fù)責(zé)人申請會審，尋求技術(shù)幫助，找到rootcause后再openbugBug處理過程實施基本原則8.Owner必須保證填寫的分析是Bug處理過程實施基本原則CQ中OpenBug的操作過程1.Owner必填analysis字段：Bug的分析描述，包括Bug解決分析、驗證結(jié)果分析以及一些備注信息2.必填carrier字段，owner根據(jù)對bug的分析，可以修改PDM給出的carrierlist3.如果是三方bug，則需要在supplier字段中選擇三方名稱Bug處理過程實施基本原則Bug處理過程實施基本原則RejectBug的準(zhǔn)備工作1.Owner要明確reject的原則，才可以向PDM或TL申請rejectbug1）Bug描述的現(xiàn)象能夠重現(xiàn)

2）經(jīng)確認(rèn)（確認(rèn)方式：Submitter，UI,requirementowner，SPDM，TL一起確認(rèn)）存在以下問題：該現(xiàn)象屬于符合規(guī)范、標(biāo)準(zhǔn)或行業(yè)慣例正?，F(xiàn)象測試條件本身存在問題該bug不屬于合理范圍內(nèi)的修改，比如baselined的需求定義以外的一些額外的功能等；3）必須征求submitter的意見，把rootcause說清楚，得到認(rèn)同即可向PDM或TL提出申請2.在reject過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁Bug處理過程實施基本原則RejectBug的準(zhǔn)備工作Bug處理過程實施基本原則CQ中rejectBug的操作過程1.PDM或TL必填analysis字段，填寫經(jīng)大家同意的reject理由,將bug置為rejected狀態(tài)Bug處理過程實施基本原則CQ中rejectBug的操作過Bug處理過程實施基本原則DuplicateBug的準(zhǔn)備工作1.Owner要明確duplicate的原則，才可以向PDM或TL申請duplicatebug1）Bug描述的現(xiàn)象能夠重現(xiàn)

2）必須是兩個或多個bugs的操作路徑和表現(xiàn)結(jié)果均一致。保留先提交的bug，將后提交的一個或多個bugs置為duplicated，并將先提交的bugCustID號記錄在后面被duplicated掉的bugs上何謂“操作路徑”一致？兩個或多個bugs的所有操作步驟均一致，錯誤表現(xiàn)也一致兩個或多個bugs入口不一樣，但后面的操作步驟和表現(xiàn)結(jié)果均一致，比如：Bug1：步驟1，步驟2，步驟3，步驟4，步驟5Bug2：步驟1'，步驟2'，步驟3，步驟4，步驟5這兩個bugs前2步不同，但錯誤發(fā)生在步驟3/4/5中，而且錯誤表現(xiàn)也一樣，我們可以認(rèn)為“操作路徑”一致3）對bugs之間的“操作路徑”和“表現(xiàn)結(jié)果”一致的認(rèn)定，必須征求submitter的意見，把rootcause說清楚，得到認(rèn)同即可向PDM或TL提出申請Bug處理過程實施基本原則DuplicateBug的準(zhǔn)備工Bug處理過程實施基本原則在duplicate過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁CQ中duplicateBug的操作過程Duplicatebug時，PDM或TL可以根據(jù)保留的bugcarrier信息，填寫被duplicated掉的bugcarrier字段填寫保留的BugCustID到Duplicate_ID字段中將duplicate的原因記錄在notes字段中Bug處理過程實施基本原則在duplicate過程中，如果發(fā)Bug處理過程實施基本原則延遲解決Bug的準(zhǔn)備工作（Postpone）1.Owner要明確postpone的原則，才可以向PDM申請postponebug1）經(jīng)過分析（open）后，發(fā)現(xiàn)當(dāng)前不具備解決條件的缺陷，例如:平臺限制軟件架構(gòu)限制第三方限制Bug不會對用戶使用產(chǎn)生負(fù)作用，但Bug的修改會帶來負(fù)面的風(fēng)險和更多的問題

2）一個bug被fail多次，PDM評估后認(rèn)可bug不會對項目產(chǎn)生block2.要發(fā)正式郵件向PDM申請，抄送給Testleader，Submitter，TL，SQA3.郵件的收件人以及抄送人全部同意后，PDM才可postponebug4.QA會抽查postponedbugs，如果發(fā)現(xiàn)理由不合理，可以將bug重新打開CQ中postponeBug的操作過程1.PDM要將合理的postpone理由填寫到notes字段中Bug處理過程實施基本原則延遲解決Bug的準(zhǔn)備工作（PostBug處理過程實施基本原則監(jiān)控Bug的準(zhǔn)備工作（Monitor）1.對于復(fù)現(xiàn)率低的bug，如果發(fā)生以下情況，Owner可以向PDM或TL申請monitorbug；1）分析（open）bug時，Owner無法復(fù)現(xiàn)bug2）Resolvebug時，Owner無法確定bug是否在分支上被解決了

3）Releasebug時，Owner無法確定bug是否在集成版本上被解決了2.在申請之前：

1）Owner必須將試圖復(fù)現(xiàn)bug的操作，重現(xiàn)次數(shù)等信息記錄在notes字段中；在重現(xiàn)bug的時候一定要在發(fā)現(xiàn)bug的版本上驗證：在當(dāng)前版本沒有發(fā)現(xiàn)bug，不代表該bug不存在在模擬器上驗證，無效2）對于notmust的bug，需要測試100次以上

3）如果這個Bug是很難復(fù)現(xiàn)，但測試已經(jīng)提供了必要的Log文件，則測試不負(fù)責(zé)復(fù)現(xiàn)；如果owner經(jīng)過多次驗證仍然不能復(fù)現(xiàn)的bug，可以向

PDM申請專項測試

4）專項測試的次數(shù)定義原則為：申請測試次數(shù)為50的倍數(shù)且不少于Fail_total值的分母

5）如果成功復(fù)現(xiàn)bug，測試人員需要及時通知owner并試圖抓取trace信息以便分析解決

Bug處理過程實施基本原則監(jiān)控Bug的準(zhǔn)備工作（Monito3.Owner需要發(fā)正式郵件向PDM或TL申請，并抄送給Testleader，Submitter，SQA4.郵件的收件人以及抄送人全部同意后，PDM或TL才可monitorbug

對于復(fù)現(xiàn)率低的bug，在verifybug時，測試人員無法確定bug是否在正式發(fā)布的版本上被解決了，也可以monitorbug

所有被monitor的bug，需要由測試人員在后續(xù)的三個版本中（不包括當(dāng)前版本）進(jìn)行驗證；成功復(fù)現(xiàn)則fail掉bug；如果沒有復(fù)現(xiàn)，測試leader在與SPDM確認(rèn)后，可以將bugverify掉；如果有客戶，需要在verify之前得到客戶的確認(rèn)監(jiān)控過程中，測試人員需要通過modify的方式，將每個版本的復(fù)現(xiàn)結(jié)果記錄在CQ(包括測試的版本以及測試的次數(shù)，復(fù)現(xiàn)的次數(shù)等等）

CQ中monitorBug的操作過程1.如果bug在沒有release之前被monitor，PDM需要必填ReleasedSWversion和ReleasedHWversion字段，給測試人員在后續(xù)三個版本中復(fù)現(xiàn)bug提供參考版本2.PDM需要將monitor的理由必填到notes字段中Bug處理過程實施基本原則3.Owner需要發(fā)正式郵件向PDM或TL申請，并Bug處理過程實施基本原則重新打開Bug的準(zhǔn)備工作（Reopen）1.當(dāng)測試人員不同意reject或duplicatebug，可以在得到研發(fā)人員同意后reopenbug2.Owner在release時，發(fā)現(xiàn)bug仍然存在，需要將bugreopen3.當(dāng)延遲解決的bug具備解決條件后，Owner，PDM，TL都可以將bugreopen4.當(dāng)QA認(rèn)為postponebug原因不合理時，可以將bugreopenCQ中reopenBug的操作過程1.可以修改carrier字段2.將reopen的原因填寫在analysis字段中Bug處理過程實施基本原則重新打開Bug的準(zhǔn)備工作（ReopBug處理過程實施基本原則解決Bug的準(zhǔn)備工作（Resolve）在對Bug產(chǎn)生的原因進(jìn)行細(xì)致分析后，Owner需要確認(rèn)bug初步的解決方案在分支上實施解決方案后，進(jìn)行單元測試以及代碼評審活動。單元測試通過后，需要在peerreview工具中提交申請并組織正式評審會議

1）評審?fù)ㄟ^后，owner將要合并的分支提交給軟件集成工程師（SWbuildengineer），將狀態(tài)設(shè)置為resolved并填寫通過驗證的解決方案；

2）評審沒有通過，owner需要修改評審issue直到評審?fù)ㄟ^為止CQ中resolveBug的操作過程1.Owner在resolvebug時，可以修改carrier字段的信息2.將通過驗證的解決方案（solution）記錄在analysis字段中3.選擇Bug發(fā)生原因分類，填寫在Defect_Cause_Analysis字段中，具體分類參考“DefectCauseAnalysis4.還需要選擇對應(yīng)的peerreviewID。PeerReviewID字段添加了勾選框;1）當(dāng)該框被勾上，列出已被Verify或Close的PeerReviewIDlist；

2）未勾上，則反列出Submitted、Failed或Resolved狀態(tài)的PeerReviewIDlistBug處理過程實施基本原則解決Bug的準(zhǔn)備工作（ResolvBug處理過程實施基本原則發(fā)布Bug的準(zhǔn)備工作（Release）軟件集成工程師（SWbuildengineer）將提交的分支進(jìn)行集成，并在軟件內(nèi)部發(fā)布此版本Owner要在發(fā)布的軟件上進(jìn)行驗證

1）如果驗證通過，在軟件集成工程師提交的軟件發(fā)布計劃確認(rèn)單上進(jìn)行確認(rèn)，在確認(rèn)后的一個工作日內(nèi)將bugrelease并填寫發(fā)布版本號

2）如果驗證發(fā)現(xiàn)Bug仍然存在，owner需要將bug重新打開（reopen），再次分析bug并找出新的solution3.驗證及release工作需要在版本發(fā)布后的一個工作日內(nèi)完成CQ中releaseBug的操作過程1.Owner在releasebug時，可以修改carrier和Defect_Cause_Analysis字段的信息2.將通過集成驗證的最終解決方案記錄在analysis字段中3.將通過集成驗證的SW和HW版本號記錄在ReleasedSWversion和ReleasedHWversion字段中4.將通過集成驗證的分支填寫在SW_Formal_Branch字段中Bug處理過程實施基本原則發(fā)布Bug的準(zhǔn)備工作（ReleasBug處理過程實施基本原則驗證Bug的準(zhǔn)備工作（Verify）1.驗證releasedbug

1）測試人員（一般是submitter）要在開發(fā)人員填寫的SW和HW發(fā)布版本號上對releasedbug進(jìn)行驗證

2）如果發(fā)布版本號不是最新版本，測試人員需要在最新的版本上進(jìn)行驗證2.驗證rejected&duplicatedbug1）在verifyrejected或duplicatedbug時，需要檢查reject和duplicate的理由是否和溝通的結(jié)果一致，duplicateID是否填寫正確，確認(rèn)沒有問題后再verifybug2）如果之前研發(fā)人員沒有和測試人員溝通，當(dāng)測試人員不認(rèn)同bug的處理時，可以將bug重新reopenNotes：Releasedbugs的驗證工作需要在版本正式發(fā)布后的一個工作日內(nèi)完成Bug處理過程實施基本原則驗證Bug的準(zhǔn)備工作（VerifyBug處理過程實施基本原則CQ中verifyBug的操作過程1.在分析中填寫驗證概率、驗證人、驗證結(jié)果2.對某些需要驗證報告的bug，則需要提交驗證報告作為附件。3.如果驗證通過，verifybug并填寫SW和HW驗證版本號4.如果驗證不通過，bug仍然存在，測試人員需要和owner溝通確認(rèn)后，再將bugfail掉Bug處理過程實施基本原則CQ中verifyBug的操作過Bug處理過程實施基本原則FailBug的準(zhǔn)備工作1.測試人員驗證releasedbug時，發(fā)現(xiàn)bug仍然存在，需要將bugfail掉2.QA抽查verify掉的bug時，發(fā)現(xiàn)bug仍然存在，需要將bugfail掉3.被Monitor掉的bug，測試人員在監(jiān)控三個版本的過程中，如果復(fù)現(xiàn)成功，需要將bugfail掉4.在fail之前都要和研發(fā)人員溝通確認(rèn)后再執(zhí)行操作CQ中failBug的操作過程1.可以修改carrier字段2.測試人員或QA需要在analysis字段中填寫驗證不成功的原因說明（包括驗證概率、驗證人、驗證結(jié)果、驗證不成功具體原因描述）Bug處理過程實施基本原則FailBug的準(zhǔn)備工作Bug處理過程實施基本原則關(guān)閉/丟棄Bug的準(zhǔn)備工作（Closed/Discard）QA要對verify掉的bug進(jìn)行關(guān)閉和丟棄。

1)當(dāng)closetype為released，則closebug;2)當(dāng)closetype為rejected和duplicated，則discardbug;流程方面，關(guān)閉和丟棄bug時，QA需要檢查Bug信息是否填寫完整，信息是否有效？是否符合流程定義？產(chǎn)品方面：對于有效bug，QA還需要抽查verify掉的bug，是否真的被解決了；如果沒有，可以fail掉bug；關(guān)閉/丟棄bug的工作需要在bug被verify掉后的一個工作日內(nèi)完成CQ中close/discardBug的操作過程1.直接在CQ中執(zhí)行close/discard操作即可Bug處理過程實施基本原則關(guān)閉/丟棄Bug的準(zhǔn)備工作（Clo附錄1—SeveritydefinitionSeverityDefinitionofSeverity

S-FatalSeverityissue,e.g..hurtbodyorlostcustomerinfo.TheSoftwaresystemcrashandcan'tresumebyoneself

A-SeriousCustomerdatalostbutcanresumeSWsystemcrashbutcanresumeAffectcustomeroperationbadlyliketheoftenusefunctionhavehighfailureratereset,freeze,messup,confusionscreen,functionfailureThefunctionproblemcannotresumethatwillaffectphoneused

TheseriousMEproblemthatmaybeaffectusedfunctionMostcustomerswillreturnit

B-ModerateCustomeroftenusefunctionhavelowfailureratereset,freeze,messup,confusionscreen,functionfailureItcan'taccordwithperformancerequirementThefunctionproblemcanresumethatwillaffectphoneused

TheappearanceofMEpartisnotgoodbutitwon'taffectphoneusedCriticalcustomerwillreturnit

C-MinorSystemfunctiontargetimplementbasically,SWfunctionaccordwithrequirementbasically,buthavealittledifferencewithUISpecTheMEpartdisabledbutcanresumeandslightappearanceproblemsTheproblemsthatMostcustomerscouldtoleranceorcanbeignore

D-SuggestionInterfacedisplayaccordswithrequestsbuttheconsumeruseuncomfortablyoruseinterfaceunkindly.附錄1—SeveritydefinitionSeverit附錄2—PrioritydefinitionPriorityDefinitionofPriority1-ResolveImmediatelyResolvedefectoncurrent.Ifdefectisnotresolved,releaseisnotacceptable.2-GiveHighAttentionResolvedefectassoonaspossible.Mustbesolvedbeforenextrelease.3-NormalQueueDefectneedstoberesolvedwithin2nextreleases.4-LowPriorityDefectneedstoberesolvedwithin3nextreleases.附錄2—PrioritydefinitionPriorit附錄3—FrequencydefinitionFrequency定義DefinitionMust100%OftenMorethan50%OccasionalBetween1%and50%OnceOnlyhappensonetime附錄3—FrequencydefinitionFreque

DefectdisposeDemandresponsetimeDefectsubmita)ForSWtestdept.,itwillbesubmittedtodatabaseinaworkdayafterdefect

found.b)ForPVdept.,itwillbesubmittedtodatabaseinaworkdayafterdefect

foundinBTCinternallab.Defectswhichfoundinexternallabshouldbesubmittedtodatabaseinaworkdayafterreceivedtestreportform.c)Tothedefectcomesfromcustomer,itwillbeconfirmedandsubmittedinoneworkdaytoo.DefectassignTheassignmentofdefectshallbecompletedinoneworkday.DefectanalysisThedefectanalysisresultshallbefilledin3workdaysafteritassigned.DefectresolveThedefectshouldberesolvedaccordingtoduedateDefectreleaseTheSWdefectshouldbereleasedinoneworkdayafterverifiedonSWversionTheHW&MEdefectsshouldbereleasedinoneworkdayafterbuildfinishedDefectVerifyTheSWdefectverifiedwillbecompleteinoneworkdayafternewversionreleased.TheHW,MEtestersneedtocompleteresolveddefectsverifiedinoneworkdayaftergetLabtestreportDefectCloseQAneedtofinishthecloseofverifieddefectsintheversionwithin1workdayRejected&DuplicateddefectdisposeThetestersneedtoconfirmthedefectisinvalidandduplicateinoneworkday附錄4—BugdisposetimeDefectdisposeDemandrBug處理過程實施細(xì)則Bug處理過程實施細(xì)則目的為了幫助項目組成員更好的理解Bug處理過程，提高工作效率,規(guī)范行為準(zhǔn)則；本文檔對各部門項目組成員如何實施Bug處理過程進(jìn)行了細(xì)化

Notes:如果在公司文檔中發(fā)現(xiàn)有Error，Bug，Defect，PR等字樣，請不要發(fā)生混淆，這四個代名詞代表的都是產(chǎn)品缺陷

目的為了幫助項目組成員更好的理解Bug處理過程，提高工作效率內(nèi)容1.參與Bug處理過程之前，我們需要做好哪些準(zhǔn)備工作？2.缺陷狀態(tài)轉(zhuǎn)移圖3.各個角色的權(quán)限及職責(zé)4.Bug處理過程中都包括哪些子過程？5.每個子過程都是如何實施的？6.附錄

內(nèi)容參與Bug處理過程準(zhǔn)備工作1.確認(rèn)PC可以訪問Bug管理工具

BYD使用IBM公司的Clearquest工具管理bug，登陸方式分為Web方式和客戶端方式，這兩種方式都可以采用。2.確認(rèn)擁有CQ登陸賬號每位項目組成員都需要向SCM申請Clearquest工具賬號，SPDM審批即可

3.確認(rèn)CQ的操作權(quán)限

CQ為bug處理過程中涉及到的角色分配了操作權(quán)限。如果沒有權(quán)限，請向CM提出申請，CM會根據(jù)申請人的角色開放操作權(quán)限

4.識別工作過程中的相關(guān)人員以及聯(lián)系方式包括PDM,Teamleader，F(xiàn)eatureowner，Testers，testleader以及SQA

發(fā)生問題時，電話、當(dāng)面溝通是最有效的溝通方式，

Email的作用只是要留證據(jù)和highlight5.確認(rèn)參與了Bug管理過程培訓(xùn)

QA會為項目組成員培訓(xùn)Bug管理過程，如果是新加入到項目組的工程師且沒有參加過培訓(xùn)，請聯(lián)系QA

參與Bug處理過程準(zhǔn)備工作缺陷跟蹤流程—狀態(tài)轉(zhuǎn)移圖Action:

SubmitAssignOpenResolveReleaseVerifyClosePostponeFailMonitorRejectDuplicateDiscardReopenRe-VerifyRe-rejectRe-duplicateNotes:AllactionswhicharemarkedbypinkcoloraredonebyST.缺陷跟蹤流程—狀態(tài)轉(zhuǎn)移圖Action:角色和職責(zé)RolesSPDMQATestleader&TestersSWTLOwnerSubmitterSubmitüüüüüüAssignü

ü

Postponeü

Open

ü

ReopenüüüüüFail

üü

üResolve

ü

Release

ü

Rejectü

ü

Duplicateü

ü

Monitorü

üü

üVerify

ü

üClose

ü

Discard

ü

Re-reject

ü

Re-duplicate

ü

Re-verify

ü

Actions角色和職責(zé)RolesSPDMQATestleadBug處理過程實施基本原則提交Bug準(zhǔn)備工作（Submit）1.測試人員發(fā)現(xiàn)Bug后，要依照本部門Bug描述模板，將Bug信息填寫完整，選用本部門常用詞進(jìn)行描述，語言盡量簡潔，清晰，完整，不要出現(xiàn)生僻詞；

（Bug描述模板是可以根據(jù)項目實際需求進(jìn)行裁剪的）2.測試組長每天要檢查測試人員提交的Buglist，確認(rèn)每個Bug的信息是否填寫完整，Bug描述是否清晰，Bug是否有效等3.經(jīng)過測試組長確認(rèn)的Bug，測試人員才可以提交到Clearquest工具中4.Bug的提交要在一個工作日內(nèi)完成Bug處理過程實施基本原則提交Bug準(zhǔn)備工作（Submit）Bug處理過程實施基本原則CQ中提交Bug的操作過程1.測試人員提交Bug時，需要先選擇Ownerdepartment，確認(rèn)是SW的問題，即選SW，HW即選HW，其他同理2.再根據(jù)項目名稱，選擇Project3.其他字段可以不分順序進(jìn)行填寫，標(biāo)識紅色字段為必填項，如果有必填項為空，是不能提交當(dāng)前記錄的4.提交Bug時填寫的字段注釋如下：Bug處理過程實施基本原則Bug處理過程實施基本原則3.Headline:Bug的概要描述，測試人員要使用能突出Bug失效現(xiàn)象的詞語，如Freeze，Halt，Restart，functionfailure等，4.Owner:

選擇PDM或者featureowner.5.Owner_Department:選擇Bugowner所屬部門,必須首先選擇此字段6.Submitter:系統(tǒng)自動生成為提交人員7.Supplier:測試部門可選，主要是研發(fā)部門使用，三方bug時，選擇三方名稱；不是，則空；8.Priority:解決Bug的優(yōu)先級別（1,2,3,4），具體定義參考附錄“Prioritydefinition”9.Severity:Bug的嚴(yán)重程度（S,A,B,C,D），具體定義參考附錄“Severitydefinition”10.SWVersion:發(fā)生Bug的軟件版本11.Project:項目名稱1.Cust_ID:自動生成(項目名稱簡寫_P+自定義的連續(xù)ID)2.State:Bug當(dāng)前處理狀態(tài)，參考Bug狀態(tài)遷移圖Bug處理過程實施基本原則3.Headline:BugBug處理過程實施基本原則12.SW_Sub_Version:

軟件版本的補充，用于具體表明同一個版本不同的軟件(比如不同運營商)，同軟件版本組合在一起進(jìn)行使用(內(nèi)容是運營商三個字母的縮寫)13.Platform:與Project關(guān)聯(lián)，選擇project后自動生成14.HWVersion:發(fā)生Bug的硬件版本15.FoundMethod：Bug的發(fā)現(xiàn)途徑，具體定義參考附錄“FoundMethoddefinition”16.MEVersion:SW測試部門和SW部門可選，主要是PV,HW&ME部門使用；發(fā)生Bug的結(jié)構(gòu)版本17.Repeatable：Bug發(fā)生頻率，具體定義參考附錄“Frequencydefinition”18.ModuleName:發(fā)生Bug的模塊19.DueDate:研發(fā)部門使用；標(biāo)識計劃解決Bug的日期

20.SubModule:測試部門可選，發(fā)生Bug的子模塊，與Module關(guān)聯(lián)Bug處理過程實施基本原則12.SW_Sub_VersionBug處理過程實施基本原則21.Tested_Times:測試次數(shù)/樣機數(shù)量22.Failed_Times:失效次數(shù)/樣機數(shù)量23.FailRatio:失效比率（自動生成）24.Mobile_No：發(fā)生Bug的手機編號（測試手機的唯一標(biāo)識，不是測試卡的號碼）25.CustomerDefectID：BTC代替客戶提交Bug時必填，記錄客戶的BugID26.Testcase_ID：提交時根據(jù)測試類型可選Mark"Y",needfillinwhensubmitandverify.Ifmark"N",canfillinoptionallywhensubmitandverify.Iffoundmethodiscertificationtest,Testersneedtomarkcertificationtypein“headline”field

Bug處理過程實施基本原則21.Tested_Times:Bug處理過程實施基本原則27.Company：提交Bug人員所在公司(如果是客戶要求BTC提交,則填寫客戶公司名稱)30.Description：Bug的具體描述，包括前題條件，發(fā)生步驟，實際結(jié)果，預(yù)期結(jié)果，測試人員的聯(lián)系方式等重要信息31.Attachment：測試人員可以將Buglog信息，測試圖片，鈴聲等信息作為附件上傳到CQ中，作為研發(fā)人員復(fù)現(xiàn)、分析Bug的參考28.Bugtype：發(fā)現(xiàn)bug類型(Degrade/New/Missed)29.PeerReview：代碼評審的ID，開發(fā)必填Bug處理過程實施基本原則27.Company：提交BuBug處理過程實施基本原則分配Bug操作指南（Assign）SPDM需要每天查詢owner為自己的Bug，確認(rèn)bug是否屬于本部門。如果是，根據(jù)Bug的實際描述分配給TL/Featureowner，重新定義Bug解決優(yōu)先級別以及計劃解決Bug的duedate；如果不是，需要和HPDM溝通確認(rèn)后再修改ownerdepartment為HW/ME分配任務(wù)要在一個工作日內(nèi)完成，QA會抽查沒有及時被分配的bug并進(jìn)行highlightSW部門要定義每個feature的owner，便于PDM識別featureowner以及供測試人員溝通bug使用TL/Featureowner確認(rèn)是組/feature內(nèi)的bug后，通過modifyOwner字段，最后將bug分配給實際的責(zé)任人（Realowner）分配過程中如出現(xiàn)轉(zhuǎn)Bug、RejectBug，DuplicateBug的需求，申請人首先要和關(guān)聯(lián)人員進(jìn)行充分溝通，達(dá)成一致后發(fā)出正式郵件向項目管理層申請并將郵件內(nèi)容通過modifynotes字段填寫到CQ中

1）溝通Feature/Team間轉(zhuǎn)bug：Featureowner之間的溝通Rejectbug：Owner、testers、requirement、SPDM,TL之間的溝通Duplicatebug：Owner,testers,SPDM,TL之間的溝通Bug處理過程實施基本原則分配Bug操作指南（Assign）Bug處理過程實施基本原則CQ中assignBug的操作過程1.PDM在assignbug時，CQ會自動清空owner、priority字段，需要PDM重新定義2.如果PDM判定此記錄為三方bug，則需要在supplier字段中選擇三方名稱（PDM根據(jù)項目三方列表，可以向CM提出添加supplierlist到CQ中）3.Duedate的選擇需要符合releaseplan4.如果是交叉bug，測試人員識別的modulename不夠準(zhǔn)確，PDM是可以在

assign的時候進(jìn)行修改的5.需要必填carrier字段，標(biāo)識Bug在哪些版本上存在(通常用于指明不同的運營商)

Bug處理過程實施基本原則CQ中assignBug的操作過Bug處理過程實施基本原則分析Bug的準(zhǔn)備工作（Open）Owner一定要在發(fā)生bug的版本上復(fù)現(xiàn)bug，而且要嚴(yán)格按照bug的發(fā)現(xiàn)步驟和環(huán)境對于bug描述不清或不完整，需要修改的情形，owner和測試溝通清楚，由testers或者testleader進(jìn)行修改有些bug會有附件，一定要查看attachment處是否有附件，供分析bug使用在分析的過程中，要將所有的分析結(jié)果通過modifynotes字段添加到CQ中，包括：做了哪些驗證Debug過程、方式和結(jié)果原因分析如果確認(rèn)bug是自己的，需要在三天之內(nèi)openbug，同時需要將最初始的分析結(jié)果（rootcause）記錄在analysis字段中6.Owner要有時間觀念：PDM預(yù)先給定一個DueDate

如果有問題，可以反饋回來；并給出合理的理由如果沒有問題，就按照這個時間計劃發(fā)布版本；

任何delay都是不允許的；即使是他人問題導(dǎo)致，也要在duedate到來前和PDM溝通原因，才可被接受7.PDM對于Owner提出的要求要做出積極響應(yīng)，實時關(guān)注bug的解決情況，如果發(fā)現(xiàn)會有delay，要及時和owner溝通，采取措施幫助owner盡量避免發(fā)生delayBug處理過程實施基本原則分析Bug的準(zhǔn)備工作（Open）Bug處理過程實施基本原則8.Owner必須保證填寫的分析是有效的。不該出現(xiàn)的分析如下：在我的板子/手機上沒有發(fā)現(xiàn)Action:用和測試工程師一樣的環(huán)境復(fù)現(xiàn)新的版本中這個問題沒了Action:查到rootcause不是我的問題Action:查到是誰的問題，并和他確認(rèn)我覺得應(yīng)該這樣做（或者：XXX要求我這么做）Action:需求都以DOORS中baselined的需求為準(zhǔn)，有變化需走需求變更三天之內(nèi)沒有找出原因，填寫“正在分析中”，“空格”等無效信息Action:向架構(gòu)和相關(guān)模塊負(fù)責(zé)人申請會審，尋求技術(shù)幫助，找到rootcause后再openbugBug處理過程實施基本原則8.Owner必須保證填寫的分析是Bug處理過程實施基本原則CQ中OpenBug的操作過程1.Owner必填analysis字段：Bug的分析描述，包括Bug解決分析、驗證結(jié)果分析以及一些備注信息2.必填carrier字段，owner根據(jù)對bug的分析，可以修改PDM給出的carrierlist3.如果是三方bug，則需要在supplier字段中選擇三方名稱Bug處理過程實施基本原則Bug處理過程實施基本原則RejectBug的準(zhǔn)備工作1.Owner要明確reject的原則，才可以向PDM或TL申請rejectbug1）Bug描述的現(xiàn)象能夠重現(xiàn)

2）經(jīng)確認(rèn)（確認(rèn)方式：Submitter，UI,requirementowner，SPDM，TL一起確認(rèn)）存在以下問題：該現(xiàn)象屬于符合規(guī)范、標(biāo)準(zhǔn)或行業(yè)慣例正?，F(xiàn)象測試條件本身存在問題該bug不屬于合理范圍內(nèi)的修改，比如baselined的需求定義以外的一些額外的功能等；3）必須征求submitter的意見，把rootcause說清楚，得到認(rèn)同即可向PDM或TL提出申請2.在reject過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁Bug處理過程實施基本原則RejectBug的準(zhǔn)備工作Bug處理過程實施基本原則CQ中rejectBug的操作過程1.PDM或TL必填analysis字段，填寫經(jīng)大家同意的reject理由,將bug置為rejected狀態(tài)Bug處理過程實施基本原則CQ中rejectBug的操作過Bug處理過程實施基本原則DuplicateBug的準(zhǔn)備工作1.Owner要明確duplicate的原則，才可以向PDM或TL申請duplicatebug1）Bug描述的現(xiàn)象能夠重現(xiàn)

2）必須是兩個或多個bugs的操作路徑和表現(xiàn)結(jié)果均一致。保留先提交的bug，將后提交的一個或多個bugs置為duplicated，并將先提交的bugCustID號記錄在后面被duplicated掉的bugs上何謂“操作路徑”一致？兩個或多個bugs的所有操作步驟均一致，錯誤表現(xiàn)也一致兩個或多個bugs入口不一樣，但后面的操作步驟和表現(xiàn)結(jié)果均一致，比如：Bug1：步驟1，步驟2，步驟3，步驟4，步驟5Bug2：步驟1'，步驟2'，步驟3，步驟4，步驟5這兩個bugs前2步不同，但錯誤發(fā)生在步驟3/4/5中，而且錯誤表現(xiàn)也一樣，我們可以認(rèn)為“操作路徑”一致3）對bugs之間的“操作路徑”和“表現(xiàn)結(jié)果”一致的認(rèn)定，必須征求submitter的意見，把rootcause說清楚，得到認(rèn)同即可向PDM或TL提出申請Bug處理過程實施基本原則DuplicateBug的準(zhǔn)備工Bug處理過程實施基本原則在duplicate過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁CQ中duplicateBug的操作過程Duplicatebug時，PDM或TL可以根據(jù)保留的bugcarrier信息，填寫被duplicated掉的bugcarrier字段填寫保留的BugCustID到Duplicate_ID字段中將duplicate的原因記錄在notes字段中Bug處理過程實施基本原則在duplicate過程中，如果發(fā)Bug處理過程實施基本原則延遲解決Bug的準(zhǔn)備工作（Postpone）1.Owner要明確postpone的原則，才可以向PDM申請postponebug1）經(jīng)過分析（open）后，發(fā)現(xiàn)當(dāng)前不具備解決條件的缺陷，例如:平臺限制軟件架構(gòu)限制第三方限制Bug不會對用戶使用產(chǎn)生負(fù)作用，但Bug的修改會帶來負(fù)面的風(fēng)險和更多的問題

2）一個bug被fail多次，PDM評估后認(rèn)可bug不會對項目產(chǎn)生block2.要發(fā)正式郵件向PDM申請，抄送給Testleader，Submitter，TL，SQA3.郵件的收件人以及抄送人全部同意后，PDM才可postponebug4.QA會抽查postponedbugs，如果發(fā)現(xiàn)理由不合理，可以將bug重新打開CQ中postponeBug的操作過程1.PDM要將合理的postpone理由填寫到notes字段中Bug處理過程實施基本原則延遲解決Bug的準(zhǔn)備工作（PostBug處理過程實施基本原則監(jiān)控Bug的準(zhǔn)備工作（Monitor）1.對于復(fù)現(xiàn)率低的bug，如果發(fā)生以下情況，Owner可以向PDM或TL申請monitorbug；1）分析（open）bug時，Owner無法復(fù)現(xiàn)bug2）Resolvebug時，Owner無法確定bug是否在分支上被解決了

3）Releasebug時，Owner無法確定bug是否在集成版本上被解決了2.在申請之前：

1）Owner必須將試圖復(fù)現(xiàn)bug的操作，重現(xiàn)次數(shù)等信息記錄在notes字段中；在重現(xiàn)bug的時候一定要在發(fā)現(xiàn)bug的版本上驗證：在當(dāng)前版本沒有發(fā)現(xiàn)bug，不代表該bug不存在在模擬器上驗證，無效2）對于notmust的bug，需要測試100次以上

3）如果這個Bug是很難復(fù)現(xiàn)，但測試已經(jīng)提供了必要的Log文件，則測試不負(fù)責(zé)復(fù)現(xiàn)；如果owner經(jīng)過多次驗證仍然不能復(fù)現(xiàn)的bug，可以向

PDM申請專項測試

4）專項測試的次數(shù)定義原則為：申請測試次數(shù)為50的倍數(shù)且不少于Fail_total值的分母

5）如果成功復(fù)現(xiàn)bug，測試人員需要及時通知owner并試圖抓取trace信息以便分析解決

Bug處理過程實施基本原則監(jiān)控Bug的準(zhǔn)備工作（Monito3.Owner需要發(fā)正式郵件向PDM或TL申請，并抄送給Testleader，Submitter，SQA4.郵件的收件人以及抄送人全部同意后，PDM或TL才可monitorbug

對于復(fù)現(xiàn)率低的bug，在verifybug時，測試人員無法確定bug是否在正式發(fā)布的版本上被解決了，也可以monitorbug

所有被monitor的bug，需要由測試人員在后續(xù)的三個版本中（不包括當(dāng)前版本）進(jìn)行驗證；成功復(fù)現(xiàn)則fail掉bug；如果沒有復(fù)現(xiàn)，測試leader在與SPDM確認(rèn)后，可以將bugverify掉；如果有客戶，需要在verify之前得到客戶的確認(rèn)監(jiān)控過程中，測試人員需要通過modify的方式，將每個版本的復(fù)現(xiàn)結(jié)果記錄在CQ(包括測試的版本以及測試的次數(shù)，復(fù)現(xiàn)的次數(shù)等等）

CQ中monitorBug的操作過程1.如果bug在沒有release之前被monitor，PDM需要必填ReleasedSWversion和ReleasedHWversion字段，給測試人員在后續(xù)三個版本中復(fù)現(xiàn)bug提供參考版本2.PDM需要將monitor的理由必填到notes字段中Bug處理過程實施基本原則3.Owner需要發(fā)正式郵件向PDM或TL申請，并Bug處理過程實施基本原則重新打開Bug的準(zhǔn)備工作（Reopen）1.當(dāng)測試人員不同意reject或duplicatebug，可以在得到研發(fā)人員同意后reopenbug2.Owner在release時，發(fā)現(xiàn)bug仍然存在，需要將bugreopen3.當(dāng)延遲解決的bug具備解決條件后，Owner，PDM，TL都可以將bugreopen4.當(dāng)QA認(rèn)為postponebug原因不合理時，可以將bugreopenCQ中reopenBug的操作過程1.可以修改carrier字段2.將reopen的原因填寫在analysis字段中Bug處理過程實施基本原則重新打開Bug的準(zhǔn)備工作（ReopBug處理過程實施基本原則解決Bug的準(zhǔn)備工作（Resolve）在對Bug產(chǎn)生的原因進(jìn)行細(xì)致分析后，Owner需要確認(rèn)bug初步的解決方案在分支上實施解決方案后，進(jìn)行單元測試以及代碼評審活動。單元測試通過后，需要在peerreview工具中提交申請并組織正式評審會議

1）評審?fù)ㄟ^后，owner將要合并的分支提交給軟件集成工程師（SWbuildengineer），將狀態(tài)設(shè)置為resolved并填寫通過驗證的解決方案；

2）評審沒有通過，owner需要修改評審issue直到評審?fù)ㄟ^為止CQ中resolveBug的操作過程1.Owner在resolvebug時，可以修改carrier字段的信息2.將通過驗證的解決方案（solution）記錄在analysis字段中3.選擇Bug發(fā)生原因分類，填寫在Defect_Cause_Analysis字段中，具體分類參考“DefectCauseAnalysis4.還需要選擇對應(yīng)的peerreviewID。PeerReviewID字段添加了勾選框;1）當(dāng)該框被勾上，列出已被Verify或C