软件缺陷管理
软件缺陷-概念
软件缺陷-基本概念主要分为：缺陷、故障、失效。
·缺陷（Defect）：以静态形式存在于软件内部，相当于BUG；
· 故障（Fault）：软件运行中出现的状态，不处理可能会失效，以动态形式存在；
· 失效（Failure）：软件运行时产生的外部异常行为结果，与用户需求不一致。
缺陷不一定导致故障，故障也不一定会失效；缺陷导致故障，有可能导致失效，也有可能不会导致失效。
软件缺陷-定义
软件未达到产品说明书中已标明的功能软件未达到产品说明书中虽未指出但应达到的目标软件出现产品说明书中指明不会出现的错误软件功能超出了产品说明书中指明的范围软件测试人员认为软件中难以理解、不易使用、运行速度缓慢，或者最终用户认为不好缺陷的几种类型：
· 设计不合理;
· 功能、特性没有实现或部分实现;
· 运行出错，包括运行中断、系统崩溃、界面混乱等;
· 与需求不一致，在执行TestCase时则为实际结果和预期结果不一致;
· 用户不能接受的其他问题，如存取时间过长、界面不美观;软件实现了需求未提到的功能。
软件缺陷-产生的原因
人员沟通不到位，交流上有误解或根本不交流文档不完善需求不断的变化参与人员过度自信程序设计有误软件复杂性工期短、任务重、时间压力大软件开发工具与软硬件。
识别软件缺陷
· 通过测试用例中的预期结果进行识别通过需求规格说明书进行识别
· 通过用户手册及其他文档进行识别通过同行业相类似成熟的商业软件识别
· 通过与开发人员的沟通进行识别通过与有经验测试人员沟通进行识别
· 通过参照同行业隐式需求进行识别
软件缺陷-组织架构
· 缺陷的标题（一句话简单描述问题）
· 缺陷的基本信息
· 测试的软件和硬件环境
· 测试的软件版本
· 缺陷的类型
· 缺陷的严重程度
· 缺陷的处理优先级
· 缺陷的操作步骤（测试步骤、预期结果、实测结果）
· 备注/注释文字和截图
软件缺陷-相关属性
缺陷相关属性：提交人、提交日期、BUG状态、严重程度、缺陷优先级、缺陷版本、修复日期。
1.缺陷发现人：最直接的是测试人员，测试人员发现的BUG数是进行个人绩效考核的依据。
2.缺陷发现时间：发现BUG并提交的时间。
3.缺陷优先级：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需优先考虑；正常排队是指缺陷正常排队等待修复；而低优先级是指缺陷可最后修改。
4.缺陷版本：执行测试并发现BUG的版本号。
5.缺陷修复日期：开发人员修复BUG的日期。
缺陷状态
1.新建New缺陷的初始状态
2.打开Open测试人员提交BUG
3.指派Assigned指派给相关开发人员进行修复
4.已修复Fixed开发人员已修复
5.已关闭Closed测试通过，关闭
6.重新打开Reopen回归测试未通过，或关闭后又复现了
7.延期Postpone推迟修改
8.拒绝Rejected开发人员拒绝修改
9.重复Duplicate重复提交
10.已取消/终止Abandon被拒绝和重复提交的BUG，在确认不是问题后，置为此状态
缺陷严重程度：致命、严重、一般、较小、改进建议；或A、B、C、D、E
1.致命：软件死机、退出或崩溃、数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
2.严重：主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
3.一般：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
4.较小的：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范，辅助说明描述不清楚。
5.改进建议：由测试人员对软件的改进意见、建议或质疑。
软件缺陷-填写要求
1.缺陷标识：必填，缺陷的标识编号。
2.指派人：必填，新提交的问题分配给相应的开发人员。
3.提交人：必填，问题提交者，默认为自己。
4.测试版本：必填，问题最开始发现的软件版本号，对应开发的版本号。
5.测试日期：必填，问题最开始提交的时间，默认为当天。
6.严重程度：必填，问题本身的严重级别，越高表示越严重
7.缺陷发生概率：必填，出现概率为必现、概率性出现（出现几次）、不可复现。
8.优先级：必填，缺陷要求解决的优先级，越高表示开发尽快修复问题。
9.缺陷状态：必填，缺陷的状态，新提交时默认为“新建”。
10.缺陷起源：在需求、架构、设计、编码、测试、用户哪阶段发现的。
11.缺陷来源：来源于需求规格说明书、设计文档、集成接口、代码。
12.缺陷模块：必填，哪个功能模块的BUG。
13.问题描述：必填，详细描述问题，描述中必须包括预期结果和实际结果，尽量附图，如有建议，写出修改建议。
14.问题处理意见：项目人员对缺陷给出处理的建议，均可读写。
软件缺陷-描述原则
缺陷描述原则：分类准确、叙述简洁、步骤清楚、易再现、复杂问题有据可查（截图或其它形式的附件）。具体为：
·问题描述格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；
· 叙述简洁：单一准确，一个缺陷一个报告；每步骤的描述尽量简洁明了。短小简练：只解释事实、演示和描述软件缺陷必要的细节，不写无关信息；
· 再现：可以再现（个别严重问题复现不了也可入库，但需标明）；
· 特定条件：缺陷是否在特定条件下才会出现；
· 补充完善：复杂的问题应附上截图、LOG等信息作为补充说明；
· 不使用抽象词句：比如“有错误”“是不是”“请确认”等等；不做评价：请勿在BUG描述中，评价BUG缺陷加入个人主观思想。
软件缺陷-生命周期
简单周期：发现、打开、修复、关闭。
· 测试员找到并登记软件缺陷，软件缺陷移交到程序员；
· 程序员修复软件缺陷，软件缺陷移交到测试员测试员确定软件缺陷被修复，测试员关闭软件缺陷。
复杂周期：
· 发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员）
· 软件缺陷移交到项目管理员（以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员
· 重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员）
· 项目管理员同意缺陷需要修复，缺陷转给程序员
· 以修复形式解决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷）
· 缺陷关闭
测试/开发角色职责
·测试执行人员：缺陷发现者。对版本进行测试发现BUG，并对已修复的BUG进行验证。
· 测试组长：缺陷管理者。负责对缺陷的审核，跟踪和汇报，针对有争议的BUG进行各方协调。
· 开发负责人：缺陷解决者。接收BUG，并指派给具体开发人员进行修复，给出解决途径或修复建议。
· 开发人员：缺陷修复者。执行开发负责人指派的BUG修复并自测是否修复通过。
软件缺陷管理流程
BUG跟踪流程：
1.测试人员拿到最新软件版本，执行测试；
2.发现BUG并记录到BUG管理平台；提交BUG报告或测试报告，邮件抄送开发人员；
3.开发人员得到最新BUG并修复BUG（如复杂问题，进行专家评审如何处理）；
4.修复BUG后把新代码Checkin到源代码服务器；
5.Buider人员会进行版本编译并提交到发布版本服务器；
6.测试人员开始执行新的一轮测试任务。
缺陷跟踪目的：
1.保证BUG得到有效的跟踪和解决，使每一环节都有相对应责任人负责。
2.进行缺陷分析和产品度量。
软件缺陷分析
·缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。
· 主要参数
-状态：缺陷的当前状态（打开的、正在修复或关闭的等）。
- 优先级：必须处理和解决缺陷的相对重要性。
- 严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
- 起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件。
· 创建缺陷趋势图或报告；为揭示软件可靠性的缺陷趋势或缺陷分布提供判断依据。
缺陷报告
缺陷报告-概念：
测试执行过程中，发现缺陷故障/失效后，提出书面的报告。
缺陷报告-作用：
1.记录软件缺陷
2.进行缺陷分类
3.用于缺陷分析
4.跟踪软件缺陷
5.度量软件质量
缺陷报告的5C准则：
·Correct（准确）
· Clear（清晰）
· Concise（简洁）
· Complete（完整）
· Consistent（一致）
BUG管理工具
管理BUG的工具：Excel、Bugzilla、TestDirector（TD）、ClearQuest（CQ）、Bugfree、JIRA等。
· TestDirector商业、支持Win平台、B/S架构、在广泛的应用环境下自动执行软件质量测试和管理。
· ClearQuest商业、支持Unix/Win平台、C/S、B/S架构、提供了从开发到部署的完整的审计跟踪，并扩展了跨生命周期的可追溯性。
· Bugzilla免费、支持Unix/Win平台、B/S架构、Bug追踪系统设计用来帮助管理软件开发。
· Bugfree免费、借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug管理系统。简单实用、免费并且开放源代码。
· JIRA商业、是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
