报表系统测试计划
Test plan for reporting system
我有一个由多个集成软件包组成的软件套件。它们都 运行 来自一个集中式 SQL 数据库。
我们正处于编写测试计划的阶段，为软件的每个独立模块分配了一个单独的测试计划。唯一要写的是报告模块的测试计划。这个特定的模块除了 运行 报告 SQL 数据库中的数据（将由其他模块写入）之外什么都不做。
任何测试迭代之前都会进行开发人员、回归和集成测试，这应该会消除数据库数据未正确维护的任何问题。
我的困境是如何接近报告模块的黑盒测试计划。我看到它的方式有三个选项：
- 将报告测试用例附加到影响它们的模块的测试计划中（缺点：模块协同工作生成报告；报告不能像那样按模块划分）
- 编写一个带有指定先决条件的报告测试计划，这些先决条件本质上是在其他模块中执行的任务说明列表，然后是测试用例以测试报告是否正确生成以响应这些任务（缺点：非常复杂和冗长）
- 在专用受控 SQL 数据库上编写报告集数据集的测试计划（缺点：缺乏灵活性）
在我看来，第二个选项是最好的。这是最长的啰嗦，但仅凭这一点很难成为打折的理由。
有没有人有过纯粹为了报告而测试模块的经验，谁能提供有关执行此操作的最佳/行业标准方法的见解？
提前致谢！
问自己一个有用的问题是 "What is the purpose of this test?"。查看 Agile Testing Quadrants 了解有关不同测试类型的作用的一些详细信息。
（图片来源：Lisa Crispin）
选项 1 侧重于集成点本身，这对团队可能很有价值，因为它可以简化问题的诊断（假设一次只使用 1 个模块）但无法像它那样测试系统实际使用。从这个意义上说，大概属于象限2。
选项 2 更侧重于测试系统，因为它将在现实世界场景中使用，调用多个模块。您从选项 1 中失去了对问题的简单诊断，但您实际上开始以对最终用户有价值的方式对其进行测试，将其置于象限 3。
选项 3 基本上是选项 2 的一个不太灵活的版本。您还失去了与各个模块的大量交互，这使得选项 2 如此有价值（因为它将系统作为一个整体来运行）。足够 'real-world-like' 的数据库可以使它成为第三季度的选项，但您仍然会失去灵活性。
通过这个镜头比较选项 2 和 3，我们可以看到它们有不同的用途。当然，他们都执行很多相同的代码路径，但选项 1 主要支持团队，让他们知道特定模块的更改何时破坏了报告，而选项 2 用于批评产品，询问它是否真的可以在一个真实世界的场景。现在的问题是，哪些结果对您更有价值，这完全取决于您和您的团队。
希望对您有所帮助。
我有一个由多个集成软件包组成的软件套件。它们都 运行 来自一个集中式 SQL 数据库。
我们正处于编写测试计划的阶段，为软件的每个独立模块分配了一个单独的测试计划。唯一要写的是报告模块的测试计划。这个特定的模块除了 运行 报告 SQL 数据库中的数据（将由其他模块写入）之外什么都不做。
任何测试迭代之前都会进行开发人员、回归和集成测试，这应该会消除数据库数据未正确维护的任何问题。
我的困境是如何接近报告模块的黑盒测试计划。我看到它的方式有三个选项：
- 将报告测试用例附加到影响它们的模块的测试计划中（缺点：模块协同工作生成报告；报告不能像那样按模块划分）
- 编写一个带有指定先决条件的报告测试计划，这些先决条件本质上是在其他模块中执行的任务说明列表，然后是测试用例以测试报告是否正确生成以响应这些任务（缺点：非常复杂和冗长）
- 在专用受控 SQL 数据库上编写报告集数据集的测试计划（缺点：缺乏灵活性）
在我看来，第二个选项是最好的。这是最长的啰嗦，但仅凭这一点很难成为打折的理由。
有没有人有过纯粹为了报告而测试模块的经验，谁能提供有关执行此操作的最佳/行业标准方法的见解？
提前致谢！
问自己一个有用的问题是 "What is the purpose of this test?"。查看 Agile Testing Quadrants 了解有关不同测试类型的作用的一些详细信息。
选项 1 侧重于集成点本身，这对团队可能很有价值，因为它可以简化问题的诊断（假设一次只使用 1 个模块）但无法像它那样测试系统实际使用。从这个意义上说，大概属于象限2。
选项 2 更侧重于测试系统，因为它将在现实世界场景中使用，调用多个模块。您从选项 1 中失去了对问题的简单诊断，但您实际上开始以对最终用户有价值的方式对其进行测试，将其置于象限 3。
选项 3 基本上是选项 2 的一个不太灵活的版本。您还失去了与各个模块的大量交互，这使得选项 2 如此有价值（因为它将系统作为一个整体来运行）。足够 'real-world-like' 的数据库可以使它成为第三季度的选项，但您仍然会失去灵活性。
通过这个镜头比较选项 2 和 3，我们可以看到它们有不同的用途。当然，他们都执行很多相同的代码路径，但选项 1 主要支持团队，让他们知道特定模块的更改何时破坏了报告，而选项 2 用于批评产品，询问它是否真的可以在一个真实世界的场景。现在的问题是，哪些结果对您更有价值，这完全取决于您和您的团队。
希望对您有所帮助。