原创力文档- 1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
- 2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
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中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。
（5）验证问题
创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。
验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不
通过则激活Bug。
(6)关闭问题
通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给
Closed。
如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。
5.2特别处理过程
(1)客户问题
客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到的客户问题，经确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。
创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。
(2)争议处理
当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。
项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。
(3)延期解决
当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较大等，可以说明原因或理由并指派给项目经理来确认。
项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。
5.3缺陷管理工具
软件测试过程中所有缺陷要提交到公司测试管理系统进行跟踪管理。
(1)管理工具的作用
a.确保每个被发现的缺陷都能够被跟踪与处
文档评论（0）