测试驱动和行为驱动开发是否属于“验证”范畴？

Question

在大学里，我们被介绍了“验证”和“验证”这两个术语。定义可以是小结，如下所示：

• 验证检查所定义的规范和需求是否满足客户的实际需求。(我们生产正确的产品吗？)
• 验证正在构建的软件是否符合所定义的规范和需求。(我们生产的产品正确吗？)

我无意中发现了测试驱动开发和行为驱动开发这两个术语。在阅读它们时，我试图将这两者与我前面提到的知识联系起来。

说TDD和BDD被归类为“验证”是一个有效的概括吗？

因为我的理解是，这两种方法的重点是检查软件而不是需求。或者说，有什么地方我忽略了，反对这样严格的分类？

Answer 1

说TDD和BDD被归类为“验证”是一个有效的概括吗？

不是的。TDD和BDD以特定的方式将验证过程合并到开发过程中，但它们不仅仅是这样，因此将TDD和BDD本身归类为验证是不正确的。

TDD和BDD验证过程也不是这样，但区别于BDD和TDD的一件事是将验证--类似于开发时间表中的事情--推高，并至少在某种程度上使用用于验证的相同方法来处理，比如类似于验证的目的。

验证和验证是质量控制的不同方面。它们不是发展方法的类别。软件开发工作通常都涉及到两者，而不管所使用的开发方法如何。验证通常与日常的开发工作紧密结合在一起，但是如果在验证过程中发现了缺陷，那么完全有理由认为这也会反馈到开发过程中，可能会引发对正在执行的验证的添加或更新。

Answer 2

说TDD和BDD被归类为“验证”是一个有效的概括吗？

是。所有以客户规范为输入(并以此作为事实)的测试技术都属于验证的范畴。

验证只能在用户验收测试或类似的情况下进行，在这种情况下，实际的客户(最好是最终用户)可以看到产品的动作和/或与其交互。只有顾客才能告诉你，如果你制造了正确的产品。

Answer 3

测试是一种验证活动:它们表明软件系统表现出某种行为。

然而，创建测试用例的行为有时会有类似于验证的方面。TDD和BDD不仅仅是对软件进行测试，也是为了找出要构建什么。它们是一种发现需求的技术，测试套件成为对需求的可执行描述。

例如，TDD红绿重构循环是从我们考虑一个新的软件原子需求开始的，然后为这个需求编写一个测试用例，然后实现它。严格地说，这不允许我们对需求本身做出任何声明。然而，编写测试用例的行为迫使我们想象，如果软件系统满足了这一需求，我们将如何使用它。这有时会显示某些功能不合适，例如，它是多余的，或者它与设计的其他方面相冲突。

与需求的连接在BDD实践中更为明显，因为BDD的目标是捕获业务级别的需求。例如，描述示例场景不是用代码，而是用半形式化的Gherkin语法，可以方便开发人员和主题专家之间的对话，这样中小企业就可以指出场景缺少相关细节。