HTML CSS JAVASCRIPT PYTHON PYTHON2 JAVA C C++ C# SQL Excel Linux AI BOOTSTRAP PHP 教程库 参考手册 技术文章 测验 练习 HOWTO FAQ
❮ 上一节 下一节 ❯

BDD - 测试驱动开发

当您查看有关行为驱动开发的任何参考资料时，您会发现诸如"BDD 源自 TDD"、"BDD 和 TDD"之类的短语的用法。 要知道BDD是怎么产生的，为什么说它是从TDD衍生出来的，什么是BDD和TDD，就得对TDD有一定的了解。

为什么要测试?

首先，让我们了解测试的基础知识。 测试的目的是确保所构建的系统按预期工作。 考虑以下示例。

测试

因此，根据经验，我们了解到，在缺陷出现时发现缺陷并立即修复它是具有成本效益的。 因此，有必要在开发和测试的每个阶段编写测试用例。 这就是我们传统的测试实践所教给我们的，通常称为"早期测试"。

探索性测试

这种测试方法称为"最后测试"方法，因为测试是在一个阶段完成后完成的。

最后测试方法面临的挑战

软件开发项目中相当长一段时间都遵循最后测试方法。 然而，实际上，采用这种方法，由于测试必须等到特定阶段完成，因此常常被忽视 −

  • 该阶段完成的延迟。

  • 时间安排紧张。

  • 专注于按时交付，跳过测试。

此外，在"最后测试"方法中，通常会跳过本应由开发人员完成的单元测试。 找到的各种原因都是基于开发者的心态 −

  • 他们是开发人员，而不是测试人员。

  • 测试是测试人员的责任。

  • 他们的编码效率很高，而且他们的代码不会有缺陷。

这会导致 −

  • 损害交付产品的质量。

  • 仅对测试人员的质量负责。

  • 交付后修复缺陷的成本很高。

  • 无法获得客户满意度，这也意味着失去回头客，从而影响信誉。

这些因素要求改变范式，将重点放在测试上。 结果是测试优先方法。

测试优先方法

测试优先方法将由内而外(编写代码然后测试)的开发方式替换为由外而内(编写测试然后代码)的开发方式。

此方法已纳入以下软件开发方法(也是敏捷方法) −

  • eXtreme Programming (XP).

  • Test Driven Development (TDD).

在这些方法中，开发人员在编写单行代码模块之前设计并编写代码模块的单元测试。 然后，开发人员创建代码模块，目标是通过单元测试。 因此，这些方法使用单元测试来驱动开发。

需要注意的基本点是，目标是基于测试的开发。

红-绿-重构循环

测试驱动开发用于开发由单元测试引导的代码。

步骤 1 − 考虑一个要编写的代码模块。

步骤 2 − 编写测试

步骤 3 − 运行测试。

测试失败，因为代码还没有写。 因此，第 2 步通常称为编写失败测试。

步骤 4 − 编写尽可能少的代码来通过测试。

步骤 5 − 运行所有测试以确保它们仍然通过。 单元测试是自动化的以促进此步骤。

步骤 6 − 重构。

步骤 7 − 对下一个代码模块重复步骤 1 到步骤 6。

每个周期应该很短，典型的一个小时应该包含很多周期。

红绿重构周期

这也通常称为红-绿-重构循环，其中 −

  • 红色 − 编写失败的测试。

  • 绿色 − 编写代码以通过测试。

  • 重构 − 消除重复并将代码改进到可接受的标准。

TDD 流程步骤

TDD 流程的步骤如下所示。

TDD 流程步骤

TDD 的优点

测试驱动开发的好处或优点是 −

  • 开发人员在创建代码之前需要首先了解所需的结果应该是什么以及如何测试它。

  • 只有测试通过并重构代码后，组件的代码才算完成。 这确保了开发人员在进行下一个测试之前进行测试和重构。

  • 由于单元测试套件在每次重构后运行，因此每个组件仍在工作的反馈是恒定的。

  • 单元测试充当实时文档，始终符合数据。

  • 如果发现缺陷，开发人员会创建一个测试来揭示该缺陷，然后修改代码以使测试通过并修复缺陷。 这减少了调试时间。 所有其他测试也会运行，当它们通过时，它确保现有功能不会被破坏

  • 开发人员可以随时做出设计决策和重构，并且测试的运行确保系统仍然正常工作。 这使得软件易于维护。

  • 开发人员有信心进行任何更改，因为如果更改影响任何现有功能，运行测试就会发现同样的情况，并且可以立即修复缺陷。

  • 在每次连续的测试运行中，也会验证所有先前的缺陷修复，并减少相同缺陷的重复。

  • 由于大部分测试是在开发过程中完成的，因此缩短了交付前的测试时间。

TDD 的缺点

起点是用户故事，描述系统的行为。 因此，开发商经常面临以下问题 −

  • 什么时候测试?

  • 要测试什么?

  • 如何知道是否满足规范?

  • 代码是否能带来商业价值?

对 TDD 的误解

业界存在以下误解，需要澄清。

误解 说明
TDD 就是测试和测试自动化。 TDD 是一种使用测试优先方法的开发方法。
TDD不涉及任何设计。 TDD 包括基于需求的关键分析和设计。 设计在开发过程中出现。
TDD 仅在单元级别。 TDD 可用于集成和系统级别。
传统测试项目无法使用TDD。 TDD 在极限编程中变得流行，并被用于其他敏捷方法中。 但是，它也可以用于传统的测试项目。
TDD 是一种工具。

TDD 是一种开发方法，在每次新的单元测试通过后，它被添加到自动化测试套件中，因为每当添加新代码或修改现有代码以及每次重构后都需要运行所有测试。

因此，支持 TDD 的测试自动化工具促进了这一过程。
TDD 意味着将验收测试交给开发人员。 TDD 并不意味着将验收测试交给开发人员。

接受 TDD

验收测试驱动开发 (ATDD) 在开发早期的用户故事创建过程中定义验收标准和验收测试。 ATDD注重客户、开发人员和测试人员之间的沟通和共识。

ATDD的关键实践如下 −

  • 讨论现实场景以建立对该领域的共同理解。

  • 使用这些场景来达成验收标准。

  • 自动化验收测试。

  • 将开发重点放在这些测试上。

  • 将测试用作实时规范以促进更改。

使用ATDD的好处如下 −

  • 要求明确且没有功能差距。

  • 其他人了解开发人员预见的特殊情况。

  • 验收测试指导开发。

接受 TDD

TDD 与 BDD

根据 Dan North 的说法，程序员在进行测试驱动开发时通常会面临以下问题 −

  • 从哪里开始

  • 测试什么和不测试什么

  • 一次性测试多少

  • 如何称呼他们的测试

  • 如何理解测试失败的原因

所有这些问题的解决方案是行为驱动开发。 它是从既定的敏捷实践发展而来的，旨在使敏捷软件交付新手的团队更容易访问和有效地使用它们。 随着时间的推移，BDD 已经发展到涵盖更广泛的敏捷分析和自动化验收测试。

TDD 和 BDD 之间的主要区别是 −

  • TDD 描述了软件的工作原理。

  • 另一方面，BDD −

    • 描述最终用户如何使用该软件。

    • 促进协作和沟通。

    • 强调系统行为的示例。

    • 针对从示例中导出的可执行规范

❮ 上一节 下一节 ❯