缺陷处理流程

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