我回顾了最近几乎完成的项目并发现了一个非常严重的问题。我花了大部分时间来测试代码，重现不同情况“可能”导致代码错误。
您是否有任何想法或经验可以分享如何减少测试所花费的时间，从而使开发更加顺畅？
我尝试按照我所有代码的测试驱动概念，但我发现很难实现这一点，真的需要一些资深人士的帮助。
由于
Re：全部
感谢上面的答案，最初我的问题是如何减少一般测试的时间，但现在，问题在于如何编写有效的自动化测试代码。
我将尝试提高我的技能，如何编写测试套装以减少这部分时间。
但是，我仍然在努力减少如何减少重现错误的时间，例如，标准的博客项目很容易重现情况可能会导致错误，但是复杂的定制内部系统可能“永远不会”可以轻松测试，是否值得？您对如何在此类项目上构建测试计划有任何想法吗？
感谢您提供进一步的答案。
答案 0 :(得分：6)
测试驱动设计与测试（质量保证）无关。它从一开始就被命名为。
这是关于机器可运行的假设和程序行为规范，并且是程序员在编程期间完成的，以确保假设是明确的。
由于这些任务必须在产品生命周期的某个阶段完成，这只是工作的转变。是否效率更高或更低是另一次辩论。
你所指的我不会打电话给测试。拥有强大的TDD确实意味着测试阶段不必依赖于大量的错误，这些错误会在他们达到测试版本之前很久就会被捕获（因为他们与经验丰富的程序员在非TDD中具有良好的规范和响应的利益相关者环境）。
如果您认为前期测试（可运行的规范）是一个严重的问题，我想这可归结为预计开发的相对阶段需要花费多少时间和金钱？
答案 1 :(得分：3)
我想我明白了。在开发人员测试级别之上，您拥有客户测试级别，听起来，在那个级别，您发现了很多错误。
对于你找到的每一个虫子，你必须停下来，脱掉你的测试帽，戴上你的复制帽，并找出一个精确的复制策略。然后你必须记录这个bug，或者把它放在一个bug跟踪系统中。然后你必须戴上测试帽。与此同时，您已经失去了正在进行的任何设置，并且无法跟踪您所遵循的任何测试计划。
现在 - 如果不是必须发生 - 如果你有很少的错误 - 你可以直接进行测试，对吗？
GUI驱动测试自动化将有助于解决这个问题，这是值得怀疑的。您将花费大量时间记录和维护测试，这些回归测试将花费相当长的时间来返回投资。最初，使用GUI驱动面向客户的测试会慢得多。
所以（我提交）可能真正有用的是开发活动中出现的更高/初始/代码质量。微测试 - 也称为原始意义上的开发人员测试或测试驱动开发 - 可能真的有助于此。另一件可以帮助的事情是结对编程。
假设你不能抓住别人配对，我会花一个小时看你的bug追踪系统。我会看看过去的100个缺陷，并尝试将它们分类为根本原因。 “培训问题”不是原因，但可能是“一个错误”。
对它们进行分类和计数后，将它们放入电子表格并进行排序。无论出现什么根本原因，最常见的是您首先预防的根本原因。如果你真的想得到花哨的话，可以将根本原因乘以一些数字，这是它引起的痛苦程度。 （例如：如果在那100个错误中你在菜单上有30个拼写错误，这很容易修复，10个难以重现的javascript错误，你可能想先修复javascript问题。）
这假设您可以对每个根本原因应用一些神奇的“修复”，但值得一试。例如：IE6中的透明图标可能是因为IE6无法轻松处理.png文件。因此，有一个版本控制触发器在签入时拒绝.gif，并且问题已修复。
我希望有所帮助。
答案 2 :(得分：2)
Subversion团队通过自动化整个过程开发了一些pretty good test routines。
我自己也开始使用这个过程，例如在实现新功能之前编写测试。它运行良好，并在整个编程过程中生成一致的测试。
SQLite还有一个不错的测试系统，其中有一些very good documentation关于它是如何完成的。
答案 3 :(得分：2)
根据我在测试驱动开发方面的经验，在您完成测试后，或者至少在编写基本测试用例之后，节省的时间很长。这里的关键是你实际上必须编写我们的自动化测试。你提出问题的方式让我相信你实际上并没有写自动化测试。编写测试后，您可以轻松返回并更新测试以涵盖以前未找到的错误（以便进行更好的回归测试），并且您可以轻松且相对快速地重构代码，并且易于编写代码。在你彻底改变之后仍然按预期工作。
答案 4 :(得分：2)
您写道：
“感谢上面的答案， 最初我的问题是如何 减少一般测试的时间， 但现在，问题在于如何解决 编写高效的自动化测试 代码“。
在多项实证研究中已经证明，为了最大限度地提高测试效率而已经证明的一种方法是组合测试。在这种方法中，测试人员将识别应测试的东西（并将其输入到一个简单的工具中），该工具将确定如何测试应用程序。具体来说，该工具将生成测试用例，指定应在哪个测试脚本中执行测试条件的组合以及每个测试脚本应在其中执行的顺序。
例如，在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。它包含屏幕截图，并解释了我们的工具如何通过识别最大化覆盖范围的测试子集来提高测试效率。
我们的Hexawise测试用例生成器的免费版本也可以在www.hexawise.com/users/new
找到答案 5 :(得分：1)
如果您正在高效地测试，那么花费大量时间进行测试并没有什么本质上的错误。请记住，测试驱动的开发意味着首先编写（主要是自动化的）测试（如果你编写一个完整的测试套件，这可能需要很长时间）。运行测试不应该花费太多时间。
答案 6 :(得分：1)
听起来你的问题是你没有做自动测试。使用自动化单元和集成测试可以大大减少您花在测试上的时间。
答案 7 :(得分：1)
首先，你认识到你需要帮助是很好的 - 现在去找一些：）
我们的想法是使用测试来帮助您思考代码应该做什么，它们是您设计时间的一部分。
您还应该考虑代码的总拥有成本。将bug导入生产而不是先修复的成本是多少？如果你在银行，是否会对数字错误产生严重影响？有时候，正确的东西需要时间。
答案 8 :(得分：0)
任何具有重要规模的项目最难的事情之一就是设计基础架构和API。所有这些都暴露在单元测试的水平上。如果您首先编写测试，那么设计的那个方面就会在编写测试时发生，而不是程序逻辑。这使得代码可测试的额外努力更加复杂。一旦你完成测试，程序逻辑通常很明显。
话虽如此，似乎有一些有趣的automatic测试建设者即将出现。