CR提交和处理规范20110909精篇课件.pptVIP

CR提交和处理规范(for Tester)  2011-09-9 CR定义 CR（Change Request）即变更请求，用于记录和追踪、扩展请求和任何其他类型的产品变更请求。 这里主要是指缺陷。 CR主流程框图 CR的状态 如何提交一个CR 点击工具栏的New change，出现下表，完成后点”OK” CR 提交规则（针对ST) 并非测试发生死机或assert才要提交CR外，不明确的问题需要和需求对照以及与开发沟通，确认问题。 但对于下面明确的问题请提交CR。 1、手机发生ASSERT、死机、定屏、画屏 提交CR 2、测试中发现功能错误，不合理、失效、显示错误 3、操作响应慢、连接多次失败、发送多次不成功 请提交CR。 4、杂音、破音、断续、音乐视频不流畅、格式不支持、安装失败 等文件处理请确认源文件是否异常，确认源文件正常，请提交CR 5、逻辑关系不合理、优先级顺序不合理、和需求不一致，请提交CR 如何填写CR Headline：产品项目标识、简单描述此CR。 Catalog： 判断是哪个类别的问题，选择相应的类别，软件-SW Product：项目project类别：如： MOCOR、8800G、MOCORSMART Base On (Ver) ：测试的版本编号 Fix On（Ver）：CR解决和merge的版本-由开发解决人员填写 Severity：缺陷的严重级别 Change Type：根据选择的Change Type不同， Description中的提示也不一样，请按照要求填写(一般由测试人员提交的CR为defect） Probability：缺陷重现的概率 Component：在哪块功能上出现问题 Priority：缺陷的优先级 Owner：填写此CR的处理人，一般可以填写PL或该模块开发人员。 Description：根据给出的提示详细填写重现CR的步骤、表现的现象和相关的分析，可能的原因等等信息，帮助CR相关的人员了解所要反映的问题（尽可能具体，详细，信息准确）。 严重级别severity 1- Critical致命问题 造成整个系统崩溃或死机的问题 ； 常用以及主要功能必现的死机或Assert问题 2-Major严重问题 造成主要功能失效的问题 常用以及主要功能失败或错误问题 系统性能问题 3-Average一般问题 造成部分功能失效，但不影响主要功能的缺陷 非主要及常用功能失败或错误问题 4-Minor提示性问题 影响系统外观，但不影响系统功能。如:写信息中的错别字，界面颜色等 5-Improved改进建议 不影响系统功能，满足需求，但可考虑改进以更好的满足用户需求。 优先级priority 1-Resolve Immediately 对于产品在市场上的成功至关重要。能够直接影响销售和公司的成功。迫切需要开发组织理解以及立即解决。 2-Give High Attention 对于产品的成功至关重要。开发组织应该尽快理解和解决。 3-Normal Queue 对于产品的成功是重要的。该缺陷研究和修改的时间应该列在存在的项目日程中。 4-Low Priority 如果时间不允许，可以暂缓解决 缺陷重现概率 Probability occur count/test count 发生了几次/测试了几次 1-Always Recurrence 每次同样操作必发生同样的缺陷现象。 2-Occasionally Recurrence 同样的操作会发生多次同样的问题。 3-Seldom Recurrence 缺陷重现的概率很低。 注：对于非必现的问题，需要在Description中写明发生过几次这样的现象， 自动测试发现的问题，概率写1/100 ODC缺陷分析填写 ODC-缺陷分析填写 发现活动：有系统测试、外场测试之分 如：ST则填写系统测试 触发因素：单一功能、边界、非