BDD自动化框架和关键字驱动的自动化框架有什么区别？

Question

我正在使用Cucumber BDD框架进行测试自动化。我读过关于关键字驱动的文章，这些文章指出像sign_in这样的关键字向非程序员公开，并且在定义文件中提到了实现。我们在Cucumber中使用了类似的技巧，用Gherkin语言用简单的英语描述动作。

我想通过一个例子来理解关键字驱动的自动化框架与像Cucumber这样的BDD有什么不同？

Answer 1

首先理解BDD:

BDD不仅仅是测试--它是一种开发实践，它避免了提供“完成”定义的困难。

https://dannorth.net/introducing-bdd/是BDD样式定义的作者

根据文件

“行为”是一个比“测试”更有用的词，现在我有了一个工具-- agiledox --来删除单词“test”和每个测试方法名称的模板。我突然想到，人们对TDD的误解几乎总是回到“测试”这个词上。这并不是说测试并不是TDD的固有特性--生成的一组方法是确保代码工作的有效方法。但是，如果这些方法没有全面地描述系统的行为，那么它们就会诱使您产生一种虚假的安全感。在与TDD打交道时，我开始用“行为”一词代替“测试”，发现这不仅似乎符合，而且还发现整类辅导问题神奇地溶解了。我现在有了一些TDD问题的答案。什么叫你的测试很容易-这是一个句子描述下一个行为，你感兴趣。有多少测试变得毫无意义-你只能用一个句子来描述这么多的行为。当测试失败时，只需完成上面描述的过程--要么您引入了bug，要么迁移了行为，要么测试不再相关。我发现从在测试中思考到在行为上思考的转变是如此深刻，以至于我开始将TDD称为BDD，或行为驱动的开发。

它表明，关注系统的行为而不是功能，我们对此有更清楚的理解。

1. 要实施什么？
2. 要测试什么
3. 为“已完成”的故事打上标记的验收标准是什么？
4. 从哪里开始，将故事作为起点，它定义了系统应该具有的功能和行为。它避免了对系统产生误解的情况，并确保不存在“不存在错误谬误”(没有错误谬误意味着没有错误，但系统本身无法使用，因为它没有按照要求的方式构建)
5. 要做什么改变及其对系统行为的影响
6. 提供更多的系统功能和特性的可追溯性和可见性。
7. 更多的测试覆盖可跟踪性，因为您知道要涵盖的所有场景或行为。

BDD与KDT的

差异

BDD:

https://dannorth.net/whats-in-a-story/

行为驱动的开发使用一个故事作为功能的基本单元，因此也是交付的基本单元。接受标准是故事中固有的一部分--实际上，它们定义了它的行为范围，并给出了“已完成”的共同定义。在我们进行规划时，它们也被用作估计的基础。最重要的是，这些故事是项目涉众、业务分析师、测试人员和开发人员之间对话的结果。BDD不仅是关于开发过程的输出，也是项目中不同人员之间的交互。

KDT

关键字驱动测试是在测试中实现BDD方法的一种方法，您可以使用关键字定义系统的行为。

您也可以使用Gherkin (黄瓜中的Gherkin)来完成此操作。

Robotframework这样的框架既支持关键字抽象，也支持Gherkin的使用(给定，何时，然后)

摘要：

BDD是一种开发实践，通过定义系统的预期行为来定义用户故事。它使开发、测试和交付的内容更加清晰。

而KDT是在测试框架中实现BDD的方法，这样我们就可以通过测试脚本和用户故事获得测试覆盖率和一对一的可跟踪性。

Gherkin*是测试中定义BDD的另一种语法方法，

因此，您可以使用Gherkin、关键字驱动或简单的页面对象方法抽象来定义行为，而不是BDD测试框架中的功能。

重要：

除非关键字或Gherkin或测试方法定义了系统的行为，否则不能将非Gherkin、关键字驱动或简单测试方法视为行为驱动，它们只是Gherkin、KDT或简单的低测试方法。

，所以并不是所有关键字或Gherkin或测试方法都符合BDD标准的

。