2016-08-06 29 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部分是较新的访问。 –

相关问题