软件缺陷管理规范(1).docxVIP

软件缺陷管理规范 （ ISO9001：2015） 1. 目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规 范性，以保证项目研发质量。 2. 适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规 范。 3. 定义 3.1 术语 缺陷（Defect ）：存在于软件之中偏差， 可被激活， 以静态形式存在于软件内部。 Bug：缺陷一种表现形态， 系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （ 1 ）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认 为不好。 4. 缺陷生命周期 4.1 缺陷生命周期图 4.2 缺陷状态说明 缺陷状态激活状态 缺陷状态 激活状态 缺陷的初始状态，或者重新被激活的状态。 激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合 适的工程师处理。 解决状态缺陷被解决之后的状态。 解决状态 激活状态的缺陷经过成功修复以后，由开发工程师操作为解 决状态，系统将自动指派回创建者。 关闭状态解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭， 关闭状态 命周期结束。 如果验证未修复或者新版本又发生，则重新激活，缺陷状态 重新变为激活。 5. 缺陷处理过程 5.1 正常处理过程 （ 1）创建问题 在测试管理系统中， 所有用户都可以创建新问题， 包括需求问题和软件缺陷等。 创建问题时，需要描述清楚，并选择正确的选项，详细请参考 5.4 和5.5 。 （2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直 接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工 程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后， 需要分析和确认此问题是否为 Bug。如果是 Bug， 则选择“确认状态”；如果认为非 Bug，则注明原因并指派回创建者。 当创建者收到确认指派时， 需要进行及时确认。 如果同意为非 bug，则及时关闭 它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于 6 次时，需要进入“争议处理”流程，详细请参考 5.2 。 （4 ） 解决问题 此为开发工程师的主要职责，包括 Bug的复现、修改和修改验证。