缺陷处理流程
本页仅作为文档页封面，使用时可以删除
This document is for reference only-rar21year.March
缺陷处理流程
1
缺陷处理流程
1. 缺陷处理流程图如下：
2
新建缺陷是否打开缺陷否已否决是(重新)打开处理缺陷否延期处理是否已经修复测试回归是否关闭是关闭缺陷 2. 缺陷处理流程图中判定说明：
1) 是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先
级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。
2) 处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺
陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发
3
组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。
3) 是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。
并在注释中说明重新打开理由。
3. 缺陷处理流程图中流程说明：
1) 新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。 2) 已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而
定），找到缺陷相关人员进行确认。如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。
3) （重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺
陷。
4) 延期处理：开发组长/经理根据情况，对缺陷进行延期处理。
5) 已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。并
通知测试人员进行回归。
6) 回归测试：测试人员对已经修复的缺陷进行回归。 7) 关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。
4. 为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如
下：
4
缺陷处理流程测试人员测试组长/经理开发组长/经理开发人员会议小组（项目经理、开发/测试经理、开发员、测试员）新建缺陷缺陷管理是否打开缺陷否已否决处理是是否打开否决重新打开否处理缺陷延期处理缺陷否是修复缺陷测试回归是否关闭是关闭缺陷
5
如果上面判定和流程中，某一方存在异议的，应及时反馈上级。然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
2
1. 2. 3.
缺陷填写说明
BUG全部提交到QC中（指定域名的指定项目下）。
“摘要”，用简单明了的语句说明白你这个BUG，相当于BUG的中心语句。 详细信息填写规范： 1)
“分配给”，选择这个BUG所属模块是属于那个研发人员 ，并把问题指派给他（如果不知道，就直接提交给该负责人）。 2)
“缺陷类别”，分为5种(参考平台共享文件《QC操作守则0922》)
BUG-功能——功能上的缺陷，如按钮没响应，充值不成功，需求上提到的功能没实现等。 BUG-样式——页面样式的缺陷，如界面颜色、字号、排版、图片大小与所需求不符等。 功能建议——新增加的网页功能性建议。
UI建议 ——对我们网页的布局、设计、色彩、交互、按钮、动静态效果、字体、文本框、表情、图片等有关视觉效果和操控便利性方面的建议。
课程建议——提出的和课程的学习、播放、内容、课程制作等有关的一切建议。
3) 4) 5)
“缺陷主题”，选择你提交的BUG所属那个模块。 “项目”选择提交问题时测试系统的影响版本。 “严重程度”，分为5个等级
1-低：
① UI 控件不符合界面规范。 ② 影响UI友好性。
③ 用户不频繁使用的功能易用性差。 2-中：
① 用户需求未实现（不影响用户完成业务、用户使用不频繁)。
6
注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类。
② 用户需求实现错误（不影响用户完成业务、用户使用不频繁)。 ③ 用户操作过程中系统出现异常报错，但不影响系统功能的使用。 ④ 用户使用不频繁的功能，响应时间超出忍耐限度。 注：忍耐限度根据实际软件系统的特点而定。 ⑤ UI 上存在错误引导用户的信息。
⑥ UI 上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。 ⑦ 用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）。 3-高：
① 用户需求未实现（影响到用户完成业务）。 ② 用户需求实现错误（影响到用户完成业务）。
③ 用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）。 4-非常高：
① 用户体验性非常差，会导致“大量”用户投诉的。 5-紧急：
① 后台数据受损或丢失。
② 导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃。
③ 与“钱”沾边的，如充值、购买课程后不能使用、不购买课程也能使用课程等。 4.
缺陷“描述”规范 1)
指明当时出这个BUG的现场环境，示例如下：
测试服务器： 浏览器：IE9、360浏览器（兼容模式）
2) 3)
指明缺陷所属模块或页面的路径，示例如下：
路径：把BUG产生的步骤一步一步写清楚，可以用以下方法写。（如果一句话就可以说明的BUG，就不必要分步骤了）
示例：
缺陷重现步骤：
7
1、。。。 2、。。。 3、。。。 4、。。。
测试结果：。。。。。。 期望结果：。。。。。。
4)
另外可以通过上传截图或附件，可以进行简单明了的说明BUG存在，也可作为BUG证据。
注意：
①关于优化建议方面的缺陷，根据实际情况，可以简化以上的一些步骤。 ②问题描述简洁明了，条理清晰，使开发人员能据此复现定位问题。 ③缺陷描述语句，应避免出现错别字，语病，歧义等。
3
1.
BUG验证/关闭问题说明
当BUG状态变为“已修复”，根据回归清单或测试申请（由开发提供）进行回归测试，如果回归测试后该问题被解决，则关闭该BUG，并在注释中填写如下信息：
2. 3.
验证通过：是 验证日期：。。。
如果回归测试验证不通过，则“重新打开”该BUG，并在注释中填写明情况。 如果出现“延期处理”、“已否决”的缺陷，首先查明原因，如果与研发不能达成一致的需要及时向上级反馈。
4
1.
关于研发人员处理缺陷
当研发人员接到一个缺陷后，应该填写“估计修复工时”、“估计修复日期”。
8
2. 研发人员解决BUG写的注释一定要有以下几点： 1) 2) 3)
说清楚BUG产生的原因。
简单说明BUG处理的方法或过程。
并在bug中注明实际修复工时，实际修复日期。
3. 研发人员否决或延期处理bug，需要注明原因。
9
因篇幅问题不能全部显示，请点此查看更多更全内容