测试基础系列之缺陷报告 第3讲

一、软件项目的测试流程（常见面试题）

     1、熟悉需求（熟悉，分析需求，整理业务）

     2、制定《测试计划》

     通常由测试组长或经理制定测试计划

     测试人员阅读计划，并按要求执行。

     3、设计测试（分析，提取测试点，编写“测试用例”）

     4、执行测试，记录测试结果（通过，失败）

     5、记录缺陷，跟踪管理bug（《缺陷报告》）

     6、测试总结（提交测试总结报告 、测试报告）

     测试总结报告中主要是一些测试数据的统计总结。

 

二、缺陷报告

1、什么是缺陷报告？

（1）测试人员发现缺陷，通过缺陷报告记录缺陷。

（2）通过缺陷报告将缺陷告知给开发方。

（3）对缺陷进行跟踪管理。

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

-----------------------------------------------------------

下载学习资料：

https://pan.baidu.com/s/1AiOGeJXv_bmmWyGR6UGeBg

提取码：jjnr

 一、复习 ：进制和进制转换

   1、任意进制→十进制

    方法：按权展开求和

   2、十进制→任意进制

    方法：除基取余逆读法

   3、二进制→十六进制（八进制）

     方法：4（3）合1

   4、十六进制（八进制）→二进制

      方法：1分4（3）

-------------------------------------------------------------

2、如何编写缺陷报告？

（1）企业中都是使用“缺陷管理工具”来管理bug，例如：禅道（免费、中文）--zentao、qc（收费、英文）、jira（鸡爪）、bugfree、bugzilla等（还有公司自制缺陷管理工具），不同的企业可能使用不同的缺陷管理软件，可能存在不同之处，但是核心部分大同小异。

（2）缺陷报告的核心组成（11项）

     bug案例：当两个数进行除法操作时，如果除数为0，程序异常退出。

       1）缺陷编号（Defect ID）

       缺陷编号唯一标识缺陷（类似身份证号）

       缺陷编号在管理软件中通常是自动生成的。

       缺陷编号一般是项目团队统一管理，而不是只管理你自己的。

       2）缺陷标题（summary）

       简明扼要的概括缺陷

       3）缺陷发现者（detected by）

       填写测试者的账号（在工具中注册的工作账号）或姓名

       例： cuihui_qa

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

       注意：测试人员发现bug应“及时”提交。

       发现缺陷不应人为延误影响开发或测试进度，但是也不应立即提交缺陷，而是应对bug进行评审，尽量避免由于自身的失误或配置错误等原因造成“假bug”的提交。

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

        常规：测试人员→开发方负责人→具体负责的开发人员

        也有些公司管理严格，指派过程如下：

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

       6）功能模块（subject）

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

       说明：确定功能模块后，开发主管更容易确定解决bug的开发人员（一般谁开发的该模块，谁负责解决这个模块中的bug）

       7）发现bug的版本（detected in release/version）

     说明：对于测试专业人员来说，不是只有最终发布的版本是版本，在研发过程中出现过的临时版本也同样是版本。

 

扩展--  回归测试（回测）

回归测试：就是在当前版本中对上一个版本中测试过的所有功能，再测试一遍。

为什么需要做回归测试？

   原因1：新增加的功能有可能会对原有功能造成影响，产生新的bug。

   原因2：在当前版本修复的bug，有可能在解决bug的同时，又带来了别的问题。

   综合以上原因，需要进行回归测试。

回归测试存在重复测试，在实际应用中，建议使用自动化实现回归测试，更高效。

      8）缺陷的状态（status）

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

缺陷的常见状态：

         新的--new

         激活的--open

         已解决的--fixed

         关闭的--closed

      缺陷的其它状态：

         重新激活--reopen

         被拒绝的--rejected

扩展：常见面试题1--缺陷的跟踪管理过程？（流程？步骤？生命周期？）

  步骤1：测试人员将新的缺陷报告提交给开发方负责人。（提bug）

  步骤2：开发方负责人要“确认”bug：

  情况1：确认通过，将缺陷激活（open），并指派给相应的开发人员

  情况2：确认未通过，开发方负责人将缺陷“拒绝”（rejected）。

  步骤3：开发人员将bug解决，设置为“已解决”（fixed）状态。--待返测的bug

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

         情况1：返测通过，将bug关闭（closed）

         情况2：返测失败，将bug“重新激活”(reopen)，指派回给开发人员继续修改，直到bug返测通过，关闭为止。

常见面试题2：测试人员提交的bug如果被拒绝，该如何处理？

  首先--自检自查，是否自己有失误，或者没有按要求配置系统。

  接下来--根据bug被拒的原因与相关人员进行沟通（产品经理、开发人员），讨论，最终确认是否是bug。

  如果不是bug，测试人员或测试主管将bug关闭；如果是bug，谁拒绝的谁负责将bug激活，继续执行bug处理流程。

  最后--如果遇到测试人员难以解决的问题，可以向测试主管汇报，由测试主管做出合适的处理。

     9）缺陷严重程度（severity）

     表明缺陷有多糟糕，对程序的破坏有多大。

     常见的缺陷严重级别：

     p1--致命的--urgent

     p2--严重的--high

     p3--中等的--medium（较多）

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

补充：并不是所有的工具中严重级别都是分4级，也有分5级的，例如qc中会在致命和严重级别中间 ，多一个“非常严重-very high”级别。（了解）

   问题：缺陷的严重级别定义过于笼统，在实际工作中，很可能会造成开发与测试人员之间的争论。

   解决方案:企业通常会制定详细的说明文档，对于严重级别进行详细情况说明，测试人员测试时应参考。

    注意：不同公司，甚至同一个公司的不同项目组，详细定义都有可能不同。

    严重级别应专业准确制定，不要为了引起开发方重视就故意夸大，或受其它因素影响随意改动。

    10）缺陷的优先级（priority）

    建议开发方在什么时候或什么版本解决bug。（决策权在开发方）

    缺陷优先级：

    P1--立即解决--urgent

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

    P3--软件发布之前解决--medium（常用）

    P4--尽量在软件发布之前解决--low（有可能有bug发现但是没解决，软件就已经发布了）

   补充：qc中优先级是5个级别，在P1后多加一个级别“very high--当前版本解决”

注意：测试方对于bug的优先级只是建议，如果不合适，开发方可以修改。

扩展：常见面试题

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

    1、缺陷的严重程度，一般越严重，优先级越高。（例外的情况，界面（UI）的bug，严重级别低但是通常优先级都很高）

    2、缺陷的影响范围，一般影响范围越大，优先级越高。

    3、开发人员的开发压力，一般开发压力越小，优先级越高。

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

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

    严重程度和优先级不是严格成正比关系，例如：界面（UI）的bug，严重级别低但是通常优先级都很高

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

    严重级别确定后不修改。

    优先级可以改，而且经常是向后推延。

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

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

    该类bug通常是要开“bug讨论会”，讨论解决bug的成本，以及不解决bug是否会给用户造成严重影响或带来法律诉讼。

    软件公司通常会在后期通过升级版本或打补丁的方式来解决bug。

一、复习

  1、用状态变化表示缺陷的处理过程

     （1）缺陷基本的跟踪管理过程

     new→open→fixed→closed

      （2）带有返测失败的缺陷跟踪管理过程（返测失败1次）

       new→open→fixed→reopen→fixed→closed

      （3）被拒绝的bug处理过程

        1）不是bug

        new→rejected→closed

        2）是bug

        new→rejected→open→fixed→closed

一、缺陷报告组成

    1、缺陷编号（defect ID）

    2、缺陷标题（summary）

    3、发现者（detected by）

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

    5、指派（assigned to）

    6、功能模块（subject）

    7、版本（detected in release）

    8、状态（status）

    9、严重程度（severity）

    10、优先级（priority）

    11、描述（description）

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

     要求：逻辑清晰、语言专业、准确、易读易懂、不要出现任何评价性的语言，做到如实记录bug。

     常见格式：

       步骤（step）：

       预期结果（expect result）：

       实际结果（actual result）：

    

经验：缺陷严重级别

      通常情况下：1）功能没有实现 --2：严重

1. 功能实现，但是极值，边界限制错误--3：中等
2. UI问题--4：建议性小问题

   

复选框--勾选或者选择

 

三、缺陷报告总结

1、缺陷报告的作用？

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

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

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

2、如何识别bug？

（1）参考需求相关文档-与需求要求不符就是bug。

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

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

（4）通过与产品经理，开发人员，测试同事，用户等沟通讨论来确认bug。  

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

随机bug：也叫不可重现bug，按照相同的操作过程时有时无的bug。

测试人员应如何处理随机bug?

（1）随机bug也要提交，并且需要标识为随机bug。

（2）测试人员对于随机bug的描述应尽量详细，最好能够提供证迹（截图或视频）

（3）测试人员需要配合开发方对随机bug进行“缺陷调查”（例如：保留测试环境，随机bug出现的频率）

（4）如果条件允许，测试方可以加入白盒测试，进一步调查bug。