1

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

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

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

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

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

在我看来，第二种选择是最好的。这是最长的，但仅此一点并不能成为打折某些东西的理由。

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

提前致谢！

4

1 回答 1

1

问自己一个有用的问题是“这个测试的目的是什么？”。查看敏捷测试象限，了解不同测试类型的作用的一些细节。

在此处输入图像描述 （图片来源：丽莎克里斯平）

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

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

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

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

希望有帮助。

于 2015-04-29T13:14:31.767 回答