0.软件缺陷的产生
软件缺陷 - Software Defect - Bug；缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷的标准定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
在软件的开发测试过程中项目组会特别关注软件缺陷的状况，这是因为一方面软件缺陷状况是项目质量和状态的重要指示数据，另一方面越到软件生命周期的后期修复软件缺陷的成本越高。
1.常见的缺陷
功能没有实现或与需求规格说明不一致；界面、消息、提示、帮助不够准确或误导用户；屏幕显示、打印结果不正确；软件无故退出或没有反应;边界条件未做处理，输入错误数据没有提示和说明；运行速度慢或占用资源过多；与常用的交互软件不兼容；有时把尚未完成的小功能也归属于软件缺陷
2.产生原因
在软件开发的过程中，软件缺陷的产生是不可避免的，”零缺陷”是软件产品很难达到一个状态。导致软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷，概括来说这些原因可以归结为四大类。
软件本身的复杂性和抽象性：在产品真正完成之前，每个人对软件的理解都不完全相同，这种复杂和抽象使得软件容易出现缺陷
软件技术在某些领域应用不成熟，使得某些功能或性能无法达到应用要求，也会导致软件缺陷的产生
如果软件开发流程不完善，存在太多的随机性，缺乏严谨的评审机制，则容易产生软件缺陷。目前软件行业对项目管理和软件过程的研究实践已经有很多成果，比如全流程质量管理、CMMI模型等软件工程方法。
软件团队的成员能力水平不足也会引起软件缺陷的产生。比如编码人员能力不足，会产生很多算法错误和语法错误导致软件不能正常工作或者性能低下。
3.缺陷属性
为了方便引用、理解、解决、测试、回归，跟踪、分析软件缺陷，软件缺陷有很多属性，比如编号ID，解决人，测试人、状态、所属功能模块、严重程度等等。这些属性并不是在缺陷录入的时候就全部指定的，而是随着软件缺陷的流转根据需要不断完善的。一个完整的缺陷报告应该清楚的描述BUG的症状和其他基本信息。不同的团队根据缺陷管理的需要使用的缺陷属性不同。
优先级是处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
理论上来说，确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修复是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修复缺陷的难度和风险。
但是实际上，企业在确定缺陷优先级并不只站在开发工程师角度，而是对解决的难度、缺陷对产品销售的影响、客户的重要性等方面综合考虑确定的。
严重性(Severity)是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户造成的后果的严重性。
团队在开展测试工作时会根据团队管理和产品的实际需要定义缺陷的字段，少则六七个字段，多则可达十几二十个。
4.统计度量
软件缺陷作为软件质量的重要指标变量，对其进行统计分析以明确项目质量情况，帮助管理者进一步做决策意义重大。
缺陷密度Dd：Dd=缺陷数量/代码行或功能点的数量，其单位为每千行代码的缺陷数(Defects/KLOC)。
遗留缺陷密度：遗留缺陷数/代码行或功能点数
缺陷探测率DDP：发布前发现的缺陷数/缺陷总数
缺陷趋势分析统计
缺陷分布分析统计
缺陷根源分析统计
5.管理工具
软件缺陷管理指南、软件缺陷报告录入模板和指南、软件缺陷管理系统、
（0）分类
软件缺陷管理系统分类：1.自主开发、购买、开源 2.单独的缺陷管理工具、集成在研发管理系统中
典型的软件缺陷管理系统：1.Bugzilla：https://www.bugzilla.org/ 2.禅道项目管理软件中的缺陷管理子系统 3.JIRA：https://www.atlassian.com/software/jira 4.ALM中的缺陷管理子系统
（1）功能
工具是理论的载体，理解了理论才能灵活运用工具，一般的缺陷管理系统有如下功能:字段配置、缺陷跟踪、添加缺陷、修改缺陷、关联缺陷和测试用例、统计分析功能