四、缺陷

1、缺陷的基本概述

①缺陷的定义

   软件未实现产品说明书要求的功能

    软件出现了产品说明书指明不应该出现的功能

    软件实现了产品说明书中未提到的功能

    软件未实现产品说明书虽为明确提及但应该实现的功能

（所有不满足需求或查出需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷）

   （软件难以理解、不易使用、运行缓慢或者“从测试的角度看”，最终用户会认为不好）

②缺陷的属性

1）缺陷类型：根据缺陷的自然属性划分的缺陷种类。功能缺陷（Function）、界面（UI）、文档（Document）、软件包（Package）、性能（Performance）、接口（Interface）。

      注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多一些；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷；

2）缺陷严重程度：指因缺陷引起的故障对软件产品的影响程度。一般有分类，每个公司和团队的分类标准略有不同。

注意：结合缺陷的影响，结合软件的具体功能（业务或流程）

3）缺陷优先级：指缺陷必须被修复的紧急程度。很大程度上取决于缺陷对测试工作的影响程度。

注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分。软件的基本功能的缺陷，优先级较高，甚至需要立即解决。软件的备选流、基本功能，测试中的反向测试的内容，优先级较低，甚至有些可改可不改。

面试提问：缺陷的严重程度和缺陷的优先级有什么关系？

1）没有任何直接的关系。

2）不要认为严重的缺陷，修复优先级就高。

3）如果碰到，优先级和严重程度都高的缺陷，也只是偶然。企业logo错误，不影响任何功能，但必须有限修复；QQ的帮助功能经常出现闪退现象，严重程度很高，但优先级低。

面试提问：提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级？

①提交bug时必须保持客观公正

②不可夸大

4）缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。

   发现缺陷是缺陷处理的前提，但是还没有进入缺陷的处理流程。

   ①激活/打开（新建）——由测试人员进行标注

   ②确认。确认新提交的缺陷是一个真实有效的缺陷。——一般由测试主管/质量保证（QA）/产品经理确认。确认后，有效的缺陷会指派给相关人员进行处理。

   ③已修复/修正。——在缺陷被修复后，由开发人员进行

   ④关闭/非激活。——缺陷被修复完成后，经过测试人员的验证后，没有问题

   ⑤重新打开。——经过测试人员验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。

   ⑥推迟——缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。

   ⑦保留。缺陷暂时修复不了——一般由开发人员设定。也需要测试人员进行确认

   ⑧不能重现。开发按照缺陷的复现步骤步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息出现的问题。所以作为测试人员提交bug之前，要再三确认bug。

   ⑨需要更多的信息。作为测试人员，提交bug的时候，要尽可能的把所有相关的文件一起提交（图片、视频）

   ⑩重复。测试中，一定要避免提交重复的bug。

   ⑪不是缺陷。

   ⑫需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或设计不明确造成的。

5）缺陷起源：指缺陷引起的故障或事件第一次被检测的阶段

6）缺陷来源：指缺陷的起因——直接原因（需求说明书、设计文档、系统集成接口、数据流、程序代码）

7）缺陷根源：指发生错误的起因——在总结阶段

③缺陷的生命周期

发现缺陷（测试人员）——提交缺陷（测试人员）——确认缺陷（测试主管/QA/产品经理）——分配缺陷（测试主管/QA/产品经理，分配给相关负责人）——修复缺陷（开发人员/产品经理）——验证缺陷（测试人员）——关闭缺陷（测试人员）

面试提问：针对你工作中发现的一个bug,说说这个bug的处理过程。（缺陷的生命周期中，每一个环节谁做什么）

④缺陷识别

依据：需求文档、设计文档、产品原型、测试用例，都是客观的依据

     同行业的类似成熟软件，和开发人员的沟通，和有经验的测试人员沟通，同行业隐形需求，都是带有主观色彩的依据。

测试人员在识别缺陷的时候，要很灵活的对待。

⑤缺陷报告

1、缺陷编号。Bug_项目名称_模块名称_功能名称_0001.

2、所属模块。一级模块/二级模块/三级模块   

3、优先级。缺陷的修复紧急程度。P1>P2>p3>p4

4、严重程度。S1>S2>S3>S4

5、缺陷概述。用一句话描述缺陷的基本情况。

6、缺陷的描述。将缺陷的复现步骤、预期结果和实际结果列出来。

7、提交人。

8、备注。一般写产生该缺陷的特殊情况。将bug的截图和视频作为备注信息。

2、缺陷报告

①编写目的

1) 展现缺陷的详细信息

2) 展现缺陷的影响程度及方式

②预期读者

开发人员、质量管理人员、市场人员、运维人员.....

③编写准测

 准确、清晰、简洁、完整、一致

缺陷报告要写的很直白、清晰、明了

④缺陷描述的准则

1）可以再现。针对绝大多数的缺陷都是如此。但是有一些小部分的缺陷是难以做到（类似闪退、崩溃这种不可再现的缺陷，无须做到。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述）

2）不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。

⑤缺陷报告模板

缺陷报告本身要保证没有任何表述性错误

⑥缺陷跟踪系统

Bugzilla    英文

Bugfree    中文

禅道      中文

QC（ALM） 英文

JIRA    

3、测试需求和测试用例、缺陷报告的关系？

①测试的基本流程

获取测试需求——编写测试计划——制订测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本测试

获取测试需求是测试工作的重点。通过需求的分析，了解和掌握测试的方向和内容。

例如：

1）分析出系统的模块和组织结构

2）分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。

3）识别出软件的重要功能和次要功能

获取测试需求的过程中，测试人员就要有相应的分析成果。一般用Xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。

设定测试中需求的正、反向和优先级。

当有了测试需求后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点都要被测试。因此在测试过程中衡量需求的覆盖程度就非常重要。

需求覆盖程度-被测试用例覆盖的需求数/需求点总数进行计算和说明。

如果需求覆盖度＜100%，那一定说明了测试的覆盖度不够。

测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。

1）设计的测试用例总量TC

2）执行测试用例数量EC

3）未执行的测试用例数量WC

4）执行通过的测试用例总量SC

5）执行失败的测试用例总量FC

6）提交的缺陷的总量BC

以上几个数据，他们要符合如下的数量关系：

1）TC≥EC

2）TC=EC+WC

3）EC=SC+FC

4）BC≥FC。提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量固定（甚至是唯一的）。说明了测试过程中发现的缺陷，除了一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的。

5）通过SC/EC可以表现出系统的质量是否合格。

6）通过EC/TC可以表现出系统的需求是否得到满足。

P107——P124  Linux  测试环境配置  跳过