软件缺陷管理系统流程.docx

软件缺陷管理方法
目的
本文档定义了软件缺陷管理流程和相关规如此，确保软件缺陷管理的系统性和规X性，以保证项目研发质量。
适用X围
适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进展指导和规X。
定义
术语
缺陷〔Defect〕：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。
缺陷定义
〔1〕软件未达到需求规格说明书的功能；
〔2〕软件出现了需求规格说明书指明不会出现的错误；
〔3〕软件功能超出需求规格说明书的X围；
〔4〕软件未达到需求规格说明书未指出但应达到的目标；
〔5〕测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
缺陷生命周期

缺陷状态说明
缺陷状态
状态说明
激活状态
缺陷的初始状态，或者重新被激活的状态。
激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给适宜的工程师处理。
解决状态
缺陷被解决之后的状态。
激活状态的缺陷经过成功修复以后，由开发工程师操作为解决状态，系统将自动指派回创建者。
关闭状态
解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期完毕。
如果验证未修复或者新版本又发生，如此重新激活，缺陷状态重新变为激活。

正常处理过程
〔1〕创建问题
在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，。
〔2〕指派问题
创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
如果指派人是错误的，或者需要他人确认或帮助，如此可以重新指派给适宜的工程师，写上相关备注。
〔3〕确认问题
通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，如此选择“确认状态〞；如果认为非Bug，如此注明原因并指派回创建者。
当创建者收到确认指派时，需要进展与时确认。如果同意为非bug，如此与时关闭它；如果不同意，如此需要注明理由并指派回相关工程师。
如果问题确认指派次数大于6次时，需要进入“争议处理〞流程，。
〔4〕 解决问题
此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要与时对确认状态Bug进展分析和解决，并自己验证通过，如此操作为解决状态，，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
如果Bug无法解决或修改影响比拟大，可申请进入“延期解决〞流程，。
〔5〕 验证问题
创建者需要与时对解决状态的Bug在对应版本上面进展验证。如果验证通过，如此可关闭Bug；如果验证不通过，如此激活此Bug，系统将自动指派回给解决者。
验证通过准如此：一样的操作步骤，进展一定次数的验证测试都没有发生。
验证不通过准如此：一样的操作步骤，全部或局部实际结果还会发生，验证不通过如此激活Bug。
(6) 关闭问题
通过验证的Bug，验证者需要注明验证结果并进展关闭操作