原创力文档- 1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
- 2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
软件缺点管理措施
目标
本文档定义了软件缺点管理步骤和相关规则，确保软件缺点管理系统性和规范性，以确保项目研发质量。
适用范围
适适用于部门项目研发过程缺点管理，对各阶段缺点管理过程进行指导和规范。
定义
3.1术语
缺点（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺点一个表现形态，系统或程序存在任何一个破坏正常运转能力问题。
3.2缺点定义
（1）软件未达成需求规格说明书功效；
（2）软件出现了需求规格说明书指明不会出现错误；
（3）软件功效超出需求规格说明书范围；
（4）软件未达成需求规格说明书未指出但应达成目标；
（5）测试工程师认为软件难以了解、不易使用、运行速度慢，或最终用户认为不好。
缺点生命周期
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缺点管理工具
软件测试过程中全部缺点要提交到企业测试管理系统进行跟踪管理。
管理工具作用
确保每个被发觉缺点全部能够被跟踪和处理。
搜集缺点数据并依据缺点趋势曲线识别或汇报测试状态。
搜集缺点数据并在其上进行数据分析，作为测试评定依据。
（2）缺点驱动标准
缺
文档评论（0）