测试驱动开发的相对成本效率

Question

我想知道资源规划对软件项目的总体影响是什么，在那里，项目的需求和设计是由自动化验收测试和单元测试驱动的，而不是更“传统”的软件开发方法。

根据您的经验，在TDD下完成软件项目对资源需求的总体影响是什么，而不是更“传统”的开发方法？在我看来，质量的提高和不确定性的减少是不言而喻的，因为测试是提前完成的，但要求预先进行测试似乎需要更多的开发人员时间来完成。开发工作增加了多少，还是由于预先消除了bug而减少了？

客户还需要付出多少努力？他们是否必须改变他们与项目相关的方式，特别是如果他们习惯于预先进行大型设计的话？顾客所需的小时数是增加了，还是实际减少了？

我可以想象，在TDD项目开始时(因为没有软件开发计划)，在迭代的TDD过程中，时间估计会非常模糊。在一个项目中，比如20%的项目中，是否有足够的信心增长，从而最终能够向客户提供一个或多或少稳定的时间和金钱估算？

注:我不是在寻找主观的意见或理论，所以请不要猜测。我正在寻找更多的真实世界的经验在TDD。

Answer 1

首先需要说明的是，TDD并不一定会提高软件的质量(从用户的角度来看)。这不是一颗银弹。这不是灵丹妙药。减少bug的数量并不是我们做TDD的原因。

TDD之所以完成，主要是因为它带来了更好的代码。更具体地说，TDD会导致更容易更改的代码。

您是否希望使用TDD更多地取决于您的项目目标。这是一个短期的咨询项目吗？你需要在直播后支持这个项目吗？这是一个琐碎的项目吗？在这种情况下，增加的开销可能不值得。

然而，我的经验是，TDD的价值主张随着项目所涉及的时间和资源的线性增长而呈指数增长。

良好的单元测试具有以下优点：

1. 单元测试提醒开发人员注意意外的副作用。
2. 单元测试允许在旧的、成熟的系统上快速开发新功能。
3. 单元测试使新开发人员能够更快、更准确地理解代码。

TDD的一个副作用可能是but较少，但不幸的是，根据我的经验，大多数but(特别是最讨厌的but)通常是由不明确或糟糕的需求引起的，或者不一定会被第一轮单元测试所涵盖。

概括如下：

第1版的开发可能要慢一些。第2-10版的开发将更快.

Answer 2

制作软件中有一章是关于测试驱动开发的，它引用了论文在此讨论。

案例研究由微软的三个开发团队和IBM的一个采用TDD的开发团队进行。案例研究结果表明，与未采用TDD实践的同类项目相比，四种产品的预释放缺陷密度降低了40% ~ 90%。主观上，在采用TDD之后，团队的初始开发时间增加了15-35%。

当然，这些结果是否可以概括到您的情况，TDD的支持者会认为这是显而易见的，而TDD的反对者则认为这是不正确的。

Answer 3

资源需求

根据您的经验，在TDD下完成软件项目对资源需求的总体影响是什么，而不是更“传统”的开发方法？

根据我的经验，通过预先定义明确的验收标准，然后编写测试，可以立即降低要求预先测试的成本。不仅前端测试的成本降低了，我还发现它通常会加速整体开发。尽管这些速度的提高可能会被糟糕的项目定义或不断变化的需求所抹杀。然而，我们仍然能够在不受严重影响的情况下对这种变化作出相当好的反应。在以下情况下，ATDD还大大减少了开发人员通过其自动化测试套件来验证正确的系统行为的努力：

• 大型再因素
• 平台/软件包升级
• 平台迁移
• 工具链升级

这是假设一个团队熟悉所涉及的过程和实践。

客户参与

客户还需要付出多少努力？

他们必须不断地更多地参与进来。我已经看到了前期投资的大幅减少，但更大的需求仍在继续。我还没有测量，但我相当肯定，这对客户来说是一项更大的时间投资。

然而，我发现在5次左右的演示之后，客户关系有了很大的改善，他们看到他们的软件慢慢成形。随着时间的发展，客户的时间承诺会逐渐减少，每个人都会习惯这个过程和所涉及的期望。

项目估计

我可以想象，在TDD项目开始时(因为没有软件开发计划)，在迭代的TDD过程中，时间估计会非常模糊。

我发现，这通常是一个问题，询问是如何明确的，以及技术主管(S)是否能够将项目(包括卡片估计)显示出来。假设项目进行得很好，并且有一个合理的速度、平均值和标准偏差，我们发现很容易得到一个不错的估计。显然，项目越大，不确定性就越大，这就是为什么我通常会将一个大型项目分解为一个小项目，并承诺以后继续进行。一旦你和客户建立了良好的关系，这就容易多了。

例如：

我的团队的“冲刺”是一个星期，我们有一个跑步平均值和性病。过去14周的偏差。如果这个项目是120分，我们有一个平均25和一个性病。6然后估计项目完成情况的偏差是：

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

我们用的是2性病。我们95%置信度估计的偏差法则。在实践中，我们通常在第一个std下完成项目。偏离，但超出了我们的平均水平。这通常是由于改进，改变等。