在我目前的公司中，测试和开发团队之间对于错误的严重程度并不清楚吗？有一些争论来回减少或增加严重性。我们目前不知道有任何文件规定了规则。测试人员根据他的直觉提出错误并分配优先级。开发人员会根据他的负载或其他因素请求更改。
错误的严重性/优先级如何分类？是否有任何标准可以指导如何根据客户需求、时间线和其他因素确定软件缺陷优先级？
问问题
6122 次
15 回答
11
使用故意与严重性或影响无关的优先级，并仅描述错误在计划中的概念位置。该字段将确定哪些错误得到解决，因此它将成为谈判的目标。
使用故意具有具体的、可验证的定义且与调度或优先级无关的严重性级别。我已经成功地使用了 Debian BTS 使用的严重性定义，普遍适用于一般的编程项目。
这样，严重性就更多地是一个可验证的事实问题，独立于优先级声明。然后可以通过协商或其他方式自由调整优先级，而不会影响严重性字段中的事实信息。
试图将“严重性”和“优先级”混为一谈会导致令人筋疲力尽的争论和浪费时间。错误报告者需要一个可靠的事实指南来确定错误有多“糟糕”，这需要独立各方轻松达成一致。另一方面，优先级是谈判和安排比赛的正确目标。
于 2009-04-28T07:18:01.677 回答
8
我在紧急控制中心系统上工作，所以这组错误级别有点，嗯......极端：
- 有人死了
- 需要 DR 调用的总系统故障
- 服务器故障需要工程师响应
- 涉及失去呼叫连续性的故障
- 涉及数据丢失的故障
- 记录的数据不正确
- 应用程序失败 - 不可恢复
- 应用程序失败 - 不可恢复，但会自动重新启动
- 不符合要求规范，没有解决方法
- 不符合要求规范，但有解决方法
- 化妆品 - 布局等
- 实际上是一个功能请求
这不是我的想法。如果您想知道，这是从最极端到最不重要的:-)
于 2009-04-28T08:35:41.567 回答
4
我们以前用过的一些东西。我们将缺陷等级分为优先级和严重性。
严重性（由提交者在提交缺陷时设置）
- 最高 (5)：数据丢失、可能的硬件损坏或与安全相关的故障
- 高 (4)：在没有任何合理解决方法的情况下失去功能
- 中 (3)：通过合理的解决方法丧失功能
- 低（2）：功能或特征集的部分丢失（特征仍然达到设计要求）
- 最低 (1)：外观错误
优先级（在缺陷评估期间由开发、管理和 QA 调整）
- 最高 (5)：系统实际上无法使用此缺陷。
- 高（4）：该缺陷将对公司销售和维护该系统的能力产生严重影响。
- 中（3）：如果系统有这个缺陷，公司会损失一些钱，但按时完成可能更重要。发布后修复。
- 低（2）：不要延迟发布，但要在之后修复这个问题。
- 最低 (1)：在时间和资源允许的情况下进行修复。
这两个数字共同构成一个风险优先级编号 (RPN)。简单地将严重性与优先级相乘。更高的结果意味着更高的风险。25 定义了终极缺陷炸弹。1 可以在空闲时间或某人无聊需要做点什么时完成。
第一个目标：任何类型的最高或高等级缺陷应在发布前修复。第二个目标：RPN > 8 的缺陷应该在发布产品之前修复。
这当然有点人为，但有助于为所有各方（支持、QA/测试、工程和产品经理）提供一个工具来设置优先级，而不会影响另一方的意见。
于 2009-06-02T20:42:47.017 回答
3
用fogbugz 替换您的错误跟踪系统并完全摆脱严重性字段。
请参阅优先级与严重性
于 2009-04-28T06:52:40.210 回答
2
“去过也做过”。
我在不同的项目上一遍又一遍地讨论过这个问题。我们试图将优先级与严重性结合起来，但我学到的教训是：不要将严重性与优先级结合起来！
我们进行了很多头脑风暴和会议，最后都以“就是这样”作为结尾。已经创建了多个指南文档并在不同的“各方”之间传播，但一段时间后我们发现它最终不起作用。不同的“各方”对错误的看法不同：我们的帮助台对优先级的理解不同于开发团队或销售人员的理解。
同时具有严重性和优先级将很快变得非常混乱，因为：
- 当使用数字（1 到 5 之间）时，人们不会知道每个数字的含义
- 如果某个问题的优先级最高，但严重性最低怎么办？我相信这会发生！
- 如果有人降低了严重性，他是否也需要降低优先级？
“那你该怎么办？”：
只对问题的“级别”使用一种指标：不管你怎么称呼它。
使用数字（例如 1 - 5，但可能或多或少取决于您的需要）清楚地表明重要性，但将其与关键字结合使用，以便清楚其含义（例如，'nice to have'、'show stopper' ）。对于某些人来说，prio 1 意味着最重要，对于其他人来说，5 确实 -> 因此需要一个关键字来指示数字的含义。
区分“正常问题”或“红色警报”。在我们的案例中，必须立即解决“红色警报”并立即投入生产。一个正常的问题将遵循正常的开发-测试-部署-流程。优先级/严重性/但是如何称呼它应该只针对正常问题设置，对于“红色警报”将被忽略。*> 在实践中，“红色警报”可以成为
“正常问题”：支持团队发现了一个重大错误并创建了“红色警报”。但经过一番调查，我们发现数据库中的数据已经“损坏”，因为它是直接插入而不是通过应用程序插入的。*
选择一个允许您自定义流程的好工具；但大多数工具都可以。
于 2009-08-13T14:46:07.657 回答
1
至于标准，IEEE 软件异常分类指南，尽管我不确定它的采用范围有多广。IEEE 1044.1-1995
于 2009-04-28T06:54:06.010 回答
1
一种选择是让产品负责人确定错误的优先级。虽然对于错误有多“糟糕”有一些普遍的直觉，但产品所有者可能有责任设置优先顺序（即错误 A 应该在错误 B 之前修复等......）。
可以提供给产品所有者的更多信息（清晰和简洁）可以帮助个人做出这些决定（即有多少用户遇到了错误，哪些功能由于错误而不可用，等等......）
于 2009-04-28T06:56:06.130 回答
1
- 现在必须完成
- 必须在我们发货前完成
- 轻微的烦恼（不会阻止用户使用该功能）
- Edge case/Remote/Tester-from-Mordor 场景
好吧，我只是编造了……我的意思是对错误进行分类不应该是每周一个小时+长时间的仪式……
恕我直言，按照流程图优先考虑是浪费时间。修复 Cat#1 和 #2 中的错误 - 尽快修复。如果您发现自己被虫子淹没，请放慢速度并反思。如果计划不允许或优先级更高的项目覆盖，则推迟 Cat#3 和 Cat#4。
关键是你们所有人都对这种严重性和预期质量有共同的理解。不要让遵守 X 的神圣标准拖慢您交付客户想要的东西的速度……工作软件。
于 2009-04-28T07:13:35.667 回答
1
我个人喜欢两层严重性/优先级模型。我知道单级的论点，但我工作过的地方通常我刚刚看到两级的层次结构更好
严重性由支持团队设置（基于客户的输入）。优先级由客户设定（来自支持团队的输入）。
对于严重性，我使用：
1 - 阻止程序/节目停止
2 - 主要功能不可用（或实际上不可用），没有实际解决办法
3 - 主要功能不可用（或...），可以解决
4 - 次要功能不可用（或实际上不可用），没有工作围绕可能
5 - 次要功能不可用（或......），围绕可能
6 - 化妆品或其他琐碎
然后对于优先级，我只使用高、中、低，但任何 3 到 5 级都可以（远远超过顶部）。
我通常会先按优先级排序，然后再按其中的严重性排序。重要的是客户有最重要的发言权。如果他们说他们的徽标在报告上打印出来的方式是最高优先级，那么这就是要查看的内容，但它会在其他客户的高优先级阻止他们登录之后进行查看。
一般来说，我不会发布任何高优先级问题或任何严重程度为 1 - 4 的中等优先级问题。显然，在理想的世界中，你会解决所有问题，但我从来没有幸运地拥有这个选项。
于 2009-04-28T09:27:16.047 回答
1
- 测试人员告诉你坏了什么
- 开发人员估计要修复多少工作
- 客户决定业务价值，即优先级。
于 2009-04-28T23:04:52.023 回答
0
我将以下类别用于功能和错误：
- Showstopper，程序（或主要功能）将无法运行
- 必须有，很大一部分客户会为此烦恼
- 会有的，有些客户会被打扰
- 很高兴有几个客户想要这个
通常您计划修复 1、2 和 3，但由于时间限制，3 通常会推迟到下一个版本。
于 2009-04-28T07:30:58.040 回答
0
我和我们的一位客户有同样的问题。最后，我们一起建立了一个文档，描述了什么样的错误会与某种严重性相匹配。除了偶尔使用本文档作为指导进行讨论之外，似乎可行。
但是请注意，测试团队和开发团队对于什么是严重错误和什么不是严重错误可能有非常不同的看法。从测试人员的角度来看，当开发人员只是说没有人会注意到时，一个小的布局错误可能是高优先级的。
在我们的文档中，如果这些错误是“品牌损害”，则这些错误可能是高优先级的，即如果布局错误出现在徽标或其中一个产品中，那么它是严重的 - 如果它只是页面上的一个段落，距离 2 个像素那么它不是。
于 2009-04-28T07:32:01.517 回答
0
我认为这是我们在上一份工作中使用的比例：
- 导致文件丢失或系统不稳定。
- 使程序崩溃。
- 功能不起作用。
- 功能不起作用，但有解决方法。
- 化妆品问题。
- 要求加强。
有时这会被滥用——如果某个功能设计得非常糟糕，以至于有人无法弄清楚如何使用它，则将其归类为 6，并且从未得到修复。
于 2009-04-29T02:29:07.977 回答
0
设置项目的需求，以便您可以将修复的优先级基于受 bug 干扰的需求的优先级。
于 2009-04-28T06:54:39.643 回答
0
我同意 FogBugz 的人认为这应该保持超级简单： http: //fogbugz.stackexchange.com/questions/352/priority-vs-severity
我制定了这个方案，我觉得很容易记住：
- pS：秒很重要，例如，服务器着火了
- pM：分钟很重要，例如，有些东西坏了
- pH值：时间很重要，即在完成之前不要上床睡觉
- pd：天数，即正常优先级
- pw：星期很重要，即优先级较低
- pm：几个月很重要，即，不着急
- py：岁月很重要，即，也许/有一天，即愿望清单
它与 Debian 的方案大致相似：http: //www.debian.org/Bugs/Developer#severities
我喜欢它，因为它直接将优先级和严重性组合到一个易于为其设置值的字段中。
PS：您还可以在“分钟很重要”和“小时很重要”之间选择“pMH”之类的中间紧急情况。或者“pHd”介于“小时很重要”和“日子很重要”之间——粗略地说，“不要真的为此熬夜，但在完成之前不要做任何其他事情”。
于 2011-04-16T20:12:55.717 回答