SRT-VAS-SOP-09VAS缺陷管理规范

1、 B/2版 VAS缺陷管理规范 文件编号：SRT-VAS-SOP-09VAS缺陷管理规范 B/2版文件编号： SRT-VAS-SOP-09 编 制： 胡悦瑾、陈鹃、李慧敏 审 核： 郑晓燕 批 准： Fred 受控状态： 受控 分 发 号： 2011年06月27日 发布 2011年06月27日 实施 修 订 页 编号修订内容简述修订日期修订后版本号修订人审核人批准人1在用系统问题反馈的BUG处理流程，专门增加流程图表示。 增加：测试阶段的分类描述。 重要的流转环节，增加文字说明以强调2006.03.15A/1栾燕飞 吴慧丽刘小琴吕凡2增加缺陷状态，修改角色名称2009.06.18B胡悦瑾申屠哲

2、泱郑晓燕31、修改角色名称；2、测试阶段分类调整，升级测试适用流程更改；3、修改流程图，调整优化各状态流转过程：调整Modify、Commit、Rejected、Delay、Audit及Tracing等状态顺序；调整工程录入TD时通知步骤的操作；调整测试验证Common bug的步骤顺序；增加Rejected流程中，PM关闭BUG的步骤。2010.09.20B/1胡悦瑾、陈鹃郑晓燕Fred41、增加BUG状态定义解释2、优化升级测试及在用系统BUG流程图：a)取消需求人员在TD中的权限b)取消PM从“Commit>Unrelease”和“Modify>Fixed”的状态3、细化内部

3、测试BUG流程图和升级测试及在用系统BUG流程图各环节步骤内容，并按角色对操作步骤进行分类标识2011.06.16B/2胡悦瑾、陈鹃、李慧敏郑晓燕Fred 2/9 杭州世导科技有限公司 B/2 VAS缺陷管理规范 文件编号：SRT-VAS-SOP-091. BUG类型 Bug Type 描述 编码错误功能实现过程有错误。 设计错误实现需求功能的设计有错误 界面错误界面美观性、友好性、合理性。如界面提示信息，控件名称，大小等 数据库错误所有数据库错误。包括字段定义、数据、数据库连接错误等 逻辑错误包括业务逻辑、数据逻辑。如：业务之间的关联及数据流的正确性。对输入信息的正确性、合法性等判断问题。

4、功能错误功能未实现或实现错误。 合理建议一些建议，如：功能、界面等各方面 组件错误组件功能错误，返回提示信息错误，或无提示信息等问题 性能优化系统承受压力、负载的能力，系统响应速度等不理想，或影响正常操作。可操作性用户操作简便性方面的错误。 2. BUG状态 Bug Status 描述 Open待开发修改的问题 Modify开发正在修改问题 Commit问题已经处理，并已上传配置库，等待测试验证 Unrelease在测试环境下，问题已验证通过，待升级后现场验证；或内部因环境、资源问题无法验证，需要等发布至现场后由现场工程直接验证 Fixed问题已发布到现场，待现场验证 Closed验证后问题已

5、解决 Reopen问题仍存在，需要开发继续解决 Audit开发与工程/测试有争议，需要PM判断解决；或问题需由PM关闭 Rejected问题被拒绝（开发认为不是问题，或者录入的问题不符合规范，开发无法处理问题）Delay问题需延迟解决（至少每个月反馈一次问题的处理状态） Tracing问题需跟踪解决（开发/工程至少每个月反馈一次问题的跟踪状态）3. BUG严重级 Bug Severity 描述 灾难性严重危及系统正常工作。 严重严重影响系统要求或基本功能的实现。 一般基本功能已实现，但存在逻辑等类型的错误。 微小不影响系统运行及功能实现方面的错误。有关一些建议性的BUG。 4. BUG优先级

6、Bug Priority 描述 高立即修正。缺陷已危及系统的稳定性，影响功能正常运行 中尽快修正。缺陷不影响系统正常运行，部分功能逻辑修改，或需求变更后功能更改等。 低短期内修正。不影响系统运行和功能实现，如：界面修改，提示信息变更等。 稳定阶段解决允许等到程序稳定或上线以后再修正。该判断应由BUG审计人员定义，并得到认可。 下一版本解决允许等到一下版本升级时解决。该判断应由BUG审计人员定义，并得到认可。 5. 测试阶段 Test Stage 描述 集成测试 在公司测试环境下，按集成测试策略进行的测试。（一般为业务开发阶段，由公司组织的内部测试）（包括需求变更、升级前相关测试：此两类测试需要

7、在测试前明确测试范围/策略） 确认测试 在公司测试环境下，按确认测试策略进行的测试。（一般为集成测试以后，由公司组织的内部验收测试） 系统测试 在用户真实的系统环境下，进行的测试。（一般为系统刚加载时，连接真实环境组织的集成测试或确认测试） 升级测试 系统进行试商用阶段，系统实施升级后，在用户真实的系统环境下，对升级功能进行验证的测试。 用户验收测试 在商用以前，由用户参与的验收测试。 在用系统问题反馈 系统进入试商用、商用阶段（不包括升级测试），发现的在运行系统BUG。 6. 内部测试阶段BUG处理过程 （以下测试阶段适用本流程：集成测试、确认测试、系统测试、用户验收测试。） 7. 升级测试

8、及在用系统问题反馈BUG处理过程 （以下测试阶段适用本流程：升级测试、在用系统问题反馈） 8. BUG处理注意事项 1) 所有的BUG必须录入TD管理： a) PM或开发人员在受理BUG时，非紧急的问题必须看到TD的记录以后才受理，否则不应受理。 b) 对于在用系统的问题反馈，统一由系统维护工程师录入、通知、跟踪、验证修正结果、回复问题反馈人员。 c) 在用系统问题录入TD的同时，若为紧急问题，要求工程师第一时间邮件通知开发PM、QA、QC等人。d) 需求人员、PM等反馈在用系统问题时，发送系统维护工程师的同时要求抄收QA等人员。以便于质量管理部跟踪及判断此类问题现场系统维护工程师是否有及时录

9、入TD。 e) 所有的在用系统问题反馈，公司内部测试人员需在开发环境或现场环境上进行通用验证，明确是否为通用版本的BUG，并在TD的Common Bug、CB_Validate By 、Comment中做好选择及注释说明。供PM在各工程点业务升级时整理升级内容所用。同时通过此方式来提高测试、测试文档的质量。 2) 在用系统反馈的问题处理期限的约定： a) 紧急的问题要求当时就处理及回复。 b) 非紧急的要求PM、开发人员在3个工作日以内受理，受理不代表必须马上解决，但要求在TD写明受理意见及计划受理时间。 c) COMMIT的问题测试人员必须在3个工作日以内完成验证。3) BUG处理的注意事项

10、： a) 测试人员、开发人员、系统维护工程师都应及时跟踪自己所负责的BUG，包括BUG STATUS的更新、COMMENT中的注释、每个环节处理完成后的提醒通知。（当BUG成批处理、验证时，建议统一邮件通知，同时建议启用TD的邮件发送功能。） b) Delay、Tracing的BUG要求负责人每个月至少跟踪一次，并将跟踪意见填写于COMMENT中。 c) TEST STAGE为集成测试、确认测试、升级测试、系统测试、用户验收测试时，BUG的处理时限由PM把握，把握原则为不影响、不耽搁测试进度、不影响产品发布期限。 d) 质量管理部根据BUG审计制度，定期审计BUG的处理情况。对于不符合的，纳入

11、QA审计。 9. TD规划说明： 1) TD Project规划： a) TD Project按照业务划分，对各工程点现场环境测试发现的BUG也统一按业务录入TD，以字段“Test Area”来标明每个BUG是在哪个测试环境下发现的。 b) 增加字段“Common Bug”，公司测试人员对在用系统问题反馈问题进行验证后，填写此字段，标识是否为通用版本的BUG，状态包括：Yes、No、All Release。同时要求填写注释说明。 c) 每次升级以后，若通用版本中的BUG已升级处理，PM应在COMMENT中做注释说明。 2) TD用户设置： a) 分PM、测试、开发、工程等用户组。每个用户组有不

12、同的权限。 3) TD常用字段表： 序号 字段名称 说明 1.Test Area Bug所在的地点 2.ACCESS Type Bug所在的模块 3.Subiect Bug所在的子模块 4.Status 状态 5.Test Stage 测试阶段 6.Bug Type Bug种类 7.Severity Bug的严重程度 8.Priority Bug的优先级 9.Assigned To Bug的负责人 10.Detected By Bug提出人 11.Detected on Date Bug提出的日期12.Validate By Bug是谁验证通过的 13.Validate Date Bug的验证日期 14.Agreed 验证人是否同意该问题的关闭 15.Common Bug 该问题是否是通用版本中都存在，（YES or NO） 该问题是否已经发布到所有地区（All Release）16.CB_ Validate By 该问题是谁验证是否为通用版本的 4) TD限制条件： a) 每个工程点只能看