主题:BUG发现率及严重程度重概述
1.BUG等级划分建议:
目前project上的BUG严重程度分为五个等级,按照CMMI5中定义的规范,BUG严重等级可分为3-5个等级,建议将BUG等级划分四个等级,分别为严重、主要、次要、轻微。
● 严重(可对应目前BUG体系中的“非常严重”):
严重问题主要为:系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为:
○ 严重花屏
○ 内存泄漏
○ 用户数据丢失或破坏
○ 系统崩溃/死机/冻结
○ 模块无法启动或异常退出
○ 严重的数值计算错误
○ 功能设计与需求严重不符
○ 导致其它功能无法测试的错误
● 主要(可对应目前BUG体系中的“主要”)
主要问题主要为:影响系统功能或操作,主要功能存在缺陷,但不会影响到系统稳定性。
具体基本上可分为:
○ 功能未实现
○ 功能错误
○ 系统刷新错误
○ 语音或数据通讯错误
○ 轻微的数值计算错误
○ 系统所提供的功能或服务受到明显的影响
● 次要(可对应于目前BUG体系中的“次要”)
一般性问题主要为:界面、性能缺陷
具体基本上可分为:
○ 操作界面错误(包括数据窗口内列名定义、含义是否一致)
○ 边界条件显示错误
○ 提示信息错误(包括未给出信息、信息提示错误等)
○ 长时间操作无进度提示
○ 系统未优化(性能问题)
○ 光标跳转设置不好,鼠标(光标)定位错误
● 轻微(可对应于目前BUG体系中的“轻微及建议”)
提示性问题主要为:易用性及建议性问题
具体基本上可分为:
○ 界面格式等不规范
○ 辅助说明描述不清楚
○ 操作时未给用户提示
○ 可输入区域和只读区域没有明显的区分标志
○ 个别不影响产品理解的错别字
○ 文字排列不整齐等一些小问题
○ 建议
注意:对于结构及硬件问题,由于产品测试部仅是进行辅助测试,碰到此类问题时,均将定位于等级“严重的”,具体情况由结构及硬件部门相关人员确认。
2.BUG发生率划分建议:
目前通用的对BUG发生率的划分主要有两种划分方法:一种是测试发生率:即按照特定步骤执行多次的BUG重现率;另外一种是用户使用发生率:即模拟用户在使用产品时发生此问题的概率。第一种方法计量精确简单,可操作性高,但不太符合产品的实际使用情况。第二种方法,则需要推断用户使用某一业务的频率,因此计量相对没有第一种精确,操作性高,但比较符合产品的实际使用情况。由于产品的最终使用总是用户,因此建议BUG发生率采用第二种方法——即用户使用发生率。
用户使用发生率=用户类别*业务类别*测试发生率
● 用户类别:
主要客户群有生产人员、客服人员、最终用户。根据其对公司产品的生产、销量、声誉、维护的不同可以分配不同的权重(权重范围为0-1之间)。
如:生产人员——>0.3
客服人员——>0.5
最终用户——>1.0
● 业务类别:
业务类别根据具体项目的业务情况分为主要业务、次要业务及辅助业务。
业务类别的确认具有人为的主观因素,若需求文档有明确说明各个业务功能的优先级(业务功能优先级由“风险”,“复杂度”及“用户需要”在撰写需求时确认),那么一般可参考此优先级来确认。优先级高的为主要业务,优先级其次的为次要业务,其它为辅助业务(注:仅可作为参考,确认业务类别最好由市场相关人员来确认。如产品经理,市场分析人员等。)
若需求中没有明确说明各业务功能的优先级,哪么应当在测试开始前,召开由产品,研发及测试部门一同出席的会议,确认各业务功能的分类,并将其记录于需求文档中。
● 测试发生率
测试发生率为按照特定步骤执行多次的BUG重现率
测试发生率=BUG重现次数/按照特定步骤执行的总次数。
其中:对于概率性问题,执行的总次数应根据BUG的复杂程度执行(20-50次)
用户使用发生率等级划分:
如上所述,用户使用发生率=用户类别*业务类别*测试发生率,根据最终得到的用户使用发生率的值的不同,可以将用户使用发生率划分为如下几个等级(也可沿用旧等级划分,将<2%的问题划入等级“低”):
70%-100% 常常发生 高
30%-70% 经常发生 中
2%-30% 有时发生 低
<2% 一次发生 无
本文章来自 点击: [url]http://www.51qa.net[/url] 浏览测试服务网。
目前project上的BUG严重程度分为五个等级,按照CMMI5中定义的规范,BUG严重等级可分为3-5个等级,建议将BUG等级划分四个等级,分别为严重、主要、次要、轻微。
● 严重(可对应目前BUG体系中的“非常严重”):
严重问题主要为:系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
具体基本上可分为:
○ 严重花屏
○ 内存泄漏
○ 用户数据丢失或破坏
○ 系统崩溃/死机/冻结
○ 模块无法启动或异常退出
○ 严重的数值计算错误
○ 功能设计与需求严重不符
○ 导致其它功能无法测试的错误
● 主要(可对应目前BUG体系中的“主要”)
主要问题主要为:影响系统功能或操作,主要功能存在缺陷,但不会影响到系统稳定性。
具体基本上可分为:
○ 功能未实现
○ 功能错误
○ 系统刷新错误
○ 语音或数据通讯错误
○ 轻微的数值计算错误
○ 系统所提供的功能或服务受到明显的影响
● 次要(可对应于目前BUG体系中的“次要”)
一般性问题主要为:界面、性能缺陷
具体基本上可分为:
○ 操作界面错误(包括数据窗口内列名定义、含义是否一致)
○ 边界条件显示错误
○ 提示信息错误(包括未给出信息、信息提示错误等)
○ 长时间操作无进度提示
○ 系统未优化(性能问题)
○ 光标跳转设置不好,鼠标(光标)定位错误
● 轻微(可对应于目前BUG体系中的“轻微及建议”)
提示性问题主要为:易用性及建议性问题
具体基本上可分为:
○ 界面格式等不规范
○ 辅助说明描述不清楚
○ 操作时未给用户提示
○ 可输入区域和只读区域没有明显的区分标志
○ 个别不影响产品理解的错别字
○ 文字排列不整齐等一些小问题
○ 建议
注意:对于结构及硬件问题,由于产品测试部仅是进行辅助测试,碰到此类问题时,均将定位于等级“严重的”,具体情况由结构及硬件部门相关人员确认。
2.BUG发生率划分建议:
目前通用的对BUG发生率的划分主要有两种划分方法:一种是测试发生率:即按照特定步骤执行多次的BUG重现率;另外一种是用户使用发生率:即模拟用户在使用产品时发生此问题的概率。第一种方法计量精确简单,可操作性高,但不太符合产品的实际使用情况。第二种方法,则需要推断用户使用某一业务的频率,因此计量相对没有第一种精确,操作性高,但比较符合产品的实际使用情况。由于产品的最终使用总是用户,因此建议BUG发生率采用第二种方法——即用户使用发生率。
用户使用发生率=用户类别*业务类别*测试发生率
● 用户类别:
主要客户群有生产人员、客服人员、最终用户。根据其对公司产品的生产、销量、声誉、维护的不同可以分配不同的权重(权重范围为0-1之间)。
如:生产人员——>0.3
客服人员——>0.5
最终用户——>1.0
● 业务类别:
业务类别根据具体项目的业务情况分为主要业务、次要业务及辅助业务。
业务类别的确认具有人为的主观因素,若需求文档有明确说明各个业务功能的优先级(业务功能优先级由“风险”,“复杂度”及“用户需要”在撰写需求时确认),那么一般可参考此优先级来确认。优先级高的为主要业务,优先级其次的为次要业务,其它为辅助业务(注:仅可作为参考,确认业务类别最好由市场相关人员来确认。如产品经理,市场分析人员等。)
若需求中没有明确说明各业务功能的优先级,哪么应当在测试开始前,召开由产品,研发及测试部门一同出席的会议,确认各业务功能的分类,并将其记录于需求文档中。
● 测试发生率
测试发生率为按照特定步骤执行多次的BUG重现率
测试发生率=BUG重现次数/按照特定步骤执行的总次数。
其中:对于概率性问题,执行的总次数应根据BUG的复杂程度执行(20-50次)
用户使用发生率等级划分:
如上所述,用户使用发生率=用户类别*业务类别*测试发生率,根据最终得到的用户使用发生率的值的不同,可以将用户使用发生率划分为如下几个等级(也可沿用旧等级划分,将<2%的问题划入等级“低”):
70%-100% 常常发生 高
30%-70% 经常发生 中
2%-30% 有时发生 低
<2% 一次发生 无
本文章来自 点击: [url]http://www.51qa.net[/url] 浏览测试服务网。