缺陷处理流程.docVIP

缺陷处理流程 导读：就爱阅读网友为您分享以下“缺陷处理流程”资讯，希望对您有所帮助，感谢您对92的支持! 缺陷处理流程 1/6 缺陷处理流程 1 缺陷处理流程 1. 缺陷处理流程图如下： 缺陷处理流程 2/6 2. 缺陷处理流程图中判定说明： 1) 是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复 日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。 2) 处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能 实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。 3) 是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。并在注释中 说明重新打开理由。 3. 缺陷处理流程图中流程说明： 1) 新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。 2) 已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷 相关人员进行确认。如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。 3) （重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。 4) 延期处理：开发组长/经理根据情况，对缺陷进行延期处理。 5) 已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。并通知测试人员 进行回归。 6) 回归测试：测试人员对已经修复的缺陷进行回归。 7) 关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。 4. 为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下： 缺陷处理流程 3/6 如果上面判定和流程中，某一方存在异议的，应及时反馈上级。然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。 缺陷处理流程 4/6 2 缺陷填写说明 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-紧急： 后台数据受损或丢失。 导致被测软件响应明显