软件测试（六）——缺陷以及总结

缺陷的基本概述

缺陷的定义

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

缺陷的属性

缺陷类型：

功能（Function）
用户界面（UI）
文档（Documentation）：用户手册、注释等
安装包（Package）
性能（Performance）
接口（Interface）
需求分析、测试阶段、设计夹断，文档类型的缺陷多；验收测试阶段更多关注的是性能缺陷；试试过程可能会遇到一些软件报的缺陷

缺陷的严重程度：

致命（Fatal）、严重（Critical）、一般（Major）、较小（Minor）
一般而言，跟钱有关的都属严重缺陷

缺陷优先级：

立即解决（P1）、高级优先（P2）、正常排队（P3）、低级优先（P4）
取决于缺陷对测试工作的影响程度
（立即修复：电子商城无法注册，无法登录、购买、结算、支付、下订单、物流跟踪、收货等都无法实现。）
（正常排队：开发之前完善即可）
（正常排队或者低级优先：用户购买流程帮助说明的网页链接点击404）
优先级的衡量一般根据软件测试系统的全业务流程划分，
软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的翻相册时内容，优先级比较低，甚至有些可改可不改

缺陷的优先级和严重程度有什么关系？

二者之间没有任何直接的关系
不要认为严重的缺陷，修复的优先级就高
如果遇到优先级和严重程度都高的缺陷，也只是偶然（例如：QQ的帮助按钮，经常闪退，严重程度很高；但是优先级很低）
例如：企业的logo出错不严重、不影响使用，但需要立即修复

提交缺陷时能不能夸大或降低缺陷的严重程度
不能。公正、客观。不能狼来了或者私人关系。变成恶性循环

缺陷的状态：

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

缺陷的起源：

缺陷的来源：

缺陷的根源：总结时关注的问题

注意：正向测试用例产生的缺陷修复的紧急程度要比反向的紧急程度高。
在这里插入图片描述

缺陷的生命周期

周期	负责人
发现缺陷	测试人员
提交缺陷	测试人员
确认缺陷	测试主管/质量保证（QA）、产品经理确认
分配缺陷	谁确认谁分配。分配对象可能是开发、UI、产品经理
修复缺陷	主要由开发修复，也可能有产品经理、UI
验证缺陷	测试
关闭缺陷	只能是测试人员。否则出了问题一律不背锅

面试：针对在你工作中发现的bug，说说这个bug的处理过程。（缺陷的生命周期中，每一个环节由谁做什么）————不着急回答，思考一下实际人家想问什么。

缺陷的识别

依据：
客观依据：需求文档、设计文档、产品原型，测试用例
主观依据：同行业类似的成熟软件，和开发人员沟通（下下策），有经验的测试人员，同行业隐形需求

缺陷报告

缺陷编号：Bug_项目名称_模块名称_功能名称_001
所属模块：一级模块、二级模块、三级模块
优先级：缺陷的修复紧急程度。P1>P2>P3>P4
严重程度：S1>S2>S3>S4
缺陷概述：用一句话描述缺陷的基本情况
缺陷的描述：将缺陷的复现步骤，预期结果，实际结果列出来
提交人：名字
备注：一半写该缺陷的特殊情况。将Bug的截图作为备注信息。（闪退无法复现这类情况可以无图片，其他均需要有）

例子： 所属模块：上课直播签到功能：查看签到历史记录：直播主界面-互动应用-签到-签到历史记录（根据需求分析的图）

编写目的和预期结果

注：公司新手提交缺陷报告，最好提前问公司的缺陷评判标准，有没有书面的形式，最好看一下之前员工的缺陷提交情况。

缺陷报告编写目的（展现缺陷的详细信息、影响程度和方式）

易于搜索软件测试报告的缺陷
报告的软件缺陷进行了必要的隔离，报告的缺陷信息，更详细，更具体
开发人员希望获得缺陷的本质特征和复现步骤
市场和技术等部门希望获得缺陷类型分布以及对市场和用户的影响程度
预期读者：
开发人员、质量管理人员，市场人员、运维人员
报告要直白、清晰、明了（准确、清晰、简洁、完整、一致）

报告编写准则

缺陷描述准则

缺陷管理方式和模板

总结