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