缺陷和缺陷报告

蔚落 2022-12-23 06:25 136阅读 0赞

**文章目录**

一、缺陷的基本概述

1、缺陷的定义（重要）：

2、缺陷属性

二、缺陷的生命周期（重要）

三、缺陷的识别

四、缺陷报告

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

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

# 一、缺陷的基本概述 #

## 1、缺陷的定义（重要）： ##

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

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

## 2、缺陷属性 ##

1、缺陷的类型：  
功能、用户界面、文档、软件包、性能、系统/模块接口

注意：需求分析、设计阶段，文档类型缺陷多；  
集成测试阶段，一般接口类型的缺陷多一些；  
系统测试阶段，功能、界面类型的缺陷多一些；  
验收测试阶段，更多地关注性能缺陷；  
实施过程，可能会遇到一些软件包的缺陷。  
  
2、缺陷的严重程度：缺陷的故障对软件的影响，每个公司和团队的分类标准略有不同。

①致命：系统任何一个主要功能完全丧失，用户数据收到破坏，系统崩溃、悬挂、死机，或者危及人身安全。

②严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的的功能或服务收到明显的影响。

③一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。

④较小：是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等小问题。

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

3、缺陷的修复优先级：很大程度上取决于缺陷对测试工作的影响程度。有以下等级：立即解决、高优先级、正常排队、低优先级。  
例如：电商系统的用户注册功能无法使用（导致无法登录、购买、结算、支付、下单、物流跟踪、收获、评论等功能无法进行），就必须立即修复。但是电商系统中关于用户购买流程帮助说明的网页链接点击404页面，就比较次要。

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

缺陷的严重程度和优先级有什么关系？  
1、没有任何直接的关系，严重程度是指缺陷对软件的影响，而优先级是指缺陷对测试的影响。  
2、不要认为严重的缺陷，修复优先级就高；  
3、如果碰到，优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮，会有经常闪退的现象。严重程度很高，但是优先级就很低。又例如企业logo错误，不影响任何功能，但是必须优先修复。

提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级？  
不能，不能搞“狼来了”，也不能搞私人关系，"帮"好朋友减少不良影响。要公正、客观。

4、缺陷的状态：  
缺陷状态指缺陷的处理进度。  
发现缺陷时缺陷处理的前提，但是还没有进入缺陷的处理流程。

①激活/打开（新建）：由测试人员进行标注。  
②确认：确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管或者质量保证、产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。  
③已修复/修正。缺陷修复，一般由开发人员进行。  
④关闭/非激活。缺陷被修复完成后，经过测试人员的验证后，没有问题。  
⑤重新打开。经过测试人员的验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。  
⑥推迟。缺陷现在不修复，推迟到下一个版本或阶段。测试要跟开发或者其他相关管理人员进行确认。  
⑦保留。缺陷暂时修复不了，一般也是由开发人员去设定。也需要测试人员进行确认。  
⑧不能重现。开发按照缺陷的复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三确认bug。  
⑨需要更多信息。作为测试人员，提交bug的时候，要尽可能把所有相关的文件一起提交（图片、视频）。  
⑩重复。测试中，一定要避免这种情况的出现。尤其在软件的某个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。  
⑪不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是bug。  
⑫需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或设计不明确。

5、缺陷的起源：

缺陷起源是指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷起源有：需求、构架、设计、编码、测试、用户。

6、缺陷的来源：

缺陷来源指缺陷的起因。缺陷被发现的阶段，直接原因。

缺陷来源有：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。

7、缺陷的根源：

缺陷根源指发生错误的根本因素。一般发生在总结阶段。

缺陷根源有：测试策略、过程/工具和方法、团队/人、缺乏组织和通讯、硬件、软件、工作环境。

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

# 二、缺陷的生命周期（重要） #

类似于面试官提问：针对你工作中发现的一个bug，说说这个bug的处理过程。其实就是要说明缺陷的生命周期中，每一个环节由谁做什么。

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

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

3、确认缺陷。一般由测试主管、质量保证、产品经理进行确认。

4、分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发，也可能是UI、产品经理。

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

6、验证缺陷。测试去验证缺陷有没有修复成功。

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

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

# 三、缺陷的识别 #

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

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

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

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

# 四、缺陷报告 #

1、缺陷报告模板：

1.  缺陷编号。Bug\_项目名称\_模块名称\_功能名称\_0001
2.  所属模块。一级模块/二级模块/三级模块
3.  优先级。缺陷的修复紧急程度。P1>P2>P3>P4
4.  严重程度。S1>S2>S3>S4。
5.  缺陷概述。用一句话描述缺陷的基本情况（时间、地点、人物、事件）。
6.  缺陷描述。将缺陷的复现步骤、预期结果和实际结果列出来。缺陷描述的准则：可再现，除了类似闪退、崩溃等不可再现的缺陷。不做评价，不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断。
7.  提交人。
8.  备注。一般写产生该缺陷的特殊情况。将Bug的截图作为备注信息。

![20201124155226813.png][]

2、缺陷报告编写目的：

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

3、预期读者：开发人员、质量管理、市场人员、运维人员。

所以缺陷报告要写得很直白、清晰明了。

4、缺陷报告编写准则：准确、清晰、简洁、完整、一致。

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

5、缺陷跟踪系统：禅道、ALM、JIRA等

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

# 五、测试需求、测试用例、缺陷报告的关系？ #

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

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