你的错误管理流程是什么？

Question

你的错误管理流程是什么？

process

6

一个bug的生命周期/过程是什么？一般来说，有没有什么建议或提示可以帮助修复bug的过程？

- user48545

4

将引入漏洞的过程逆转即可！ - Carl Norum

1

"否认、延迟、谴责、借记、调试" 算吗？ - BobMcGee

9个回答

1

用户报告错误
QA重现错误
开发人员对错误进行分类，以验证它是否是错误或新功能请求
如果是错误，则分配给开发人员
QA在下一个版本中测试错误修复
发布

- Joel Martinez

1

关于这个主题的好书是：

Debugging by David J. Agans

其中之一是在调试时使用步枪而不是散弹枪方法。也就是说，一定要测试每个部分以找到问题。此外，一旦您进行修复，请尝试再次破坏它，以确保您了解出了什么问题。

有时我会发现自己修复了一些东西（在维护代码中），但却发现修复导致其他问题。在将错误标记为已修复之前，请确保修复不会破坏其他内容。

这带来了一个真正的问题： 无法完全理解代码正在执行的操作。

- Todd Moses

我个人很喜欢这本书：http://www.amazon.com/Science-Debugging-Yuan-Hsieh/dp/1932111182/ref=sr_1_42?ie=UTF8&s=books&qid=1269380162&sr=1-42#noop - HLGEM

1

我的组织一直遵循这个模式：

系统工程师或QA注意到错误并将其输入错误跟踪工具中。
项目经理或开发主管根据严重性、可能的解决方法和修复所需的工作量对错误进行优先级排序。
项目经理或开发主管将错误分配给开发人员。
开发人员在必要时从第1步的人员那里获得帮助，重现错误。
开发人员编写解决方案并制作构建（或让其他人制作构建）。
来自第1步的测试人员重新测试错误。
如果错误已修复，则重新部署或打补丁。否则，请重复步骤5和6，直到修复或更紧迫的问题成为优先事项。
如果客户发现了错误，请与他们确认已修复。

通常，错误会经历以下分配周期：测试人员 -> （项目经理/主管，然后是开发人员；或者是开发人员） -> 测试人员 -> 项目经理/主管 -> 已关闭。

- David

1

我想明确指出，严重性（severity）!= 优先级（priority）。这个答案正确地暗示了这一点，但我只是想明确说明一下。优先级是利益相关者做出的决定，是主观的，并基于此答案中的许多因素。严重性是客观的。这个 bug 要么很严重（崩溃、数据丢失等），要么适度（功能损坏/错误、性能差等），要么轻微（不影响功能的视觉问题、次要的功能问题等）。 - mockobject

@m0ck0bject - 这正是我使用这些术语的方式。谢谢！ - David

1

我在这里忍不住要说一句刻薄的话。我试过了，但最终崩溃了。真正的错误处理过程：

用户通过电子邮件请求开发人员修复错误。开发人员回复说，除非将其输入到项目管理系统中，否则无法处理。每个人都讨厌项目管理系统，因此用户抱怨必须输入它。开发人员坚定地表示需要一个地方来计费时间。错误已输入到系统中并分配给另一个开发人员。

从这里有三个分支：

分支1，开发人员查看提供的屏幕截图，并注意到用户正在寻找2009年报告页面上的2010年数据。通知用户错误并关闭错误。

开发人员同意系统绝对不按照用户想要的方式工作。但是，它确实按照规范定义的方式工作。用户不想听到这现在是一个开发工作而不是错误。当他不得不告诉客户由于这是新工作，他将不得不额外支付费用时，用户特别沮丧。决定仍将其视为错误以使客户满意，并修复和关闭错误。后来管理层想知道为什么系统如此容易出错，我们在开发上亏损。

哦，天啊，真的有一个实际的错误，开发人员修复并将修复移动到生产环境并关闭错误。

- HLGEM

0

测试（软件） -> 记录（漏洞） -> 修复 -> 验证 -> 关闭

- Justin Niessner

0

注意错误。
找到错误并能够重现它。
编写解决方案，修复错误。
测试 - 证明您已经修复了错误并且没有引入新的错误（功能和单元测试）。
重新部署或打补丁。

简单问题，简单回答。希望这可以帮助您。

- Steve H.

如果错误是设计固有的呢？ - Carl Norum

0

当我发现一个 bug 时，首先要做的是将其记录在 bug 系统中。然后编写测试以说明 bug，并修复代码以确保测试通过。这样可以确保您能够 a）重现该 bug 和 b）修复该 bug。

定期，我会对 bug 数据库进行一些分析，以确定 bug 发生的原因。规范中是否存在错误、代码中是否存在逻辑错误等？并采取适当的措施来减少 bug 数量。

我在我的博客 http://jeffastorey.blogspot.com/2010/02/what-to-do-when-you-find-bug.html 中详细介绍了这一点。

- Jeff Storey

0

首先要确保你正在查看的错误确实值得你花时间去修复。在处理/生命周期中，弄清楚错误的影响以及对用户的影响是一个重要的第一步。当错误数量增加时，需要确定错误的优先级，不仅仅是一个，可能是数百个。

需要考虑的事情：

错误频率
受影响的用户
代码区域
VIP客户

以下是有助于更轻松地确定错误优先级的方法：

智能警报
静音或暂停错误的能力
将类似的错误分组在一起
将错误映射到用户
将系统中的错误汇总到一个地方

您可以在这里找到更多有用的建议：https://blog.bugsnag.com/bug-prioritization/

- Kristine P.

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mike Mooney · Accepted Answer

除了标准的查找->修复->测试->发布周期外，还有一些其他的事项：

一个缺陷应该有多个分配，这样就可以将其分配给一个人进行修复和另一个人进行测试，而不是分配给单个人。
您的错误跟踪系统必须跟踪所有更改历史记录。
跟踪一个缺陷在哪个版本中被发现，修复，测试，然后发布。它们都是不同且重要的值。
具有将问题从错误更改为增强功能的能力。
拥有“问题”或“等待答案”的状态，表示已向业务分析师发送了问题，从本质上阻止了缺陷的进展。
将一个缺陷限制在一个问题上，以便您可以验证该问题是否真正得到解决。因此，如果屏幕有3个问题，就记录3个缺陷，而不是单个“某屏幕上的问题”；这些缺陷可以单独修复和发布，并且您需要能够跟踪它们。