我不明白当没有实际的商业行为来测试某些东西时，情景会是怎样的。
以下情况是否足够好？我不明白它如何被转换成过去，行动，未来序列。
Scenario:
Given The system contains the following users
| email | role |
| [email protected] | ADMIN |
| [email protected] | USER |
And The system contains the following Products
| Name | Active |
| Product1 | true |
| Product2 | false |
Then The list of Products for '[email protected]' user should contain the following entries
| Name | Active |
| Product1 | true |
| Product2 | false |
And The list of Products for '[email protected]' user should contain the following entries
| Name | Active |
| Product1 | true |
沟通如果难以实现。将行为（即“when”子句）嵌入需求中更好（IMO）。
您发布的建议实际上并没有告诉我要求是什么！相反，我现在必须弄清楚潜在的意图必须是什么才能得到你想要的东西。换句话说，我必须“反向工程”预期的逻辑。这是沟通需求的更糟糕方式。事实上，这是一种更糟糕的沟通方式。
这是对您发布的建议的一种解释
Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products
Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products
但是，在您发布的建议中，是否应允许非管理员查看非活动产品？这是一个合理的问题。
如果您唯一说的是某些产品是“某某”，那么我不知道您的意思是“所有权”还是“可见度”。如果我编写的代码允许所有用户查看其他人的产品，该怎么办？如果单击管理员用户配置文件，则会看到所有产品。如果单击非管理员用户配置文件，则只能看到活动产品。看到？我已根据您的要求成功策划了每个用户的列表。但是如果你的意图是基于安全的呢！不知何故，非管理员根本不应该看到UI中存在的那些产品。这是一个非常不同的要求，但你的写作并没有区分它。这是另一个很好的解释：如果你想让我过滤的唯一东西是某种“选择性”怎么办？即：我可以查看所有产品，但我无法选择/附加/使用非活动产品（除非我是管理员）。同样，这是对策展和可见性的不同解释。
你可能会声称“背景”使这一点显而易见。鉴于应用程序的页面流，没有人会误解意图。但是，在您看到有足够的程序发生重大变化之后，您将重视不依赖于“上下文”来使事情“显而易见”。或者有人只是将你的小黄瓜文件分成两部分。如果需要周围的要求来正确解释这个问题，那么现在我们只是通过改进代码中的文件结构就失去了它。
总之，沟通如果难以实现。我认为将嵌入行为纳入要求会降低人们误解它的可能性。
相比之下，这个答案中的建议是文字的。在以后添加或更改其他权限层或者数据库架构如何更改无关紧要，我们知道需求是什么。
我认为行为驱动的要求可以帮助您更好地与产品负责人沟通。我打赌产品所有者会说“我不希望任何其他人（管理员除外）能够看到不活跃的产品。”我的建议几乎是逐字逐句产品所有者在这种情况下会说的。您的建议必须将真实意图“转化”为程序员喜欢思考的“数据驱动”视图。但是，我们越多地将他们的意见“翻译”成不同的格式（如数据结构图），我们就越有风险假设和误解。这种翻译是“有损的”。在整个职业生涯中，我们听到我们的产品所有者说“什么？这不是我所说的！”。我们对“隐性”沟通或“明显”要求的翻译感到不舒服。相反，明确说明每个字面要求。
根据我的经验，产品所有者总是首先考虑更多的行为/客户驱动的术语。这只是我的经历。
小黄瓜只是一种工具，所以它做了一件事，一件好事：它迫使你在行为驱动的发展（BDD）中思考。如果你使用小黄瓜，你必须用“输入”行为来写东西，这是必需的结果。否则你使用的是错误的工具。
相反，您应该决定是否认为BDD是强迫自己遵循的好理念。如果你认为遵循这种哲学是好的，那么你需要不断重述这个要求，直到有一个“何时”的陈述。一些人（包括我）认为强迫自己做出“何时”陈述的行为是好的。
此外，小黄瓜与其他文档并不相互排斥。例如，您仍然会有ERD图表，UI模型等。事实上，您甚至可以在其他设计文档中引用小黄瓜场景。 Gherkin旨在帮助您了解您是否正在做客户要求的事情，而不是您是否正在设计代码。其他规格可以做到这一点，它们可以协同工作。
不仅如此，“要求”本身也有层次，并以不同的媒介来表示。例如，您可能需要产品所有者为客户写的“签收”文档。该文件的格式与小黄瓜非常不同，因此很好。在另一个极端，你有一个ERD图。我认为小黄瓜是“介于两者之间”的需求抽象层次。
此外，回归测试应该很容易。使用小黄瓜，你甚至可以实现自动化。然而，再次，根据您发布的建议，我担心回归测试人员必须推断并找出要测试的案例。这是进行回归测试的一种可怕方式。每个案例都应该拼写出来。即使它对你来说“显而易见”，我保证对其他人来说并不明显（反之亦然）。另外，即使是你自己，如果你必须进行回归测试，那么你希望事情变得容易。回归测试压力越大，发生的可能性就越小，完成得越少。明确的清单使其压力更小，更容易理解。行为驱动与回归测试完美对齐。
就个人而言，这就是我写这种情况的方式：
Scenario Outline: Viewing inactive products in different roles
Given I am logged in as <user_role>
And the system contains the active product "product1"
And the system contains the inactive product "product2"
When I view the available products
Then I should see the "product1" product
And I <should_see_inactive?> see the "product2" product
Examples:
| user_role | should_see_inactive? |
| an admin | should |
| a user | should not |
您在此处测试的是，角色中的特定用户是否具有查看非活动产品的正确访问级别。
你的陈述是以一种似乎应该编写2个场景的方式编写的，并且当你为2个不同的用户组测试相同的东西以显示我正在使用Scenario Outline的差异时