缺陷管理流程.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2020年5月29日星期五,#,11 十一月 2026,缺陷管理流程,目的,为了帮助项目组成员更好的理解Bug处理过程，提高工作效率,规范行为准则；本文档对各部门项目组成员如何实施Bug处理过程进行了细化,Notes:如果在公司文档中发现有Error，Bug，Defect，PR等字样，请不要发生混淆，这四个代名词代表的都是产品缺陷,内容,1.参与Bug处理过程之前，我们需要做好哪些准备工作？,2.缺陷状态转移图,3.各个角色的权限及职责,4.Bug处理过程中都包括哪些子过程？,5.每个子过程都是如何实施的？,6.附录,参与Bug处理过程准备工作,1.确认PC可以访问Bug管理工具,BYD使用IBM公司的Clear quest工具管理bug，登陆方式分为Web方式和客户端方式，这两种方式都可以采用。,2.确认拥有CQ登陆账号,每位项目组成员都需要向SCM申请Clear quest工具账号，SPDM审批即可,3.确认CQ的操作权限,CQ为bug处理过程中涉及到的角色分配了操作权限。,如果没有权限，请向CM提出申请，CM会根据申请人的角色开放操作权限,4.识别工作过程中的相关人员以及联系方式,包括 PDM,Team leader，Feature owner，Testers，test leader以及SQA,发生问题时，电话、当面沟通是最有效的沟通方式，,Email的作用只是要留证据和highlight,5.确认参与了Bug管理过程培训,QA会为项目组成员培训Bug管理过程，如果是新加入到项目组的工程师且,没有参加过培训，请联系QA,缺陷跟踪流程状态转移图,Action:,Submit,Assign,Open,Resolve,Release,Verify,Close,Postpone,Fail,Monitor,Reject,Duplicate,Discard,Reopen,Re-Verify,Re-reject,Re-duplicate,Notes:,All actions which are marked by pink color are done by ST.,角色和职责,Roles,SPDM,QA,Test leader&Testers,SW TL,Owner,Submitter,Submit,Assign,Postpone,Open,Reopen,Fail,Resolve,Release,Reject,Duplicate,Monitor,Verify,Close,Discard,Re-reject,Re-duplicate,Re-verify,Actions,Bug处理过程实施基本原则,提交Bug准备工作（Submit）,1.测试人员发现Bug后，要依照本部门Bug描述模板，将Bug信息填写完整，选用本部门常用词进行描述，语言尽量简洁，清晰，完整，不要出现生僻词；,（Bug描述模板是可以根据项目实际需求进行裁剪的）,2.测试组长每天要检查测试人员提交的Bug list，确认每个Bug的信息是否填写完整，Bug描述是否清晰，Bug是否有效等,3.经过测试组长确认的Bug，测试人员才可以提交到Clear quest工具中,4.Bug的,提交要在一个工作日内完成,Bug处理过程实施基本原则,CQ中提交Bug的操作过程,1.测试人员提交Bug时，需要先选择,Owner department,，确认是SW的问题，即选SW，HW即选HW，其他同理,2.再根据项目名称，选择,Project,3.其他字段可以不分顺序进行填写，标识红色字段为必填项，如果有必填项为空，是不能提交当前记录的,4.提交Bug时填写的字段注释如下：,Bug处理过程实施基本原则,3.,Headline,:,Bug的概要描述，测试人员要使用能突出Bug失效现象的词语，,如Freeze，Halt，Restart，function failure等，,4.,Owner,:,选择PDM或者feature owner.,5.,Owner_Department,:,选择Bug owner所属部门,必须首先选择此字段,6.,Submitte,r:系统自动生成为提交人员,7.,Supplier,:测试部门可选，主要是研发部门使用，,三方bug时，选择三方名称；不是，则空；,8.,Priority,:,解决Bug的优先级别（1,2,3,4），具体定义参考附录“Priority definition”,9.,Severity,:,Bug 的严重程度（S,A,B,C,D），具体定义参考附录“Severity definition”,10,.,SWVersion,:,发生Bug的软件版本,11.,Project,:,项目名称,1.,Cust_ID,:自动生成(项目名称简写_P+自定义的连续ID),2.,State,:Bug当前处理状态，参考Bug状态迁移图,Bug处理过程实施基本原则,12.SW_Sub_Version:,软件版本的补充，用于具体表明同一个版本不同的软件(比如不同运营商)，同软件版本组合在一起进行使用(内容是运营商三个字母的缩写),13.,Platform,:与Project关联，选择project后自动生成,14.,HWVersion,:,发生Bug的硬件版本,15.,FoundMethod,：,Bug的发现途径，,具体定义参考附录“FoundMethod definition”,16.,MEVersion,:SW测试部门和SW部门可选，主要是PV,HW&ME部门使用；,发生Bug的结构版本,17.,Repeatable,：,Bug发生频率，具体定义参考附录“Frequency definition”,18.,ModuleName,:,发生Bug的模块,19.,DueDate,:研发部门使用；标识计划解决Bug的日期,20.SubModule,:测试部门可选，发生 Bug的子模块，与Module关联,Bug处理过程实施基本原则,21.,Tested_Times,:,测试,次数/样机数量,22.,Failed_Times,:,失效,次数/样机数量,23.,FailRatio,:失效比率（自动生成）,24.,Mobile_No,：,发生Bug的手机编号（,测试手机的唯一标识，不是测试卡的号码,）,25.,Customer Defect ID,：BTC代替客户提交Bug时必填，记录客户的Bug ID,26.,Testcase_ID,：,提交时根据测试类型可选,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,Bug处理过程实施基本原则,27.,Company：,提交Bug人员所在公司,(如果是客户要求BTC提交,则填写客户公司名称),30.,Description,：,Bug的具体描述，包括前题条件，发生步骤，实际结果，,预期结果，测试人员的联系方式等重要信息,31.,Attachment,：测试人员可以将Bug log信息，测试图片，铃声等信息作为附件上,传到CQ中，作为研发人员复现、分析Bug的参考,28.,Bug type,：发现bug类型(Degrade/New/Missed),29.,PeerReview,：代码评审的ID，开发必填,Bug处理过程实施基本原则,分配Bug操作指南（Assign）,SPDM需要每天查询owner为自己的Bug，确认bug是否属于本部门。如果是，根据Bug的实际描述分配给TL/Feature owner，重新定义Bug解决优先级别以及计划解决Bug的due date；如果不是，需要和HPDM沟通确认后再修改owner department为HW/ME,分配任务要在一个工作日内完成,，QA会抽查没有及时被分配的bug并进行highlight,SW部门要定义每个feature的owner，便于PDM识别feature owner以及供测试人员沟通bug使用,TL/Feature owner确认是组/feature内的bug后，,通过modify Owner字段,，最后将bug分配给实际的责任人（Real owner）,分配过程中,如出现转Bug、Reject Bug，Duplicate Bug的需求，,申请人首先要和关联人员进行充分沟通，达成一致后发出正式邮件向项目管理层申请并将邮件内容,通过modify notes字段填写到CQ中,1）沟通,Feature/Team间转bug：Feature owner之间的沟通,Reject bug：Owner、testers、requirement、SPDM,TL之间的沟通,Duplicate bug：Owner,testers,SPDM,TL之间的沟通,Bug处理过程实施基本原则,CQ中assign Bug的操作过程,1.PDM在assign bug时，CQ会自动清空,owner、priority字段,，需要PDM重新定义,2.如果PDM判定此记录为三方bug，则需要在,supplier字段,中选择三方名称,（PDM,根据项目三方列表，可以向CM提出添加supplier list到CQ中）,3.Due date,的选择需要符合release plan,4.如果是交叉bug，测试人员识别的module name不够准确，PDM是可以在,assign的时候进行修改的,5.需要,必填carrier字段,，标识Bug在哪些版本上存在(通常用于指明不同的运营商),Bug处理过程实施基本原则,分析Bug的准备工作（Open）,Owner一定要在发生bug的版本上复现bug，而且要严格按照bug的发现步骤和环境,对于bug描述不清或不完整，需要修改的情形，owner和测试沟通清楚，由testers或者test leader进行修改,有些bug会有附件，一定要查看attachment处是否有附件，供分析bug使用,在分析的过程中，要将所有的分析结果,通过modify notes字段,添加到CQ中，包括：,做了哪些验证,Debug过程、方式和结果,原因分析,如果确认bug是自己的，需要在,三天之内open bug,，同时需要,将最初始的分析结果（root cause）记录在analysis 字段中,6.,Owner要有时间观念,：PDM预先给定一个Due Date,如果有问题，可以反馈回来；并给出合理的理由,如果没有问题，就按照这个时间计划发布版本；,任何delay都是不允许的；即使是他人问题导致，也要在due date到来前和PDM 沟通原因，才可被接受,7.,PDM对于Owner提出的要求要做出积极响应，实时关注bug的解决情况，,如果发现会有delay，要及时和owner沟通，采取措施帮助owner尽量避免发生delay,Bug处理过程实施基本原则,8.Owner必须保证填写的分析是有效的。,不该出现的分析如下：,在我的板子/手机上没有发现,Action:用和测试工程师一样的环境复现,新的版本中这个问题没了,Action:查到root cause,不是我的问题,Action:查到是谁的问题，并和他确认,我觉得应该这样做（或者：XXX要求我这么做）,Action:需求都以DOORS中baselined的需求为准，有变化需走需求变更,三天之内没有找出原因，填写“正在分析中”，“空格”等无效信息,Action:向架构和相关模块负责人申请会审，寻求技术帮助，找到root cause后再open bug,Bug处理过程实施基本原则,CQ中Open Bug的操作过程,1.Owner必填,analysis字段,：Bug的分析描述，包括Bug解决分析、验证结果分析以及一些备注信息,2.必填,carrier字段,，owner根据对bug的分析，可以修改PDM给出的carrier list,3.如果是三方bug，则需要在,supplier字段,中选择三方名称,Bug处理过程实施基本原则,Reject Bug的准备工作,1.Owner要,明确reject的原则,，才可以向PDM或TL申请reject bug,1）Bug描述的现象能够重现,2）经确认（确认方式：Submitter，UI,requirement owner，SPDM，TL一起确认）存在以下问题：,该现象属于符合规范、标准或行业惯例正常现象,测试条件本身存在问题,该bug不属于合理范围内的修改，比如baselined的需求定义以外的一些额外的功能等；,3）必须征求submitter的意见，把,root cause,说清楚，得到认同即可向PDM或TL提出申请,2.在reject过程中，如果发生争执，则要求QA仲裁,Bug处理过程实施基本原则,CQ中reject Bug的操作过程,1.PDM或TL必填,analysis字段,，填写经大家同意的reject理由,将bug置为rejected状态,Bug处理过程实施基本原则,Duplicate Bug的准备工作,1.Owner要,明确duplicate的原则,，才可以向PDM或TL申请duplicate bug,1）Bug描述的现象能够重现,2）必须是两个或多个bugs的,操作路径,和,表现结果,均一致。,保留先提交的bug，将后提交的一个或多个bugs置为duplicated，,并将先提交的bug Cust ID号记录在后面被duplicated掉的bugs上,何谓“操作路径”一致？,两个或多个bugs的所有操作步骤均一致，错误表现也一致,两个或多个bugs入口不一样，但后面的操作步骤和表现结果均一致，比如：,Bug1：步骤1，步骤2，步骤3，步骤4，步骤5,Bug2：步骤1，步骤2，步骤3，步骤4，步骤5,这两个bugs前2步不同，但错误发生在步骤3/4/5中，而且错误表现也一样，我们可以认为“操作路径”一致,3）对bugs之间的“操作路径”和“表现结果”一致的认定，必须征求submitter的意见，把root cause说清楚，得到认同即可向PDM或TL提出申请,Bug处理过程实施基本原则,在duplicate过程中，如果发生争执，则要求QA仲裁,CQ中duplicate Bug的操作过程,Duplicate bug时，PDM或TL可以根据保留的bug carrier信息，填写被duplicated掉的bug,carrier字段,填写保留的Bug Cust ID到,Duplicate_ID,字段,中,将duplicate的原因记录在,notes字段,中,Bug处理过程实施基本原则,延迟解决Bug的准备工作（Postpone）,1.Owner要,明确postpone的原则,，才可以向PDM申请postpone bug,1）经过分析（open）后，发现当前不具备解决条件的缺陷，例如:,平台限制,软件架构限制,第三方限制,Bug不会对用户使用产生负作用，但Bug的修改会带来负面的风险和更多的问题,2）一个bug被fail多次，PDM评估后认可bug不会对项目产生block,2.要发正式邮件向PDM申请，抄送给Test leader，Submitter，TL，SQA,3.邮件的收件人以及抄送人全部同意后，PDM才可postpone bug,4.QA会抽查postponed bugs，如果发现理由不合理，可以将bug 重新打开,CQ中postpone Bug的操作过程,1.PDM要将,合理的postpone 理由填写到notes字段,中,Bug处理过程实施基本原则,监控Bug的准备工作（Monitor）,1.对于复现率低的bug，如果发生以下情况，Owner可以向PDM或TL申请monitor bug；1）分析（open）bug时，Owner无法复现bug,2）Resolve bug时，Owner无法确定bug是否在分支上被解决了,3）Release bug时，Owner无法确定bug是否在集成版本上被解决了,2.在申请之前：,1）Owner必须将,试图复现bug的操作，重现次数等信息记录在,notes字段,中；,在重现bug的时候一定要在发现bug的版本上验证：,在当前版本没有发现bug，不代表该bug不存在,在模拟器上验证，无效,2）,对于not must的bug，需要测试100次以上,3）,如果这个Bug是很难复现，但测试已经提供了必要的Log文件，则测试,不负责复现,；,如果owner经过多次验证仍然不能复现的bug，可以向,PDM申请专项测试,4）专项测试的次数定义原则为：申请测试次数为50的倍数且不少于Fail_total值的分母,5）如果成功复现bug，测试人员需要及时通知owner并试图抓取trace信息以便分析解决,3.Owner需要发正式邮件向PDM或TL申请，并抄送给Test leader，Submitter，SQA,4.邮件的收件人以及抄送人全部同意后，PDM或TL才可monitor bug,对于复现率低的bug，在verify bug时，测试人员无法确定bug是否在正式发布的版本,上被解决了，也可以monitor bug,所有被monitor的bug，需要由测试人员在后续的三个版本中（不包括当前版本）进行验证；成功复现则fail掉 bug；如果没有复现，,测试leader在与SPDM确认后,，可以将bug verify 掉；如果有客户，需要在verify之前得到客户的确认,监控过程中，测试人员需要通过modify的方式，将每个版本的复现结果记录在CQ(包括测试的版本以及测试的次数，复现的次数等等）,CQ中monitor Bug的操作过程,1.如果bug在没有release之前被monitor，PDM需要必填,Released SW version和 Released HW version字段,，给测试人员在后续三个版本中复现bug提供参考版本,2.PDM需要将monitor的理由必填到,notes字段,中,Bug处理过程实施基本原则,Bug处理过程实施基本原则,重新打开Bug的准备工作（Reopen）,1.当测试人员不同意reject或duplicate bug，可以在得到研发人员同意后reopen bug,2.Owner在release时，发现bug仍然存在，需要将bug reopen,3.当延迟解决的bug具备解决条件后，Owner，PDM，TL都可以将bug reopen,4.当QA认为postpone bug原因不合理时，可以将bug reopen,CQ中reopen Bug的操作过程,1.可以修改,carrier字段,2.将reopen的原因填写在,analysis字段,中,Bug处理过程实施基本原则,解决Bug的准备工作（Resolve）,在对Bug产生的原因进行细致分析后，Owner需要确认bug 初步的解决方案,在分支上实施解决方案后，进行单元测试以及代码评审活动。,单元测试通过后，需要在peer review 工具中提交申请并组织正式评审会议,1）评审通过后，owner将要合并的分支提交给软件集成工程师（SW build engineer），将状态设置为resolved 并填写通过验证的解决方案；,2）评审没有通过，owner需要修改评审issue直到评审通过为止,CQ中resolve Bug的操作过程,1.Owner在resolve bug时，可以修改,carrier字段,的信息,2.将通过验证的解决方案（solution）记录在,analysis,字段中,3.选择Bug发生原因分类，填写在,Defect_Cause_Analysis字段,中，具体分类参考“Defect Cause Analysis,4.还需要选择对应的,peer review ID,。Peer Review ID字段添加了勾选框;,1）当该框被勾上，列出已被Verify或Close的Peer Review ID list；,2）未勾上，则反列出Submitted、Failed或Resolved状态的Peer Review ID list,Bug处理过程实施基本原则,发布Bug的准备工作（Release）,软件集成工程师（SW build engineer）将提交的分支进行集成，并在软件内部发布此版本,Owner要在发布的软件上进行验证,1）如果验证通过，在软件集成工程师提交的软件发布计划确认单上进行确认，在确认后的一个工作日内将bug release并填写发布版本号,2）如果验证发现Bug仍然存在，owner需要将bug重新打开（reopen），再次分析bug并找出新的solution,3.,验证及release工作需要在版本发布后的一个工作日内完成,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字段,中,Bug处理过程实施基本原则,验证Bug的准备工作（Verify）,1.验证released bug,1）测试人员（一般是submitter）要在开发人员填写的SW和HW发布版本号,上对released bug进行验证,2）如果发布版本号不是最新版本，测试人员需要在最新的版本上进行验证,2.验证rejected&duplicated bug,1）在verify rejected或duplicated bug时，需要检查reject和duplicate的理由是否和沟通的结果一致，duplicate ID是否填写正确，确认没有问题后再verify bug,2）如果之前研发人员没有和测试人员沟通，当测试人员不认同bug的处理时，可以将bug重新reopen,Notes：Released bugs的验证工作需要在版本正式发布后的一个工作日内完成,Bug处理过程实施基本原则,CQ中verify Bug的操作过程,1.在分析中填写验证概率、验证人、验证结果,2.对某些需要验证报告的bug，则需要提交验证报告作为附件。,3.如果验证通过，verify bug 并填写SW和HW验证版本号,4.如果验证不通过，bug仍然存在，测试人员需要和owner沟通确认后，再将bug fail掉,Bug处理过程实施基本原则,Fail Bug的准备工作,1.测试人员验证released bug时，发现bug仍然存在，需要将bug fail掉,2.QA抽查verify掉的bug时，发现bug仍然存在，需要将bug fail掉,3.被Monitor掉的bug，测试人员在监控三个版本的过程中，如果复现成功，需要将bug fail掉,4.在fail之前都要和研发人员沟通确认后再执行操作,CQ中fail Bug的操作过程,1.可以,修改carrier字段,2.测试人员或QA需要在,analysis字段,中填写验证不成功的原因说明（包括验证概率、验证人、验证结果、验证不成功具体原因描述）,Bug处理过程实施基本原则,关闭/丢弃Bug的准备工作（Closed/Discard）,QA要对verify掉的bug进行关闭和丢弃。,1)当close type为released，则close bug;,2)当close type为rejected和duplicated，则discard bug;,流程方面，关闭和丢弃bug时，QA需要检查Bug信息是否填写完整，信息是否有效？是否符合流程定义？,产品方面：对于有效bug，QA还需要抽查verify掉的bug，是否真的被解决了；如果没有，可以fail 掉bug；,关闭/丢弃bug的工作需要在bug被verify掉后的一个工作日内完成,CQ中close/discard Bug的操作过程,1.直接在CQ中执行close/discard操作即可,附录1Severity definition,Severity,Definition of Severity,S-Fatal,Severity issue,e.g.hurt body or lost customer info.,The Software system crash and cant resume by oneself,A-Serious,Customer data lost but can resume,SW system crash but can resume,Affect customer operation badly like the often use function have high failure rate reset,freeze,mess up,confusion screen,function failure,The function problem can not resume that will affect phone used The serious ME problem that maybe affect used function,Most customers will return it,B-Moderate,Customer often use function have low failure rate reset,freeze,mess up,confusion screen,function failure,It cant accord with performance requirement,The 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 it,C-Minor,System function target implement basically,SW function accord with requirement basically,but have a little difference with UI Spec,The ME part disabled but can resume and slight appearance problems,The problems that Most customers could tolerance or can be ignore,D-Suggestion,Interface display accords with requests but the consumer use uncomfortably or use interface unkindly.,附录2Priority definition,Priority,Definition of Priority,1-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 Queue,Defect needs to be resolved within 2 next releases.,4-Low Priority,Defect needs to be resolved within 3 next releases.,附录3Frequency definition,Frequency,定义,Definition,Must,100%,Often,More than50%,Occasional,Between 1%and 50%,Once,Only happens one time,