我刚刚回顾了最近即将完成的项目，发现了一个非常严重的问题。我将大部分时间都花在测试代码上，重现“可能”导致代码错误的不同情况。
您有什么想法或经验可以分享，如何减少测试时间，从而使开发更加顺利？
我尝试对我的所有代码都遵循测试驱动的概念，但我发现很难做到这一点，真的需要这里的资深人士的帮助。
谢谢
回复：全部
感谢上面的回答，最初我的问题是如何减少一般测试的时间，但现在问题在于如何编写高效的自动化测试代码。
我会努力提高自己编写测试服的技能，以减少这部分时间。
但是，我仍然很纠结如何减少重现错误所花费的时间，例如，一个标准的博客项目很容易重现可能导致错误的情况，但复杂的定制内部系统可能“永远不会”可以很容易地测试出来，值得吗？您对如何在此类项目上制定测试计划有任何想法吗？
仍然感谢您的进一步回答。
【问题讨论】：
标签： unit-testing testing tdd functional-testing
测试驱动设计与测试无关（质量保证）。从一开始它的名字就很糟糕。
这是关于程序行为的机器可运行假设和规范，由程序员在编程期间完成，以确保假设是明确的。
由于这些任务必须在产品生命周期的某个时间点完成，这只是工作的转变。它的效率更高或更低是另一个时间的争论。
你所说的我不会称之为测试。拥有强大的 TDD 确实意味着不必过度依赖测试阶段来解决在测试构建之前很久就会被捕获的错误（因为在非 TDD 中有经验丰富的程序员具有良好的规范和响应式利益相关者）环境）。
如果您认为前期测试（可运行规范）是一个严重的问题，我想这归结为相关的开发阶段预计会花费多少时间和金钱？
【讨论】：
我想我明白了。在开发人员测试级别之上，您有客户测试级别，听起来，在那个级别，您会发现很多错误。
对于您发现的每一个错误，您都必须停下来，摘下测试帽，戴上重现帽，并找出精确的重现策略。然后你必须记录错误，也许把它放在错误跟踪系统中。然后你必须戴上测试帽。与此同时，您已经丢失了您正在处理的任何设置，并且忘记了您在遵循的任何测试计划中所处的位置。
现在 - 如果这不是必须发生的 - 如果你的 bug 很少 - 你可以顺利通过测试，对吧？
GUI 驾驶测试自动化是否有助于解决这个问题值得怀疑。您将花费大量时间记录和维护测试，而这些回归测试将花费大量时间来收回投资。最初，使用 GUI 驱动的面向客户的测试会慢得多。
因此（我认为）真正有帮助的是开发活动带来的更高/initial/ 代码质量。微测试——在最初的意义上也称为开发人员测试或测试驱动开发——可能真的有帮助。另一件可以帮助的事情是结对编程。
假设您不能找其他人配对，我会花一个小时查看您的错误跟踪系统。我会查看过去的 100 个缺陷，并尝试将它们归类为根本原因。 “培训问题”不是原因，但“因一个错误而关闭”可能是原因。
对它们进行分类和计数后，将它们放入电子表格并排序。最常发生的根本原因是您首先预防的根本原因。如果您真的想变得花哨，请将根本原因乘以某个数字，即它引起的疼痛量。 （例如：如果在这 100 个错误中，您在菜单上有 30 个拼写错误，很容易修复，还有 10 个难以重现的 javascript 错误，您可能需要先修复 javascript 问题。）
这假设您可以对每个根本原因应用一些神奇的“修复”，但值得一试。例如： IE6 中的透明图标可能是因为 IE6 无法轻松处理 .png 文件。所以有一个版本控制触发器在签入时拒绝 .gif，问题就解决了。
希望对你有帮助。
【讨论】：
Subversion 团队通过自动化整个过程开发了一些pretty good test routines。
我自己已经开始使用这个过程，例如在实现新功能之前编写测试。它运行良好，并在整个编程过程中生成一致的测试。
SQLite 也有一个不错的测试系统，其中包含一些关于它是如何完成的 very good documentation。
【讨论】：
根据我在测试驱动开发方面的经验，在您编写完测试之后，或者至少在您编写了基本测试用例之后，可以节省大量时间。这里的关键是您实际上必须编写我们的自动化测试。您提出问题的方式让我相信您实际上并没有编写自动化测试。编写完测试后，您可以轻松地稍后返回并更新测试以覆盖他们以前没有发现的错误（以获得更好的回归测试），并且您可以轻松且相对快速地重构您的代码，并且放心，代码将在您进行了重大更改后仍然可以按预期工作。
【讨论】：
你写的：
“感谢楼上的回答， 最初我的问题是如何 减少一般测试的时间， 但现在，问题在于如何 编写高效的自动化测试 代码。”
已在多项实证研究中证明可以非常有效地最大限度地提高测试效率的一种方法是组合测试。在这种方法中，测试人员将确定应该测试哪些类型的事物（并将其输入到一个简单的工具中），并且该工具将确定如何测试应用程序。具体来说，该工具将生成测试用例，指定应该在哪个测试脚本中执行哪些测试条件组合以及每个测试脚本应该执行的顺序。
例如，在August, 2009 IEEE Computer article I co-wrote with Dr. Rick Kuhn, Dr. Raghu Kacker, and Dr. Jeff Lei 中，我们重点介绍了我领导的 10 个项目研究，其中一组测试人员使用他们的标准测试设计方法，另一组测试人员测试相同的应用程序，使用组合测试用例生成器为他们确定测试用例。使用组合测试用例生成器的团队平均每个测试人员每小时发现的缺陷数量是其两倍以上。这是效率的有力证据。此外，组合测试人员发现的缺陷总体上增加了 13%。这是质量/彻底性的有力证据。
这些结果并不罕见。有关此方法的更多信息，请参见 http://www.combinatorialtesting.com/clear-introductions-1 和我们的工具概述 here。它包含屏幕截图和说明，说明我们的工具如何通过识别最大化覆盖率的测试子集来提高测试效率。
您还可以在www.hexawise.com/users/new 找到我们的 Hexawise 测试用例生成器的免费版本
【讨论】：
如果您进行有效的测试，那么花费大量时间进行测试本身并没有错。请记住，测试驱动开发意味着首先编写（大部分是自动化的）测试（如果您编写完整的测试套件，这可能需要很长时间）。运行测试应该不会花费太多时间。
【讨论】：
听起来您的问题是您没有进行自动测试。使用自动化单元和集成测试可以大大减少您花费在测试上的时间。
【讨论】：
首先，很高兴您认识到自己需要帮助——现在去找一些帮助吧:)
我们的想法是使用测试来帮助您思考代码应该做什么，它们是您设计时间的一部分。
您还应该考虑代码的总拥有成本。一个错误进入生产环境而不是首先修复的成本是多少？如果您在银行，弄错数字是否有严重影响？有时，正确的东西只是需要时间。
【讨论】：
对于任何大型项目，最困难的事情之一就是设计底层架构和 API。所有这些都暴露在单元测试级别。如果您首先编写测试，那么设计的这方面会在您编写测试代码时发生，而不是程序逻辑。使代码可测试的额外努力使这更加复杂。完成测试后，程序逻辑通常非常明显。
话虽如此，似乎有一些有趣的automatic 测试构建器即将出现。
【讨论】：