测试流程之缺陷

近期公众号以输出测试基础文档为主，主要是为了帮助测试新人和想入行的同学能尽快了解测试，熟悉测试的工作内容，同时也可以帮助测试老司机更深地认识测试，如果大家有什么想了解的或者有什么意见，欢迎在后台留言，我会一 一作答。

前言：缺陷是测试人员的重中之重的工作内容，提交一个高质量的缺陷单应该是测试人员必备功力，这篇文章，我们就来分析一下缺陷产生原因，组成以及缺陷处理流程。

1.缺陷产生的原因

在什么情况下，测试人员会提交缺陷单？

在测试执行阶段，测试人员根据测试用例去执行程序，如果执行的实际结果与用例中的预期结果不符就会产生缺陷，这时测试人员应该提交一个缺陷单来跟踪此缺陷的生命周期。

那执行的实际结果与用例中的预期结果又有哪些不符会产生缺陷？

一般来说，缺陷产生的原因有功能点遗漏，功能做错了，功能冗余，功能未达到需求文档的要求，再则就是用户的体验性不好，这些都会产生缺陷单的原因。

2.缺陷等级

在提交缺陷单时，测试人员会根据缺陷对程序产生影响的程度而为缺陷单定等级，给缺陷单定缺陷等级可以方便开发在修改多个缺陷时能快速找到主次之分。

缺陷的等级一般有：致命，严重，一般，提示

致命性问题

程序无响应或崩溃 核心功能未实现或无法运行或功能页面无法打开 程序实现与需求规格严重不符 严重性数值计算错误 致命安全漏洞 数据库内存泄漏等

严重性问题

产品功能实现不正确 主业务流程功能没正确实现，阻碍其子功能测试 严重兼容性或页面样式问题 程序实现与需求不符 主要数值计算错误 严重的功能逻辑错误 页面JS错误导致功能不可用 角色或权限错误等

一般性错误

轻微的数值计算错误 操作界面UI严重错误 功能实现错误，但不影响主要功能 编程性规范类错误

提示类错误

操作界面文字错误 提示信息错误 界面格式不规范（区分标示、界面排版） 界面边框、线条错误

建议类

易用性操作类建议 界面提示建议 优化性建议

3.缺陷优先级

在提交缺陷单时确定缺陷的优先级，可以方便开发人员在修改缺陷单时明确开发人员什么时间段内将缺陷单修改完。

缺陷优先级有：紧急，高，中，低

根据缺陷的优先级定出修复时间

紧急：立即解决，优先级最高

高：当天解决

中：一到二个工作日

低：三到四个工作

每个公司制定的缺陷优先级都有可能不同，这里只是提出建议。

4.缺陷等级与优先级的关联

一般来说缺陷等级高的，往往优先级就高，但是这个公式却并不一定所有都是，例如：概率性极低的系统崩溃，它的缺陷等级就高，但优先级并不一定是紧急。

同时反之亦成立，缺陷等级低，但不一定优先级就最低，例如：软件的LOGO错误，这样缺陷等级往往很低，但优先级却是最高的

5.一张缺陷单包含的元素

测试人员发现bug时，需要在缺陷管理工具上进行提交bug单，以方便跟踪，并不建议测试人员发现bug后直接在即时通讯工具上给开发反馈，开人员进行修改，这样操作后期会给测试人员回归工作带来麻烦，易造成bug回归遗漏，给程序留下安全隐患。

6.缺陷处理流程

作为一个测试人员不仅仅主要是为了发现缺陷和提交缺陷，测试人员还应该具备分析缺陷和定位缺陷的能力，但因为分析和定位缺陷设计到后台环境和每个公司业务的不同而处理的方式也不同，所以就不在这里讨论了，后期文档中再更新。