我想了解如何正确创建我的BDD REST测试场景。
从我在网上读到的，我们应该只有一个WHEN-THEN对，断言应该在THEN步骤中完成。
如果我们有这样的情况
给定用户搜索航班
和用户选择座位
和用户将行李添加到航班
,用户购买航班
然后航班预订成功
当我们尝试将行李添加到航班时，如果得到500 Status错误会发生什么?我们至少应该在所有步骤中做基本断言吗?
您可以在所有步骤中添加断言。
从我在网上看到的，我们应该只有一个WHEN-THEN对断言应该在THEN步骤
中完成
场景的主要断言可以在Then步骤完成。下面的例子来自我目前的项目，你可以看到我是如何写步骤的，
@TC_CUE_Search_for_all_templates_and_validate_particular_template_response
Scenario: Validate json details for given template
Given Get template key and Application key from db
And Load Datasheet for Iteration
And Execute the request to fetch all the templates of an application
Then Get and verify the response of given template from template result list
Given Get template key and Application key from db
验证DB是否返回有效响应。如果我收到有效的响应，那么我从数据库中获取所需的详细信息，并将其写入excel中。
And Load Datasheet for Iteration
读取excel表格。
And Execute the request to fetch all the templates of an application
得到请求将被执行，我验证响应代码并存储结果。
Then Get and verify the response of given template from template result list
这里我执行主验证。在前面的步骤中，它返回巨大的响应，我根据参数获取特定的响应并验证所有必需的字段。
这个示例的目的是阐明如何自动化REST场景。
理想情况下，每个场景只执行一个方面的行为。一个场景有三个部分:
Given *a context*
When *an event occurs*
Then *an outcome should happen*
给定的是场景发生的上下文。在这个场景中，我们是如何到达那里的并不重要。因此，例如，如果您的用户添加了包，那么无论是通过Gui还是通过将数据插入后端都无关紧要。只要你分辨不出其中的区别，就没问题。你可以有多个给定条件，因为很多事情可能会适合上下文。
只有一个When是正常的，因为它是你想要锻炼的行为的触发器。我发现的例外是当交互发生时，例如与另一个人或时间，你需要他们都正确地展示行为。
Then是该行为应该产生的结果。你可以有多个then，因为可能会有多个利益相关者或不同的事情发生——例如，当优步司机接受你的预订时，他们会得到成功的接受确认，你会得到通知，优步也会知道这件事。
因此，如果您想要检查能够向航班添加行李的行为，那么这可能应该是一个明确的场景。你可以把它作为"When"如果你想:
Given the user has selected flight B1234 LON-YYZ 22 Oct 2021 16:45
And the ticket costs $240
And extra bags cost $40
And an exit row upgrade costs $20
When they book the flight with 2 bags and an upgrade to the exit row
Then their ticket should show 2 bags and an upgrade to the exit row
And they should be charged $300.
注意，我在这里放置了两个方面的行为:包和出口行升级。我对此非常务实，但如果因为任何原因变得复杂，将它们分开
重要的是，你会注意到它们最终都在When。
如果在设置给定时得到500错误，那就不是场景的一部分。但是，您可以选择运行更长的测试，如冒烟测试或客户旅程。严格地说，这些都不是BDD场景，但我发现通常有几个这样的场景是值得的(真的，它们需要很长时间才能运行，所以保持少量的数量!)
你会得到这样的结构:
Given the user is on the flight search page
And Flight B12345 leaves LHR for YYZ at 16:59
When they search for a flight from LHR to YYZ on 22 Oct 2021
Then Flight B12345 should show up in the results
When they add an extra bag and an exit row seat to the booking
Then the bag and exit row seat should show in the checkout
When they checkout...
etc.
"Thens"在整个客户旅程中，我们看到的是实现中期成果的地方;要么是客户可以为以后保存的东西，要么是他们刚刚完成的工作得到反馈的地方。这仍然是从客户的角度出发;我们没有提到500个错误。如果你得到一个500的错误，它无论如何都会失败，但是我们不想让这些类型的检查破坏代码库，所以我们不倾向于让它们显式。
部分原因是这些并不是真正的测试!它们是系统如何工作的活生生的例子，碰巧提供了测试作为一个很好的副产品。它们帮助开发人员理解系统并轻松更改代码;防止错误，而不是捕获它们。话虽如此，我有时确实会在任何给定的情况下放置可能失败的断言。作为第一步的一部分，我可能会检查网站是否已经启动。任何其他基于网络的问题，我都允许在接下来的旅程中浮出水面。
您可能也会发现这个答案在更长的客户旅程中很有用。