缺陷和缺陷报告

1.缺陷的基本概述

2.缺陷的生命周期

3.缺陷的识别

4.缺陷报告

 

缺陷的定义

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

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

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

4.软件为实现产品说明书未明确提及但应该实现的目标

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

 

缺陷的属性

 

一：缺陷的定义和属性

1.****缺陷和定义

2.缺陷的属性

1）缺陷的类型：功能，界面，文档，软件包，性能(performance)

注意：需求分析，设计阶段，文档类型的缺陷比较多；集成测试阶段：接口类型的缺陷比较多；

系统测试阶段：功能，系欸按类型的缺陷多一些；焉廋测试阶段，更多而关注的性能缺陷；实施过程，可能会遇到一些软件包的缺陷

2）缺陷的严重程度，缺陷的故障对软件的影响。一般要有分类，每个公司和团队的扽类标准或略偶不同。

学习过程中，以描述上的严重等级进行缺陷严重程度分析

注意：结合却显得影响，结合软件的具有功能（业务或者流程）

3）缺陷的修复优先级，很大程度上取决于对缺陷测试工作的影响程度

例如：

电商系统的用户注册功能无法使用（无法登陆，商品购买，支付结算，下订单，物流跟踪，收货，评论等功能）

就必须立即修复；电商系统中关于购买流程帮助说明的网页链接点击404页面

注意：优先级别的衡量，一般可以根据测试的软件系统业务流程划分，软件的基本功能的反向测试的额内容，优先级别较低。软件的备选流，

基本功能测试跟踪的反向测试的内容，优先级别较低，甚至可以可改可不改。

 

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

1）二者之间没有直接的关系。

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

3）如果碰到，优先级和严重程度都高的缺陷，也只是偶然情况

例如：QQ的帮助按钮，会经常有闪退的现象。严重程度很高，但是优先级别就很低。

企业logo错误，不影响任何功能；但必须优先级修复；

 

面试提问：

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

坚持原则，公正公平

不能搞“狼来了”

也不能私人关系，帮好朋友减少不良影响；

 

 

 

 

缺陷的修复优先级

缺陷的优先级指缺陷必须被修复的紧急程度

 

 

缺陷的状态

缺陷的章台通过一个跟踪修复的过程的进展情况；

 

 

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

①激活/打开（新建）。有测试人员进行标准

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

③确认。确认已修复（修正）。在缺陷被修复之后，一般由开发人员进行

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

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

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

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

⑧不能重新。开发按照缺陷的复现步骤不能再次发现缺陷。一啊不能闪退，奔溃类型的特征具有类似的特征。

或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三确认bug。

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

⑩重复的缺陷。测试中一定要避免这种i情况的出现。尤其在软件的某一个功能频繁被多个摸板（由不同的测试人员测试）调用的情况下。

⑩①不是缺陷。一定不要在测试工程师工作生涯被开发标注缺陷状态不是bug

⑩②需要修改需求说明书，缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成的

 

缺陷的起源

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

 

缺陷的来源

缺陷的来源指缺陷的起因

 

缺陷的根源

缺陷的根源指发生错误的根本因素

 

5）缺陷的起源，根源，来源。已关注比较多的缺陷的来源（直接原因）；在测试总结的时候，关注却显得根源；

 

缺陷的生命周期

 

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

2.调教缺陷。由测试人员。开发不可能提交缺陷

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

4.分配缺陷。经确认之后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。

分配的对象可能是开发，也可能时开发，UI，也可能时产品经理

5.修复缺陷。主要由开发修复，也可能时产品经理此u夫问题

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

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

 

面试提问：

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

 

三：缺陷的识别

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

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

 

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

 

 

四：缺陷报告

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

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

3.优先级。缺陷的修复紧急程度。P1>P2>P3(参照优先级）

4.严重程度。S1>S2>S3(参照严重程度等级）

5.缺陷概述。用一句话描述却显得基本情况。

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

7.提交人。是谁就写谁得名字

8.备注。一般写产生该缺陷的特殊情况，将bug截图

 

缺陷报告编写的目的：

易于搜索软件测试报告的缺陷

报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体，准确

软件开发人员希望获得缺陷的本质特征和复现步骤

市场和技术等部门希望获得缺陷类型分布一级对市场和用户的影响程度

 

预期读者

开发人员，质量管理人员，市场人员，运维人员。。。

1）展现缺陷的详细信息

2）展现缺陷的影响程度和方式

 

由于缺陷报告的读者很多：开发，质量管理，市场人员，运维人员

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

 

缺陷报告的编写准则

correct（准确）：每个组成部分描述准确，不会引起误解

clear（清晰）：每个组成部分的描述清晰，易于理解

concise（简洁）：只包含必不可少的信息，不包括任何多余的内容

complete（完整）：包含复现该缺陷的完整步骤和其他本质信息

consistent（一致））：按照一致的格式书写全部的缺陷报告

 

缺陷描述的规则：

1）可以再现。针对绝大多数的缺陷都是如此。但是有一些小部分缺陷是难以做到的（类似闪退，奔溃这种不可出现的缺陷，无需做到）

针对一些可以重复出现的闪退缺陷，也可以进行步骤详细描述）

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

 

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