错误的生命周期/过程是什么？一般来说，是否有任何提示，建议过程明智地应该修复bug？
答案 0 :(得分：11)
标准Find-＆gt; Fix-＆gt; Test-Release周期之外的一些事情：
错误应该有多个分配，因此可以分配给一个人进行修复，另一个人进行测试，而不是分配给一个人。
您的错误追踪系统必须跟踪所有更改内容的历史记录。
跟踪发现错误的版本，修复版本，测试版本，然后发布。它们都是不同且重要的值。
能够将问题从错误更改为增强功能。
拥有“问题”或“等待答案”的状态，表示已向业务分析师发送问题，从根本上阻止了错误的进展。
将错误限制在一个问题上，以便您可以验证该问题是否已得到修复。因此，如果屏幕出现3个问题，请记录3个错误，而不是单个“无论屏幕上的问题”;这些错误可以单独修复和发布，您需要能够跟踪它。
答案 1 :(得分：1)
答案 2 :(得分：1)
关于这个主题的好书是：
David J. Agans其中一个是在调试时使用步枪而不是霰弹枪方法。这是确保测试每件作品以找到问题。此外，一旦你做了修复，然后尝试再次打破它，以确保你明白出了什么问题。
有时候我修复了（在维护代码中）只是发现修复程序破坏了其他东西。在将错误标记为已修复之前，请确保该修复不会破坏其他内容。
这提出了一个错误的真正问题：未能完全理解代码正在做什么。
答案 3 :(得分：1)
我的组织遵循了这种模式：
系统工程师或QA会注意到该错误并将其输入错误跟踪工具。
PM或Dev Lead会根据严重程度，可能的解决方法以及修复错误所需的工作量来确定错误的优先级。
PM或Dev Lead将错误分配给开发人员。
开发人员会在步骤1中向此人提供任何必要的帮助，以重现该错误。
开发人员编写解决方案并进行构建（或进行构建）。
来自第1步的测试人员重新测试该错误。
如果修复了错误，请重新部署或修补。否则，重复步骤5和6，直到它被修复或更紧迫的问题为主。
如果客户发现了该错误，请与他们核实是否已修复。
通常，错误会经历此分配周期：Tester - ＆gt; （PM / Lead，然后是开发人员;或开发人员） - ＆gt;测试仪 - ＆gt; PM / Lead - ＆gt;闭合。
答案 4 :(得分：1)
我不禁在这里嗤之以鼻。我试过但终于崩溃了。真正的错误过程：
用户向开发人员发送电子邮件以修复错误。除非进入项目管理系统，否则开发人员会回复电子邮件并表示无法对其进行操作。每个人都讨厌PM系统，因此用户抱怨必须输入它。 Dev因为需要某个地方来充实自己的时间而坚定不移。 Bug进入系统并分配给不同的开发人员。
这里有三个分支：
分支1，dev查看提供的屏幕截图，并注意到用户正在2009年报告页面上查找2010年数据。用户通知错误并关闭错误。
开发人员同意系统肯定不会像用户想要的那样工作。但它确实按规范定义的方式工作。用户不希望听到这现在是开发工作而不是错误。当用户必须告诉客户，由于这是新工作，他将不得不支付额外费用。决定将它视为一个错误，以使客户满意并且bug被修复和关闭。后来的管理层想知道为什么系统如此错误，我们在开发方面亏损。
哦，我的确有一个真正的错误，开发修复和移动修复prod并关闭bug。
答案 5 :(得分：0)
测试（软件） - ＆gt;记录（错误） - ＆gt;修复 - ＆gt;验证 - ＆gt;关闭
答案 6 :(得分：0)
简单的问题，简单的答案。希望这会有所帮助。
答案 7 :(得分：0)
当我发现错误时，我要做的第一件事就是将其记录在错误系统中。然后我编写测试来说明bug，然后修复代码以确保测试通过。这可以确保您可以a）重现错误并b）修复错误。
我会定期对bug数据库进行一些分析，找出错误发生的原因。规范中是否存在错误，代码中存在逻辑错误等？并采取适当措施减少错误计数。
我已在我的博客http://jeffastorey.blogspot.com/2010/02/what-to-do-when-you-find-bug.html中详细说明了这一点。
答案 8 :(得分：0)
首先要确保你所看到的错误是你应该花时间修理的错误。弄清楚错误的影响及其对用户的影响是错误的过程/生命周期中的重要的第一步。当错误量更高并且您需要确定错误的优先级时，这变得更加困难，不仅仅是一个错误，而且可能是数百个错误。
需要考虑的事项：
可以帮助您更轻松地优先处理错误的事情：
您可以在此处找到更多有用的建议：https://blog.bugsnag.com/bug-prioritization/