缺陷管理流程（PPT35页)

CompanyConfidentialPage1Bug处理过程实施细则Page2DocNo:FMZ06-0006Ver:1.1CompanyConfidential目的为了帮助项目组成员更好的理解Bug处理过程，提高工作效率,规范行为准则；本文档对各部门项目组成员如何实施Bug处理过程进行了细化Notes:如果在公司文档中发现有Error，Bug，Defect，PR等字样，请不要发生混淆，这四个代名词代表的都是产品缺陷Page3DocNo:FMZ06-0006Ver:1.1CompanyConfidential内容1.参与Bug处理过程之前，我们需要做好哪些准备工作？2.缺陷状态转移图3.各个角色的权限及职责4.Bug处理过程中都包括哪些子过程？5.每个子过程都是如何实施的？6.附录Page4DocNo:FMZ06-0006Ver:1.1CompanyConfidential参与Bug处理过程准备工作1.确认PC可以访问Bug管理工具BYD使用IBM公司的Clearquest工具管理bug，登陆方式分为Web方式和客户端方式，这两种方式都可以采用。2.确认拥有CQ登陆账号每位项目组成员都需要向SCM申请Clearquest工具账号，SPDM审批即可3.确认CQ的操作权限CQ为bug处理过程中涉及到的角色分配了操作权限。如果没有权限，请向CM提出申请，CM会根据申请人的角色开放操作权限4.识别工作过程中的相关人员以及联系方式包括PDM,Teamleader，Featureowner，Testers，testleader以及SQA发生问题时，电话、当面沟通是最有效的沟通方式，Email的作用只是要留证据和highlight5.确认参与了Bug管理过程培训QA会为项目组成员培训Bug管理过程，如果是新加入到项目组的工程师且没有参加过培训，请联系QAPage5DocNo:FMZ06-0006Ver:1.1CompanyConfidential缺陷跟踪流程—状态转移图Action:SubmitAssignOpenResolveReleaseVerifyClosePostponeFailMonitorRejectDuplicateDiscardReopenRe-VerifyRe-rejectRe-duplicateNotes:AllactionswhicharemarkedbypinkcoloraredonebyST.Page6DocNo:FMZ06-0006Ver:1.1CompanyConfidential角色和职责RolesSPDMQATestleader&TestersSWTLOwnerSubmitterSubmitAssignPostponeOpenReopenFailResolveReleaseRejectDuplicateMonitorVerifyCloseDiscardRe-rejectRe-duplicateRe-verifyActionsPage7DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则提交Bug准备工作（Submit）1.测试人员发现Bug后，要依照本部门Bug描述模板，将Bug信息填写完整，选用本部门常用词进行描述，语言尽量简洁，清晰，完整，不要出现生僻词；（Bug描述模板是可以根据项目实际需求进行裁剪的）2.测试组长每天要检查测试人员提交的Buglist，确认每个Bug的信息是否填写完整，Bug描述是否清晰，Bug是否有效等3.经过测试组长确认的Bug，测试人员才可以提交到Clearquest工具中4.Bug的提交要在一个工作日内完成Page8DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则CQ中提交Bug的操作过程1.测试人员提交Bug时，需要先选择Ownerdepartment，确认是SW的问题，即选SW，HW即选HW，其他同理2.再根据项目名称，选择Project3.其他字段可以不分顺序进行填写，标识红色字段为必填项，如果有必填项为空，是不能提交当前记录的4.提交Bug时填写的字段注释如下：Page9DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则3.Headline:Bug的概要描述，测试人员要使用能突出Bug失效现象的词语，如Freeze，Halt，Restart，functionfailure等，4.Owner:选择PDM或者featureowner.5.Owner_Department:选择Bugowner所属部门,必须首先选择此字段6.Submitter:系统自动生成为提交人员7.Supplier:测试部门可选，主要是研发部门使用，三方bug时，选择三方名称；不是，则空；8.Priority:解决Bug的优先级别（1,2,3,4），具体定义参考附录“Prioritydefinition”9.Severity:Bug的严重程度（S,A,B,C,D），具体定义参考附录“Severitydefinition”10.SWVersion:发生Bug的软件版本11.Project:项目名称1.Cust_ID:自动生成(项目名称简写_P+自定义的连续ID)2.State:Bug当前处理状态，参考Bug状态迁移图Page10DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则12.SW_Sub_Version:软件版本的补充，用于具体表明同一个版本不同的软件(比如不同运营商)，同软件版本组合在一起进行使用(内容是运营商三个字母的缩写)13.Platform:与Project关联，选择project后自动生成14.HWVersion:发生Bug的硬件版本15.FoundMethod：Bug的发现途径，具体定义参考附录“FoundMethoddefinition”16.MEVersion:SW测试部门和SW部门可选，主要是PV,HW&ME部门使用；发生Bug的结构版本17.Repeatable：Bug发生频率，具体定义参考附录“Frequencydefinition”18.ModuleName:发生Bug的模块19.DueDate:研发部门使用；标识计划解决Bug的日期20.SubModule:测试部门可选，发生Bug的子模块，与Module关联Page11DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则21.Tested_Times:测试次数/样机数量22.Failed_Times:失效次数/样机数量23.FailRatio:失效比率（自动生成）24.Mobile_No：发生Bug的手机编号（测试手机的唯一标识，不是测试卡的号码）25.CustomerDefectID：BTC代替客户提交Bug时必填，记录客户的BugID26.Testcase_ID：提交时根据测试类型可选MarkY,needfillinwhensubmitandverify.IfmarkN,canfillinoptionallywhensubmitandverify.Iffoundmethodiscertificationtest,Testersneedtomarkcertificationtypein“headline”fieldPage12DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则27.Company：提交Bug人员所在公司(如果是客户要求BTC提交,则填写客户公司名称)30.Description：Bug的具体描述，包括前题条件，发生步骤，实际结果，预期结果，测试人员的联系方式等重要信息31.Attachment：测试人员可以将Buglog信息，测试图片，铃声等信息作为附件上传到CQ中，作为研发人员复现、分析Bug的参考28.Bugtype：发现bug类型(Degrade/New/Missed)29.PeerReview：代码评审的ID，开发必填Page13DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则分配Bug操作指南（Assign）1.SPDM需要每天查询owner为自己的Bug，确认bug是否属于本部门。如果是，根据Bug的实际描述分配给TL/Featureowner，重新定义Bug解决优先级别以及计划解决Bug的duedate；如果不是，需要和HPDM沟通确认后再修改ownerdepartment为HW/ME2.分配任务要在一个工作日内完成，QA会抽查没有及时被分配的bug并进行highlight3.SW部门要定义每个feature的owner，便于PDM识别featureowner以及供测试人员沟通bug使用4.TL/Featureowner确认是组/feature内的bug后，通过modifyOwner字段，最后将bug分配给实际的责任人（Realowner）5.分配过程中如出现转Bug、RejectBug，DuplicateBug的需求，申请人首先要和关联人员进行充分沟通，达成一致后发出正式邮件向项目管理层申请并将邮件内容通过modifynotes字段填写到CQ中1）沟通Feature/Team间转bug：Featureowner之间的沟通Rejectbug：Owner、testers、requirement、SPDM,TL之间的沟通Duplicatebug：Owner,testers,SPDM,TL之间的沟通Page14DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则CQ中assignBug的操作过程1.PDM在assignbug时，CQ会自动清空owner、priority字段，需要PDM重新定义2.如果PDM判定此记录为三方bug，则需要在supplier字段中选择三方名称（PDM根据项目三方列表，可以向CM提出添加supplierlist到CQ中）3.Duedate的选择需要符合releaseplan4.如果是交叉bug，测试人员识别的modulename不够准确，PDM是可以在assign的时候进行修改的5.需要必填carrier字段，标识Bug在哪些版本上存在(通常用于指明不同的运营商)Page15DocNo:FMZ06-0006Ver:1.1CompanyConfidentialBug处理过程实施基本原则分析Bug的准备工作（Open）1.Owner一定要在发生bug的版本上复现bug，而且要严格按照bug的发现步骤和环境2.对于bug描述不清或不完整，需要修改的情形，owner和测试沟通清楚，由testers或者testleader进行修改3.有些bug会有附件，一定要查看attachment处是否有附件，供分析bug使用4.在分析的过程中，要将所有的分析结果通过modifynotes字段添加到CQ中，包括：做了哪些验证Debug过程、方式和结果原因分析5.如果确认bug是自己的，需要在三天之内openbug，同时需要将最初始的分析结果（rootcause）记录在analysis字段中6.Owner要有时间观念：PDM预先给定一个DueDate如果有问题，可以反馈回来；并给出合理的理由如果没有问题，就按照这个时间计划发布版本；任何delay都是不允许的；即使是他人问题导致，也要在duedate到来前和PDM沟通原因，才可被接受7.PDM对于Owner提出的要求要做出积极响应，实时关注bug的解决情况，如果发现会有delay，要及时和owner沟通，采取措施帮助owner尽量避免发生delayPage