问只有在敏捷软件开发中必要时才进行测试:好的还是坏的？

EN

我的问题是:当涉及到测试，即创建测试用例，并且只在必要时进行测试，或者这是一个糟糕的想法，同样的方法可以应用吗？

我不认为必要是一个好的选择在这里，无论你说的是测试还是特性。通常情况下，特性没有添加到软件中是因为它们是必要的，而是因为它们是有用的、有价值的或可取的。添加特性是因为它们通过一些对涉众很重要的度量来使产品更好。

考试也是如此，而且在更大程度上也是如此。测试与正在测试的产品是分开的，因此它们根本不直接影响它的功能，而且它们对产品的操作当然是不必要的。测试只是帮助开发人员和其他涉众保持一致质量水平的工具。测试可以帮助确保产品满足需求；它们可以检测失败；它们可以节省时间和金钱；等等。简而言之，测试通常是有用的、有价值的和可取的，即使它们实际上并不是必需的。

敏捷开发的思想是构建一个最小可行的产品，然后在此基础上迭代，以改进它，无论涉众决定哪个方向是最重要的。您可以将相同的理念应用于测试:从一组基本的测试开始，这些测试会给您带来最大的好处，然后在最大效益的方向上进行迭代改进。

通常，测试将与新功能并行开发，因为测试在开发过程中可能是一个有用的工具。例如，敏捷开发中的一个重要思想是对要完成的任务的含义有一个共同的理解，而测试是确定已完成任务的定义并证明您已经满足了需求的一种方法。但是测试也可以稍后开发--也许是为了演示一个bug，或者是为了增强人们对该产品一贯行为的信心。

请注意，作为一名测试人员，我有偏见。

我要说的是，至少在开发过程的早期建立一个基本的测试计划是非常重要的，测试人员应该参与新特性的讨论，以帮助在实现如何将这些特性添加到测试计划方面处于领先地位。

越早开始测试，就越早捕获那些看起来像边缘案例的bug，但几千行代码后来变得很难找到猛犸象。如果这些问题是孤立的，而不是连接到其他方法、对象或整个特性，则更容易解决这些问题。

一个务实的回答：

在开发新特性时，TDD (测试驱动开发)可以加速开发：

• 单独开发(使用单元测试)技术功能。
• 不是每一个次要的方法，也不是高度集成的，而是像容易合并的独立方面。与其他编码方法一样，实际的非测试代码所要求的小型重新设计将需要重写测试。
• 然后编写非测试代码。
• 并将单元测试添加为API /用例示例。
• 用测试完成高级代码。用例应该包括边界案例，错误也包括在内。这些单元测试最好是在最后进行，以不妨碍开发的动力。不过，我们不应忘记他们。

这使得一些低级别方面的方法没有经过测试。然而，高级用例很有可能已经涵盖了这些方面的功能测试。

最后但并非最不重要的一点:如果使用IntegrationBuildwith如Jenkins，那么像SonarQube这样的代码分析工具将警告缺少的测试覆盖率。那么，人们可能应该任意地接受85%的覆盖率作为“最佳”性能/成本比，或者以次优的方式工作，并进行全面的测试。

概述：

• 由于单元测试是没有人喜欢的工作，测试驱动的开发可以减轻一些高耸的工作，并允许快速的结果。
• TDD应仅限于基本功能。
• 在几个层上测试相同代码的单元测试实际上是多余的IMHO。