报告测试的规范流？

Question

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

报告显示在 ssrs 或水晶报告中，因此完整的端到端测试可能不在讨论范围内。这些报告所依赖的视图和程序虽然应该是可测试的，但我正在考虑按照这些思路来定义测试：

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 并验证结果。但是，有几点需要考虑：

1. 您遇到的问题是由于 sp 返回的数据还是报告本身的实际问题？要么可能导致数据不存在或被复制。报告定义中可能存在可见性属性或分组错误，从而导致仅检查 sp 无法发现的问题。如果您知道问题出在 sp 中，那么在该层进行测试就非常有意义。请注意，数据可能正确，但报告显示不正确。如果您需要测试实际报告的输出，一种选择可能是使用报告的导出功能来导出格式化的报告并将其与已知的正确模板进行比较以进行验证。 Beyond Compare 等工具允许对许多不同的文件格式（csv、pdf、excel 等）进行智能比较。以这种方式验证实际报告输出比简单地测试 sp 更复杂且更容易出错，因此您可能希望从测试 sp 开始并在此处添加大部分场景，然后进行少量测试来验证如果收益值得实施和维护此类测试的成本，则报告输出。

2. 如果您确实继续使用 SpecFlow，请记住 SpecFlow 测试的核心优势是支持协作并充当活文档，向利益相关者清楚地确定您的系统是如何工作的。如果这纯粹是为了获得一些测试覆盖率并且您对协作方面不感兴趣，那么您可能只想考虑对 sp 进行简单的单元测试。但是，如果您正在寻找协作的好处，我建议您使您的场景标题更能描述报告的工作原理。例如，在您的第一个示例中，您可能想要考虑诸如“结果中包含日期范围内或日期范围内的记录”或您的第二个示例，“对于返回的每条记录，记录的地址将列出一次”。这可能看起来微不足道，但是从长远来看，将场景标题作为产品需求编写会使 SpecFlow 测试更有价值。