软件缺点管理方法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的复现、修改和修改验证。开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺点管...
