在我目前的公司中，测试和开发团队之间对于bug的严重程度尚不清楚？有些论据来回减少或增加严重性。我们现在还不知道任何列出规则的文件。测试人员根据他的直觉提出错误并分配优先级。开发人员会根据他的负载或其他因素请求更改。
如何分类错误的严重性/优先级？是否有任何标准指导软件缺陷优先级如何根据客户需求，时间线和其他因素确定？
答案 0 :(得分：10)
使用优先级故意与严重性或影响无关，并仅描述计划中错误的概念位置。此字段将确定要处理哪些错误，因此需要非常清楚错误的事实是否未公开进行协商。
使用严重性级别，故意拥有具体的，可验证的定义，与调度或优先级无关。我已经成功地使用severity definitions used by the Debian BTS，一般用于编程项目。
这样，严重性更多地是可验证事实的问题，与优先级声明无关。然后可以通过协商或其他方式自由调整优先级，而不会影响严重性字段中的事实信息。
尝试将“严重性”和“优先级”混合到一个字段中会导致消耗灵魂的论点和浪费时间。错误记者需要一个明确的 fact 指南来确定错误的“坏”，这需要由独立的各方轻松达成一致。另一方面，优先级是谈判和安排游戏的正确目标。
答案 1 :(得分：8)
我在应急控制中心系统上工作，所以这套bug水平有点......嗯......极端：
这是我的头脑。如果你想知道，它是从最极端到最少： - ）
答案 2 :(得分：3)
用fogbugz替换你的bug跟踪系统，并完全摆脱严重性字段。
答案 3 :(得分：3)
我们之前使用的一些东西。我们将缺陷评级分为优先级和严重程度。
严重程度（在提交缺陷期间由提交者设置）
优先级（在缺陷评估期间根据开发，管理和质量保证进行调整）
两个数字一起创建风险优先级编号（RPN）。简单地将严重性与优先级相乘。结果越高意味着风险越高。 25定义了最终的缺陷炸弹。 1可以在空闲时间内完成，或者如果有人感到无聊并且需要做些什么。
第一个目标：在发布前应修复任何类型的最高或最高等级的缺陷。 第二个目标：RPN的缺陷＆gt;在释放产品之前应该修复8。
这当然有点人为，但有助于为所有各方（支持，质量保证/测试，工程和产品经理）提供一个工具来设定优先级而不会撇开另一方的意见。
答案 4 :(得分：2)
“去过那里”。
我在不同的项目上一遍又一遍地讨论这个问题。我们尝试将优先级与严重程度结合起来，但是我学到的教训是：不要将严重性与优先级结合起来！
我们经历了很多头脑风暴和会议，最后是“ 这是 ”。已经创建了多个指南文档并在不同的“各方”之间传播，但过了一段时间后我们发现它最终没有起作用。不同的“政党”对错误有所不同：我们的服务台对开发团队或销售人员的优先级有另一种理解。
同时具有严重性和优先级将很快变得非常混乱，因为：
“那你该怎么做？”：
仅针对问题的“级别”使用一种指标：无论您如何称呼它。
使用数字（例如1 - 5，但可能会更多或更少，具体取决于您的需要）来清楚地表明重要性，但将与关键字结合起来，以便明确其含义（例如'很高兴'，'显示塞子'）。对于一些人来说，prio 1意味着最重要的，而其他人则意味着 - ＆gt;因此，需要一个关键字来表示数字的含义。
区分“正常问题”或“红色警报”。在我们的情况下，必须立即解决“红色警报”并立即投入生产。正常的问题将遵循正常的开发 - 测试 - 部署 - 流程。优先级/严重性/但是如何调用 - 它应该只针对正常问题设置，并且将被忽略为“红色警报”。 * GT;在实践中，“红色警报”可以成为
'正常问题'：支持团队 发现了一个主要的bug并创建了一个 '红色警报'。但经过一番 调查我们发现了数据 在数据库中变得'腐败' 因为它直接插入那里 而不是通过申请。*
选择一个可以自定义流程的好工具;但大多数工具都有。
答案 5 :(得分：1)
至于标准的， IEEE软件异常分类指南虽然我不确定它的采用范围有多广泛。 IEEE 1044.1-1995
答案 6 :(得分：1)
一种选择是让产品所有者确定错误的优先级。虽然对于错误的“坏”有一些一般的直觉，但是产品所有者可以负责设置预先确定的顺序（即错误A应该在错误B等之前修复......）。 p>
可以提供给产品所有者的更多信息（简洁明了）可以帮助个人做出这些决定（即有多少用户遇到过该错误，哪些功能因错误而无法获得等等）。 ..）
答案 7 :(得分：1)
嗯，我刚刚做到了......我的观点是将虫子分类不应该是每周一小时+长时间的仪式..
恕我直言，优先考虑流程图是浪费时间。修复Cat＃1和＃2中的错误 - 尽快浮出水面。如果你发现自己被虫子淹没，慢下来反思。如果时间表不允许或更高优先级项目覆盖，则推迟Cat＃3和Cat＃4
关键是你们所有人都对这种严重性和预期质量有共同的理解。不要让遵守X的神圣标准，使你无法满足客户的需求......工作软件。
答案 8 :(得分：1)
我个人赞成两层严重性/优先级模型。我知道单一级别的论点，但我工作过的地方一般我刚看到两级层次的工作更好
严重性由支持团队设置（基于客户端的输入）。优先级由客户设置（来自支持团队的输入）。
对于严重性我使用：
1 - 拦截/显示已停止 2 - 主要功能不可用（或实际上不可用），没有实际可行的工作 3 - 主要功能不可用（或......），可以解决问题 4 - 次要功能不可用（或实际上不可用），无法解决问题 5 - 次要功能不可用（或......），可以解决问题 6 - 化妆品或其他微不足道的
然后，对于优先级我只使用高，中，低，但是3到5级的任何东西都可以工作（远远超过顶部）。
我通常先按优先顺序排序，然后按顺序排序。对此重要的是客户有最重要的发言权。如果他们说他们的徽标在报告上打印出来的方式是最优先考虑的，那就是看到的内容，但是在另一个客户端的高优先级停止他们登录之后会看到它。
一般来说，我不会发布任何高优先级问题或严重性为1 - 4的任何中等优先级问题。显然，在一个理想的世界中你会解决所有问题，但我从来没有幸运地拥有这个选项。 / p>
答案 9 :(得分：1)
答案 10 :(得分：0)
设置项目的要求，以便您可以将修复的优先级基于受错误干扰的要求的优先级。
答案 11 :(得分：0)
我对功能和错误使用以下类别：
通常你计划修复1,2和3，但由于时间限制，3经常被推迟到下一个版本。
答案 12 :(得分：0)
我和我们的一位客户有同样的问题。最后，我们一起设置了一个文档，描述了哪种类型的bug会与某种严重程度相匹配。除了偶尔使用本文档作为指南的讨论似乎也有效。
但请注意，测试团队和开发团队可能对什么是严重错误和什么不是错误有不同的看法。从测试人员的角度来看，当开发人员只是说没有人会注意到时，一个小的布局错误可能是高优先级。
在我们的文档中，如果这些错误是“品牌损害”，那么这些错误可能是高优先级的，即如果布局错误在徽标或其中一个产品中那么它是严重的 - 如果它只是页面上的一个段落是2像素关闭然后它不是。
答案 13 :(得分：0)
我认为这是我们之前工作中使用的规模：
有时候这被滥用了 - 如果某个功能设计得太差，以至于有人无法弄清楚如何使用它，那就被归类为6，它永远不会被修复。
答案 14 :(得分：0)
我同意FogBugz的人认为这应该保持超级简单：http://fogbugz.stackexchange.com/questions/352/priority-vs-severity
我制定了这个方案，我觉得很容易记住：
它大致与Debian的方案相似：http://www.debian.org/Bugs/Developer#severities
我喜欢它，因为它直接将优先级和严重性组合到一个易于设置值的字段中。
PS：您还可以在“分钟事项”和“小时事项”之间选择“pMH”等中间紧急情况。或者“pHd”介于“小时消息”和“日常事务”之间 - 粗略地说，“不要真的为它做一个全能的事情，但在完成之前不要做任何事情。”