报告系统测试计划

Question

我有一个包含多个集成软件包的软件包。它们都使用一个集中的 SQL 数据库。

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

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

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

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

在我看来，第二个选项是最好的。这是最啰嗦的，但仅此一点并不能成为打折的理由。

有没有人有任何测试纯粹用于报告的模块的经验，谁能提供有关最佳/行业标准方法的见解？

提前致谢！

Answer 1

问自己一个有用的问题是“这个测试的目的是什么？”。查看Agile Testing Quadrants 了解有关不同测试类型的作用的一些详细信息。

（图片来源：丽莎·克里斯平）

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

选项 2 更侧重于测试系统，因为它将在真实场景中使用，调用多个模块。您失去了选项 1 中对问题的简单诊断，但实际上您开始以对最终用户有价值的方式对其进行测试，将其放在象限 3 中。

选项 3 基本上是选项 2 的一个不太灵活的版本。您还失去了与使选项 2 如此有价值的各个模块的大量交互（因为它作为一个整体来锻炼系统）。一个足够“真实世界”的数据库可以使它成为第三季度的选择，但您仍然失去了灵活性。

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

希望对您有所帮助。