我们不时会遇到可以修复的错误，例如通过更改配置，禁用部分逻辑等等。
我和我的经理争论过，我们应该在本地重现这些错误以确保修复工作，更重要的是，开发人员和QA可以将这些案例的检查作为常规版本的一部分。
我的经理认为这是浪费时间，因为解决方案有效，因此无需在本地重现。
所以： 我们是否应该尝试在本地重现以验证修复？ 如果你同意我的话，有关如何将这一点卖给我的经理的任何指示？
答案 0 :(得分：46)
如果您没有复制该错误，那么您的“修复”并不比猜测更好。
答案 1 :(得分：18)
脱离我的头顶：
答案 2 :(得分：11)
如果在经济上可行（例如，不是为了重现环境而将某些用户的整个硬盘驱动器复制到本地计算机上），我非常相信再现错误。
错误的不幸之处在于，通常只有一种方法可以修复错误，但是有很多方法可以修复错误，许多修复方法实际上是掩盖而不是修复。您可能永远找不到根本原因，因此错误会再次出现，或者稍后会出现另一个看似不同的错误。
如果你能找到一个已经发生过的例子（例如，来自同一根本原因的两个不相关的错误），你可能会胜过你的老板。
答案 3 :(得分：9)
该错误的性质也存在问题：
通过单元测试可以快速复制缺陷吗？如果是这样，开发修复程序的开发人员应编写所述单元测试，并将其集成到更完整的回归套件中。这确保了未来的工作不会重新引入缺陷。
可以以编程方式复制缺陷（例如使用Perl或Python脚本）吗？如果是这样，QA团队应该有一个覆盖它的自动化测试用例，并且可以快速用于验证。
可以通过一系列逐步说明复制缺陷吗？如果是这样，QA团队（或最初标记该bug的人）应该提供绝对最少的再生步骤。
这三项原则极大地有助于推动我的测试团队的质量保证流程。
开发人员最好自己重现缺陷。如果这是不可能的（例如硬件资源的稀缺性），直接与QA（或最初标记该错误的人）合作将是下一个最好的事情。虽然有些缺陷是显而易见的（例如菜单选项中的拼写错误），但其他缺陷可能会产生更大的后果，而这些后果可能会被了解应用程序基础状态的开发人员所捕获。
让开发人员重现缺陷以确认它们确实是缺陷也很有帮助。测试人员虽然不可或缺（作为软件测试人员发言;）），但往往缺乏对应用程序代码的深入了解，并且可能无法深入理解为什么行为不符合他们的期望（或规范）。
答案 4 :(得分：6)
唯一不应该在本地重现的情况是，这种情况不可行。也许它需要 LOT 的数据，专有数据，硬件，或者它需要比你更复杂的设置。
我不得不这样做几次，因为我们无法在内部复制设置。 （有些开发工作甚至已经在客户端的系统上完成。）客户从一开始就知道他们超出了我们可以重现的范围，并且这些错误会导致处理这些问题。
答案 5 :(得分：5)
测试驱动开发背后的基本原则是您有一个演示某些功能的测试。
在这种情况下，您创建一个演示错误的测试。测试失败。
你修复了这个bug。测试通过。和所有其他测试一样。您已经实际修复了该错误而没有产生其他问题。
答案 6 :(得分：4)
这个问题有很多好的答案，但其中大多数并没有直接谈到情况的经济学，这可能是影响你的经理的主要因素。
如果你不重复，那么你
权衡降低风险的努力之间的权衡取决于具体情况 - 您正在生产什么样的软件，有多少客户，生产中有多少“坏”错误（例如销售网站是否会下降）你每天损失一百万美元，或者网络论坛是否会下降，人们必须等到明天才能进行在线聊天），你有多少测试自动化（影响重复/回退错误的程度），......
许多（大多数？）经理都厌恶风险，所以说到说服，试着说出各种风险（回归其他功能，部署一个实际上没有修复它的修复程序（并且对客户看起来很愚蠢）， ......）以及估算为减轻风险而需要花费的精力（重新计算成本并对修复有信心）。
答案 7 :(得分：3)
Test Automation使您的所有测试可以随时重新播放，几乎不需要额外的努力。 Unit testing是一种非常常见的测试自动化，涉及测试每个最小的部分。
答案 8 :(得分：3)
你赶时间吗？如果是这样，那么重现错误！这创建了一个有条不紊的思维模式，您需要防止进一步的问题。你怎么可能发现重新引入的旧错误？再现错误会引起别人的注意：
优秀经理：“你在做什么？”
优秀的开发人员：“我们再次遇到了这个错误。我正在重建测试环境，以便我们可以重播它。”
好经理：“WTF？我以为戴夫说他修好了？嘿戴夫，你不解决这个错误吗？为什么我们再浪费时间呢？
对战：
屁股经理：“你在做什么？”
优秀的开发人员：“我们再次遇到了这个错误。我正在重建测试环境，以便我们可以重播它。”
屁股经理：“不 - 我们没有时间。只需修理并回滚。您是否回复了有关会议的电子邮件？我得走了 - 我得10和史蒂夫一起好。啊，滚回去，发送那封电子邮件啊。“
作为导演，我告诉我的所有团队“今天花点时间”才能做到正确，所以我们不会在午夜开始。
答案 9 :(得分：3)
您必须始终尝试。您需要确定它是否是错误，错误或缺陷。如何在不理解问题的情况下解决或缓解问题？
如何解决记录或测试套件？是否适当的状态
- “固定”，“打开”，“无法再现”，“无法修复”，“功能”？
如果你无法重现它，那么仍然必须做出决定，让它漂进/ dev / null就要求它回来咬你。
答案 10 :(得分：3)
我前一段时间阅读a good book on debugging，建议不仅要复制错误，还要修复它：
原因是你可能会试图修复一个错误，这将帮助你知道你修复了它。如果你没有知道你修复它，它可能仍然会被破坏。
（前几天我遇到了这样一个案例，似乎没有任何关系的代码行导致我们的网站表现得很奇怪：当我把代码行拿出来时，网站工作了，但是当我把它放进去，网站还行。但事实证明这只是巧合;无论我做了什么，网站都是每隔一段时间都做错了，因为它巧妙地记录了我的进出。你必须知道你的修复是一个真正的解决方案。）
编辑：我在一个所有者非常胡思乱想的地方工作，这些错误据称已被修复但未被修复。之所以发生这种情况，是因为即使我（或另一个开发者）能够重现这个错误，我也没有像测试人员那样重现它。您不仅应该重现该错误，而且您应该确保以与测试者完全相同的方式再现错误。
（但如果您想先尝试自己，请继续;也许您会发现另一个错误！之后，让测试人员在您开始处理错误之前展示他/她的复制品。）
答案 11 :(得分：2)
必须在本地重现错误的最重要原因是确保在修复错误时没有其他任何东西。如果修复只是一个配置或任何不需要重新编译的东西，那么这个参数就不那么强大，因为编译的任何东西都应该已经过测试。
如果你的经理没有得到这一点，那么除了向他展示真实的情况之外，你可以做些什么来说服他除了修复一个错误实际上搞砸了一些东西，这导致了比复制所需的更多延迟本地的bug。
答案 12 :(得分：2)
我发现没有复制错误来修复它的想法就是奇怪的。
毕竟，在重现之前，你不能确定问题是什么。直到那时它只是猜想（即使它是消息灵通的，它仍然是猜想）。
现在您是否进行单元测试我认为与此讨论无关，因为重现性只是一个问题，您是否发现了该错误？如果你正在测试错误的东西，做一些不正确的假设或者只是误解了（可能是模糊的）关于实际发生的事情的错误报告，单元测试将无法帮助你。
这就是你重现问题的原因。
答案 13 :(得分：2)
我认为这个问题的答案取决于你如何测试你的bug。
除非上述问题的答案是全面的，否则结合检查以验证错误修复已经发生将是乏味和痛苦的。也很难说服经理花时间合并这些支票，因为他们总是说“我们没有足够的人力资源”
如果您在自动化解决方案上投入一些时间，那么将这些测试添加到构建过程中将是明智的选择，因为解决任何错误的第一步应该是创建一个无论如何都能在本地重现问题的测试。 / p>
对于我的项目，我们使用subversion进行源代码管理，使用Jira进行活动管理，使用Hudson进行构建，使用Fitnesse和MSTest进行测试。所有这些都是通过持续集成捆绑在一起的。 Fitnesse进行验收测试和MSTest单元测试，每次执行构建时它们都会自动运行，以便为我们提供构建“良好”的定量指标。
答案 14 :(得分：1)
是的，在可行/可行的情况下;见Regression Testing
答案 15 :(得分：1)
在大多数情况下，您无法知道您复制的错误与您的客户遇到的错误相同。因此，复制并不能保证问题真正得到解决。
例如，客户遇到了我工作的项目的沟通错误。我们通过代码搜索来修复任何可能的错误。一个错误涉及PIC微处理器中的ASIC错误，芯片勘误表提供了我们实施的解决方法。然后我的一个同事经历了极端的措施来重现这个错误，以便他可以声称我们客户的问题可能是固定的。
不是。
最后，我们添加了许多防御性编码，客户再也没有遇到过这个问题。我们不确定究竟是哪个解决方案解决了这个问题，知道并重现客户所遇到的问题会很棒，但最终没有任何问题。重要的是软件的工作原理。
因此能够重现错误并深入了解导致问题的原因非常棒，但复制错误并不能保证解决客户的问题，而且工作软件更为重要。
听起来你的工作场所在光谱的“无任何重现”方面太过分了，当一点额外的工作可以产生更可靠的软件时，这是一种耻辱。在这篇文章中，我认为光谱的另一端也不是那么好，所以我会尝试在两者之间推动。
答案 16 :(得分：1)
虽然说单元测试是解决方案而你不必重现错误，如果你使用它们听起来不错，我认为它不适用于现实世界。事实上，他们没有在网站上复制错误意味着复制可能并非微不足道。这可能意味着来源很复杂。如果在单元测试中代表该问题是微不足道的，则该单元测试将是该错误的再现。如果他们没有复制它，他们可能无法为它编写简单的单元测试。
如果你没有复制这个bug，你就不会真正理解它。您可能在系统中发现了 错误，但这并不能保证您找到了客户看到的 错误。
如果您无法重现该错误，则无法确定它是否已修复。您可能只处理问题的症状而不是核心问题。客户可能对同一核心问题有不同的向量，他们的问题将无法解决。
答案 17 :(得分：1)
我和我的经理争论过，我们应该在本地重现这些错误以确保修复工作，更重要的是，开发人员和QA可以将这些案例的检查作为常规版本的一部分。
我特别赞同关于开发人员和QA的部分，包括支票。这是日本人称之为Jidoka（代表“人性化自动化”）的一部分：
[...] Autonomation阻止了 生产有缺陷的产品， 消除了过度生产和焦点 注意理解问题 并确保它永远不会再次出现。它 是一个质量控制过程 适用以下四个原则：
- 检测异常。
- 停止。
- 修正或纠正即时情况。
- 调查根本原因并安装对策。
对策是防止再次发生。这就是构建Poka-Yoke - 防错过程的过程（以及让缺陷发生的过程是一个有缺陷的过程）。优秀的经理人应该这样做。
答案 18 :(得分：1)
更改配置，禁用逻辑的某些部分等生产是暂时的解决方案。
我们需要通过本地测试确保产品可靠并满足客户要求，跨设备（移动设备，平板电脑等）和跨平台（Firefox，Chrome，Internet Explorer）测试也可以这里的重要作用。
检查问题的必要性是首先在本地复制以确保产品的质量，因为如果客户发现同样的问题，那将是一个问题：）
提供可靠，无错误的产品理解和重现问题是最重要的。
正如你所提到的，通过改变配置，禁用逻辑的某些部分等来修复错误（即不重现）。但是如果客户具有相同的配置，那么暂时你正在改变那么它实际上将是一个大问题，因此跨设备（移动设备，平板电脑等）和跨平台（Firefox，Chrome，Internet Explorer）测试非常重要的。
答案 19 :(得分：0)
对于来自现场的随机崩溃，有时你无法重现它们。我使用微软Windows错误报告服务收集的死后故障转储调试了罕见的竞争条件和“不可能”的崩溃。我认为微软大师雷蒙德·陈称之为“通灵调试”。
如果您的公司向公众提供Windows软件（C ++或.NET），我强烈建议您使用Microsoft的Windows错误报告（WER）服务。它是免费的，即使对于商业软件公司也是如此。它比编写自己的错误报告和故障转储收集服务更简单。 WER甚至整理所有堆栈跟踪，以便您知道哪些崩溃是重复的，这在您不想调试数千次重复崩溃时很有用。 ：）
答案 20 :(得分：0)
尝试让你的经理被解雇是因为它愚蠢而得到了他的工作，这可能是一个机会！
答案 21 :(得分：0)
可能会重复已经写过的内容，但是是的！理由是：只找一次bug。如果您可以编写一个复制错误的测试，则无需再次手动测试 - 您的自动测试会找到它。
因此，您可以修复该错误，并且您可以安全地知道您的软件将永远不会再遇到此错误。这很好。它会节省你的时间。它会省钱。
答案 22 :(得分：0)