Bug指标在JIRA中的实现 - 蛊魅的测试人生 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
Bug指标在JIRA中的实现
& 11:30:30
/ 个人分类：
是澳大利亚Atlassian公司开发的一款不错的商业问题跟踪工具，包括、需求变更、评审等均可以在这个软件中进行管理。我们在统计bug数据时，经常需要对bug参照一些指标进行统计分析。本文介绍一些常用bug指标在JIRA中的实现。1&Bug分布　　Bug严重级别　　在项目中，
我们不能仅仅用“bug总数”作为评价项目出错程度的唯一指标。因为不同bug严重程度是不相同的，较为严重的bug带来的影响远远大于一般bug，所
以，我们引入“bug严重级别”指标，用来标定bug的严重程度。现在公司是分6个级别（Blocker、Critical、Major、Minor、
Trivial、Enhancement）。这个指标的用途是用于对bug按严重程度进行分类汇总。管理者可以很清楚的得知整个项目中，不同严重级别的
bug分别占有bug总数的百分比。计算公式为：严重级别＝各个级别的bug数/bug总数。　在JIRA中，bug严重性分布图如下图所示：标识bug的状态，从上到下分别为：Resolved、Closed、Reopened。标识bug的严重性，从上到下，分别为Bloker、Critical、Major、Minor、Trivial。&　　Bug类别　　Bug类别用来描述bug的内容类别，比如功能、性能、界面等。这个指标可以帮助我们分析，在所有的bug中，哪些类型的bug比较多，应该值得关注，并且在后续的开发中，加强对类似问题的审核；在后续的测试工作中，加强对类似bug的测试力度，最大程度的在源头减少类似错误的发生。计算公式为：bug类别＝各种bug类型的bug数/bug总数。　　在JIRA中，bug类别图和问题类型图类似，这里以问题类型图为例，如下所示：2&Bug修复率（bug修改成功率）　　Bug修复率，也可以称为“bug修改成功率”，它能够反映bug责任人修复bug的效果，可以作为对开发人员的考核指标之一，同时可以督促开发人员认真执行。计算公式为：bug修复率＝（已解决的bug数）/bug总数。　　在JIRA中，可以查看到每个解决版本的bug处理情况，如下图所示：3&Bug修复工作量　
　根据以前项目的bug修复工作量的统计分析，可以得到不同严重性级别的bug及其对应的修改工作量。例如，经过统计分析得知，严重性为“Major”的
bug，通常需要6人时的修复工作量。通过这个数据，可以粗略的估计，处理项目中未处理的bug需要的工作量（仅包括处理工作量，不含测试人员验证的工作
量）。　　得到这个数据，主要是为了便于管理者根据项目的实际情况制定或调整项目计划。　　在JIRA中，可以使用以下三条曲线来描述：时间跟踪报告、开发者工作量报告、版本工作量报告。　　但是要实现登记修复工作量这项功能，需要开发人员执行两个动作：1.上执行bug的Resolve Issue流程2.进入另一个页面执行工作日志登记。3.1&时间跟踪报告　　这个报告，显示了项目的时间跟踪详细情况。其中，显示实际花费时间与初始估算时间的比例显示这个版本的问题与进度计划相比是超前、推迟，或者按计划进行。显示每个bug详细的工作量记录。3.2&开发者工作量报告　　这个报告显示了开发者当前的工作量的详细情况——显示了每个项目的未解决的已分配问题的数量和剩余的工作量。3.3&版本工作量报告　　这个报告显示了指定的版本的当前工作量详细情况——显示了每个用户的未解决问题的数量和剩余工作量。4&Bug预计修复完成时间　　在“bug修复工作量”中，我们考虑的是bug修改实际所需的工作量，但是没有考虑到项目开发所处阶段、人员分配等实际情况。在这个指标中，者
希望能知道bug计划完成修复所需的时间。为了实现这个目标，我们可以根据bug的优先级，估计bug计划修复完成的时间。方法是：测试人员/bug分配
人根据项目的实际情况，设置bug的优先级。每个优先级对应一个解决期限。例如，优先级P1的bug，必须在4小时内处理完毕，P4的bug可以在5工作
日内处理完毕。通过这个约定，可以根据每个bug的分配时间（不是提交时间），计算得出项目剩下的bug的预期解决时间。　　在JIRA登记bug时，可以指定预期解决时间，但是没有功能可以快速的找到某个版本bug预计能改完的日期。但是使用以下变通的办法后，可以查看到Bug预计修复完成时间。步骤：1．& 在过滤器中，设置你想查看的某个版本或者某个严重性或开发人员的值2．& 执行查询3．& 在查询结果中，点击“逾期”列，对“逾期”进行排序。此时，列表中的第一行就是你所关系bug的预计修复完成时间。另外，你也可以通过过滤器，查询逾期指定时间的bug。5&小结　　所有这些指标的综合运用，能够比较全面的从量化的角度来描述一个项目中开发和测试工作的实际情况。PM、开发组长和测试组长可以选择对自己项目有用的统计指标，跟踪这些数据，以便及时跟踪和调整项目开发和测试，更好的管理项目。bug严重等级划分_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
bug严重等级划分
上传于|0|0|文档简介
&&bug严重等级划分
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢Bug的严重程度、优先级如何定义
Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常，人员在提交Bug时，只定义Bug的Severity,
即该Bug的严重程度，而将Priority交给Project Leader 或Team
Leader来定义，由他们来决定该Bug被修复的优先等级。某种意义上来说，Priority的定义要依赖于Severity，在大多数情况下，Severity越严重，那这个Bug的Priority就越高。你知道如何合理定义bug的Sevrity么？
通常Bug管理系统里Severity分为四个等级Blocker, Critical, Major,
Minor/Trivial（也可自定义，但通常是这四个）, 而priority分为五个等级：Immediate, Urgent,
High, Normal, Low。
Blocker:&即系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。
用户数据丢失或破坏
系统崩溃/死机/冻结
模块无法启动或异常退出
严重的数值计算错误
功能设计与需求严重不符
其它导致无法测试的错误, 如服务器500错误
2.Critical：即影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
功能未实现
系统刷新错误
数据通讯错误
轻微的数值计算错误
影响功能及界面的错误字或拼写错误
安全性问题
Major：即界面、性能缺陷、兼容性。
操作界面错误（包括数据窗口内列名定义、含义是否一致）
边界条件下错误
提示信息错误（包括未给出信息、信息提示错误等）
长时间操作无进度提示
系统未优化（性能问题）
光标跳转设置不好，鼠标（光标）定位错误
兼容性问题
4.Minor/Trivial:即易用性及建议性问题。
界面格式等不规范
辅助说明描述不清楚
操作时未给用户提示
可输入区域和只读区域没有明显的区分标志
个别不影响产品理解的错别字
文字排列不整齐等一些小问题
1.Immediate
即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。&
即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。&
即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
5.&Low即”低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}