缺陷报告

第三讲   缺陷报告

一、软件项目的测试流程（步骤）：（重点面试题）

    1、熟悉软件的需求（阅读需求，分析整理：功能组成，业务实现，规则）

    2、制定《测试计划》

   说明：一般《测试计划》由测试组长或测试经理制定；测试人员要阅读并执行测试计划。

   3、设计测试 （设计、编写《测试用例》）

   4、执行测试

   5、记录测试结果

   6、分析结果，记录缺陷（《缺陷报告》）

   7、缺陷的跟踪、管理

   8、测试总结（《测试总结报告》）

   总结：测试数据（真实）

   说明:需收集整个测试组的真实测试数据，进行总结。

    二、缺陷报告

   1、什么是缺陷报告?

   测试人员发现缺陷，将缺陷记录在《缺陷报告》中，通过缺陷报告将缺陷告知给开发方，并对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。

 2、如何编写缺陷报告？

   1)说明：企业中会使用测试管理工具或bug管理工具来对bug进行管理，例如:禅道、QC、bugzilla、自制工具等，不同企业的工具不同，所以缺陷报告的模板也不完全相同，但是核心部分大同小异。

   2）缺陷报告的组成

   案例：除数为0

   （1）缺陷编号(defect ID)

    就是发现缺陷的顺序号

   注意：此处编号是整个项目的bug统一编号。

  编号在工具中是自动生成的。

  （2）缺陷标题（summary）

 要求简明扼要的将缺陷概括出来。（没有标准答案，可以自由发挥）

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

   测试人员自己账号/姓名  

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

   注意：要求测试人员要及时提交缺陷。

   （5）缺陷所属的功能模块（subject）

    在哪个功能模块中发现的该缺陷。

    说明:方便对缺陷定位，并且开发经理可以根据缺陷所在的功能模块，指定由谁来负责解决该bug。

  （6）发现缺陷的版本（detected in release/version）

   版本：测试中的版本既有可能是最终发布的版本，也有可能是研发过程中的临时版本。

  扩展:

  回归测试 ：在当前版本中对上一个版本测过的功能要再次测试一遍。

  为什么要做回归测试:1)新增加的功能可能会对原有功能带来影响；2）修改bug可能会产生新的问题；基于以上两个原因，有必要做回归测试。

  回归测试存在重复测试（将写好的用例反复执行），所以企业可以应用自动化测试，来提高回归测试的效率，节省人力成本。

  （7）指派给谁处理（assigned  to）

    首先指派给:开发方的负责人（开发经理）

    接下来再由开发方的负责人指派给具体的开发人员。

   测试人员-->开发方负责人-->开发人员

   （8）状态（status）（重点）

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

   缺陷状态：

     新的缺陷--new

     激活的缺陷--open

     已修复的缺陷--fixed

     关闭的缺陷--closed

     拒绝的缺陷--rejected

     重新激活的缺陷--reopen

   问题：缺陷报告的跟踪管理过程？

      

  第1步：测试人员发现新的缺陷（new），填写《缺陷报告》，提交给开发经理。

  第2步：开发经理审核新提交的bug，

   情况1：如果审核通过，开发经理要激活缺陷（open），并指派给相应的开发人员。

   情况2：如果审核没有通过，开发经理会拒绝该缺陷。（rejected）

  第3步：开发人员负责修复指派的bug，修复后将bug设置为“已修复”状态（fixed）。

  第4步：测试人员对修复的缺陷进行返测，

  情况1：如果返测通过，测试人员将缺陷关闭（closed）

  情况2：如果返测未通过，测试人员将重新激活缺陷（reopen），指派回开发人员继续修复，直到修复成功，缺陷关闭为止。

   问题2：被拒绝的缺陷，测试人员要怎么处理？

   1、测试人员应该要自己先确认一下是不是由于操作失误，或配置问题，造成假缺陷。

   2、测试人员应该分析bug被拒绝的原因，例如：由于需求理解不同，造成bug被拒，可以通过与开发人员、产品经理沟通，讨论解决；如果由于bug不能重现造成被拒，应该与开发人员沟通，讨论解决等。

  3、如果与各部门沟通讨论后依然无法解决问题，可以上报测试组长（经理），由组长出面，沟通解决问题。

 4、得到最终结论后，如果是假缺陷，测试方负责将假缺陷关闭。如果最终认定是缺陷，那么谁拒绝谁负责将缺陷激活，重新纳入到缺陷处理流程中。

(9) 缺陷的严重程度（severity）

   指缺陷有多糟糕，对程序的影响有多大。

   严重级别：

    致命的--urgent

   【非常严重--very high】--可能没有

    严重的--high

    中等的--medium（数量较多）

    建议性的小问题--low

说明：缺陷的严重程度的级别比较笼统，在实际工作中容易造成开发与测试方的冲突，所以需要制定严重级别的详细说明。

提示:不同企业，不同项目组的严重级别定义都是不同的，工作中要注意对应参考。

(10) 缺陷的优先级（priority）

   希望或者建议开发方在什么时候，或者什么版本解决bug。

   优先级划分：

     立即解决的bug--urgent

   【 本版本内解决--very high】可能没有

     下一个版本解决--high （最常用）

     软件发布之前解决--medium

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

  说明：软件缺陷的优先级的详细说明，不同公司，不同项目组可能会不同。

扩展：常见面试题

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

   1）缺陷的严重程度，一般越严重的缺陷，优先级越高。

   2）开发人员的开发压力，开发压力越小，优先级越高。

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

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

 

  Q2:缺陷的严重程度和优先级是严格（绝对）成正比关系吗?

    不是严格正比关系，例如:界面中有错别字，虽然严重程度低，但是优先级却较高。

 

  Q3:缺陷的严重程度和优先级确定后还能修改吗？

   缺陷的严重程度一般确定后是不能更改的。

  缺陷的优先级可以修改，开发方根据实际情况经常会做拖延处理。（delay）

  Q4：在发布的软件产品中，是否会有发现但没有解决的bug？

   有可能会有发现但没解决的bug存在于发布的软件产品中。

   在实际应用中，对于该类缺陷需要开bug讨论会，权衡解决bug的成本，和不解决bug是否会给用户带来严重影响，以及法律纠纷后，才能最终确定。

    对于该类bug,软件公司会在后期,通过版本升级或打补丁的方式给予解决。

 

11)缺陷的描述（description）

  将发现缺陷的过程，数据记录下来，使开发人员可以重现该缺陷。（开发人员要能看明白）

  要求：逻辑清晰、用语要专业、准确、易于理解、不要有任何评价性的语言出现。

 

  用状态来表述以下缺陷处理过程。

   1）常规缺陷处理过程（没有拒绝，没有返测失败）

new-->open-->fixed-->closed

   2）带有返测失败的缺陷处理过程。（返测失败1次）

   3）被拒绝的缺陷处理过程。

   是缺陷

   假缺陷

 

 

 二、缺陷报告总结

 

  1、缺陷报告的作用？

 

    1）缺陷报告能够记录缺陷。

 

    2）缺陷报告可以实现对缺陷的跟踪、管理过程。

 

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

 

  2、如何识别缺陷?

 

   1）与用户需求对比--与需求不符就是bug

 

   2）缺陷的5条定义（总纲）

 

   3）与测试人员、开发人员、产品经理、客户等进行沟通讨论，进而确定缺陷。

 

   4）与测试用例中的预期结果对比--与预期结果不一致的就是缺陷。

 

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

 

  随机bug（重点）：不可重现缺陷，按照相同的操作过程，时有时无的bug。

 

   测试人员如果发现随机bug，要如何处理？

 

   1）测试人员发现随机bug应该提交。

 

   2）提交随机bug时应该要说明该bug为随机bug。

 

   3）测试人员应该尽量详细的记录发现缺陷的详细过程，尽可能配合提供证迹（截图或视频），如果有出现错误提示，应该尽量详细记录。（错误编号、内容）

 

   4）如果开发方提出保留测试环境，提供缺陷的出现几率等配合调查缺陷的要求时，应尽量给予配合。

 

   5）测试方可以适当提供白盒测试进行配合（从代码角度）。