缺陷管理规范
一、概述
缺陷管理是测试流程中的周期较长的一个环节,统一使用磐石系统进行记录管理闭环。
以下情况下,可由测试发起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,可归类为三方问题
处理:建立三方问题模块,确认为三方问题的移至该模块,版本已知问题、月度质量缺陷统计需要单独标注。
测试可将未说明修复细节和缺陷影响范围的缺陷打回,不进行回归测试。