我刚刚回头看过近期完成的项目，发现一个非常严重的问题。我花了大部分时间在测试代码上，重现“可能”导致代码错误的不同情况。如何减少花费在测试上的时间？
您是否有任何想法或经验可以分享如何减少测试所花费的时间，从而使开发更加顺畅？
我试着按照我所有代码的测试驱动的概念，但是我发现真的很难做到这一点，真的需要一些高级人员的帮助。
感谢
回复：所有
感谢以上这里的答案，最初我的问题是如何减少对一般性测试的时间，但现在的问题是下到如何写effecient自动化测试代码。
我会尽力提高自己的技巧，如何编写测试套装以缩短这部分时间。但是，我仍然真的在努力减少花在重现错误上的时间，例如，一个标准的博客项目将很容易重现这种情况可能导致的错误，但一个复杂的定制内部系统可能“永远不会“可以很容易地进行测试，值得吗？你对如何在这类项目上建立测试计划有什么想法吗？
感谢您的进一步解答。
测试驱动设计与测试（质量保证）无关。从一开始它的命名就很差。
这是关于具有机器可运行的假设和程序行为的规范，并由程序员在编程期间完成以确保假设是明确的。
由于这些任务必须在产品生命周期的某个阶段完成，因此这只是工作的转变。不管它多少有效率都是另一次的争论。
你指的是我不会称之为测试。拥有强大的TDD意味着测试阶段不必依赖于很大程度上的错误，这些错误在他们达到测试版本之前就会被捕获很长时间（因为他们具有良好规范的程序员经验，以及非TDD中的响应利益相关者环境）。
如果您认为前期测试（可运行规范）是一个严重的问题，我想这涉及到开发的相关阶段在时间和金钱方面会花费多少成本？
如果您正在高效地测试，那么花费大量时间进行测试本身并没有什么错误。请记住，测试驱动开发意味着首先编写（主要是自动化的）测试（如果您编写完整的测试套件，这可能需要很长时间）。运行测试不应该花费太多时间。
Subversion团队开发了一些pretty good test routines，通过自动化整个过程。
我已经开始自己使用这个过程，例如通过编写测试之前实现新功能。它运行良好，并通过整个编程过程生成一致的测试。
SQLite也有一个体面的测试系统，有一些very good documentation关于它是如何完成的。
这听起来像你的问题是你没有做自动测试。使用自动化单元和集成测试可以大大减少您花费在测试上的时间。
根据我对测试驱动开发的经验，在写出测试之后或者至少在编写完基本测试用例之后，节省时间会很快。这里的关键是你必须写我们的自动化测试。你的问题的方式使我相信你并没有真正写自动化测试。在编写测试之后，您可以稍后返回并更新测试，以覆盖以前未找到的错误（以便更好地进行回归测试），并且您可以轻松而快速地重构代码，在您大幅改变之后仍然按预期工作。
感谢你的答案被发现，是的，我没有写的测试适合于覆盖码的100％。因此，通过点击鼠标并在浏览器中查看仍然是测试我在上一个项目中编写的代码的首选。 – 2009-05-31 01:48:14
对于任何规模相当大的项目来说，最困难的事情之一就是设计底层构架和API。所有这些都暴露在单元测试的层面。如果您先编写测试，那么当您编写测试代码时，设计的这个方面会发生，而不是程序逻辑。这是通过增加代码可测试的工作量来实现的。一旦你有了测试，程序逻辑通常是非常明显的。
这就是说，似乎有一些有趣的automatic测试建设者在地平线上。
首先，这是很好的，你意识到你需要帮助 - 现在去找些:)
的想法是用测试来帮助你思考的代码应该做的事情，他们的一部分你的设计时间。
您还应该考虑代码的总体拥有成本。一个bug通过生产而不是先被修复的成本是多少？如果你在银行，是否有数字错误的严重含义？有时候，正确的东西只是需要时间。
感谢您的温柔回答。 – 2009-05-31 01:52:26
我想我明白了。在开发人员测试级别之上，您拥有客户测试级别，听起来就像在这个级别，您发现了很多错误。
对于您发现的每一个错误，您必须停下来，取下您的测试帽，放上您的复制帽，并找出精确的复制策略。然后你必须记录这个bug，或许把它放在一个bug跟踪系统中。然后你必须戴上测试帽。与此同时，你已经失去了正在进行的任何设置，并且失去了跟踪你所在的任何测试计划的位置。
现在 - 如果没有必要发生 - 如果你有很少的错误 - 你可以通过测试正确拉链，对吧？
GUI驾驶测试自动化将帮助解决这个问题值得怀疑。您将花费大量的时间记录和维护测试，而这些回归测试需要相当长的时间才能收回投资。开始时，使用GUI进行面向客户的测试，您会变得更慢。
所以（我提交），真正可以帮助的是开发活动中出现的更高/最初/代码质量。微观测试 - 也称为开发者测试或原始意义上的测试驱动开发 - 可能对此有所帮助。另一个可以帮助的是配对编程。
假设你不能抓别人来配对，我会花一个小时看看你的bug跟踪系统。我会看看过去的100个缺陷，并尝试将它们归类为根本原因。 “培训问题”不是一个原因，但“一个错误”可能是。
将它们分类并统计后，将它们放入电子表格并进行排序。无论发生什么根本原因，最常见的是您首先预防的根本原因。如果你真的想变得有趣，可以通过一些数字来增加根本原因，那就是它引起的疼痛量。 （例如：如果在这100个错误中，菜单上有30个错别字，容易修复，并且有10个难以重现的javascript错误，您可能首先要解决javascript问题。）
这个假设你可以对这些根本原因应用一些神奇的“修复”，但它值得一试。例如：IE6中的透明图标可能是因为IE6无法轻松处理.png文件。因此，有一个版本控制触发器在检入时拒绝.gif，并且问题得到解决。
我希望有帮助。
您写道：
“感谢上面这里的答案， 最初我的问题是如何 减少时间上一般的测试， 但现在的问题是下到如何 写高效自动化测试 代码“。
一个方法已经在多个实证研究中得到验证，能够极好地发挥作用以最大化测试效率，这是组合测试。在这种方法中，测试人员将确定应该测试什么样的东西（并将其输入到一个简单的工具中），该工具将识别如何测试应用程序。具体来说，该工具将生成测试用例，指定应在哪个测试脚本中执行哪些测试条件组合，以及每个测试脚本应执行的顺序。
例如，在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
非常诚实的回答并回答了我的问题。 – 2009-06-01 14:25:32