一、缺陷报告的基础知识

1、什么是缺陷报告

1）测试人员通过缺陷报告来记录缺陷

2）测试方通过缺陷报告，将缺陷告知给开发方

3）通过缺陷报告实现对缺陷的跟踪管理（设计科学的缺陷管理流程）

总结：缺陷报告是测试人员和开发人员之间重要的沟通方式

2、缺陷报告常用的工具

在企业中都是通过缺陷管理工具来管理缺陷，常用的有：mantis（螳螂）、禅道（zentao国产）、QC（惠普公司、付费）、jira（谐音鸡爪）、bugfree、bugzilla等，还有一部分企业会自制bug管理工具。

提示：不同的工具缺陷报告的模板会有差异，但是毕竟都是对bug进行记录管理，所以核心的内容还是大同小异的

二、如何编写缺陷报告

1、缺陷报告核心组成

1. 缺陷编号（defect/bugID）

说明：记录发现bug顺序流水号

缺陷编号能唯一标识每个bug（不重复）

通常在缺陷管理工具中，缺陷编号是自动生成的

2.缺陷标题（summary）

简明扼要地将缺陷进行描述（概括）

3.缺陷的发现者/创建者（detected by）

此处通常会填写测试人员的账号/姓名

例：测试人员chengxiaoming_QA

4.提交缺陷的日期（detected on date）

注意：缺陷应及时提交

1）缺陷应及时提交,不应人为拖延，影响项目进度

2）在发现bug后，测试方要进行bug审核，确认bug是否有效，尽量避免无效bug（假bug/无效bug等）被提交。

5.缺陷的指派（assigned to）

就是缺陷处理流程中的工作任务安排

1）常规

测试人员→开发主管→具体的开发人员→

2）非常规

（1）例：小公司

测试人员→具体的开发人员

（2）例:大公司

测试人员→测试主管→

6.功能模块（subject）

说明：在哪个功能模块中发现的该bug

便于定位bug，也使开发主管更容易明确将bug指派给哪位具体的开发人员

7.版本（detected in releace）

版本说明:

（1）在专业的测试人员的理解中，版本不仅是指最终发布的版本，也包括在软件研发过程中，出现的若干临时版本

（2）测试方不负责生成版本信息，版本信息通常由项目团队提供

8.缺陷的状态（status)

说明:表明缺陷处于怎样的处理情况

常用的缺陷状态：

新的-new  激活的--open  

已解决--fixed  已关闭--closed

不太常用的缺陷状态：

重新激活的--reopen  被拒绝--rejected

9. 缺陷的严重程度（severity）

说明：表明bug有多糟糕，对程序的破坏有多大

通常bug的严重级别：

1--致命--urgent

2--严重--high

3--中等--medium

4--建议性的小问题--low

说明：

1）不同的bug管理工具级别划分不同，有的工具bug的严重级别划分超过4级

2）缺陷的严重级别定义比较笼统，在实际应用中容易造成争议，所以企业通常会提供详细的bug严重级别说明，测试人员定义严重级别时注意参考，提示：不同公司，甚至同一公司不同项目组，bug严重级别的说明都可能不同，注意区别参考。

3）在项目测试过程中，中等级别bug最多，建议性的小问题主要集中在项目前期

4）经验：

通常功能没有实现属于严重级别(high)

通常UI（界面）错误属于建议性的小问题（low）

10. 缺陷的优先级（priority）

说明：建议该缺陷在什么版本或什么时候被解决--测试人员在优先级的定义上没有决策权，可以给建议，但是开发方结合实际考虑多方因素，可以修改优先级。通常缺陷的优先级别：

1--立即解决--urgent

2--下个版本解决--high

3--在软件发布之前解决--medium

4--尽量在软件发布之前解决--low

说明：

1）不同的缺陷管理工具的优先级定义可能不同，有可能超过4个级别

2）通常越严重的bug，优先级越高，但是一些UI缺陷，虽然严重级别低（4级），可是优先级却高（一般优先级1/2级）

3）优先级4级的定义，一般需要讨论确定，而且该级别bug数量极少并且不严重（通常中等以下严重程度），软件发布后，可以通过省级或者打补丁的方式给与解决。

4）不同公司优先级的详细说明会有不同，大家工作时要注意参考。

11. 缺陷描述/重现步骤（description）

说明：将发现bug的过程（步骤、数据）记录下来，使程序员可以重现该bug（要让程序员看明白）注意：逻辑清晰、易读易懂、不要有二义性（歧义）、专业准确、缺陷应如实记录，不要有评价性的语言。

补充：缺陷报告中一般会要求附带“证迹”（图片或视频）

（1）缺陷报告的跟踪处理过程（重点）

（流程、步骤、生命周期、bug的一生）？

步骤1：测试人员提交新的缺陷给开发主管（提bug）

步骤2：开发主管确认该bug

情况1：确认是bug，开发主管将缺陷指派给具体的开发人员，缺陷被激活

情况2：确认不是bug，开发主管“拒绝”该bug，测试方经过沟通、确认后作出相应处理。

步骤3：开发人员调试（debug）并解决bug，解决后，bug为“已解决”状态

步骤4:测试人员对“已解决”的bug进行返测

情况1：返测通过，测试人员将bug关闭

情况2：返测未通过，测试人员将bug重新激活，指派回给该名开发人员，再次解决bug，直到返测通过，关闭为止。

（2）什么是返测？（重点）

测试人员对（已解决）的bug进行再次测试，用以验证该bug是否被修复。

面试题2：如果测试人员提bug，被开发方拒绝了？要怎么办？

首先:明确bug被拒绝的原因，然后自检自查，确认是否有bug

接下来：要与相应人员沟通确认bug，如果沟通过程遇到自己无法解决的问题，向自己的直属领导汇报，由领导出门解决问题。

最终：如果沟通讨论后确认不是bug，就由测试方（测试员/测试主管）负责“关闭bug”

如果沟通、讨论后确认是bug，那么谁拒绝的谁负责激活bug，并将bug纳入回常规处理流程。

提示：不同的缺陷管理工具，模板不同，缺陷的状态也有可能不同。

2、回归测试（重点）

（1）回归测试，在当前版本中，对上一版本测试过的所有功能再重新测试一遍，

（2）为什么要做回归测试（必要性）：

①解决bug的同时，可能会带来新的问题

②新增加功能，可能对原有功能造成影响，产生新的问题。

③回归测试存在“重复测试”，如果条件允许，可以自动化测试实现回归，这样可以提供测试效率

3、影响bug优先级的因素有哪些？

1）缺陷的严重程度--缺陷越严重优先级越高

2）缺陷的影响范围--影响范围越大，优先级越高

3）开发人员的开发压力--一般开发压力小，bug优先级越高，开发压力越大，优先级越低

4）解决bug的成本（时间）--一般成本越低，优先级越高

4、bug的严重程度和优先级一定是正比关系吗？

不一定，通常情况严重程度和优先级是成正比关系的，但是有特殊情况，例如：UI缺陷，严重程度低，但是优先级却高。

5、bug的严重级别和优先级确定后，开发方可以修改么？

严重级别确定后开发方不能修改缺陷优先级测试方给出建议，开发方可以修改（通常是延后）

6、发布的软件中，是否可能存在发现但是没有解决的bug？

有可能，通常此类bug要求数量极而且不严重，该类bug需要通过“bug讨论”，权衡解决bug的成本，以及不解决是否会给用户带来严重损害，以及是否会产生诉讼，评估讨论后，方能确定该类bug发布后，软件企业通常会通过升级版本或打补丁的方式给与解决。

三、缺陷报告总结

1、缺陷报告的作用？

1）可以记录缺陷

2）可以实现对bug的跟踪管理

3）可以实现对bug的分类、统计和总结

2、如何识别缺陷？

1) 参考需求要求--当实际结果与需求不符就是bug

2) 参考缺陷的定义（总的纲领）

3) 参考测试用例中的预期结果-当实际结果与预期结果不一致就是bug

4) 与测试人员、开发人员、产品经理、用户等沟通讨论来识别bug

3、编写缺陷报告的注意事项？

1）小的缺陷也要报告

2）对于不可重现的缺陷（随机bug）也要报告，但要注明该bug不可重现

3）及时报告缺陷，不作任何评价

4）对缺陷的严重程度、优先级的划分准确、客观，不夸大bug

5）缺陷描述清晰、准确、易读，使用最少、必须得步骤，保证缺陷可以再现

6）在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确造成的“假缺陷”