•掌握软件缺陷的基本概念和相关术语
•掌握高质量缺陷问题单的填写方法
•掌握软件缺陷的相关属性
•了解软件缺陷管理的常用工具
•掌握软件缺陷的生命周期
常见术语
•关于BUG
-Bug的由来
-Debug
•Bug和Defect
-Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以叫做“Bug”；有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
-Defect（缺陷）：既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。
缺陷类型
遗漏（missing）
错误（error）
额外实现（extra）
不满意（UNsatisfy）
缺陷评价标准
-软件未实现需求规格说明书（SRS）要求的功能
-软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
-软件出现了需求规格说明书（SRS）指明不应出现的错误
-软件实现了需求规格说明书（SRS）未提到的功能
-软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好
缺陷产生原因
软件缺陷产生的原因多种多样，一般可能有以下几种原因:
-需求表述、理解、编写引起的错误。
-系统设计架构引起的错误。
-开发过程缺乏有效的沟通及监督，甚至没有沟通或监督。
- 程序员编程中产生的错误。
-软件开发工具本身隐藏的问题。
-软件复杂度越来越高。
-与用户需求不符，即使软件实现本身无缺陷。
上述情况都可能产生缺陷，常见的缺陷分为以下4种情况
遗漏（missing） 错误（error） 额外实现（extra） 不满意（UNsatisfy）
缺陷报告单
也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
缺陷管理工具中的bug report
缺陷报告单的写作准则 （5c）
Correct（准确）
每个组成部分的描述准确，不会引起误解
Clear（清晰）
每个组成部分的描述清晰，易于理解
Concise（简洁）
只包含必不可少的信息，不包括任何多余的内容
Complete（完整）
包含复现该缺陷的完整步骤和其他本质信息
Consistent（一致）
按照一致的格式书写全部缺陷报告
缺陷报告单的相关属性
•缺陷ID
•缺陷标题
•缺陷所属模块
•缺陷严重程度
•缺陷优先级
•可再现性
•缺陷发现人
•缺陷状态
•缺陷发现阶段
•缺陷所属版本
•缺陷修改日期
•缺陷引入阶段
•缺陷引入原因
缺陷ID
缺陷ID用来唯一标识缺陷，在缺陷管理中，缺陷ID不可重复，即使缺陷被删除，ID也不可复用。缺陷ID一般用阿拉伯数字标识即可，如1、2、3等。有的公司有自己的格式规定，则按照公司规定编写即可。
概要描述
简要描述缺陷的存在形式及表象，通过概要描述，开发人员能快速理解缺陷产生的现象，推测可能的缺陷诱因，从而提高缺陷处理的效率。例如，商品查询功能查出的商品标题信息显示为乱码。
简要描述要求描述尽量简洁，通过概要描述能够基本了解缺陷的内容。
缺陷严重程度
•严重性：顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
-致命：例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。
-严重：例如，由于单功能失效导致多个相关功能均失效
-一般：例如，软件的单个功能失效；
-提示：软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；
缺陷的优先级
该字段由研发团队确定，根据缺陷的严重度，决定缺陷修复的先后次序，原则上修复优先级与缺陷严重度相同。严重度级别越高的缺陷，修复优先级也越高。
但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。
缺陷详细描述
详细描述当前缺陷引发的原因，包括环境、执行步骤、期望结果和实际结果对比等若干便于描述该缺陷的信息。
测试环境：描述发现此缺陷时，可能与缺陷相关的环境和配置描述
执行步骤：发现此缺陷操作步骤的描述，描述要求要详细，无歧义， 开发人员参照可以重现缺陷。
期望结果和实际结果对比：给出缺陷的现象
缺陷附件
当缺陷表述需额外附件的证据信息时，可提交相对应的数据信息，如截图、录屏操作、系统运行日志等，便于开发人员更好的重现缺陷或定位问题。一般缺陷管理工具都有添加附件功能。
缺陷报告写作要点
一
•再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率。
•初步定位：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改变错误的特征。
•推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在着这种问题等等，特别是那些可能存在更加严重特征的部分。
二
•压缩：精简任何不必要的信息，特别是冗余的测试步骤。
•去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
•中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
•评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。
缺陷管理
缺陷管理/软件缺陷管理（Defect Management）是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。一般的，需要跟踪管理工具来帮助进行缺陷全流程管理。
-保证信息的一致性
-保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效
-利于缺陷分析、产品度量，使项目情况可视化加强
软件缺陷跟踪过程需要有软件工具支撑：
HP Quality Center（简称QC）
HP ALM(Application Lifecycle Management)
禅道
Jira
Bugzilla
bug的生命周期
-缺陷的生命周期就是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。
-缺陷的生命周期通过缺陷流程图得以展现
一个简单的bug跟踪流程
缺陷跟踪流程人员角色
•软件开发人员
•软件测试人员
•软件测试经理
•软件项目经理
•软件开发经理
缺陷报告工具的相关状态
缺陷状态迁移矩阵(每一状态的下一有可能状态)
软件缺陷管理流程
缺陷分析
针对缺陷的关键字段，运用数据分析的统计方法，发掘软件系统的缺陷分布、密度及发展趋势，在此基础上追溯软件生产过程中引发缺陷的根本原因，为软件质量分析提供基础真实的数据依据。
缺陷分析活动中常用的度量字段有严重度、所属模块、产生原因、所属版本、持续周期、缺陷性质等。
案例