第2讲 缺陷报告

一．什么是缺陷报告

1.    测试人员发现bug，将bug记录在缺陷报告中

2.    通过缺陷报告将bug告知给开发人员

3.    通过缺陷报告实现对bug的跟踪管理

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

二．编写缺陷报告的常用工具：

在企业中通常使用缺陷管理工具来管理bug，例如：禅道（中文、国产、免费）、jira(鸡爪）、mantis（螳螂）、QC（惠普公司.收费.英文）、bugfree.、bugzilla等，还有一些企业使用自制的bug工具

说明：不同公司使用的bug管理工具不同，但是都是管理bug的，所以模板大同小异

三、如何编写缺陷报告（组成）

案例：两数加减乘除，除法功能没有实现

1、缺陷编号（defect/bug ID）

就是发现bug的顺序号(流水号），能唯一标识每一个bug,通常的bug管理工具会自动生成编号

注意：项目中的bug编号是统一排序管理的

2、缺陷标题（summary）

简明扼要的描述该bug（概括描述）

3、发现者/创建者（detected by）

通常填写发现bug的测试人员的姓名或账号

账号通常在企业由管理人员创建，例如：

测试人员账号：

Zhoujl_qa、cuihui_qa

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

注意：应“及时”提交bug

发现bug应“审核”，尽量避免“假bug”被提交（例如：操作错误、配置错误、需求理解错误等造成的假bug），保证提交bug的质量

5、缺陷的指派(缺陷指派给谁处理)：(assigned to)

常见指派：测试人员-->开发主管-->具体的开发人员

其他情况：

例如：小公司

测试人员-->具体开发人员

例如：大公司

测试人员-->测试主管-->开发主管-->具体开发人员

6、功能模块（subject）

 在哪个功能模块中发现该bug

作用：定位bug,并且通常开发主管可以通过功能模块明确，该由谁来负责解决该bug(一般是谁开发的谁负责解决)

7、所属的版本

说明：对于专业的测试人员来说，版本不仅仅指最终发布的版本，也包括在研发过程中曾经出现过的若干临时版本。

扩展：回归测试（回测），就是在当前版本中，对于上个版本测试过的功能，再重新测试一遍。

回归测试的必要性：1.如果有新增功能，新功能可能会对原有功能造成影响，引发bug;2.开发人员修改bug,很可能在解决bug的同时带来新的问题；

回归测试存在重复性测试，所以如果条件允许，自动化进行回归测试是比较高效的

8、状态（status）

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

（1）常见的状态

新的--new 激活的--open

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

(2)不是很常见的状态

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

面试题：

Q1:软件bug的生命周期？/缺陷报告的跟踪管理过程（流程步骤）

缺陷报告/缺陷的处理过程（流程、步骤、生命周期）

步骤1：测试人员提交新的缺陷给开发经理

步骤2：开发经理对缺陷进行审核，

情况1：如果确认是有效bug，会将缺陷激活，并指派给相应的开发人员

情况2：如果确认不是bug，将拒绝该bug，由测试方对被拒绝的bug进行相应处理

步骤3：开发人员对指派的bug进行调试和修改，解决后bug将设置为“已解决”状态

步骤4：测试人员对已解决的bug进行返测，

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

情况2：返测失败，测试人员将bug重新激活，指派回开发人员继续解决bug，直到bug返测通过关闭为止

返测：就是对开发人员已解决状态的bug进行测试验证该bug是否被修复

Q2、如果提交的bug（提bug）被开发方拒绝了，测试人员要怎么做？（经验型题目，以下为答题思路）

首先：明确bug被拒绝的原因，然后自检自查，确认是否由于测试人员操作失误或对于需求理解错误等造成“无效bug”被提交

接下来：找相应的人员（开发人员、产品经理等）进行沟通讨论，确认是否是bug

如果在沟通解决问题的过程中遇到了自己无法解决的问题，应问自己的直属领导汇报，由领导出面协调解决

最终：如果经过沟通讨论确认不是bug，由测试人员或测试主管负责关闭该bug，如果最终确认是bug，那么谁拒绝谁负责将bug激活，再次回到缺陷处理流程中，继续跟踪处理

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

严重程度：表明缺陷有多糟糕，对程序破坏有多大。

1--致命--urgent

2-严重--high

3-中等/一般--medium

4-建议性小问题--low

说明：1）不同的bug管理工具，严重级别的划分可能不同，有分5级甚至5级以上的。

在实际测试中：“中等”级别的bug 相对较多，“建议性小问题”在项目前期会比较集中（提示：项目面试中经常会被问印象深刻的bug，各个严重级别的bug适当留意准备）

（2）bug的的严重级别定义太笼统不详细，容易造成开发人员和测试人员之间的争议，所以企业通常会制定详细的严重级别说明解决该问题。

注意：不同公司，甚至同一公司不同项目组，关于bug严重程度说明都可能不同，要注意区别参考

3）经验：通常如果功能没有实现，属于2--严重

10、缺陷优先级（priority）

说明：就是希望或者建议开发方在什么版本或什么时候解决该bug（决策权在开发主管，测试方只是提供建议）

优先级的级别划分：

1--立即解决--brgent

2-下一个版本解决--urgent

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

4-尽量在软件发布之前解决--low(数量少、不严重--通常中等及以下级别）

说明：1）不同的bug管理工具，严重级别的划分可能不同，有分5级甚至5级以上的。

（2）测试人员建议下一个版本解决bug比较多

（3）通常严重程度和优先级是正比关系，但是有特殊情况：界面的bug(建议性小问题）严重级别低，但是通常优先级别较高（bug）

（4）测试人员建议缺陷的优先级后，开发方可能会根据实际情况修改优先级，不同公司、项目组对于bug优先级的具体说明还是可能不一样的，大家工作中应注意区别。

Q1：影响缺陷优先级的因素有哪些？

（1）缺陷的严重程度，严重程度越高，通常优先级也越高

（2）开发人员的开发压力，通常开发压力越小，解决bug的优先级越高

（3）缺陷的影响范围越大，优先级越高

（4）解决缺陷的成本（时间）成本越低，优先级越高

Q2：缺陷的严重程度和优先级是正比关系吗？

通常是正比关系，但是有特殊情况，例如：界面拼写错误严重级别低但是优先级高

Q3：缺陷的严重程度和优先级确定后，开发方可以修改吗？

严重程度一旦确定开发方不能修改

优先级开发方根据实际情况可以修改，通常延后

Q4：发布的软件中存在发现但是没有解决的bug吗？

在发布的软件中有可能存在发现但是没有解决的bug

此类bug数量应较少，严重程度应较低，通常中等及以下。

通常经过“bug讨论”，分析解决bug的付出成本，和不解决bug是否会给用户带来严重损失，以及由此是否会引发法律诉讼后，才能决定

该类bug发布后，软件企业通常会通过打补丁或升级版本的方式，在后期解决bug

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

就是将发现bug的过程（步骤、数据）记录下来，使开发人员能够重现bug

要求：逻辑清晰、用语专业准确、不要有二义性（歧义）、易读易懂、不要出现评价性的词语,做到如实记录bug

缺陷报告中可以附带“证迹”（通常就是截图或视频）

测试人员应养成随手截取证迹的习惯

提示：很多企业会对缺陷描述有格式要求，常见的格式：

例如：

 步骤：（step）

 预期：（期待）结果(expect result)

 实际： （真实）结果(actual result)

四、缺陷报告总结

1.缺陷报告的作用？

 （1）缺陷报告可以记录bug

 (2)缺陷报告可以对bug进行跟踪管理

（3）缺陷报告可以实现对bug的分类、统计和总结

2.如何识别bug?

 （1）参考需求文档，当与需求不符时就是bug

 (2)参考bug的5条定义（总的纲领）

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

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

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

补充：随机bug

也叫偶发缺陷或不可重现bug(慎重使用该名称)，就是执行相同的测试过程，时有时无的bug

Always sometimes

问题：测试人员如果遇到随机bug如何处理？

（1）遇到随机bug也要报告

（2）随机bug要说明该bug为随机bug

 (3)随机bug的描述应尽量详细，尽可能多的提供bug信息，方便开发方进行bug调查，如果能够提供证迹尽量提供

（4）如果开发方需要测试人员配合bug调查，测试人员应积极配合（例如：提供bug出现频次、保留测试环境、提供相关测试数据或日志等）

（5）如果可以进行白盒测试，也可以加入白盒测试辅助