Bug的优先级.doc

Bug的优先级 在测试工程师的日常工作中,最经常做的也是必须做的就是提交缺陷报告.在提交Bug的时候,我们要给出这个Bug的优先级(Priority),开发人员会根据Bug的优先级来决定先修那个Bug,后修哪个Bug.所以优先级的正确与否会影响到Bug的解决时间进而可能会影响测试和开发的进度.对于一个Bug的优先级也往往是QA和RD争论的焦点. ?? 在我们的公司中Bug的优先级根据其严重度和发生的频率和环境来决定.首先一个Bug有5种严重程度的定义: 严重度A--系统Crash,不能进行安装等; 严重度B--需求说明书中要求的重要功能没有实现; 严重度C--功能存在缺陷; 严重度D--功能可以进一步改进; 严重度E--建议 优先级的定义如下: Priority 1--必须立即修复; Priority 2--在Beta前必须修复; Priority 3--在release前必须修复; Priority 4--在下一版修复; Priority 5--可以修复或不修; 接下来根据Bug发生的频率和环境建立一张优先级Mapping表. 重现频率????? ? Always ?Sometimes ?Hardly In?User Environment ?严重度A ?P1 ?P1 ?P2 ?P1 ?严重度B ?P1 ?P2 ?P3 ?P2 ?严重度C ?P2 ?P3 ?P4 ?P3 ?严重度D ?P4 ?P4 ?P4 ?P4 ?严重度E ?P5 ?P5 ?P5 ?P5 根据这张表就可以很容易定义Bug的优先级了. 如何填写BugFree中严重程度和优先级 严重程度(Severity)分为4级，新建Bug时依照下面的标准必须指定。同时开发和产品等人员在Bug处理过程中可以随时调整。 1 ：系统崩溃或数据丢失 2 ：主要功能问题 3 ：次要功能问题 4 ：细微问题或建议 优先级(Priority)：测试人员如果不清楚问题的轻重缓急，新建Bug的时候不要随意填写。一般由开发人员、产品经理或者客服人员在Bug处理过程中填写。 可以参考当前业务需求、开发计划和资源状态，按照下面的标准选择一个合理优先级。 1 ：需要立即解决的问题(Now) 2 ：需要在指定时间内解决的问题(Need to be fixed in N days) 3 ：产品开发计划内解决的问题(Need to be fixed in this sprint) 4 ：资源充沛时解决的问题(Fix or not) BUG解决优先级 优先级指的是下面的这个分级: 解决优先级 1.立即解决（Resolve Immediately）缺陷必须被立即解决。 2.正常排队（Normal Queue）缺陷需要正常排队等待修复或列入软件发布清单。 3.不紧急（Not Urgent）缺陷可以在方便时被纠正。 通用测试用例工作过程 　　软件测试用例设计：从设计层面考虑（功能性、可用性、安全性等方面）； 　　软件测试用例写作：指的是软件测试用例的写作规范（格式、标识的命名规范等） 　　软件测试用例设计设计出用例的内容，按照软件测试用例写作规范落实到文档中去。 　　软件测试用例格式 　　● 测试用例编号 　　◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串 　　◇ 约定： 　　系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX 　　集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX 　　单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX 　　● 测试项目 　　◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等 　　◇ 约定： 　　系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话 　　集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口 　　单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char *pszFileName) 　　● 测试标题 　　规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。 　　● 重要级别 　　规则 　　高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例； 　　中：重要程度介于高和低之间的测试用例； 　　低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。 　　● 预置条件 　　规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件 　　● 输入 　　规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等 　　● 操作步骤 　　规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。 　　● 预期输出 　　规则：当前测试用