软件测试梳理 第九节 缺陷和缺陷报告

缺陷的基本概述

1. 缺陷的定义

   • 软件未实现产品说明书要求的功能
   • 软件出现了产品说明书指明不应该出现的功能
   • 软件实现了产品说明书未提到的功能
   • 软件未实现产品说明书虽未明确提及但应该实现的目标
   • 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

2. 缺陷的属性

   属性名称	描述
   缺陷类型（type）	缺陷类型是根据缺陷的自然属性划分的缺陷种类
   缺陷严重程度（severity）	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
   缺陷优先级（priority）	缺陷的优先级指缺陷必须被修复的紧急程度
   缺陷状态（status）	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
   缺陷起源（origin）	缺陷起源指缺陷引起的故障或者事件第一次被测到的阶段
   缺陷来源（source）	缺陷来源指缺陷的起因
   缺陷根源（root cause）	缺陷根源指发生错误的根本因素

   正向优先于反向

   • 缺陷类型：功能缺陷（function）、用户界面（ui）、文档（documentation）、软件包（package）、性能缺陷（performance）、系统/模块接口（interface）

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

   • 缺陷的严重程度（指缺陷引起的故障对软件产品的影响程度、等级）：致命（fatal）、严重（critical）、一般（major）、较小（minor）

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

   • 缺陷的修复优先级（很大程度上取决于缺陷对测试工作的影响程度、基本功能的缺陷优先级高）：立即解决（p1）、高优先级（p2）、正常排队（p3）、低优先级（p4）

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

     1.二者之间没有任何直接的关系

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

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

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

     1.不能搞“狼来了”

     2.也不能私人关系“帮”好朋友减少不良影响

   • 缺陷的状态（指缺陷通过一个跟踪修复过程的进展情况）：激活或者打开、已修正或者修复、关闭或者非激活、重新打开、推迟、保留、不能重现、需要更多信息、重复、不是缺陷、需要修改软件规格说明书
     

   • 缺陷的起源（指的是缺陷引起的故障或者时间第一次被检测到的阶段）

     

   • 缺陷的来源

     

   • 缺陷的根源

     

   缺陷的起源、来源、根源。一般关注较多的是缺陷的来源（直接来源）。在测试总结的时候关注缺陷的根源。

缺陷的生命周期

发现缺陷->提交缺陷->确认缺陷->分配缺陷->修复缺陷->验证缺陷->关闭缺陷

1、发现缺陷，由测试人员发现，开发也能知道自己哪里写错了，但是不会广而告之。

2、提交缺陷，由测试人员提交。

3、确认缺陷，一般有测试主管、或者质量保证（QA）、有产品经理确认。

4、分配缺陷，一般由谁确认就由谁分配。

5、修复缺陷，主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题。

6、验证缺陷，由测试验证。

7、关闭缺陷，只能测试人员进行，否则出了问题，测试一律不背锅。

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

缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例等等。（客观）

​ 同行业的类似成熟软件、开发人员沟通、跟有经验的测试人员沟通、同行业隐式需求。（主观）

• 通过测试用例中的预期结果进行识别
• 通过需求规格说明书进行识别
• 通过用户手册以及其他文档进行识别
• 通过同行业相类似成熟的商业软件来识别
• 通过和开发人员的沟通进行识别
• 通过和有经验的测试人员沟通进行识别
• 参照同行业隐式需求进行识别

缺陷报告

1. 编写目的和预期读者

   • 展现缺陷的详细信息
   • 展现缺陷的影响程度和方式

   

2. 报告编写准则
   

3. 缺陷描述准则

   

4. 缺陷管理方式和模板

   

   • 缺陷编号：Bug—项目名称—模块名称—功能名称—0001
   • 所属模块：一级模块、二级模块、三级模块
   • 优先级：p1>p2>p3>p4
   • 严重程度：s1>s2>s3>s4
   • 缺陷概述：用一句话描述缺陷的基本情况。
   • 缺陷的描述：将缺陷的复现步骤、预期结果和实际结果列出来。
   • 提交人：是谁就写谁的名字。
   • 备注：一般写产生该缺陷的特殊情况；将bug的截图作为备注信息。

   缺陷跟踪系统

   

需求、用例和bug报告的关系

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

获取测试需求是测试工作的重点，也是第一步。通过需求分析，了解和掌握测试的方向和内容。例如：

1. 分析出系统的模块和组织结构
2. 分析出软件的基本功能和运行流程。（业务分析）
3. 识别出软件的重要功能和次要功能。

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

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

当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，也就是，每一个需求点都要测试。

因此测试过程中，衡量需求的覆盖程度就非常重要。

需求的覆盖程度=被测试用例覆盖的需求数/需求点总和

进行计算说明：

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

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

1. 设计的测试用例总量 TC
2. 执行的测试用例数量 EC
3. 未执行的测试用例 WC
4. 执行通过的测试用例总量 SC
5. 执行失败的测试用例总量 FC
6. 提交的缺陷的总量 BC（Bug Counts）

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

1. TC>=EC
2. TC=EC+WC
3. EC=SC+FC
4. BC>=FC。提交的bug数量，多余只行为通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的）。说明了测试过程中发现的缺陷，除了一部分是用例执行失败带来的，还有一部分应该是测试人员自身经验和直觉（其他知识）带来的。
5. 通过SC/EC可以表现出系统的质量是否合格。
6. 通过EC/TC可以表现出系统的需求是否得到满足。