软件缺陷的定义
一，缺陷的定义
二，缺陷产生的原因
1、需求表述理解、编写过程中引起的错误;
2、系统设计架构引起的错误;
3、开发过程缺乏有效沟通及监督;
4、程序员编码过程产生的错误;
5、软件开发工具本身的错误;
6、软件需求、复杂度越来越高;
7、与用户需求不符合，即使本身不存在某种意义上的缺陷
三，缺陷的报告格式
四，缺陷管理流程
五，缺陷分级
致命:系统崩溃，死机，核心功能缺失，明确的报错页面
严重:核心功能出现错误，二级功能缺失，核心页面布局错位
一般:二级功能错误，三级功能缺失
轻微：三级功能出现错误，错别字，非核心页面布局错位
建议：无关缺陷，只是提升用户体验度的意见
软件缺陷，常常又被叫做Bug，从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病
等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
格蕾丝·赫柏（GraceMurrayHopper），是一位为美国海军工作的电脑专家，也是最早将人类语言
融入到电脑程序的人之一。而代表电脑程序出错的“bug”这名字，正是由赫柏所取的。1947年9月9
日，赫柏对HarvardM+arkII设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然
停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这
显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞
蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。
按照严重程度分:
一般分为5个等级:
系统崩溃，严重，一般，次要，建议
按优先级分:
修正优先级：高，中，低
六：Bug定级示例
按照测试种类分:
逻辑功能类，性能类，界面类，易用性类，安装，兼容性类
软件测试类型：
Bug处理流程 ：
提交（打开）缺陷：
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷：
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷;
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理:
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定:
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷:
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷:
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷:
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态.
