3

我正在编写一个用于 RESTful API 测试自动化的框架，我已经决定使用 REST Assured，我不确定是否 100% 添加一个层以允许使用像 Gherkin 这样的领域特定语言定义测试，因此添加一个 BDD 框架，例如黄瓜。你有什么意见？
在 API 自动化测试中使用 BDD 是一种好方法吗？

4

7 回答 7

5

在我看来，使用 BDD 始终是一种好方法（就测试自动化而言）。

  1. 易于与其他开发人员共享。一组人类可读的场景将更快地进入绳索。
  2. CI 与 BDD 的集成将使故障调查更容易。
  3. 易于维护和重构，因为您的方法名称不仅是“assertUserHasRoLe”fe，而且还带有业务意义的文本

BDD 就像一座桥梁，是测试框架中更高层次的抽象。相反，或者阅读该方法中正在发生的事情的测试代码 - 这应该足以阅读该方法的行为定义。

于 2015-12-06T10:42:03.007 回答
5

我目前正在使用 BDD 进行 RestAPI 测试。这是 BDD RestAPI 自动化框架的优缺点。

我们使用的技术：Cucumber、Java、Rest-Assured 和 junit

以下利弊是我自己的评论或个人观点。这是基于我的经验。

优点：

  • 使用 Gherkin 语言轻松编写功能文件
  • 很容易涵盖验收标准
  • 团队中的每个人（包括团队）都可以帮助您编写功能文件
  • 非常好的报告格式和调试失败
  • 在夜间或常规构建期间易于执行
  • 集成测试非常简单，因为您可以使用 Background 或 Given 以及 Gherkin 语言的其他功能

缺点：

  • 当公司中的其他团队成员需要测试用例或任何文档时，您的回答将是“我们有小黄瓜语言的场景”，有时很难理解/解释场景，因为没有像传统步骤定义或大文档这样的明确步骤

  • 高层管理人员有大量时间了解测试产品的收敛情况，例如 HP ALM 覆盖率报告。

  • 专门为那些多年编写测试用例的人编写很少的冲刺并不难。

请自由编辑或建议任何需要添加或删除的内容。我希望它会帮助你。

于 2015-12-07T02:54:45.590 回答
0

不，这不是API 测试的好方法，甚至对于 UI 测试，许多事情都必须“排队”才能让您成功使用 BDD。

我已经写了一个详细的解释作为对 Stack Overflow 上另一个问题的回答，这里是链接：

https://stackoverflow.com/a/47799207/143475

于 2017-12-22T04:20:28.083 回答
0

几年前，我确实设法为客户结合了自动化 UI 测试和 BDD ( Concordion )。更大的挑战过去和现在仍然是带有 div 和其他标签的 HTML 代码，这些标签可以在网页设计时轻松更改。对于 BDD 解决方案，人们还应该决定他们最喜欢什么，FIT、Cucumber、Concordion……有几种解决方案。

于 2018-03-20T13:21:28.390 回答
0

这取决于您的项目，如果您的项目很大并且一天比一天大，并且您希望最大程度地集成或功能测试覆盖率，那么我建议您使用 BDD。在这种情况下，您必须只为每个模块化任务定义步骤定义，并使用功能文件中的这些步骤定义创建测试用例。

于 2018-03-20T13:48:43.700 回答
0

从过去 3 年开始，我一直在使用 BDD 进行 API 自动化。这是一个非常简单且可重复使用的概念，它为任何人甚至非技术人员提供了清晰的视野。我们在这里维护的唯一部分是标头数据，其中包括标头和用于维护会话的 cookie。

我必须建议这种方法，因为它确实是面向结果的，并且易于维护和重用。

于 2018-06-28T09:12:15.177 回答
-1

已经用 selenium 实现了黄瓜：Java、TestNG 框架以及 SpecFlow、NUnit、Selenium：POM 和 Extent Reports 框架。以我过去的经验，这提供了扩大没有技术开发背​​景的业务用户和 SME 的输入和反馈池的能力。通过这种扩展的反馈，我们能够更快更好地交付。在 UAT 和发布期间很少或没有意外，因为应用程序代码是功能文件的派生而不是对需求的解释。这使得持续集成和部署更快地发生。我期待在我当前的项目中实现这一点。

于 2019-04-05T20:36:06.867 回答