测试理论（3）——BUG/ISSUE/缺陷

1、BUG概述

场景：开发转测后，我们在测试过程中发现测试的实际结果与编写的测试用例期望结果不一致，那么就需要提单（提BUG）。

1.1类型

（1）建议：是软件产品改进建议，表达的是更加完善；

（2）优化：功能已实现，需要优化问题。可以是用户体现优化、性能优化。

（3）BUG：测试人员通过测试发现程序的问题。

（4）需求：客户有了新需求，产品经理对需求进一步梳理。

1.2BUG级别

（1）致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。

（2）严重：操作性错误、结果错误、功能遗漏。

（3）⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。

（4）建议：对产品的改进建议。

1.3BUG优先级

优先级表示修复缺陷的重要程度和紧迫程度。

紧急：影响进⼀步测试，需要⽴即修复。

⾼：必须在版本发布前修复。

中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。

低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。

1.4BUG状态

主要描述缺陷当前的状态。状态如下：

新建：测试⼈员新提交的bug、优化或者建议的状态。

进⾏中：开发⼈员确认是bug，在修复bug过程的状态。

已解决：开发⼈员已修复bug的状态。

已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。

不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态。

重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发⼈员的状态。

暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。

1.5BUG流程

 

 （1）测试人员在测试过程中，发现问题后新建一个BUG；

（2）这个BUG会分配给开发，开发收到后激活这个BUG，如果确实存在问题，就进行修改，然后再提交给测试，测试验证通过后，就关闭这个BUG；

（3）若测试在后续测试过程中，发现BUG没有完全修复好，就会重新激活这个BUG；

（4）如果认为不是很紧要，就延迟这个BUG，之后再处理；

（5）如果认为不存在问题，开发就会拒绝处理这个BUG。

1.6BUG注意事项

（1）标题一定要表达出问题的核心，看了标题就知道是什么问题；

（2）BUG步骤要清晰明了，通俗易懂，步骤要非常详细；

（3）提交的BUG最好有问题截图；

（4）提交的BUG最好有详细的日志信息（主要针对的是后台服务）