遇到BUG怎么分析，全方位带你分析

软件测试的目的是尽可能早地找出软件产品中潜藏的缺陷，并确保其得以修复。所以缺陷的分析就会变得很关键，那么如何来分析缺陷呢？

根据缺陷的定义描述准则：

所有不满足需求或超出需求的都是缺陷。缺陷的判定主要的依赖点在于产品需求说明书，它主要说明了软件要具备的功能(或者不具备的功能)，它对开发的产品进行定义，给出产品的细节，如何做，做什么，不能做什么。对于BUG的分析，可以从以下角度来进行考虑：

1.缺陷类型：

根据缺陷的自然属性划分的缺陷种类，比如：功能缺陷，UI界面缺陷，文档缺陷，代码缺陷，设计缺陷，性能缺陷等...

2.缺陷严重程度：

因缺陷引起的故障对软件产品的影响程度，一般可以分为四个方面：

致命(Fatal)：

主要功能完全丧失，用户数据遭到破坏，死机，崩溃，闪退且不能恢复，甚至危及人身安全(S1)；

严重：

主要功能部分丧失，系统的次要功能完全丧失，软件闪退但是重启后可以恢复，数据不能保存(S2)；

一般：

系统的次要功能部分丧失，但是不影响用户的使用，提示信息不准确，等待时间长，界面差(S3)；

较小(建议型缺陷)：

使用不方便，错别字，排版重叠不合理(S4)

3.缺陷优先级：缺陷必须被修复的紧急程度，一般可分为：

立即解决(P1)：

该缺陷导致系统的主要流程走不通，测试工作无法进行，需要开发立刻修复；

高优先级(P2)：

缺陷严重，影响测试，需要优先考虑修复；正常排队(P3)：提交的缺陷按照顺序等待开发进行修复；

低优先级(P4)：

提交的缺陷等开发有时间再进行修复

4.缺陷状态：

缺陷通过一个跟踪修复过程的进展情况，从公司常见的缺陷管理工具中，我们能够获取到缺陷状态可以有：

激活或打开：

指的是缺陷提交以后，公开给开发以及相关的人员看到；

已修复或已修正：

开发人员认可了缺陷，并按照缺陷的描述在代码中修复了该问题(测试人员还没有进行确认验证的操作)；

关闭：

开发人员修复完成后，经过测试人员的验证，并通过，就可以把状态改为关闭；

重新打开：

开发人员修复后，测试人员进行验证，验证不通过，缺陷还存在，就要把缺陷的状态更新为打开；

推迟修复：

指的是该缺陷在当前版本不进行修复，放在下一个版本中进行修复，必须要有相关的负责人确认才可以，不能关闭，持续跟踪；

保留：

缺陷是第三方的问题，开发也是没有权限进行修复，缺陷一直保留在缺陷库中，等待第三方开发者授权或者帮助修复；

不能复现：

开发按照测试人员提供的复现步骤，不能重现该缺陷，原因可能是测试人员提交的缺陷描述或者复现步骤不清楚，相关的素材条件不完善；

我们可以提供一些截图(缺陷的截图)，甚至可以录制一些demo视频，日志文件(记录一些报错的信息)，作为有力的证据帮助开发进行复现；

重复：

指的是同一个缺陷被多个测试人员所提交。对于重复的缺陷进行删除或者合并；

不是缺陷：

不是软件缺陷，直接删除。

5.缺陷起源：

缺陷引起的故障或事件第一次被检测到的阶段，比如是在需求阶段，架构设计阶段，编码阶段，测试阶段或者用户使用阶段等

6.缺陷来源：

指缺陷的起因，是因为需求说明书，概要设计，详细设计，接口文档，还是数据库，代码等问题引起的。

所以，在实际软件应用中，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。软件测试是保障软件质量管理体系中一个非常重要的手段。作为测试从业者，应在工作中尽早和不断发现软件中潜藏的缺陷，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 希望能帮助到你！【100%无套路免费领取】