执行阶段
测试阶段，统一缺陷录入的管理，便于开发更高效的识别。
执行人
测试人员，开发人员，产品人员，设计人员
规范内容
1、目的：
（1）协助开发工程师准确定位并快速解决问题
（2）帮助项目经理准确预估修复缺陷的优先级
（3）方便产品经理了解缺陷对用户或业务的影响及重要性
2.适用范围
适用人员：测试人员，开发人员，产品经理
3.缺陷书写规范
新建缺陷必填项
image.png
如上图，红色高亮部分为提交缺陷时的必填项
3.1缺陷标题
[大模块+小模块]简短一句话描述问题所在，如：【我的-动态】iphone 6 发动态上传图片，一直失败
3.2环境配置
描述测试环境的配置细节，方便重现
3.3前置条件【可选】
测试步骤开始前的前提条件
3.4重现步骤
从用户角度出发，每个步骤可操作且连贯
3.5期望结果和实际结果
期望结果来自于对需求的理解，需要说明该发生什么，而不是不应该发生什么；
实际结果来自于测试执行的结果，需要说明发生了什么，而不是没有发生什么；
3.6处理人和模块
处理人：该缺陷所对应的开发人员或产品人员 如：黄建健
模块：该缺陷属于哪个模块 如：动态
3.7优先级和严重程度
优先级是缺陷必须被修复的紧急程度
image.png
严重程度是因缺陷而引起的故障对软件的影响程度
image.png
致命：系统崩溃，死机，无法登录进入下一步操作、对用户产生致命影响
严重：主要功能模块未实现，其它功能模块可以下一步操作
一般：次要功能不能正常使用，提示信息错误
提示：界面优化，报错时未给出友好提示，文字排列不整齐
建议：对软件使用不符合用户使用或优化的地方
3.8 发现版本和缺陷类型
发现版本：该缺陷是在哪个版本被发现的 如：20190417企业版
缺陷类型【可选】：该缺陷是属于哪种缺陷类型 如：前端缺陷
image.png
3.9附件【可选】
界面截图、测试用例日志、服务器端日志、GUI测试的执行视频等
4、缺陷修复规范
4.1缺陷修复流程
image.png
4.2流程描述
a) 测试人员发现bug提交给开发；
b) 开发人员判断是否是bug；
c) 如果是bug进行修改，修改完成后更改bug状态为已解决，并写上影响范围及原因；
d) 如果不是bug，退回给测试人员并将状态改为无需解决/外部原因/无法重现/重复bug/设计如此/问题描述不准确/需求变更/已转需求，并描述退回原因；
e) 开发人员修改完成的bug，由测试人员进行验证，确认修改正确，写上评论后将bug状态置为已关闭；
f) 验证未通过的bug写上原因并重新打开，开发人员继续修改，直到验证通过，写上评论后将bug状态置为已关闭；
g) 测试人员需要对开发人员进行延期处理、挂起的状态跟产品经理、开发负责人进行三方确认；
h) 如与开发人员意见不一致，认为是bug，需提交到产品经理处进行统一处理；
网友评论