报告系统的测试计划

Question

我有一个由多个集成软件包组成的软件套件。它们都运行在一个集中的SQL数据库中。

我们正处于编写测试计划的阶段，并为软件的每个独立模块分配了一个测试计划。剩下要写的唯一一个是报告模块的测试计划。这个特定的模块除了运行SQL数据库中的数据（将由其他模块编写）之外什么都不做。

任何测试迭代之前都有开发人员，回归和集成测试，这应该可以消除任何未正确维护的数据库数据问题。

我的困境是如何处理报告模块的黑盒测试计划。我看到的方式有三种选择：

• 将报告测试用例附加到影响它们的模块的测试计划中（缺点：模块协同工作以生成报告;报告不能按模块划分）
• 为具有指定先决条件的报告编写测试计划，该计划基本上是在其他模块中执行的任务的指令列表，然后是测试用于测试报告是否正确生成以响应这些任务的测试用例（缺点） ：非常复杂而且啰嗦）
• 在专用受控SQL数据库上编写带有设置数据集的报告测试计划（缺点：缺乏灵活性）

在我看来，第二种选择是最好的。它是最长的啰嗦，但仅凭这一点并不是打折的理由。

有没有人有纯粹为报告测试模块的经验，谁有希望提供最佳/行业标准方法的见解？

提前致谢！

Answer 1

要问自己一个有用的问题是“这个测试的目的是什么？”。查看Agile Testing Quadrants以获取有关不同测试类型角色的一些详细信息。

（图片来源：Lisa Crispin）

选项1侧重于集成点本身，这可能对团队有价值，因为它可以简化问题的诊断（假设一次只使用一个模块）但是无法测试系统，因为它实际上是用过的。从这个意义上说，可能属于象限2。

选项2更侧重于测试系统，因为它将在现实世界场景中使用，调用多个模块。您无法轻松诊断选项1中的问题，但实际上您开始以对最终用户有价值的方式对其进行测试，并将其置于Quadrant 3中。

选项3基本上是选项2的不太灵活的版本。你也失去了与单个模块的大量交互，这使得选项2如此有价值（因为它在整个系统中运行）。一个足够'真实世界'的数据库可以使这个Q3选项，但你仍然失去灵活性。

通过此镜头比较选项2和3，我们可以看到它们用于不同目的。当然，他们都执行了很多相同的代码路径，但是选项1主要支持团队，让他们知道特定模块的更改何时打破了报告，而选项2用于批评产品，询问它是否真的可以在现实世界的场景。现在的问题是，哪些结果对您更有价值，这取决于您和您的团队。

希望有所帮助。