缺陷

缺陷的定义

缺陷的属性

缺陷类型

1.功能（Function),界面（ui),文档,软件包，性能，系统/模块接口

注意：需求分析，设计阶段，文档类型缺陷多，集成测试阶段，接口类型缺陷多，系统测试阶段，功能 界面类型缺陷多，验收测试阶段更多关注性能缺陷 实施过程中可能会遇到软件包的缺陷

软件的缺陷严重程度 

缺陷修复优先级

1.很大程度上取决于缺陷对测试工作的影响程度，例如：电商系统的用户注册功能无法使用（无法登录，购买，结算------。。。。）等功能无法进行，就必须立即修复！ 如电商系统中关于用户购买流程帮助说明的网页链接点击404页面，就低级优先

注意：优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷优先级高 甚至需要立即解决

软件的备选流，基本功能测试中的反向测试的内容 优先级较低，甚至有些可改可不改

 

缺陷的状态

表示缺陷的处理进度

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

1.**/打开（新建）由测试人员进行标注

2.确认，确认新提交的缺陷是一个真实有效的缺陷 一般由测试主管或者质量保证（QA）产品经理进行确认，指派给相关人员进行处理

3.已修复/修正 在缺陷修复后 一般由开发人员进行

4.关闭/非** 缺陷被修复后 经过测试人员验证后没有问题

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

6.推迟 缺陷现在不修复 推迟到下一个版本或者阶段，测试要跟开发或者其他相关的管理人员进行确认

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

8.不能重现 开发按照缺陷的复现步骤不能再次发现缺陷 一般闪退，崩溃类型的缺陷具有类似特征，由于操作系统，浏览器的缓存等信息出现问题。所以作为测试人员在提交BUG之前，要在三确认BUG。

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

10.重复 测试中，一定要避免这种情况的出现，尤其在软件的某一个功能频繁被多个模块（又不同的测试人员测试）调用的情况下

11.不是缺陷，一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是BUG

12.需要修改需求说明书 ，缺陷不是技术原因造成的，而是由于需求不明确造成的

程序缺陷的来源