缺陷处理流程

1、缺陷处理流程1缺陷处理流程1.缺陷处理流程图如下:关闭缺陷2. 缺陷处理流程图中判定说明：1) 是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。2) 处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。3) 是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。并在注释中说明重新打开理由。3. 缺陷处理流程图中流程说明：1

2、) 新建缺陷：测试人员(其他人员)根据缺陷填写说明，新建缺陷。2) 已否决：对已否决的缺陷，最后由测试发起会议(形式可以根据情况而定)，找到缺陷相关人员进行确认。如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。3) (重新)打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。4) 延期处理：开发组长/经理根据情况，对缺陷进行延期处理。5) 已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。并通知测试人员进行回归。6) 回归测试：测试人员对已经修复的缺陷进行回归。7) 关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。4. 为了说明各个角色

3、在缺陷处理流程中的职责，据测试流程所画泳道图如下：如果上面判定和流程中， 某一方存在异议的， 应及时反馈上级。然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。2 缺陷填写说明1. BUW部提交到QC中（指定域名的指定项目下）。2. “摘要”，用简单明了的语句说明白你这个BUG,相当于BUG的中心语句。3. 详细信息填写规范：1） “分配给”，选择这个 BUG所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。2） “缺陷类别”，分为 5种（参考平台共享文件QCB作守则0922）BUG-功能一一功能上的缺

4、陷，如按钮没响应，充值不成功，需求上提到的功能没实现等。BUG-式页面样式的缺陷，如界面颜色、字号、排版、图片大小与所需求不符等。功能建议功功新增加的网页功能性建议。UI建议 一一对我们网页的布局、设计、色彩、交互、按钮、动静态效果、字体、文本框、表情、图片等有关视觉效果和操控便利性方面的建议。课程建议功功提出的和课程的学习、播放、内容、课程制作等有关的一切建议。3） “缺陷主题”，选择你提交的BUG所属那个模块。4） “项目”选择提交问题时测试系统的影响版本。5） “严重程度”，分为5个等级1-低： UI 控件不符合界面规范。影响UI友好性。 用户不频繁使用的功能易用性差。2-中： 用户需求

5、未实现（不影响用户完成业务、用户使用不频繁）。注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类。 用户需求实现错误（不影响用户完成业务、用户使用不频繁）。 用户操作过程中系统出现异常报错，但不影响系统功能的使用。 用户使用不频繁的功能，响应时间超出忍耐限度。注：忍耐限度根据实际软件系统的特点而定。 UI 上存在错误引导用户的信息。 UI 上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。 用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）。3-高： 用户需求未实现（影响到用户完成业务）。 用户需求实现错误（影响到用户完成业务）。 用户使用频繁

6、的功能，响应时间超出忍耐限度（不影响其他功能模块）。4-非常高： 用户体验性非常差，会导致“大量”用户投诉的。5-紧急： 后台数据受损或丢失。 导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃。 与“钱”沾边的，如充值、购买课程后不能使用、不购买课程也能使用课程等。4. 缺陷“描述”规范1） 指明当时出这个BUG的现场环境，示例如下：测试服务器：浏览器：IE9、 360浏览器（兼容模式）2） 指明缺陷所属模块或页面的路径，示例如下：3） 路径：把BUG产生的步骤一步一步写清楚，可以用以下方法写。（如果一句话就可以说明的BUG,就不必要分步骤了）示例：缺陷重现步骤：1、。2、。3、。4、。

7、测试结果：。期望结果：。4） 另外可以通过上传截图或附件，可以进行简单明了的说明 BUG存在，也可彳为BUG证据注意：关于优化建议方面的缺陷，根据实际情况，可以简化以上的一些步骤。问题描述简洁明了，条理清晰，使开发人员能据此复现定位问题。缺陷描述语句，应避免出现错别字，语病，歧义等。BUG验证/关闭问题说明1. 当BUG状态变为“已修复”，根据回归清单或测试申请(由开发提供)进行回归测试，如果回归测试后该问题被解决，则关闭该BUG,并在注释中填写如下信息：验证通过：是验证日期：。2. 如果回归测试验证不通过，则“重新打开”该BUG,并在注释中填写明情况。3. 如果出现“延期处理”、“已否决”的缺陷，首先查明原因，如果与研发不能达成一致的需要及时向上级反馈。关于研发人员处理缺陷1. 当研发人员接到一个缺陷后，应该填写“估计修复工时”、“估计