让我们详细说明，作为开发人员，我们都知道我们应该测试我们的代码。我们应该编写单元测试，但这通常是我们发现没有时间时跳过的第一步。作为团队领导或管理者我们都知道测试是必要的，但是当截止日期临近时，我们往往会减少测试，而将更多的精力放在编码上。这样看来，测试场似乎很紧张。我们都知道测试对我们有好处，但是一旦项目有压力我们就会停止测试。我们为什么要测试？EdsgerWDijkstra说：测试可以用来发现显性缺陷（bugs），但它不能揭示潜在的软件缺陷（bugs）。这意味着测试不能绝对保证您的软件没有缺陷（错误），但它肯定有帮助。我们也可以换句话说，如果我们不测试我们几乎可以保证我们的软件会有缺陷（bug），除非我们写的是像“helloworld!”这样简单的东西。但即使是这样一个简单的程序，您也会进行测试，因为一旦您输入了代码，您就会好奇它的输出是否真的是“helloworld!”。这是第一种测试形式，也是我们一直在做的：手动测试。我们编写一个程序，然后启动它来检查结果。对于一个简单的“helloworld”，这可能就足够了，但对于更复杂的程序，这可能会导致时间的浪费，这是对已知行为结果集的手动重复。这不就是我们发明计算机的原因吗？这对“helloworld”来说没什么大不了的，但是当你创建一个web应用程序时，测试场景是翻十次页面，点击一些按钮，输入很多表格（正确）数据然后测试一些特定的条件，和你可以看到自动化可以节省很多时间。如果你可以通过测试运行器直接执行你要测试的功能，而不是花半分钟手动执行那个功能，你会节省很多时间！但这也意味着我们需要更多的编程，而更多的编程意味着更多的时间和精力。所以这将花费更多时间，您的项目可能会稍后完成。也许不一定让我们创建一个控制台应用程序来计算两个整数的***公约数(GCD)。有很多方法可以解决这个问题，但为了简单起见，我们将1.输入两个整数2.无论其算法如何，计算GCD3。显示输出让我们来看看正常的开发周期。我们通常写一个main()函数，得到两个整数，调用一个函数计算GCD，然后显示结果。测试。在您的控制台中键入2个整数会花费一些时间，如果您需要多次重复您的代码，这将变得非常无聊。也很容易在控制台应用程序中输入错误并导致程序崩溃。这意味着您必须重新启动程序，输入两位数字，然后再次验证结果。请记住，我们讨论的是一个控制台应用程序，它只需要两个输入值，不需要点击（在Web应用程序中），正如我们所见，这需要一些时间。然后，我们可能想要测试更多的值，这意味着重新启动程序、进入两位数（正确）并进行测试。..所以我们即使看到了也不会马上去做，因为太费时间了。边缘情况将被遗忘，错误只会在生产中被发现！此外，当我们更改某些内容时，我们需要再次（手动）运行所有测试，使用遗忘的或使用快捷键进行高风险测试。在那里，将不会跟踪我们的测试工作。在整个测试过程中不要写入日志文件，除非你增加了你所做的事情列表（手动）。负反馈循环通常，当项目延迟时（无论出于何种原因），很容易陷入负反馈循环。有时我们决定跳过先写测试代码，这导致了下图所示的情况：项目延迟，导致我们不得不写更多的代码。所以与其“浪费时间”不停地测试代码，还不如不停地开发项目。这样做的结果是代码质量进一步下降，最终（迟早）导致返工。返工往往在最有限的时间内变得紧急（有人称这种现象为“墨菲是个乐观主义者！”）。事实上，返工不会改变任何东西，现在项目只会进一步推迟。奇怪的是，我们编写的代码越多，我们的项目完成的就越晚。一个常见的反应是让更多的开发人员参与该项目，但这只会加剧负面反馈循环。如果项目缺乏测试，用户通常会在验收和生产环境中发现很多错误，这会迅速降低用户对项目的信任度，从而产生负面反馈。这种反馈传递给（过度劳累的）开发人员，导致开发人员“疲劳”。结果是开发人员的工作积极性降低，开发人员离开，......，项目进一步延迟。打破消极循环我想你已经发现有办法解决这种现象。让我们描绘一个不同的场景：我们可以从一个理想的计划开始“项目将按时完成”。我们开发代码，然后立即对其进行测试。测试是自动化的（编码的），因此我们可以轻松高效地执行它们。我们将开发和测试紧密结合，每个开发和测试周期都可以非常快速地执行。在开发测试周期结束时，我们可以确信代码质量很高，因为它已经通过了测试。用户继续对我们有高度的信任，因为发现的错误更少。即使他们发现了一个错误（这仍然是可能的），我们也可以扩充我们的测试集以避免相关错误的再次发生。如果这种情况继续下去，将不再需要返工，项目必须继续进行。如果我们的项目被推迟，我们将需要一些时间来采用这种方法。可能需要冻结功能。停止开发新代码并为最严重的（恼人的-明确的-昂贵的）缺陷编写测试。在项目延迟时为整个代码库编写测试是不可行的，只针对其中的某些部分，不要浪费你的时间。但是记住其他部分还是需要写测试的。在这种情况下，我会确定最严重的问题（确定优先级）并为它们编写测试。那么“快速”更改代码就变得更容易了，而且您可以确定在更改其他部分时不会出错。可以非常频繁地执行自动化测试，从而降低错误再次出现的风险。好的，现在是时候有效地加强我们的项目了。以上通常需要代码重构以使其可测试。我会在另一篇文章中介绍。总结在大多数项目中，测试和编码之间存在平衡。但是我希望大家能够明白，测试其实是一个项目的加速器，而不是浪费时间。在下一篇文章中，我将带你走进测试驱动开发的领域，你会发现你可以变得更有效率！测试愉快！
