我知道here中场景与场景大纲之间的区别。
Scenario states 以更抽象的方式测试的一般要点。与此同时，
scenario outline通过几个示例促进了执行方案。
所以，我们通常会写一个feature file，如下所示。它以scenario开头，然后使用scenario outline完成。
功能：功能标题 我想将此模板用于我的功能文件
Scenario: Eating
Given I have "N" cucumbers
When I eat "K" ones of them
Then I will have "N-K" ones
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
但它对我来说并没有多大意义。我认为场景概述更容易理解，因此没有必要用场景表达测试的一般观点。
你同意我的意见吗？
我的意思是，该情景的作用是什么，哪种情景大纲不能做？
我建议选择更简单的
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
我知道它会导致错误，但我认为如果黄瓜团队完全删除场景概念会更好，而是更多地支持场景大纲。
答案 0 :(得分：3)
你错了。
您正在做的是遵循反模式，使您的步骤定义更简洁。在这样做你是
1）大幅减少步骤定义传达的信息量
2）增加运行时间（示例表鼓励运行许多示例。在您的表中，您有两行完全相同的事情）
3）为该场景的所有未来执行创建维护问题。
使用Cucumber示例表的唯一原因是让您更容易与利益相关者协作。在这里，我们使用概述和示例，粗略地总结了您希望在特定领域实现的目标。获得这些后，您应该提取各个方案来探索和记录每个示例所代表的特定规则和策略。因此，作为实施过程的一部分，您正在将大纲场景改进为更高质量的个人场景
如果我们采取更好的示例表
user | password | result
not_registered | goodpass | user not found
registered | badpass | bad password
registered | goodpass | logged in
然后我们最好不要将其分解为单独的场景，而不是因为很多原因将事情保存在表中。
首先，我们可以更详细地记录每项政策。如果我们采用已注册的badpass错误密码示例，我们可以
Scenario: Login with bad password
Given I am registered
When I login with a bad password
Then I should see a bad password error
现在我们可能会认为显示密码错误并不是一个好主意，因为它可以通过确认注册帐户存在来帮助人们破解帐户。所以我们也会改进这种情况
Scenario: Login with bad password (show login error only to prevent account identification)
Given I am registered
When I login with a bad password
Then I should see a bad login error
单个方案提供了添加文档和使用其他步骤的机会。更新示例表的通信要少得多（您必须猜测为什么错误的密码成为糟糕的登录）
registered | badpass | bad login
不使用示例表的其他原因是
让我们快速浏览一下。
假设我们有一个弱密码'12345'和一个强密码re432uee8l。
如果我们使用示例表，我们最终会在表格中使用硬编码密码，例如
registered | re432uee8l | logged in
现在，如果我们更改业务规则以说我们的强密码必须包含符号，我们必须更改我们的功能集中的每个强密码示例。
从一开始就使用Cucumber我强烈推荐
已实施的方案（每次'push | build | deploy`之后应该运行的方案应该没有示例，也没有大纲）。如果您正在运行大纲和示例，则表明您正在运行尚未完成的方案。
答案 1 :(得分：0)
这不是关于人们可以做什么而是另一方面，而是关于使场景尽可能简单易懂。
如果只有一个示例，请简化它并且不使用示例表，这样可以更容易阅读和理解
答案 2 :(得分：0)
给定，何时，然后是可以在场景和场景大纲中使用的步骤。 DataTable的情况也是如此（这又是一个步长约束）
一方面，引入了Scenario以事务方式执行这些步骤并将执行一次。但是，如果提供DataTable，则可以使用Java代码相应地处理数据。
另一方面，Scenario Outline为您提供了仅从基于Gherkin的功能文件执行循环的灵活性。
其他差异： - 在单次执行中，Scenario仅执行一次，而Scenario outline（对于类似的数据跟踪）可以多次执行，具体取决于作为示例提供的数据。 - 场景概述提供了一种更清晰的方法来保持功能文件更小，更易读，而不是重复编写类似的场景。
此外，使用Scenario Outline作为Scenario的替代是没有害处的，因为它只是提供了一个额外的循环功能。
注意：我们应该保留较少的步骤，因为更多的步骤需要更多时间来执行测试用例。
答案 3 :(得分：0)
场景优于场景的好处。
答案 4 :(得分：0)
如果方案代码经过正确编码，则除了方案之外，方案大纲还具有更多优势。方案和方案大纲服务器的用途不同，它们的编写方式相同，但方案大纲以示例表的形式获取用户数据并运行方案。因此，与其用不同的数据复制相同的方案，不如编写一个方案大纲并将所有数据写在Example表中。可以使代码尽可能通用，以增强步骤定义的重用性并遵循编码实践。