缺陷的定义
软件未实现产品说明书中要求的功能；
软件未实现产品说明书中未明确提及但应该实现的目标；
软件实现了产品说明书中未提到的功能；
软件出现了产品说明书中指明不应该出现的功能。
软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好
缺陷的属性
| 缺陷属性 | 描述 |
|---|---|
| 缺陷类型（type） | 缺陷类型是根据缺陷的自然属性划分的缺陷种类 |
| 缺陷严重程度（Severity） | 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度 |
| 缺陷优先级（Priority） | 缺陷的优先级指缺陷必须被修复的紧急程度 |
| 缺陷状态（Status） | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况 |
| 缺陷起源（Origin） | 缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段 |
| 缺陷来源（Source） | 缺陷来源指缺陷的起因 |
| 缺陷根源（Root Cause） | 缺陷根源指发生错误的根本因素 |
1、缺陷类型
缺陷类型是根据缺陷的自然属性划分的缺陷种类
| 缺陷类型 | 描述 |
|---|---|
| 功能 | 影响了各种系统功能、逻辑的缺项 |
| 用户界面 | 影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 |
| 文档 | 影响发布和维护，包括注释、用户手册、设计文档 |
| 软件包 | 由于软件配置库、变更管理或版本控制引起的错误 |
| 性能 | 不满足系统可测量的属性值，如执行时间、事务处理速率等 |
| 系统/模块接口 | 与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突 |
功能（Function）、界面（UI）、文档（Documentation）、软件包（Package）、性能（Performance）、接口（Interface）
注意：需求分析、设计阶段，文档类型的缺陷多；
集成测试阶段，一般接口类型的缺陷多一点；
系统测试阶段，功能、界面类型的缺陷多一些；
验收测试阶段，更多的关注性能缺陷；
实施过程，可能会遇到一些软件包的缺陷。
2、缺陷严重程度
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
| 缺陷严重等级 | 描述 |
|---|---|
| 致命（Fatal） | 系统任何一个主要功能完全丧失，用户数据收到破坏，系统奔溃、悬挂、死机，或者危机人身安全 |
| 严重（Critical） | 系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响 |
| 一般（Major） | 系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题 |
| 较小（Minor） | 是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 |
3、缺陷优先级
缺陷的修复优先级：缺陷的优先级指缺陷必须被修复的紧急程度。
| 缺陷优先级 | 描述 |
|---|---|
| 立即解决（P1级） | 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 |
| 高优先级（P2级） | 缺陷严重，影响测试，需要优先考虑 |
| 正常排队（P3级） | 缺陷需要正常排队等待修复 |
| 低优先级（P4级） | 缺陷可以在开发人员有时间的时候被纠正 |
缺陷的严重程度和优先级有什么联系？
1）没有任何的直接联系
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。
优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。
2）缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。
但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
4、缺陷状态
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
| 缺陷状态 | 描述 |
|---|---|
| 激活或打开 | 问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷 |
| 已修正或修复 | 已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 |
| 关闭或非激活 | 测试人员验证后，确认缺陷不存在之后的状态 |
| 重新打开 | 测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复 |
| 推迟 | 这个软件缺陷可以在下一个版本中解决 |
| 保留 | 由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷 |
| 不能重现 | 开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤。例如：闪退，奔溃 |
| 需要更多信息 | 开发能再现这个软件缺陷，但开发人员需要一些信息，例如切线的日志文件、图片等 |
| 重复 | 这个缺陷已经被其他测试人员发现 |
| 不是缺陷 | 这个问题不是软件缺陷 |
| 需要修改软件规格说明书 | 由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书 |
5、缺陷起源
缺陷起源指缺陷引起的故障或事件被第一次被检测到的阶段
| 缺陷起源 | 描述 |
|---|---|
| 需求 | 在需求阶段发现的缺陷 |
| 构架 | 在系统架构设计阶段发现的缺陷 |
| 设计 | 在程序设计阶段发现的缺陷 |
| 编码 | 在编码阶段发现的缺陷 |
| 测试 | 在测试阶段发现的缺陷 |
| 用户 | 在用户使用阶段发现的缺陷 |
6、缺陷来源
缺陷来源指缺陷的起因
| 缺陷来源 | 描述 |
|---|---|
| 需求说明书 | 需求说明书的错误或不清楚引起的问题 |
| 设计文档 | 设计文档描述不准确，和需求说明书不一致的问题 |
| 系统集成接口 | 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 |
| 数据流（库） | 是编码中的问题所引起的缺陷 |
7、缺陷根源
缺陷根源指发生错误的根本因素
| 缺陷根源 | 描述 |
|---|---|
| 测试策略 | 错误的测试范围，误解了测试目标，超越测试能力等 |
| 过程，工具和方法 | 无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等 |
| 团队/人 | 项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等 |
| 缺乏组织和通讯 | 缺乏用户参与，职责不明确，管理失败等 |
| 硬件 | 硬件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等 |
| 工作环境 | 组织机构调整，预算改变，工作环境恶劣，如噪音过大 |