缺陷的相关内容

缺陷的基本概述

缺陷的定义

缺陷的属性

正向修复重要于反向修复

缺陷的类型

缺陷的类型是根据缺陷的自然属性划分的缺陷种类

**注意：**需求分析、设计阶段，文档类型的缺陷多；
集成测试阶段，一般接口类型的缺陷多些；
系统测试阶段，功能、界面类型的缺陷多些；

缺陷的严重程度

缺陷的严重程度是指因缺陷引起的故障对软件产品的影响程度

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

缺陷的修复优先级

**注意：**很大程度上取决于缺陷对测试工作的影响程度（比如说登录注册功能无法使用）优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改。
**面试问题：**缺陷的严重程度和优先级有什么关系？
1.二者之间没有任何的直接关系
2.不要认为严重的缺陷，修复优先级就越高
3.如果碰到优先级和严重程度都高的缺陷，也只是偶然
（例如点QQ的帮助按钮会有闪退现象，严重程度很高，但优先级就很低；企业logo错误，不影响任何功能，但必须优先修复）
面试问题： 提交缺陷时能不能夸大或降低缺陷的严重程度或者是优先级？
1.不要因为私人恩怨而针对开发或者帮助开发哦
2.不能搞“狼来了”

缺陷的状态

缺陷状态是指缺陷通过一个跟踪修复过程的进展情况（缺陷的处理进度）

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

缺陷的起源

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

缺陷的来源

指缺陷的起因

缺陷的根源

指发生错误的根本因素

**注意：**缺陷的起源、来源、根源，一般关注较多的是来源（直接原因）;在测试总结的时候，关注缺陷的根源

缺陷的生命周期（重点）

1.发现缺陷：由测试人员发现。开发也能知道自己哪里写错了，但不会广而告之
2.提交缺陷：由测试人员发现。开发更不可能提交bug
3.确认缺陷：一般由测试主管、质量保证（QA）、产品经理进行确认
4.分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配，分配的对象可能是开发也可能是UI、产品经理
5.修复缺陷：主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题
6.验证缺陷：测试去验证缺陷有没有修复成功
7.关闭缺陷：只能由测试人员进行，否则出了问题，测试人员一律不背锅
**面试问题：**针对你工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）

缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例（都是客观的依据）
同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通，同行业隐性需求，都是带有主观色彩的依据
测试人员在识别缺陷的时候，要很灵活的对待

缺陷报告

1.缺陷编号：Bug_项目名称_模块名称_功能名称_0001
2.所属模块：一级模块/二级模块/三级模块（例如：上课所用的直播软件，如果想要查看签到的历史记录，需要进入直播主界面——互动应用——签到——签到历史记录 ）
3.优先级：缺陷的修复紧急程度。P1>P2>P3>P4（参照ppt中的优先级）
4.严重程度：S1>S2>S3>S4（参照PPT中的严重程度等级）
5.缺陷概述：用一句话描述缺陷的基本情况
6.缺陷的描述：将缺陷的复现步骤、预期结果和实际结果列出来
7.提交人：是谁就写谁的名字
8.备注：一般写产生该缺陷的特殊情况，将bug的截图作为备注信息

编写目的和预期读者

由于缺陷报告的读者有很多：开发，质量管理，市场人员，运维人员
所以缺陷报告要写的很直白，清晰，明了

报告编写准则

缺陷描述准则

1.可以再现：针对大多数的缺陷都是如此，但是有一小部分的缺陷是难以再现的（类似闪现，崩溃这种不可再现的缺陷，无需做到。针对一些可以再现的闪退缺陷，也要进行步骤的详细描述）
2.不做评价：不对缺陷的出现严重程度和缺陷表现出来的效果进行主观臆断

缺陷管理方式和模板

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

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

获取测试需求是测试工作的重点，也是第一步。通过对需求的分析，了解和掌握测试的方向和内容，例如：
1.分析出系统的模块和组织结构
2.分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用
3.识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员就要有相应的分析成果，一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析

设定测试中需求的正/反向和优先级
当有了测试需求后，就开始针对每一个需求点进行测试用例的设计，也就是每一个需求点都要被测试
因此测试的过程中，衡量需求的覆盖程度，就非常的重要，使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明
如果需求覆盖度<100%，那一定说明了测试覆盖度不够

测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量
1.设计的测试用例总量 TC
2.执行的测试用例数量 EC
3.未执行的测试用例数量 WC
4.执行通过的测试用例总量 SC
5.执行失败的测试用例总量 FC
6.提交的缺陷的总量 BC
以上6个数据，他们要符合以下数量关系：
1.TC>=EC
2.TC=EC+WC
3.EC=SC+FC
4.BC>=FC,提交的bug数量，多于执行未通过的用例数。一条用例的预期结果数量是固定（甚至是唯一的） ，说明了测试过程中发现的缺陷，除一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的
5.通过SC/EC可以表现出系统的质量是否合格
6.通过EC/TC可以表现出系统的需求是否得到满足