软件缺陷管理工作流程.docx

螆软件缺陷管理办法膄目的蚁本文档定义了软件缺陷管理流程和相关规则,确保软件缺陷管理的系统性和规范性,以保证项目研发质量。肈适用范围薃适用于部门项目研发过程的缺陷管理,对各阶段的缺陷管理过程进行指导和规范。(Defect):存在于软件之中偏差,可被激活,以静态形式存在于软件内部。蚅Bug:缺陷一种表现形态,系统或程序存在的任何一种破坏正常运转能力的问题。(1)软件未达到需求规格说明书的功能;蕿(2)软件出现了需求规格说明书指明不会出现的错误;螆(3)软件功能超出需求规格说明书的范围;螄(4)软件未达到需求规格说明书未指出但应达到的目标;罿(5)测试工程师认为软件难以理解、不易使用、运行速度慢,或者最终用户认为不好。,或者重新被激活的状态。蒆激活状态的缺陷可以通过编辑来修改缺陷内容,并指派给合适的工程师处理。蚆解决状态莃缺陷被解决之后的状态。蒁激活状态的缺陷经过成功修复以后,由开发工程师操作为解决状态,系统将自动指派回创建者。芆关闭状态蒄解决状态的缺陷在验证通过后关闭,缺陷状态变为关闭,生命周期结束。蒁如果验证未修复或者新版本又发生,则重新激活,缺陷状态重新变为激活。(1)创建问题袃在测试管理系统中,所有用户都可以创建新问题,包括需求问题和软件缺陷等。创建问题时,需要描述清楚,并选择正确的选项,。资料个人收集整理,勿做商业用途莀(2)指派问题螇创建问题时,创建者通常要指派给该项目开发负责人,再由其指派任务,或直接指派给相应模块的开发工程师。薆如果指派人是错误的,或者需要他人确认或帮助,则可以重新指派给合适的工程师,写上相关备注。羂(3)确认问题蝿通常开发工程师收到新问题后,需要分析和确认此问题是否为Bug。如果是Bug,则选择“确认状态”;如果认为非Bug,则注明原因并指派回创建者。资料个人收集整理,勿做商业用途蒇当创建者收到确认指派时,需要进行及时确认。如果同意为非bug,则及时关闭它;如果不同意,则需要注明理由并指派回相关工程师。资料个人收集整理,勿做商业用途莄如果问题确认指派次数大于6次时,需要进入“争议处理”流程,。芄(4)解决问题腿此为开发工程师的主要职责,包括Bug的复现、修改和修改验证。膈开发工程师需要及时对确认状态Bug进行分析和解决,并自己验证通过,则操作为解决状态,,在缺陷管理系统中解决方案选择相应的选项,解决后系统将自动指派回给创建者。资料个人收集整理,勿做商业用途莅如果Bug无法解决或修改影响比较大,可申请进入“延期解决”流程,。蒃(5)验证问题袂创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过,则可关闭Bug;如果验证不通过,则激活此Bug,系统将自动指派回给解决者。资料个人收集整理,勿做商业用途羈验证通过准则:相同的操作步骤,进行一定次数的验证测试都没有发生。蒆验证不通过准则:相同的操作步骤,全部或部分实际结果还会发生,验证不通过则激活Bug。薁(6)关闭问题莂通过验证的Bug,验证者需要注明验证结果并进行关闭操作,系统将指派给Closed。虿如果关闭状态的Bug在之后版本又会发生,则激活此Bug,系统将自动指派回给解决者。(1)客户问题螁客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题,经确认后的Bug提交到测试管理系统,按照以上处理流程进行处理,由创建者或测试组进行跟踪验证关闭。资料个人收集整理,勿做商业用途葿创建客户问题时,创建者需要在Bug标题开头标记为[客户问题],测试组负责检查和更正。莅(2)争议处理肂当开发和测试工程师对某问题有争议并且多次沟通无果时(暂定为6次),可以注明双方的理由,并指派给项目经理进行处理。资料个人收集整理,勿做商业用途膀项目经理可以召开评审会议,或者直接与双方沟通了解,并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。资料个人收集整理,勿做商业用途腿(3)延期解决莇当开发工程师对确认Bug进行解决时,发现或评估其解决时间紧或风险比较大等,可以说明原因或理由并指派给项目经理来确认。资料个人收集整理,勿做商业用途莄项目经理可以召开评审会议,或者直接沟通了解,并根据项目情况给出最终决定。如果不同意,项目经理将此Bug指派回开发工程师,开发工程师继续分析和解决。如果同意,项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”,然后注明解决时间计划并指派回开发工程师,开发工程师