标签：工程 测试报告 需要 bug 里程碑 哪些 *** 直接 禅道
缺陷管理规范及流程
修订历史纪录
|
日期 |
版本 |
说明 |
作者 |
|
2018-8-1 |
1.0 |
创建 |
*** |
目录
本文档定义缺陷书定规范及缺陷生命周期，以便测试及开发人员能够更好的配合工作, 提高工作效率
适用人员：测试人员，开发人员，产品经理
适用工具：禅道
3.关键角色及责任
|
序号 |
角色 |
责任 |
|
01 |
测试工程师 |
1.提交缺陷，验证缺陷 |
|
02 |
测试组长 |
1.审核测试人员提交的缺陷 2.定期对缺陷进行分析，报告现状，在测试报告中给出意见 3.分析测试中的风险 |
|
03 |
开发工程师 |
1.分析缺陷，解决缺陷 |
|
04 |
开发组长 |
1.分配缺陷,并提出处理意见 2.定期对缺陷进行分析，对bug多的模块代码走查 3.跟踪缺陷修复进 |
|
05 |
产品经理 |
1.提出需求变更 2.Bug仲裁 |
如上图，红色高亮部分为提交缺陷时的必填项
重现步骤格式说明：新建缺陷时重现步骤栏必须包含前置条件，步骤，结果，期望，具体格式见上图
简短一句话描述问题所在，如：领取优惠券失败，页面报400错误
[前置条件]
描述缺陷的必要条件，或者描述在写[步骤]之前需要的前提，如：
优惠券已生成成功，批次号：YX0726101306538
优惠券领取链接：https://pro.uselect.com.cn/activity/html/coupon.html?batchNum=YX0726101306538
[步骤]
用数字编号，一步步描述重现问题的所有操作步骤，一个步骤对应一个结果，如：
[结果]
以上步骤所对应的实际结果，必要时可以在备注栏贴上截图，如：
领取失败，页面报400错误，见截图：编号001
一个缺陷只描述一个问题
[期望]
清淅地描述期望的结果，必要时可以在备注栏贴截图，如见截图，编号：002，期望结果必须有文字描述
开发人员在处理缺陷时，根据缺陷实际情况填写如下内容：
缺陷类型：如，代码错误，配置相关，功能优化，用户体验 ，测试人员提交缺陷时可以选择缺陷类型，最终缺陷类型由开发人员在确认或解决缺陷时负责
优先级：优先级从1到4，级别分别为紧急，高，中，低
紧急：立即修复
高：下次发版前必须修复
中：下次里程碑前必须修复
低：时间允许可以修复，或经项目负责人确认后可以在维护阶段修复，对于延期处理的缺陷（功能）可以将优先级暂时设为低，在下次项目周期时再调整优先级，如目前优惠券购买价格功能漏项的缺陷
解决方案：如，已解决，设计如此，无法重现
解决日期：上传代码时间
测试人员在新建缺陷时，参照如下定义新建缺陷：
严重程序：严重程度编号从1到4，分别为致命，严重，一般，优化
致命：系统崩溃，死机，无法登录进入下一步操作
严重：主要功能模块未实现，其它功能模块可以下一步操作
一般：次要功能不能正常使用，提示信息错误
优化：界面优化，报错时未给出友好提示，文字排列不整齐
所属项目，模块，操作系统，浏览器
备注：截图及简单易读的文字
缺陷状态：激活，已确认，已修复，已关闭
测试人员根据规范提交缺陷,测试主管定期审核缺陷并提出意见
缺陷确认期限：2天
开发人员依据缺陷优先级分析解决缺陷,开发主管跟踪缺陷解决进度，对缺陷多的模块加强代码审核
确认缺陷:当天新建的缺陷状态为[激活]，对应的开发人员需在2天内全部审核一遍，将缺陷状态置为[已确认]直接解决，
修复缺陷:解决方案，版本，解决日期必填
**必须上传代码到测试服务器以后才能修改缺陷状态
写备注：开发人员在提交代码后必要时应在备注栏写明该代码预计会影响哪些功能，以便测试人员做回归测试
开发认为不是缺陷：将缺陷状态置为已拒绝；指派给缺陷提出者；同时注明拒绝理由
缺陷缺乏必要的信息：将缺陷状态置为已拒绝；指派给缺陷提出者；同时注明拒绝理由
缺陷验证期限：2天
验证缺陷:已解决的缺陷 ，测试人员需在2天内验证
验证通过：关闭缺陷，同时在备注栏写明验证通过
验证未通过：缺陷状态改为激活并指派给对应开发，同时必须在备注栏写明原因
若在验证该 缺陷时，发现新的缺陷,应重新提交缺陷, 若验证此缺陷的前提必须是该新提交的缺陷解决以后，应在备注栏写明原因，如：验证前提：待缺陷-XXX 验证通过
5.缺陷仲裁
6.需求变更
标签：工程 测试报告 需要 bug 里程碑 哪些 *** 直接 禅道
原文地址：https://www.cnblogs.com/applewang-123/p/9441814.html
