「情景」在黃瓜「場景大綱」中的優勢是什麼？

我知道場景和場景大綱與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 |

我知道它會導致一個錯誤，但我認爲它會更好，如果黃瓜隊完全刪除場景的概念，而是支持方案大綱更多。

來源

2017-06-18 Salman

這不是關於對方能做什麼，而是讓情景儘可能簡單易懂。

如果僅僅是一個例子，它簡化和不使用的示例表，它可以更容易閱讀和理解

來源

2017-06-18 22:24:10

考慮，那麼，什麼時候都可以在場景和情景大綱使用步驟以及。 DataTable的情況也是如此（這又是一個步驟約束）

一方面，Scenario被引入以事務方式執行這些步驟並將被執行一次。但是，如果提供了DataTable，則可以使用Java代碼來相應地處理數據。

另一方面，場景輪廓爲您提供了靈活性，只能從基於小黃瓜的特徵文件執行循環。

其他差異： - 在一次執行中，場景只執行一次，而場景大綱（對於類似數據跟蹤）可以根據示例中提供的數據執行多次。 - 場景大綱提供了一種更簡潔的方法來保持特性文件的小巧和可讀性，而不是反覆編寫類似的場景。

此外，使用場景大綱作爲場景的替代，因爲它只是提供了一個額外的循環功能。

注意：我們應該保留更少的步驟數，因爲更多的步驟將需要更多的時間來執行測試用例。

來源

2017-06-19 07:35:48 GaurZilla

場景優於場景。

無需有示例部分。如果您使用輪廓，即使您沒有使用任何參數，也必須使用來使用帶有表格的示例部分。
我需要傳遞整個表格作爲輸入的一些場景。使用輪廓時不容易將整個表作爲輸入。
無需定義參數名稱並在表格中保留相同的參數及其值。
爲一個故事和輸出表定義輸入表有點困難，耗時且令人困惑。

來源

2017-06-19 12:57:51 Murthi

你不會錯的。

你正在做的是遵循反模式，使你的步驟定義更簡潔。在這一過程中，你是

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

其他原因不使用例如表是

步驟定義是非常非常難寫。
的步驟定義更難重用
示例值在表是容易出錯，如果我改變24至23被予固定一個錯字或改變基本的業務規則
示例值幾乎總是重複次數值在代碼庫
示例值需要更新時的代碼庫的變化

讓我們簡單瞭解一下，在5

說我們有一個弱口令「12345」和trong密碼re432uee8l。

如果我們使用示例表，我們最終會在表中使用硬編碼密碼，例如，

registered | re432uee8l | logged in

現在，如果我們改變我們的業務規則地說，我們強大的密碼必須在它的象徵，我們必須改變我們的功能集每個強密碼的例子。

已經用黃瓜從一開始我強烈建議

實現的情況下（即那些你應該每一個「推後運行|構建| deploy`應該沒有例子，也沒有輪廓）。如果您正在運行大綱和示例，那麼您正在運行的方案尚未完成。

來源

2017-06-22 18:38:39 diabolist

「情景」在黃瓜「場景大綱」中的優勢是什麼？

回答

相關問題