软件缺陷管理作业流程.docx

软件缺点管理措施
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. 确保每个被发觉缺点全部能够被跟踪和处理。
b. 搜集缺点数据并依据缺点趋势曲线识别或汇报测试状态。
c. 搜集缺点数据并在其上进行数据分析，作为测试评定依据。
（2）缺点驱动标准
缺点管理系统关键经过指派状态来驱动相关开发工程师、测试工程师和项目经理立即地处理问题，以提升研发效率，所以会尤其关注缺点指派给谁和停留时间，并反馈在定时汇报。
所以，缺点驱动标准：尽可能不要让缺点挂在你身上。
5.4. 缺点属性定义
(1) 缺点相关属性
缺点属性
说明
缺点ID
缺点ID是标识某个缺点一组符号。每个缺点必需有一个唯一ID。
缺点类型
缺点类型是依据缺点自然属性划分缺点种类。
严重程度
缺点严重程度是指因缺点引发失效对软件产品影响程度。
发生概率
缺点发生概率指缺点根据测试操作步骤发生概率情况。
处理方案
缺点处理方案是指缺点被处理掉处理方案。
缺点描述
缺点描述是对缺点汇报，包含标题、操作步骤和结果等。

(2) 缺点类型说明
类型名称
说明
设计缺点
因为软件设计或代码实现所产生功效或步骤问题。
界面问题
系统页面展示问题。
数据问题
系统数据起源，处理及处理结果问题。
需求问题
软件需求测试发觉问题，也包含以后需求变更问题。
安装布署
软件安装布署过程错误。
性能问题
软件性能相关缺点。
文档问题
用户使用手册，软件帮助文档等出现问题
常识问题
系统用户正常使用习惯相关问题。
安全问题
系统漏洞安全问题。
优化提议
针对操作过程逻辑或界面显示优化性提议。
其它
除前面分类其它问题

3) 严重程度定义
严重程度
定义和说明
致命

阻碍开发或测试工作继续进行系统性故障，
比如：
Ø 实现功效和产品定义或软件需求规格严重不符。
Ø 系统无法实施、瓦解、冻结，死循环等。
Ø 程序引发死机，非法退出。
Ø 关键功效模块严重错误。
Ø 数据库链接错误，严重数据计算错误通讯错误等。
严重

系统出现严重错误，但不影响目前测试工作错误。
比如：
Ø 模块功效错误，模块功效未实现，乱码等；
Ø 功效错误，如链接模块有误，基础按键使用有误等。
Ø 数据错误，如用户数据丢失、破坏、计算、保留有误等。
通常

不影响用户使用非严重问题
Ø 次要功效未实现或和需求不符。
Ø 操作界面错误，如界面图表或字符通常性错误，但不影响操作。
Ø 提醒信息错误，辅助说明不清楚。
Ø 数据错误，数据边界、格式约束未实现或需求不一致
提议
测试过程中发觉不利用户操作优化提议。
Ø 界面字符或提醒和显示不合适。
Ø 页面或操作习惯优化性提议。
Ø 功效操作愈加好实现方法。
注：严重等级由创建者在创建缺点时依据此定义来选择，以后全部不能随意更改。

(5) 优先级定义
优先级
定义和说明
立即
阻碍测试工作无法进行，需要开发工程师立即处理问题。
Ø 全部致命问题全部需要立即处理；
Ø 时间紧迫时影响版本上线问题等；
紧急
不影响测试工作严重问题，下个测试版本发版前必需处理。
Ø 全部严重问题；
Ø 常见模块功效、业务逻辑或数据错误；
Ø 显著性能问题；
立即
通常性功效错误，版本公布前应该处理问题。
Ø 大多数通常问题；
Ø 页面显示，页面字符，界面图标、文字显示、链接有误，不影响使用。如错别字，图标显示异常等；
通常
不影响版本上线问题，部分问题许可不修改。
Ø 很用界面或字符显示错误或不合适；
Ø 用户使用习惯，语言表示等优化提议；
注：立即、紧急、立即问题全部要求在系统上线前处理。

(6)发生概率定义
发生概率
定义说明
验证问题最小次数
必现
100%。 测试5次，出现5次。
5次
常常
100%>&>=30%。测试5次，出现3~4次；
或测试10次，出现3次及以上；
或测试15次，出现5次及以上。
10次
偶然
30%>&>=10%。 测试10次，出现2次；
或测试15次，出现2~4次。
20次
随机
<10%。 测试15次，出现1次。
30次

(7)处理状态说明
处理状态
相关规则
确定中
当问题确定过程时，能够选择这状态来说明。
处理中
开发工程师设置此状态。当Bug正在分析或处理时，可选这状态来说明。
复现中
当正在复现问题，或正在跟踪测试问题，能够选择这状态来说明。
验证中
当验证随机问题等需要长时间，能够选择这状态来说明。
延期处理
项目经理才能设置此状态，参考5.2

(8) 处理方案定义和规则
处理方案
方案说明
相关规则
已经处理
缺点被修复或更正，并经过其验证测试。
开发工程师权限，处理时需要填写“处理版本”和注明Bug原因等。
反复缺点
相同缺点她人已经提交，或开发认为原因是相同
开发工程师权限，处理时需要填写正确反复缺点 ID。
无效缺点
设计如此，不是问题，优化提议不采纳，没法处理第三方问题。
开发工程师需要和创建者沟通说明，直到创建者同意，开发工程师才能选择此方案。
无法复现
开发和测试工程师没法复现又不能处理问题，而且跟踪测试二个以上版本也不能复现。
开发和测试工程师经过努力也不能复现，并由测试工程师跟踪测试二个以上版本，开发工程师才能选择此方案。
延期处理
开发工程师Bug进行处理时，发觉或评定其处理时间紧或风险比较大等，向项目经理说明原因。
项目经理权限，项目经理综合经过考虑处理问题时间、风险、市场需求等多方面要素决定是否选择此方案
注：无法复现问题将作为风险评定点。
5.5 缺点描述规范
（1）缺点标题
缺点标题是对所提交缺点概述，需要简短而正确描述出缺点概要信息，并使用部分精炼关键词，关键内容包含：位置+对象+动作+现象。
a. 环境关键词：包含数据环境，时间环境，地点环境条件环境，描述缺点发生时所处背景环境，或正在实施操作或所处界面环境，如“在…”页面，“当…时…”，“在…过程中…”等；
b. 动作关键词：引发缺点所实施操作，如“点…键”“选…选项”等；
c. 对象关键词：描述缺点出现对象，“页面”，“显示框” ，“图表”等；
d. 现象关键词：描述缺点出现现象，如“显示为负数”，“卡死”等。
依据上述关键词组合来描写缺点标题。
（2）重现步骤
在描述缺点重现步骤过程中，通常需要经过描述前提条件，测试步骤，实际结果，期望结果这四个方面清楚具体描述缺点。
a. 前提条件
外部环境，这里包含网络环境，硬件环境和软件环境状态。默认情况下，无需特殊说明，前提条件均为“系统正常运行”，其含义为网络正常，电脑硬件环境能支撑软件运行，系统软件配置情况正常。需要注意，软件环境有可能引发缺点功效模块所处状态，和重现该缺点需要模块相关状态或特殊设置情况应该前在前提条件中做说明。
数据环境，对缺点产生所在案件或引发bug现象数据输入和数据设计等应该在前提条件中做对应说明。
总而言之，这里对缺点现象重现紧密相关预先设置，或和缺点模块相关联预先设置全部应该在前提条件中说明。
b. 测试步骤
这里需要具体描述出重现缺点操作步骤，方便于重现缺点，修复和验证缺点。在描写测试步骤时应该注意以下几点：
精简：只描述缺点必需细节；
单一：每个缺点单只汇报一个缺点；
步骤清楚：具体、有序描述出每一个步骤，包含输入数据情况，实施操作和实施操作界面。
操作量化：对操作次数描述需要量化，如“连续3次点确定键”等，尽可能避免出现“数次”等模糊词。
c. 实际结果
实际结果是指根据测试步骤操作后实际反应情况，这里指是缺点表现现象。这里应该具体描述犯错误现象，包含页面错误，连接错误，字符错误，业务步骤错误，数据错误等。
d. 期望结果
期望结果是指根据测试步骤操作，正常情况下正确实施测试步骤后应该满足设计要求结果。对于不确定期望结果就需要用到如提议，提醒等关键字。
（3） 附件
为了方便开发工程师分析和处理，创建缺点时需要添加必需附件，包含缺点现象图、测试数据文档，测试时用到其它特殊文件，测试脚本，操作步骤录像等。
所以，测试人员在测试过程中，要求每个缺点有现象截图，方便帮助开发人员快速定位问题。