如何分析错误未被捕获的场景，并调整开发工作流程以防止类似的错误

Question

我有一个很难追踪的bug，因为所有的单元测试都是绿色的，但是生产应用程序没有正常工作。

下面是所发生的事情：

我有一个过滤器类，它将我的应用程序设置为忽略某些指定时间窗口中没有的数据。

• 单元测试，在我看来是彻底的，变成了绿色。
• 此外，我的集成测试也产生了预期的结果。
• 然而，生产不起作用。
  • 由于前两颗子弹的作用，这个问题很难找到。

事实证明，问题是我的测试日期使用了我的时区(美国/芝加哥)，但是生产数据提供了UTC的日期，我没有意识到这一点，并且过滤器的逻辑对于UTC日期是不正确的。(我使用的是joda时间DateTime对象)。

1. 我的工作流程在哪里崩溃？
   • 我是否没有生成一个规范，说明在任何时区处理日期所需的逻辑？
   • 在单元测试级别，我没有彻底考虑所有的情况吗？
   • 我是否未能确保集成测试与生产非常相似？
   • 另一个？

2. 我可以对我的工作流程做什么改变，以更好地防止这种错误在未来？
3. 当生产中有问题而不是测试中有问题时，我如何更有效地调试问题？

Answer 1

@RobertHarvey的评论是完全正确的:进程不会产生无错误的软件，但是良好的过程至少可以减少错误类的重复出现。听起来你在尝试完成后者，所以我会提出我的建议，我认为你的错误是哪里来的：

您未能在测试中说明生产环境的所有细节。您的测试应该在尽可能接近于生产的环境中运行。在您的例子中，您忽略了这样一个事实:在单元测试以不同的时区运行时，生产处理UTC中的时间。

向前看，只要知道您的生产环境是如何配置的，它是如何在尽可能多的细节中运行的。无论何时编写单元测试，都要寻找可能发生变化的内容，以尽可能地影响单元测试，并设法使这些差异与生产中发生的变化相匹配。

在编写单元测试时，这个小小的预先考虑可能会帮助您继续前进，从而捕捉到测试运行方式与生产方法不同的其他方式。如果你使用这些方法，可以把它写在一张清单上，无论哪种方式，在编写测试时都要注意到这一点。

过程不会阻止您得到更多的but，甚至与此相关的but，但是随着这种正念的推进，被称为“在生产中失败而不是在开发中的东西”的but类别将会显著减少。

您可能缺少的一件事是常见的，那就是一份详细描述系统的文档，其中包含了关于所有不同事物的详细信息。它运行在哪个时区，用什么语言编写，不管是64位还是32位，所有这些都会影响系统的行为。将它们记录下来可以帮助团队更好地了解系统，而不是单独了解系统。单个开发人员通常只知道系统的子部分，并且可能不知道这些更大的系统细节，这些细节会以他们不知道的方式影响它们。

1. 我的工作流程在哪里崩溃？
   • 您的测试试图模拟生产。

2. 我可以对我的工作流程进行哪些更改，以更好地防止将来发生这种错误？
   • 记录或说明开发和生产环境之间的这种差异。

3. 当生产中有问题而不是测试中有问题时，我如何更有效地调试问题？
   • 隔离不同系统之间可能不同的变量，并在开发和生产环境之间检查它们。如果您想学习它，使用调试器，它可以占用内存转储并让您分析活动进程状态，在这种情况下通常会有所帮助，尽管学习远远不是一项微不足道的工作。

Answer 2

除了Jimmy的回答:您在所有类型的but周围询问广域网，但是您的例子有点狭窄:据我从您的示例中可以看到，您遇到了一个应用程序的弱点，因为它不能很好地处理本地化问题。这是一个很大的领域，微妙的big可以出现，而且非常广泛。局部的差异和假设会让你头疼。下面是一些例子：

• 在美国，星期天是一周的第一天，在欧洲，是星期一。
• 前一天在美国和前一天在欧洲。
• 但同时也使用"，“或”。“当使用值是不同的。

所以我的答案是：

1)我的工作流程在哪里崩溃？

它坏了，因为你没有考虑到本土化。

2)我可以对我的工作流程做什么改变，以更好地防止将来出现这种错误？

了解本地化信息，并检查整个应用程序中的本地化问题。

Answer 3

尽管进程不能保证一个没有bug的应用程序，但是单元测试也不能保证100%的代码覆盖率。

事实上，这样做很容易导致一种错误的安全感，你不会因为“我们有100%的代码覆盖率，现在我们的系统必须没有错误”的想法而自满。

不仅单元测试本身存在bug，在软件中隐藏bug，而且单元测试也不会测试应用程序的各个部分是否像预期的那样一起工作。如果您有一个web服务客户机和一个web服务，这两个单元都经过了测试，但是针对不同的规范(比如在编写服务之后更改了规范，客户端被写入了与服务实现不同的WSDL )，那么单元测试永远不会提醒您这一点。

您还需要适当的集成测试、回归测试、功能测试(系统是否实际实现了所需的功能，如果没有，它可能在技术上是正确的，但仍然是无用的)，可用性测试(如果它有效，但是非常简单，用户不按预期使用它，它仍然是一个无用的系统)。一切都是必需的，都有自己的位置，也不能靠自己来保证制度的正常运行。

当然，所有这些都取决于正确的书面、详细的、经过充分核实和签署的功能设计文件，并将其翻译成正确的技术设计文件。