主页上的公司名称拼写错误以及很少使用的导出功能崩溃：您首先修复哪个？类似这样的争论就是测试团队区分严重性与优先级的原因。一是描述技术损坏，二是描述业务紧急程度。

如果没有这种区别，每个错误都会被标记为“严重”，这些标签就失去了意义，开发人员也不再信任它们。本指南为您提供了清晰的定义和示例，以及做出这些决策的简单流程。这些示例是说明性的，并且具体的规模因团队和工具而异。

简短的回答

严重性答案：此错误对产品的影响有多严重？崩溃或数据丢失很严重，而外观故障则不然。

优先答案：我们应该多久修复它？这取决于受影响的客户、截止日期、收入、法律风险和品牌声誉。

想想医院。严重程度是指患者病情的严重程度。优先级是患者接受治疗的顺序，这还取决于其他因素，例如谁可以安全等待以及哪些资源是免费的。

严重性与优先级并列

严重程度

大多数团队使用大约四到五个级别。这是一个常见的尺度：

优先级

写下每个级别对您的团队意味着什么，最好为每个级别设定一个目标响应时间。 “P1 意味着有人在一小时内开始”比“P1 意味着非常重要”有用得多。

四种组合，并举例

理解这一点的最清晰方法是查看每个组合：

高严重性、高优先级

每个人的结帐都失败了，企业每时每刻都在亏损，而且没有解决办法。这是显而易见的情况：放弃一切并修复它。

高严重性，低优先级

导出为旧格式时应用程序崩溃。从技术上来说，这是一个严重的失败。但如果只有一小部分用户接触过此功能，并且现代格式运行良好，则可以等待预定的发布。

低严重性，高优先级

主页上的公司名称拼写错误。没有任何损坏，也没有数据面临风险。然而，每个访问者都会看到它，这会损害信任，如果明天要进行重大发布，那么今天就需要修复。

低严重性、低优先级

一篇很少访问的帮助文章中的一个小错字。方便的时候修一下。如果您的待办事项中充满了这些内容，请考虑将它们分批放入一项清理任务中。

一个错误，两个不同的优先级

根据上下文，相同的缺陷可能需要不同的优先级。假设发出的订单确认电子邮件带有错误的徽标。

严重性没有改变，因为对系统的影响是相同的。但商业形势确实如此。时间也能改变一切。今天是 P3 的错误可能会在主要客户上线前一周变成 P1。

谁决定严重性和优先级？

• 测试人员通常会提出严重性，因为他们已经看到了行为并了解对系统的影响。
• 产品所有者或经理通常会在权衡客户、收入和路线图时决定优先级。
• 开发人员添加有关原因、修复风险以及修复所需时间的信息。
• 支持团队提供证据表明有多少客户受到影响以及影响有多严重。

这些职责的来源和团队各不相同，在小型初创公司中，一个人可能会承担所有这些职责。重要的是每个人都知道谁做出最终决定，因此分歧最终会以决定结束。

如何评估错误

当您不确定时，请解决这些问题。

对于严重程度：

1. 它是否会丢失或损坏数据，或暴露私人信息？
2. 它会阻止主要功能的工作吗？
3. 有没有解决方法，普通用户可以找到吗？
4. 有多少功能受到影响？

对于优先级：

1. 有多少用户受到影响，哪些用户受到影响？
2. 它会花钱吗？或者会产生法律或合规风险吗？
3. 即将发布、演示或销售吗？
4. 它有多明显？它会损害您的声誉吗？
5. 它是否会妨碍其他工作，例如测试？

运行错误分类

分类是定期会议，团队在会上审查新错误并决定接下来要做什么。简单的格式效果很好：

1. 准备。 测试人员确保每个新错误都有明确的步骤、证据和建议的严重性。
2. 确认。检查是否可以复制且不是重复的。
3. 决定。 就严重性达成一致，设置优先级并分配所有者。
4. 关闭循环。拒绝、推迟或安排每个错误，并记录原因。

保持简短且频繁。在发布前的最后几天，每天进行 15 分钟的分类是很常见的。严重性和优先级也会影响您的发布决策，因此请预先商定规则，例如“发布时没有开放的 S1 或 S2 错误”，作为您的 退出标准 的一部分。

错误报告中的严重性和优先级

简短、清晰的条目可以帮助每个人做出正确的决定：

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

这些数字只是例子。在真实的报告中，使用日志中的测量数据，并解释你的推理。请参阅我们关于如何编写错误报告的指南，了解更多信息。它还有助于了解错误代码的含义，因此请将我们的 HTTP 状态代码备忘单 放在手边。

常见错误

• 将它们视为同一字段。 如果两者始终匹配，您就会丢失有用的信息。
• 夸大严重性以引起注意。一旦一切都变得至关重要，就没有什么是重要的了。
• 让测试人员单独设定优先级。他们很少了解完整的业务情况。
• 从不审查待办事项。优先级会过时，因此请定期重新检查旧错误。
• 没有书面定义。 没有它们，人们会以不同的方式应用标签，并且最终会争论单词。
• 忽略低严重性的堆积问题。 五十个小问题可能会让产品感觉很糟糕，即使没有一个问题单独严重。

最后的话

将两个问题分开：问题有多严重，以及必须多快修复？就每个级别的书面定义达成一致，并明确由谁决定。下一步，找出跟踪器中最古老的十个错误，并使用上述问题重新评估它们。您可能会发现一些应该移动，还有一些应该关闭。

常见问题

继续学习