缺陷的基本概念

01第一章缺陷的基本概念

关于bug

Bug的由来

Debug

Bug和defect

Bug：电脑系统或者程序中存在的任何一种破坏正常运行运转能力的问题或者缺陷，都产可以叫做“bug”；有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。

Defect（缺陷）:既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。

常见术语

 

 

缺陷的定义

 

 

缺陷的来源

 

 

产生原因

1．产品说明书不全，不完整和不准确，修改频繁，沟通不畅和理解不同；

2．软件设计过程中过程中考虑不周到，片面，多变，理解和沟通不足；

3．文档不足，压时间，赶进度，设计和编码错误都会引入缺陷；

4．测试和实施过程中安装环境配置错误等。

02第二章 缺陷的属性

缺陷报告的相关属性

缺陷ID  标题 产生的步骤 所属模块 发现人 发现的时间 严重程度 优先级 类型 状态 可再现性 发现阶段 责任人 所属版本 修改日期 引入原因 备注信息 相关附件

 

 

缺陷类型

 

 

优先级的划分

 

 

严重程度的划分

 

 

 

缺陷跟踪的交付物

缺陷报告单：也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出的书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。

缺陷管理工具中的bug  Report

 

 

03第三章 缺陷的生命周期 

BUG的生命周期

缺陷的生命周期

缺陷的生命周期是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。

缺陷的生命周期通过缺陷流程图得以展现

 

 

状态说明

1．新建（NEW）：测试人员提交新问题标识的状态

2．打开（OPEN）：已经确认为是BUG的状态

3．已修复（FIXED）：为开发人员修改问题后所标志的状态，等待测试验证

4．重新打开：测试人员对修改问题进行验证后没有通过所标志的状态或者已经修改正确的问题又重新出现错误，由测试人员改变。

5．已关闭：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。

缺陷沟通

 

 

一个简单的BUG跟踪流程

 

 

软件测试缺陷管理流程

 

 

                     缺陷管理中的常见问题

提交的缺陷开发人员不认可怎么办？

如何处理不能重现的缺陷？

如何处理好与开发人员及其他相关人员的关系？

缺陷太多怎么办？

找不到缺陷怎么办？

缺陷得不到及时修复怎么办？

如何处理缺陷级别定义之争？

如何处理缺陷跟踪中的扯皮现象？

04第四章 缺陷报告的书写

缺陷报告单写作准则（5C）

缺陷报告的写作要点

再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题是间断的，那要报告问题发生频率。

初步定位：可能影响再现的变量，例如配置变化、工作流、数据库这些都是可能改变错误地特征。

压缩：精简任何不必要的信息，特别是冗余的测试步骤。

去除歧义：试用清晰的语言，尤其是避免试用那些有多个不同或相反含义的词汇。

中立：公正的表达自己的意思，对错误及其特征的事实进行陈述， 避免夸张，幽默和讽刺。

评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。

缺陷报告单基本内容

 

 

05第五章常用的管理工具

缺陷管理的目的

保证信息的一致性

保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效

利于缺陷分析、产品度量，使项目情况可视化加强

 

 

常用的缺陷管理工具

1．       QC

2．       禅道（bugfree升级版）

3．       Mantis

4．       JIRA

5．       Testlink

6．       Bugzilla

7．       Redmine

常用工具说明

 

 

 

06第六章缺陷分析

识别BUG

 

 

获取BUG

 

管理bug

 

 

分析bug