debug为啥是个虫子_虫子是浪费的可怕东西

debug为啥是个虫子

一些开发团队， 尤其是敏捷团队，不会费心跟踪bug 。 当测试人员发现错误时，他们不使用错误跟踪系统 ，而是与开发人员联系并进行修复，或者编写需要修复的失败测试并将其添加到Continuous Integration测试套件中，或者如果必须这样做， ，他们在卡上写下一个错误故事，然后将其张贴在墙上，以便团队知道它，并且有人会致力于修复它。 其他团队则依靠他们的错误跟踪系统来生存，他们使用诸如Jira或Bugzilla或FogBugz之类的工具来记录错误以及更改和其他工作。 这两种方法都需要争论。

用于跟踪错误的参数–和不跟踪错误的参数

在《 敏捷测试：测试人员和敏捷团队实用指南》中 ，Lisa Crispin和Janet Gregory考察了使用缺陷跟踪系统的利弊。 对于无法面对面的团队来说，使用系统跟踪错误可能是管理问题的唯一有效方法，例如，分布在不同时区的团队。 这对于在旧系统中继承了开放错误的团队也很有用； 对于因合规性原因而不得不跟踪错误的团队来说，这是必不可少的。 错误数据库中的信息对于加入团队的测试人员和开发人员来说是一个潜在的知识库-他们可以查看以前在他们正在研究的代码区域中发现的错误，以了解应该解决的问题。 如果您认为错误指标有用，则错误数据可用于收集指标并创建错误趋势。

但是精益/敏捷的观点是，使用缺陷跟踪系统通常会妨碍人们的发展并降低他们的速度。 团队应该继续专注于发现错误，修复错误，然后忘记它们。 错误是浪费 ，而与错误有关的一切都是浪费–无效的信息和无效的时间，最好将其用于传递价值。 更糟糕的是，使用缺陷跟踪系统会阻止测试人员和开发人员彼此交谈，并鼓励测试人员采取“质量警察”的心态 。 没有工具，人们就必须互相交谈，并且必须学习如何很好地玩耍。 这是一种短期的战术观点，着眼于使软件发布和运行所需的内容。 这是项目思维，而不是产品思维 。

长期的错误

但是，如果您像我们一样长时间在系统上工作，那么如果您正在管理产品或运行服务，那么您就知道这不是那么简单。 您不能只看眼前的事物，以及一年或一年后想要成为的事物。 您还必须回顾过去所做的工作，以前发生的问题，之前做出的决定，以了解您现在的位置以及将来的方向。

因为有些问题永远不会消失。 除非您采取措施阻止它，否则其他问题将再次出现。 您会发现，您以为曾经舔过的其他问题从未真正消失过。 来自旧错误的信息，发生的情况以及有人对其进行了修复（或为什么他们无法修复它们），有效的变通方法（哪些无效）可以帮助您理解和处理当前遇到的问题，并帮助您不断改进系统以及如何构建和保持系统运行。

因为您应该了解更改的历史记录，并在要更改代码时对其进行了修复。 如果您喜欢今天的代码方式，则可能想知道如何以及为什么采用这种方式。 如果您不喜欢它，那么您将想知道它是如何实现的以及为什么会这样-假设您不会犯相同的错误或被迫陷入相同的情况是很自大的。 修订控制将告诉您更改的内容以及更改的时间和对象，错误跟踪系统将告诉您原因。

因为您需要知道系统中哪里存在不稳定和风险。 您需要识别缺陷密集型代码或容易出错的代码 -包含太多错误的代码，维护成本太高并导致太多问题的代码，无法按当前方式运行的成本太高的代码。 您应尽快重写的代码，以提高稳定性并降低日常成本。 但是，如果不了解系统中的问题历史，就无法识别此代码。

因为您可能需要向审计师或监管机构以及客户和投资者证明，您正在负责任地进行测试，查找错误，修复错误并发布修复程序。

而且因为您想知道团队在发现，修复和预防错误方面的效率。 您今天看到的错误更少了吗还是更多错误您是否看到相同的错误-您是否在犯同样的错误还是不同的错误

您需要跟踪每个错误吗/h2>

只要足够早地发现错误，跟踪它们就没有任何价值。 是时候逃脱错误了，需要对其进行跟踪：开发人员无法立即，通过配对或通过在持续集成中运行的标准自动检查和测试而无法立即发现的错误。

我们不登录

• 在单元测试或其他自动化测试中发现的缺陷–除非由于某种原因无法或无法立即解决问题；
• 在同行评审中发现的问题–除非评审中的某些问题被认为很重要并且不能立即得到解决。 或者在测试已经开始之后的较晚的审查中发现问题，并且将需要重新测试代码。 或者审阅者发现未更改的代码中有错误，这是一个旧错误–仍然需要解决的问题，但是我们可能不准备立即进行处理。 记录在外部检查中发现的所有问题，例如安全检查或审核；
• 静态分析结果 –这些工具捕获的大多数问题都是简单的编码错误 ，可以立即发现并解决，而且通常还必须过滤掉相当多的噪声（ 误报 ）。 我们运行静态分析检查并每天进行审查，并且只有在我们同意发现是真实的但开发人员没有准备立即修复它的情况下才记录发现结果（除非我们针对现有的运行新工具，否则几乎不会发生）代码库）。 许多静态分析工具都有自己的系统，可以以任何方式跟踪静态分析结果，因此我们随时可以返回并稍后审查未解决的问题。
• 当开发人员和测试人员决定配对在一起以在开发的早期阶段测试变更时发现的错误，而这些错误主要是在探索某些事物应该如何工作时-我们通常不会记录这些错误，除非无法/无法修复它们（可以（例如，稍后再复制）。

虫子是浪费的可怕东西

我们会记录所有其他错误，无论它们是在生产中，内部测试，合作伙伴测试，用户验收测试还是外部测试（例如笔测试）中发现的。 因为在大多数情况下，当将软件交付给测试人员时，它应该可以正常工作。 如果测试人员发现错误，尤其是严重的错误，那么这对于测试人员，开发人员以及团队其他成员都是重要的信息。 它可以突出风险。 它可以显示需要进行更多测试和审查的位置。 它可能会突出设计中的更深层问题，缺乏可能导致其他问题的理解。

如果您认为测试不仅提供有关软件状态的重要信息 ，而且还提供有关如何设计和构建软件的重要信息 ，那么每个人都需要能够看到这些信息，并逐渐了解它们。 有些问题无法立即或在1周或2周的sprint大小的块中看到或完全理解。 您可能需要一段时间才能意识到自己在设计中存在严重缺陷，或者在开发方法或文化中遇到了某些问题。 在开始查找它们之间的关系以及寻找其根本原因之前，您需要先遇到一些问题。 您需要过去的数据，以便将来解决问题。

如果您从错误中学习，跟踪错误并不是浪费。 丢弃错误信息是真正的浪费。

参考： Building Real Software博客的JCG合作伙伴 Jim Bird指出， Bug是一件可怕的事情 。

翻译自: https://www.javacodegeeks.com/2013/02/a-bug-is-a-terrible-thing-to-waste.html

debug为啥是个虫子

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91383 人正在系统学习中 相关资源：PHP寄生虫繁殖劫持程序V3.0_寄生虫程序-PHP代码类资源-CSDN文库

来源：danpu0978