1. 缺陷的定义

　　产品不满足用户的需求或者测试执行时实际结果和预期结果不一致都属于缺陷。

　　2. 缺陷的判定标准及产生原因

　　软件不满足下述任何一种都算作是软件的缺陷，缺陷的概念是包括bug概念的。

　　未达到需求说明书指明的功能

　　出现了需求说明书指明不应该出现的错误

　　实现了需求说明书之外的功能

　　未达到需求说明书虽未明确提及但是应该实现的目标(如：性能要求等)

　　用户角度发现的各种问题与错误

　　缺陷产生的原因是多方面的，可以总结为以下几种：

　　需求文档存在错误

　　程序代码存在错误

　　同一个项目组的成员信息不同步，比如需求发生变更，但是没有同步到项目组所有成员

　　3. 缺陷报告

　　测试人员发现缺陷之后，需要将缺陷同步给项目组的其他成员，为了让其他成员能够清晰的知道软件目前存在的缺陷，就需要对软件缺陷的描述进行规范化，通常来讲测试人员需要将发现的缺陷整理成缺陷报告然后通过一些平台比如禅道或者jira指定给项目组的指定成员，然后由他们进行解决。

　　缺陷报告首先必须有以下几个核心的内容：

　　标题：描述缺陷的基本信息，如(输入密码长度为5时，注册成功。)

　　前置条件：描述缺陷出现依赖的相关基础条件，如(未注册手机号)

　　复现步骤：测试用例里面的执行步骤

　　实际结果：执行被测试软件过程中，系统给出的结果

　　预期结果：参照需求说明书，在测试用例中设计的预期结果

　　附件：方便开发定位bug的关键信息，包含图片、日志log等

　　有了上述几个核心内容之后，开发人员基本上可以根据所给信息去定位缺陷，然后进行解决，当然缺陷报告还有一些其他的基本要素：

　　ID编号：缺陷的唯一编号

　　模块：根据产品进行具体的划分，如登录、注册

　　缺陷状态：表明缺陷处理进度，通常会使用禅道等工具进行管理，缺陷状态有以下几种

　　new：新建的缺陷

　　open：打开的缺陷

　　fix：已修复的缺陷

　　close：关闭的缺陷

　　reopen：重新打开

　　reject：被拒绝解决的缺陷

　　postpone：延期处理

　　严重程度：从技术维度来衡量，bug的破坏力

　　优先级：从业务的角度，决定bug修改的先后顺序

　　缺陷类别：用于分类整理缺陷，通常缺陷类别可以从以下几个角度进行区分：

　　功能性错误

　　非功能性错误

　　界面错误

　　兼容性

　　易用性

　　...

　　缺陷报告非常重要，合格的缺陷报告可以帮助解决缺陷的开发人员更快的复现和定位缺陷，因此缺陷报告必须保证能够让开发人员复现缺陷。通常在编写缺陷报告时可以遵循以下书写规范：

　　标题：应保持简短、准确，提供缺陷的本质信息

　　复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤

　　实际结果：是执行复现步骤后软件的现象和产生的行为

　　预期结果：通常需要列出期望的结果是什么

　　附件：对缺陷描述的补充说明

　　4. 缺陷跟踪流程

　　使用禅道或者jira进行缺陷跟踪时，根据不同的场景会产生不同的缺陷状态。下图是缺陷跟踪流程图，每一条流程表示一种场景。

　　场景1：确认BUG解决

　　测试【new】》开发【open】》开发【fix】==》测试【close】

　　场景2：验证未通过，缺陷仍存在

　　测试【new】》开发【open】》开发【fix】==》测试【reopen】

　　场景3：开发延期处理

　　测试【new】》开发【open】》开发【postpone】

　　场景4：拒绝处理

　　测试【new】》开发【open】》开发【reject】