缺陷管理规范

缺陷管理规范

---

一、概述

缺陷管理是测试流程中的周期较长的一个环节，统一使用磐石系统进行记录管理闭环。

以下情况下，可由测试发起BugReview：
    1、 缺陷问题较多，解决过慢；
    2、 需项目组对已知问题达成共识，评估上线前版本质量。

---

二、缺陷阐述？

BUG：计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
需求：系统目前没有的功能，或需求的逻辑问题导致影响用户体验，不论大小。
建议：用户根据自己的业务需要对系统提出的优化要求，会同时包含BUG和需求两类信息。
其中BUG类的如：提示信息看不懂、信息描述不清、错别字、界面缺少按钮，所有的用户看不懂的异常 报错。
其中需求类的如：功能优化、界面优化、性能优化、新增功能。。

三、缺陷管理目的

1、测试：提交高质量缺陷，利于研发快速处理缺陷，减少无效bug率。
2、研发：详细的缺陷起因与修复细节，利于研发间问题流转减少沟通成本，研测问题流转减少回归漏测风险。提高问题处理效率与版本质量。
3、产品：明确的需求缺陷，利于需求问题回溯，推动需求变更或需求规划

四、缺陷属性的定义与规范

01缺陷严重程度

02缺陷发现深度

03缺陷优先级

04缺陷起因

05缺陷解决方法

06线上缺陷等级标准

五、缺陷记录规范

01陷记录规范【测试/运营】
（1）缺陷必填字段：缺陷名称、优先级、发现版本、严重性、发现方法、发现深度、责任开发、重现步骤、等。
（2）缺陷填写规范性：
严重性：参照【缺陷属性的定义与规范-01缺陷严重程度】
发现深度：参照【缺陷属性的定义与规范-02缺陷发现深度】
优先级：参照【缺陷属性的定义与规范-03缺陷优先级】
（3）提bug时，需要考虑该bug原始需求是否明确、bug前提条件是否满足、操作流程中输入数据是否正确、操作步骤是否清楚、 bug是否具有唯一性；避免提交操作错误、重复的、已知的Bug。
（4）附加截图和测试数据 ：
UI类型：需要上传bug的截图，并且标识出来；
功能类型：问题必须上传bug的视频、截图、log等；
崩溃类型：需要上传视频和log。偶现的提供出现时间点的ANR、crash日志即可。
避免低质量bug：
1、bug表述不清，只有一句话，介绍bug是什么，然后没有其他的说明。
2、不提bug，发现问题直接告诉开发人员，各种文字沟通讨论bug。
3、发现bug的场景没有保留，重现成本较高。
4、bug描述错误、不准确的bug、重复的bug、归类不准确的bug 
5、未经确认的需求类bug、 错误的建议性bug
注：研发可将提交的低质量缺陷打回，不进行修复处理。

02缺陷修复规范【开发】
（1）解决方法：参照【缺陷属性的定义与规范-05缺陷解决方法】
（2）缺陷起因：参照【缺陷属性的定义与规范-04缺陷起因】
（3）修复细节：需要明确说清楚，尤其是严重的缺陷；
注：
1）缺陷起因选择了“其他问题”，二级原因选择"其他"，必须描述清楚真是原因或填写与其相同的问题编号
2）三方问题：
定义：由三方公司、公司其他部门提供的SDK、依赖包、服务等引起的bug，可归类为三方问题
处理：建立三方问题模块，确认为三方问题的移至该模块，版本已知问题、月度质量缺陷统计需要单独标注。
测试可将未说明修复细节和缺陷影响范围的缺陷打回，不进行回归测试。