cucumber测试

Cucumber是一种规范语言的执行框架。 它并不是要成为测试语言，而是用于创建测试自动化。

Cucumber最适合出现一些实际参与者互动并取得某种成果的情况。 当可以从用户的角度编写它时，它特别有用。

 Given Sarah is a premium club member  When Sarah logs into the homepage  Then she sees the premium club member call to action 

尽管这可能是在谈论屏幕，但它也在以用户和产品的语言进行交流。 这是一个舒适的规格。

谁是后端用户？

假设我们要在Cucumber中为后端编写API测试？ 这给我们带来了一些问题，例如，它实际上是一个不一定使用用户语言的较低级接口，或者我们必须跟踪发出的请求的状态，因为我们不能仅仅谈论正在处理的内容。屏幕。

那我们应该吗？

Cucumber是编写API测试的错误工具吗？

答案在于我们是否认为后端具有可以以人类可读形式表达的规范。

我们认为后端有规范吗？

让我们承认，无论规范是什么，它所使用的语言都比功能级别的验收测试更具技术性，而功能级别的验收测试可能与此后端只是组件的业务流程有关。

这里的一些问题是写作。 我们希望以简洁的形式表达系统的预期/期望行为。 这是我们需要求助于写作1-2-3的地方 。 每个故事都有一个起点和终点。

您将如何向为您的工作付费的人解释给定API的目的是什么？

好的，此API是一种在接收到凭据的基础上为用户生成用户登录证书的API，假设该用户对凭据数据库是已知的，否则就不会……

好吧..还有一点点不足，但至少听起来很有价值。 我们可以1-2-3吗？

对于已知用户，提供凭据将产生证书。

在小Cucumber中：

 Given Sarah is known to the credentials database as "sarah" with password "s4r4h"  When Sarah's sign- in request is submitted as "sarah" , "s4r4h"  Then a certificate is returned  And the certificate contains the name "Sarah" 

从哪儿开始？

制造的示例很简单……您如何开始呢？

这里有一些想法：

• 绘制您要测试的服务的图表
• 确定图中的哪些对象是测试的目标，哪些是以下两者之一：
  • 服务的使用者
• 考虑通过服务的数据流：
  • 如何开始？

现在我们了解：

• 服务的外部触发器/客户端
• 服务返回的东西
• 服务需要发生以支持它的事情
• 服务对外界所做的事情

我们的规格应为上述术语。

奖励功能

我们的测试设计应该能够解释自动化如何将服务作为客户端使用，提供任何依赖关系以及观察服务的副作用和响应。

翻译自: https://www.javacodegeeks.com/2020/02/how-to-phrase-back-end-tests-in-cucumber.html

cucumber测试