软件测试人员除了写出一份好的测试用例，还要通过这份测试用例发现软件的缺陷，以帮助开发人员纠正错误，达到提高软件质量的目的。
软件缺陷的定义是什么？
软件缺陷，通常被叫做Defect或者Bug，Issue。所谓软件缺陷，即计算机或程序中存在的某种破坏软件正常运行能力的问题、错误或者隐藏的功能缺陷。软件缺陷会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
缺陷的类别有哪些？
1. 软件没有实现产品规格说明书所要求的功能模块；
2. 软件中出现了产品规格说明指明不应该出现的错误；
3. 软件实现了产品规格说明书没有提到的功能；
4. 软件没有实现规格说明书没有明确提及但应该实现的目标；
5. 软件难以理解，不易使用，运行缓慢；
6. 从测试人员的角度看，最终用户会认为不好的问题。
缺陷有哪些属性？
1. 缺陷标识(Identifier):是标记缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2. 缺陷标题(Summary):缺陷的标题，一般格式为[Function]Summary Description.
3. 缺陷描述(Description)：缺陷发生的具体环境及步骤。记录缺陷发生的软硬件条件及时间点，抓取log及相应的视频。
============================
Environment
============================
Used Build:
Used Board:
Network:
============================
Precondition
============================
None
============================
Description
============================
============================
Actual Result
============================
============================
Expected Result
============================
4. 缺陷类型(Type):
1)功能(Function): 功能性缺陷，需要修改设计文档。如逻辑，指针，循环，递归，功能等缺陷。
2)Assignment: 需要修改少量代码。如声明、重复命名等缺陷。
3)接口(Interface): 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
4)Checking: 提示的错误信息。
5)软件包(Build/package/merge): 由于配置库、变更管理或版本控制引起的错误。
6)文档(Documentation): 影响发布和维护，包括注释。
7)Algorithm:算法错误。
8)用户界面(User Interface): 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等缺陷。
9)性能(Performance): 不满足系统可测量的属性值，如：执行时间，事务处理速度等。
10)Norms: 不符合各种标准的要求，如编码标准、设计符号等。
11)兼容性(Compatibility) : 与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、 冲突。
5.缺陷严重程度(Severity)
1)Critical：不能执行正常工作功能或重要功能。
2)Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3)Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4)Normal：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5)Enhancement：需要改善的其它错误。
6.缺陷优先级（Priority）
1)Resolve Immediately：缺陷必须被立即解决。
2)Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。
3)Not Urgent：缺陷可以在方便时被纠正。
7.缺陷状态(Status)
1)Submitted: 已提交的缺陷
2)Open :确认“提交的缺陷”，等待处理
3)Rejected: 拒绝“提交的缺陷”，不需要修复或不是缺陷
4)Resolved :缺陷被修复
5)Closed :确认被修复的缺陷，将其关闭
8.缺陷起源(Origin)
1)Requirement：在需求阶段发现的缺陷
2)Architecture：在构架阶段发现的缺陷
3)Design：在设计阶段发现的缺陷
4)Code：在编码阶段发现的缺陷
5)Test：在测试阶段发现的缺陷
9.缺陷来源(Source)
1)Requirement： 由于需求的问题引起的缺陷
2)Architecture： 由于构架的问题引起的缺陷
3)Design： 由于设计的问题引起的缺陷
4)Code： 由于编码的问题引起的缺陷
5)Test： 由于测试的问题引起的缺陷
6)Integration： 由于集成的问题引起的缺陷
如何跟踪缺陷？
测试人员提交好缺陷之后，千万别对缺陷放任不管，除了及时回复开发人员对缺陷提出的疑问，对一些难以复现的问题，还要跟踪3个版本的验证。如果开发人员修复了问题，还要在特定的版本上进行验证，确保问题已经修复成功，并且没有出现衍生问题。要及时修改缺陷的状态，并添加备注信息。
===========================================
Verify info:
===========================================
Build No.:
Verify result:
===========================================