Question

最近我们的报告遇到了很多问题，重复的条目，不包括正确的信息，缺少信息等。我正在考虑为报告创建带有specflow的测试套件。

报告显示在ssrs或crystal报告中，因此完整的端到端测试可能不在桌面上。这些报告依赖的观点和程序应该是可测试的，我正在考虑测试定义的这些行：

Scenario: Some Report contains expected values
    Given I execute uspSomeReport with:
    | Field | Value    |
    | From  | 1/1/2015 |
    | To    | 1/1/2016 |
    Then the result should contain:
    | Id    | Name  |
    | 3456  | John  |
    | 98345 | Barry |

Scenario: Address not duplicated
    Given I execute uspSomeReport with:
    | Field | Value    |
    | From  | 1/1/2015 |
    | To    | 1/1/2016 |
    Then Address, Postcode should be unique

我想我的问题是否有人有任何编写报告测试的经验？像这样的方法有任何明显的问题吗？有更好的想法吗？

Answer 1

您可以完全编写测试，指示将输入参数提供给报告SP并验证结果。但是，有几点需要考虑：

由于sp返回的数据或报告本身存在问题，您遇到的问题是什么？两者都可能导致数据不存在或被复制。报告定义中可能存在可见性属性或分组错误导致仅检查sp无法发现的问题。如果您知道sp中存在问题，那么在该层进行测试非常有意义。请注意，数据可以正确，但报告显示不正确。如果您需要测试实际报告的输出，一个选项可能是使用报告的导出功能导出格式化的报告，并将其与已知的正确模板进行比较以进行验证。 Beyond Compare等工具可以对许多不同的文件格式（csv，pdf，excel等）进行智能比较。以这种方式验证实际报告输出比简单地测试sp更复杂且容易出错，因此您可能希望从测试sp开始并在此处添加大量场景，然后使用较少数量的测试验证如果利益值得实施和维护此类测试的成本，则报告输出。
如果您继续使用SpecFlow，请记住SpecFlow测试的核心优势是启用协作并充当活文档，清楚地向利益相关者确定系统的工作方式。如果这纯粹是为了获得一些测试覆盖率并且您对协作方面没有兴趣，那么您可能只想考虑sp的简单单元测试。但是，如果您正在寻找协作优势，我建议您使用方案标题更好地描述报告的工作方式。例如，在您的第一个示例中，您可能需要考虑类似＆＃34;类似于日期范围内的记录包含在结果中＃34;或者你的第二个，＆＃34;对于每个返回的记录，记录的地址将被列出一次＆＃34;。这可能看起来微不足道，但是将您的方案标题编写为产品要求会使您的SpecFlow测试从长远来看变得更有价值。

报告测试的规格流程？

1 个答案: