BDD，TDD，ATDD，看板和Scrum与瀑布方法到底有何不同？

#1 楼

我已经看到TDD / BDD / ATDD与Scrum / Kanban / Agile可以互换使用，因此混淆是可以理解的。以下是我对这些差异的看法：瀑布是一种软件开发方法，其中每种开发活动都在单独的阶段（需求收集，设计，开发，测试）进行。 ..）。通常，在完全了解并明确定义了软件要解决的问题的情况下，瀑布项目最为有效。满足该标准的软件项目并不多-导致问题的是未知的未知数。

敏捷是一种软件开发理念，旨在将精力更多地集中在所有开发活动同时进行的短周期上（尽管不在同一时间）项目的各个部分同时进行-发现新的需求后，团队将它们纳入他们的设计中，同时致力于开发和测试他们在先前周期中设计的区域。有许多敏捷方法，包括：Scrum，它着重于团队成员之间通过频繁的简短仪式进行持续的交流。我经常看到Scrum用作敏捷过程的框架，而看板板则用作与团队外部人员交流进度的主要工具。

看板板，专注于看板板（至少以我的经验）。董事会保留了迭代中商定的任务，团队成员选择任务以在工作时将其移至不同的状态列。
还有其他敏捷方法，但是Scrum / Kanban组合是较常见的变体之一。



TDD / BDD / ATDD是软件开发技术，尽管这三个方面通常都是团队敏捷方法的一部分，但是它可以用于任何方法中。



TDD是测试驱动的开发：其思想是先编写单元测试，然后编写足够的代码以使测试通过。纯TDD周期是编写一个失败的单元测试，然后编写足够的代码以通过测试。然后是第二个失败的单元测试，然后是足够的新代码通过了这两个测试。依此类推。

BDD是行为驱动的开发：该技术的运行水平比TDD略高，同时仍遵循编写测试，然后通过编码以通过测试的基本原理。 BDD通常是将使用“按时间给出”模式来描述测试的最低级别（例如“鉴于我已登录，当我单击“我的订单”链接时，我将被定向到“订单列表”页面”）。很难区分BDD和ATDD-这里的区别很细微。

ATDD-是接受测试驱动的开发：根据我的经验，此和BDD通常可以互换使用，尤其是当验收测试以“准时”模式表示（例如：“鉴于我是已登录的用户，当我进入“订单”时，我将看到系统中已完成的所有订单的列表） ，从最新到最旧的顺序排列。”）


使用的三种技术的融合并不罕见：被写为一个或多个用户接受测试（失败）
每个接受测试都分解为一个或多个行为测试（失败）。
每个行为测试都分解为一个或多个单元测试（表明失败）。
此时，编码开始，并且每个级别都进行迭代，直到所有用户接受测试都通过为止。

#2 楼

Kate的回答很好，但是我想花2美分来区分TDD / BDD / ATDD。

TDD首先编写测试，让这些测试推动应用程序的开发。这介绍了红色/绿色/重构的概念。基本过程是：


编写失败的测试
使应用程序代码通过测试
重构应用程序代码以实现可维护性，性能等。（同时保持测试绿色）

请注意，TDD是一个高级概念，可以应用于金字塔的任何级别的测试（单元，集成，验收）。

BDD是进行TDD的技术。您对测试进行框架设计，以便它们测试应用程序行为，而不是特定场景。这似乎有些细微差别，确实如此。这就是BDD与TDD和ATDD如此互换使用的原因。请考虑以下测试：

describe Calculator do
  it "returns 2 when I add 1 and 1" do
    expect(Calculator.add 1, 1).to eq 2
  end
end

该测试是什么？好吧，我们对其进行了框架设计，使其仅测试1 + 1 == 2。我们不是在测试行为，而是在测试特定的数据集。我们没有证明2 + 1 == 3。或99 + 1 = 100。

但是如果我们这样构造测试，该怎么办呢？证明1 + 1 == 2和6 + 1 == 7和1500 + 1 == 1501。

简而言之就是BDD。

BDD也是一个高级概念，可以应用于任何级别的测试金字塔。声明式的验收测试方法本质上是BDD。但是您可以进行命令式验收测试，而该命令验收测试与具体情况更为相关，并且本质上通常不需要BDD。

我认为单元测试应该是BDD。我发现通常是这样，尽管这种方式并不常见。

ATDD正在从业务的角度进行测试。我们不在乎操作方法，而在乎什么。

如果单元测试或集成测试与实现相关（API返回正确的状态代码），那么验收测试与结果相关（用户可以登录）。

ATDD正在接受验收测试的这一原则，使其自动化，并让这些测试推动应用程序的开发。因此，您可以看到TDD如何适合ATDD。当我与同事讨论它们的实现时，我认为定义它们以建立共同的基础会有所帮助。我的BDD并不总是与我的同事所指的BDD相同。 ATDD和（在较小程度上）TDD也是如此。

TDD是一个过程。 BDD和ATDD是用于执行TDD的技术。编写单元测试，然后进行编码以使该单元测试通过，这也是TDD。

但是TDD已成为最后一个示例的代名词，我认为这就是很多困惑的来源。

#3 楼

Waterfall方法和迭代方法（敏捷，Scrum等）之间的区别在于，Waterfall需要按照定义的顺序执行定义过程的每个步骤才能完成。通过一种迭代方法，您只需收集一些需求并对每个需求进行编码，一次完成一小部分问题，然后征求用户的反馈。

The Waterfall

在Waterfall中，您遵循严格的模式。您可以收集所有需求，然后进行分析，然后设计解决方案，编写解决方案，然后测试解决方案，然后部署解决方案。它起源于很久以前的物理世界的工程过程，并被转移到软件世界，因为它是一个众所周知的过程。

瀑布的问题Waterfall的主要问题是，如果不能很好地完成它，成本或质量都会受到影响。如果测试人员发现错误，则将其报告给编码人员。编码人员看了一下，可能会说“嗯，这是设计中的缺陷”，然后交给设计人员。设计师说：“嗯，这就是要求。”因此，他们回到了分析人员，等等，依此类推。他们确定需求，将确定的需求传递给设计者，由设计者修改设计，将其交给编码人员，等等。每个错误的修复成本都非常高。为了避免这种成本，Waterfall需要在每个步骤中全神贯注于每个细节。需求必须由设计人员，测试人员和利益相关者进行审查。必须审查设计，必须审查代码等。

这就是瀑布会导致质量下降的地方。如果测试人员将错误传递给编码人员，则编码人员可能会看着它并说：“要正确修复，这将需要进行较大的设计更改，或者我们可以在此处放置一个补丁。”管理层几乎总是说“打补丁，因为它比修复整个设计要快，而且我们有一个截止日期”。而且，无需花费很多补丁就能将灵活的设计变成易碎的产品。

Waterfall的另一个问题是用户缺乏持续的反馈。瀑布过程可能需要数月或数年。到产品完全交付时，团队可能已经对需求进行了不同的解释，并开发出与预期或期望完全不同的产品。否则该产品的市场可能已经改变，并且不再需要该产品。所有的工作都变成了沉没成本，从来没有带来一毛钱的价值。产品开发大大缩短。在诸如Scrum之类的某些方法中，迭代可以以周为单位进行定义。在其他情况下，迭代可以在几天，几小时甚至几分钟内完成。使用BDD收集需求，然后以功能测试的形式编写规格。开发人员的一个普遍抱怨是要求很差。在BDD中，由于无法编写测试，因此会立即发现一个较差的要求。因此，要求几乎在编写后就已确定。这样可以减少很多问题。

这些功能（行为）测试显然失败了，因为还没有编写任何代码通过这些测试。然后，开发人员只编写足以通过测试的代码（他们在较短的TDD周期内执行此操作，首先通过创建一个快速骨架，然后一次添加一部分功能来构建功能。）可能会发现规格中的缺陷或遗漏；修复它们通常和向涉众询问一个明确的问题，修复测试，然后修复该代码模块一样便宜。关键是反馈越快，进行正确纠正的成本就越便宜。

测试驱动开发然后通过三个步骤来构建代码：红色，绿色，重构。当他们开始开发时，他们会编写失败的测试（失败的测试显示为红色）。通过首先编写测试的行为，开发人员必须考虑他们正在编写的模块的接口，以及如何使其易于测试。无状态逻辑比有状态逻辑更易于测试，因此它们有动力编写无状态代码，将其代码分为服务对象和值对象。易于测试的代码是模块化且易于使用的代码。这提供了良好设计的第一步。然后，他们编写足够的代码以通过测试（绿色）。现在，他们可以放心地重构代码了。他们重构刚编写的代码，以消除重复并遵守SOLID设计原则。重构的行为赋予了与模块化相关的良好品质：紧密的内聚和松散的耦合，这使得代码模块易于使用和重用。这些测试为开发人员提供了不断的证明，证明他们所做的更改无害。

瀑布倒置了

TDD颠倒了瀑布模型：首先测试需求，然后测试代码，然后编写代码，最后为代码赋予良好的设计。因为该团队生产的功能很少，但始终都经过充分测试，因此质量起步很高，并且保持很高水平。因为在重构过程中遵循设计原则，所以代码是模块化的，灵活的和可重用的。而且，由于利益相关者不断参与审查和使用每个小小的功能，因此他们可以随时进行更改而不会产生巨大的成本。产品对吗？”以及“我们正在构建合适的产品吗？”

迭代问题

这就是迭代方法的局限性：满足具有特定功能列表的最后期限。产品负责人需要看到团队正在朝着一个目标迈进，他们甚至可以衡量进度，但是无法非常准确地提前预测日期X上的实际功能。

当迭代团队必须与外部团队交互时，这也会成为问题。如果两个团队都敏捷，他们将了解彼此的问题；但是，如果一个团队是硬件团队或服务组织，则其灵活性通常是无法控制的。这可能会导致摩擦，因此必须谨慎处理这种相互作用。乘积或迭代。支持Waterfall的观点是它已经成功使用了很长时间。有些人真的很擅长瀑布。经理和高管必须处理预算和截止日期，并且瀑布式步骤很容易理解。

迭代方法产生更高质量的产品并不直观；被告知“我们将于一月初为您提供某种产品，我们可以向您保证它会完美地工作，但它可能不是您今天想到的产品”，这也让您感到不舒服。这些辩论一直在进行，但无助于回答选择哪种方法的问题。事实证明，辩论集中在错误的事情上。有一个简单的测试可以确定是应该使用瀑布式构建还是迭代式构建产品，从而衡量部署成本。

部署成本

考虑一个网站。您可以通过单击鼠标来部署网站的新版本-价格便宜。考虑可以通过向应用商店发送新版本来部署的智能手机应用-同样相当便宜。甚至传统的计算机程序都可以通过Web将更新传递给客户端。

现在考虑部署困难的客户端，例如运行闹钟的软件。您可以在办公室的舒适环境中进行所有想要的迭代，但是一旦将这些时钟订单发送到离岸工厂，并且10,000个时钟正坐在码头上的运输容器中或已交付到货架，则为时已晚来更新他们的软件。硬件的生产和安装使这些步骤的迭代过于昂贵。

然后就不可能迭代产品。任何影响健康或安全的事物都有政府或行业机构强制要求的某些设计和测试标准；当前的标准不允许采用迭代方法进行设计。您无法交付5％的空中交通管制系统，并期望飞机保持安全飞行。

通过迭代混合瀑布

回到闹钟示例，很诱人的是在产品的软件或固件部分上使用迭代开发以确保高质量，并使用Waterfall有效地管理硬件的生产。这种混合必须谨慎进行。迭代方法不能保证按时完成任务，但是工厂，组件订单，安装人员和货运通常是提前几个月预定的，并且如果没有大笔成本也不能延迟。在这些情况下，您可能必须考虑自定义方法。也许可以将硬件设计为灵活的-产品1.0版上的虚拟空白按钮可能会隐藏2.0版随附的缺少的SuperWakeyAlarm功能。也许打印出来的盒子没有缺少功能，但是当出厂时，盒子会得到“新！改进！”。

结论

通常，迭代方法比Waterfall更快，更便宜地提供了更高质量的软件；但并非每个项目都适合迭代产品管理。

#4 楼

看板和Scrum是敏捷过程框架，因此与瀑布项目的较长单独阶段相比，迭代开发周期短。敏捷项目的重点是在较短的迭代中获得可用的产品，每次迭代都应交付一个可部署的产品。它们是设计需求和测试案例的技术，可以自动化。它们经常用于敏捷软件开发中，因为它们为正在开发的需求和代码提供了快速的反馈周期。

因为敏捷开发没有单独的测试阶段，所以重要的是，即使不是全部，大多数测试也是自动化。应用BDD或TDD可确保每个新开发都具有自动测试覆盖范围，并且行为在迭代之后得到安全保护。这就是为什么这些实践在敏捷开发中比在瀑布开发中更重要的原因。
我将阅读《敏捷艺术》一书，尽管它描述了另一种敏捷风味极限编程。它清楚地描述了诸如TDD之类的技术的使用方式以及使用方式。另一个不错的读物是敏捷测试。