2016-08-06 31 views
0

我們正在使用SpecFlow進行功能測試,當人類讀取生成的電子郵件並驗證所有部分符合規範時,這些功能測試會取代手動測試。問題是,方案綱要成爲成長有太多的參數如何解決具有太多參數的SpecFlow場景輪廓?

Scenario Outline: generate and send confirmation email 
     Given I have stored itinerary in '<EmbeddedItinerary>' 
     When Generate confirmation email 

     Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',... 
     Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',.. 
     Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',... 
.... 

例子:

| EmbeddedItinerary | Param1_1| Param1_2| Param1_3| Param2_1| Param2_2| Param2_3| Param3_1| Param3_2| Param3_3|... 

| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |... 
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |... 

但列的實例數量將變得難以管理。我希望有多行的例子(但是在Multiple Multi-Line Examples in SpecFlow Feature File中有不同的理由)。

我看到的選項是將所有ExpectedResults存儲在嵌入式xml或json資源文件中,並且SpecFlow功能非常小,例如,

Scenario Outline: generate and send confirmation email with correct email address for flight section 
     Given I have stored embedded resource '<EmbeddedItinerary>' 
     When Generate confirmation email 
     Then sections should be as specified in '<ExpectedResultsFile>' 
Examples: 
| EmbeddedItinerary | ExpectedResultsFile 

| Itinerary_1 | ExpectedResults1 | 
| Itinerary_2 | ExpectedResults2 | 
... 

這是一個好主意嗎?
任何人都可以提出更好的方式(更多SpecFlow風格)? 我擔心的是將預期數據移動到單獨的文件中我失去了可視性,這是SpecFlow功能的優勢之一。

更新:在寫這個問題時,我發現商業產品(每位用戶$ AUD 255)Specflow + Excel http://www.specflow.org/plus/excel/getting-started/,這可能會滿足我的需求來維護許多列。
它是一種成熟/可靠的產品嗎?我應該使用它來代替自己解析專有格式的預期結果文件嗎?

回答

1

如果我在場景大綱中有很多參數,我會嘗試儘可能多地使用默認參數或將場景大綱拆分爲多個參數。

我認爲在你的情況下,應該可以將多個場景大綱中的'生成併發送確認電子郵件'場景大綱分割爲每個部分都有一個場景大綱。

這將減少每個場景所需參數的數量,並且如果發生錯誤,您將獲得更快的反饋。您立即看到哪一部分出現錯誤。

例如爲:

Scenario Outline: generate and send confirmation email - section 1 
    Given I have stored itinerary in '<EmbeddedItinerary>' 
    When Generate confirmation email 

    Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',... 

Examples: 
    | EmbeddedItinerary | Param1_1 | Param1_2 | Param1_3 | 
    | Itinerary_1  | Value1_1 | Value1_2 | Value1_3 | 


Scenario Outline: generate and send confirmation email - section 2 
    Given I have stored itinerary in '<EmbeddedItinerary>' 
    When Generate confirmation email 

    Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',.. 

Examples: 
    | EmbeddedItinerary | Param2_1 | Param2_2 | Param2_3 | 
    | Itinerary_1  | Value2_1 | Value2_2 | Value2_3 | 


Scenario Outline: generate and send confirmation email - section 3 
    Given I have stored itinerary in '<EmbeddedItinerary>' 
    When Generate confirmation email 

    Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',... 

Examples: 
    | EmbeddedItirerary | Param3_1 | Param3_2 | Param3_3 | 
    | Itinerary_1  | Value3_1 | Value3_2 | Value3_3 | 

關於SpecFlow + Excel中:這也是一種選擇。在Excel中維護示例大部分時間比在功能文件中更容易。它至少會在短期內解決你的問題,但你必須小心編寫仍然可以理解和可讀的場景。

你可以從這裏獲得試用許可證爲它:http://www.specflow.org/request-your-specflow-trial-license/


全面披露:我的SpecFlow +(亞軍& Excel)中的開發者之一。

+0

謝謝,安德烈亞斯,我的一位同事想要以同樣的方式。我擔心的是,實際的業務情景是發送包含所有部分的電子郵件,並確保所有部分都正確。你把它分解成單獨的場景來單獨測試每個部分的方法更像是單元測試,我們無論如何(但沒有SpecFlow)。我錯了嗎? –

+0

這取決於您對單元測試Unit的定義。通常它是一個類,所以你正在測試一個沒有依賴關係的類的行爲。如果超過這個參與自動化測試,你就開始稱之爲集成測試。當你正在生成文本和發送電子郵件時,我假設你在這裏有不止一個班級。這意味着你有一個集成測試。 –

+0

如何確定在同一測試中哪些值需要測試,取決於您的代碼。如果您始終獲得某個部分的相同內容,則無論您首先檢查其他部分,如果您在一個場景或多個場景中檢查它們,結果無關緊要。 但是,如果例如第2部分取決於您首先檢查第1部分,然後您需要在一個場景中檢查它們,因爲如果將它們分開,則第1部分是較新的訪問。 –

相關問題