缺陷管理流程（PPT35頁)

1、v 為了幫助項目組成員更好的理解Bug處理過程，提高工作效率,規(guī)范行為準(zhǔn)則；本文檔對各部門項目組成員如何實施Bug處理過程進(jìn)行了細(xì)化 Notes:如果在公司文檔中發(fā)現(xiàn)有Error，Bug，Defect，PR等字樣，請不要發(fā)生混淆， 這四個代名詞代表的都是產(chǎn)品缺陷 1.參與Bug處理過程之前，我們需要做好哪些準(zhǔn)備工作？2.缺陷狀態(tài)轉(zhuǎn)移圖3.各個角色的權(quán)限及職責(zé)4. Bug處理過程中都包括哪些子過程？5.每個子過程都是如何實施的？6.附錄 1.確認(rèn)確認(rèn)PC可以訪問可以訪問Bug管理工具管理工具 BYD使用IBM公司的Clear quest工具管理bug，登陸方式分為Web方式和客戶端方式，這兩種方

2、式都可以采用。 2.確認(rèn)擁有確認(rèn)擁有CQ登陸賬號登陸賬號 每位項目組成員都需要向SCM申請Clear quest工具賬號，SPDM審批即可 3.確認(rèn)確認(rèn)CQ的操作權(quán)限的操作權(quán)限 CQ為bug處理過程中涉及到的角色分配了操作權(quán)限。 如果沒有權(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ā)生問題時，電話、當(dāng)面溝通是最有效的溝通方式， Email的作用只是要留證據(jù)和highlight 5.確

3、認(rèn)參與了確認(rèn)參與了Bug管理過程培訓(xùn)管理過程培訓(xùn) QA會為項目組成員培訓(xùn)Bug管理過程，如果是新加入到項目組的工程師且 沒有參加過培訓(xùn)，請聯(lián)系QA Action: SubmitAssignOpenResolveReleaseVerifyClosePostponeFailMonitorRejectDuplicateDiscardReopenRe-VerifyRe-rejectRe-duplicateNotes:All actions which are marked by pink color are done by ST.角色和職責(zé)角色和職責(zé)Actionsv提交提交Bug準(zhǔn)備工作（準(zhǔn)備工作（S

4、ubmit）1.測試人員發(fā)現(xiàn)Bug后，要依照本部門Bug描述模板，將Bug信息填寫完整，選用本部門常用詞進(jìn)行描述，語言盡量簡潔，清晰，完整，不要出現(xiàn)生僻詞； （Bug描述模板是可以根據(jù)項目實際需求進(jìn)行裁剪的）2.測試組長每天要檢查測試人員提交的Bug list，確認(rèn)每個Bug的信息是否填寫完整，Bug描述是否清晰，Bug是否有效等3.經(jīng)過測試組長確認(rèn)的Bug，測試人員才可以提交到Clear quest工具中4.Bug的提交要在一個工作日內(nèi)完成vCQ中提交中提交Bug的操作過程的操作過程1.測試人員提交Bug時，需要先選擇Owner department，確認(rèn)是SW的問題，即選SW，HW即選HW

5、，其他同理2.再根據(jù)項目名稱，選擇Project3.其他字段可以不分順序進(jìn)行填寫，標(biāo)識紅色字段為必填項，如果有必填項為空，是不能提交當(dāng)前記錄的4.提交Bug時填寫的字段注釋如下：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:測試部門可選，主要是研發(fā)部門使用， 三

6、方bug時，選擇三方名稱；不是，則空；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: 項目名稱1. Cust_ID:自動生成 (項目名稱簡寫_P+自定義的連續(xù)ID)2. State: Bug當(dāng)前處理狀態(tài)，參考Bug狀態(tài)遷移圖12.SW_Sub_Version: 軟件版本的補充，用于具體表明同一個版本不同的軟件(比如不同運營商)，同軟

7、件版本組合在一起進(jìn)行使用(內(nèi)容是運營商三個字母的縮寫)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ā)生頻率，具體定義參考附錄“Frequency definition”18.ModuleName:發(fā)生Bug的模塊19.DueDate:研發(fā)部門使用；標(biāo)識計劃解

8、決Bug的日期 20.SubModule:測試部門可選，發(fā)生 Bug的子模塊，與Module關(guān)聯(lián)21. Tested_Times:測試次數(shù)/樣機數(shù)量22. Failed_Times:失效次數(shù)/樣機數(shù)量23. FailRatio:失效比率（自動生成）24. Mobile_No：發(fā)生Bug的手機編號（測試手機的唯一標(biāo)識，不是測試卡的號碼）25.Customer Defect ID：BTC代替客戶提交Bug時必填，記錄客戶的Bug ID26. Testcase_ID：提交時根據(jù)測試類型可選Mark Y , need fill in when submit and verify. If mark N,

9、 can fill in optionally when submitand verify.If found method is certification test, Testers need to mark certification type in “headline” field 27. Company：提交Bug人員所在公司(如果是客戶要求BTC提交,則填寫客戶公司名稱)30. Description：Bug的具體描述，包括前題條件，發(fā)生步驟，實際結(jié)果，預(yù)期結(jié)果，測試人員的聯(lián)系方式等重要信息31. Attachment：測試人員可以將Bug log信息，測試圖片，鈴聲等信息作為附件上

10、 傳到CQ中，作為研發(fā)人員復(fù)現(xiàn)、分析Bug的參考28.Bug type：發(fā)現(xiàn)bug類型(Degrade/New/Missed)29.PeerReview：代碼評審的ID，開發(fā)必填v 分配分配Bug操作指南（操作指南（Assign）SPDM需要每天查詢owner為自己的Bug，確認(rèn)bug是否屬于本部門。如果是，根據(jù)Bug的實際描述分配給TL/Feature owner，重新定義Bug解決優(yōu)先級別以及計劃解決Bug的due date；如果不是，需要和HPDM溝通確認(rèn)后再修改owner department為HW/ME分配任務(wù)要在一個工作日內(nèi)完成，QA會抽查沒有及時被分配的bug并進(jìn)行highlig

11、htSW部門要定義每個feature的owner，便于PDM識別feature owner以及供測試人員溝通bug使用TL/Feature owner確認(rèn)是組/feature內(nèi)的bug后，通過modify Owner字段，最后將bug分配給實際的責(zé)任人（Real owner）分配過程中如出現(xiàn)轉(zhuǎn)Bug、Reject Bug，Duplicate Bug的需求，申請人首先要和關(guān)聯(lián)人員進(jìn)行充分溝通，達(dá)成一致后發(fā)出正式郵件向項目管理層申請并將郵件內(nèi)容通過modify notes字段填寫到CQ中 1）溝通）溝通Feature/Team間轉(zhuǎn)bug：Feature owner之間的溝通Reject bug：O

12、wner、testers、requirement、SPDM,TL之間的溝通Duplicate bug：Owner, testers, SPDM,TL之間的溝通vCQ中中assign Bug的操作過程的操作過程1.PDM在assign bug時，CQ會自動清空owner、priority字段，需要PDM重新定義2.如果PDM判定此記錄為三方bug，則需要在supplier字段中選擇三方名稱（PDM根據(jù)項目三方列表，可以向CM提出添加supplier list到CQ中）3.Due date的選擇需要符合release plan4.如果是交叉bug，測試人員識別的module name不夠準(zhǔn)確，PD

13、M是可以在 assign的時候進(jìn)行修改的5.需要必填carrier字段，標(biāo)識Bug在哪些版本上存在(通常用于指明不同的運營商) 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字段添加到CQ中，包括：做了哪些驗證Debug過程、方式和結(jié)果原因分析

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

15、是有效的。不該出現(xiàn)的分析如下：不該出現(xiàn)的分析如下：v在我的板子/手機上沒有發(fā)現(xiàn)Action: 用和測試工程師一樣的環(huán)境復(fù)現(xiàn)v新的版本中這個問題沒了Action: 查到root causev不是我的問題Action: 查到是誰的問題，并和他確認(rèn)v我覺得應(yīng)該這樣做（或者：XXX要求我這么做）Action: 需求都以DOORS中baselined的需求為準(zhǔn)，有變化需走需求變更v三天之內(nèi)沒有找出原因，填寫“正在分析中”，“空格”等無效信息Action: 向架構(gòu)和相關(guān)模塊負(fù)責(zé)人申請會審，尋求技術(shù)幫助，找到root cause后再open bugv CQ中中Open Bug的操作過程的操作過程1.Owne

16、r必填analysis字段：Bug的分析描述，包括Bug解決分析、驗證結(jié)果分析以及一些備注信息2.必填carrier字段，owner根據(jù)對bug的分析，可以修改PDM給出的carrier list3.如果是三方bug， 則需要在supplier字段中選擇三方名稱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è)慣例正常現(xiàn)象測試條件本身

17、存在問題該bug不屬于合理范圍內(nèi)的修改，比如baselined的需求定義以外的一些額外的功能等；3）必須征求submitter的意見，把root cause說清楚，得到認(rèn)同即可向PDM或TL提出申請2.在reject過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁v CQ中中reject Bug的操作過程的操作過程1. PDM或TL必填analysis字段，填寫經(jīng)大家同意的reject理由,將bug置為rejected狀態(tài)v Duplicate Bug的準(zhǔn)備工作的準(zhǔn)備工作1.Owner要明確duplicate的原則，才可以向PDM或TL申請duplicate bug 1）Bug描述的現(xiàn)象能夠重現(xiàn) 2）必須

18、是兩個或多個bugs的操作路徑和表現(xiàn)結(jié)果均一致。 保留先提交的bug，將后提交的一個或多個bugs置為duplicated， 并將先提交的bug Cust ID號記錄在后面被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é)果

19、”一致的認(rèn)定，必須征求submitter的意見，把root cause說清楚，得到認(rèn)同即可向PDM或TL提出申請 在duplicate過程中，如果發(fā)生爭執(zhí)，則要求QA仲裁v CQ中中duplicate Bug的操作過程的操作過程 Duplicate bug時，PDM或TL可以根據(jù)保留的bug carrier信息，填寫被duplicated掉的bug carrier字段 填寫保留的Bug Cust ID到Duplicate_ID字段中 將duplicate的原因記錄在notes字段中v 延遲解決延遲解決Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Postpone）1.Owner要明確postpone的原則，才

20、可以向PDM申請postpone bug 1）經(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申請，抄送給Test leader，Submitter，TL，SQA3.郵件的收件人以及抄送人全部同意后，PDM才可postpone bug4.QA會抽查postponed bugs，如果發(fā)現(xiàn)理由不合理，可以將bug 重新打開v CQ中中postpone Bug的操作過程的操作過程1.P

21、DM要將合理的postpone 理由填寫到notes字段中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時，Owner無法復(fù)現(xiàn)bug 2）Resolve bug時，Owner無法確定bug是否在分支上被解決了 3）Release bug時，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)

22、bug，不代表該bug不存在在模擬器上驗證，無效2）對于not must的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信息以便分析解決 3. Owner需要發(fā)正式郵件向PDM或TL申請，并抄送給Test leader，Submitter，SQA4. 郵件的收件人以及抄送人全部同意后，P

23、DM或TL才可monitor bug 對于復(fù)現(xiàn)率低的bug，在verify bug時，測試人員無法確定bug是否在正式發(fā)布的版本 上被解決了，也可以monitor bug 所有被monitor的bug，需要由測試人員在后續(xù)的三個版本中（不包括當(dāng)前版本）進(jìn)行驗證；成功復(fù)現(xiàn)則fail掉 bug；如果沒有復(fù)現(xiàn)，測試leader在與SPDM確認(rèn)后，可以將bug verify 掉；如果有客戶，需要在verify之前得到客戶的確認(rèn)監(jiān)控過程中，測試人員需要通過modify的方式，將每個版本的復(fù)現(xiàn)結(jié)果記錄在CQ(包括測試的版本以及測試的次數(shù)，復(fù)現(xiàn)的次數(shù)等等）v CQ中中monitor Bug的操作過程的操作過

24、程1.如果bug在沒有release之前被monitor，PDM需要必填Released SW version和 Released HW version字段，給測試人員在后續(xù)三個版本中復(fù)現(xiàn)bug提供參考版本2.PDM需要將monitor的理由必填到notes字段中v 重新打開重新打開Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Reopen）1.當(dāng)測試人員不同意reject或duplicate bug，可以在得到研發(fā)人員同意后reopen bug2.Owner在release時，發(fā)現(xiàn)bug仍然存在，需要將bug reopen3.當(dāng)延遲解決的bug具備解決條件后，Owner，PDM，TL都可以將bug reop

25、en4.當(dāng)QA認(rèn)為postpone bug原因不合理時，可以將bug reopenv CQ中中reopen Bug的操作過程的操作過程1.可以修改可以修改carrier字段字段2.將將reopen的原因填寫在的原因填寫在analysis字段字段中中v 解決解決Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Resolve） 在對Bug產(chǎn)生的原因進(jìn)行細(xì)致分析后，Owner需要確認(rèn)bug 初步的解決方案 在分支上實施解決方案后，進(jìn)行單元測試以及代碼評審活動。 單元測試通過后，需要在peer review 工具中提交申請并組織正式評審會議 1）評審?fù)ㄟ^后，owner將要合并的分支提交給軟件集成工程師（SW build

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

27、，列出已被Verify或Close的Peer Review ID list； 2）未勾上，則反列出Submitted、Failed或Resolved狀態(tài)的Peer Review ID listv 發(fā)布發(fā)布Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Release） 軟件集成工程師（SW build engineer）將提交的分支進(jìn)行集成，并在軟件內(nèi)部發(fā)布此版本 Owner要在發(fā)布的軟件上進(jìn)行驗證 1）如果驗證通過，在軟件集成工程師提交的軟件發(fā)布計劃確認(rèn)單上進(jìn)行確認(rèn)，在確認(rèn)后的一個工作日內(nèi)將bug release并填寫發(fā)布版本號 2）如果驗證發(fā)現(xiàn)Bug仍然存在，owner需要將bug重新打開（reopen），

28、再次分析bug并找出新的solution3.驗證及release工作需要在版本發(fā)布后的一個工作日內(nèi)完成v CQ中中release Bug的操作過程的操作過程1.Owner在release bug時，可以修改carrier和Defect_Cause_Analysis字段的信息2.將通過集成驗證的最終解決方案記錄在analysis字段中3.將通過集成驗證的SW和HW版本號記錄在Released SW version和 Released HW version字段中4.將通過集成驗證的分支填寫在SW_Formal_Branch字段中v 驗證驗證Bug的準(zhǔn)備工作（的準(zhǔn)備工作（Verify）1.驗證驗證r

29、eleased bug 1）測試人員（一般是submitter）要在開發(fā)人員填寫的SW和HW發(fā)布版本號 上對released bug進(jìn)行驗證 2）如果發(fā)布版本號不是最新版本，測試人員需要在最新的版本上進(jìn)行驗證2.驗證驗證rejected & duplicated bug 1）在verify rejected或duplicated bug時，需要檢查reject和duplicate的理由是否和溝通的結(jié)果一致，duplicate ID是否填寫正確，確認(rèn)沒有問題后再verify bug 2）如果之前研發(fā)人員沒有和測試人員溝通，當(dāng)測試人員不認(rèn)同bug的處理時，可以將bug重新reopenNot

30、es：Released bugs的驗證工作需要在版本正式發(fā)布后的一個工作日內(nèi)完成v CQ中中verify Bug的操作過程的操作過程1.在分析中填寫驗證概率、驗證人、驗證結(jié)果2.對某些需要驗證報告的bug，則需要提交驗證報告作為附件。3.如果驗證通過，verify bug 并填寫SW和HW驗證版本號4.如果驗證不通過，bug仍然存在，測試人員需要和owner溝通確認(rèn)后，再將bug fail掉v Fail Bug的準(zhǔn)備工作的準(zhǔn)備工作1.測試人員驗證released bug時，發(fā)現(xiàn)bug仍然存在，需要將bug fail掉2.QA抽查verify掉的bug時，發(fā)現(xiàn)bug仍然存在，需要將bug fai

31、l掉3.被Monitor掉的bug，測試人員在監(jiān)控三個版本的過程中，如果復(fù)現(xiàn)成功，需要將bug fail掉4.在fail之前都要和研發(fā)人員溝通確認(rèn)后再執(zhí)行操作v CQ中中fail Bug的操作過程的操作過程1.可以修改carrier字段2.測試人員或QA需要在analysis字段中填寫驗證不成功的原因說明（包括驗證概率、驗證人、驗證結(jié)果、驗證不成功具體原因描述）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為reje

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

33、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 screen, function failureThe function

34、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 accord with performance requirementThe

35、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 little difference with UI SpecThe M

36、E 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. PriorityDefinition of Priority1-Resolve Immediately Resolve

37、 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.Frequency定義DefinitionMust100%OftenMore than50%OccasionalBetween 1% and 50%OnceOnly happens one tim