报告系统测试计划

Question

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

我们正处于编写测试计划的阶段，并为软件的每个独立模块分配了一个测试计划。唯一需要编写的是报告模块的测试计划。这个特定模块只运行SQL数据库中的数据报告(这些数据将由其他模块编写)。

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

我的困境是如何处理报告模块的黑匣子测试计划。在我看来，有三个选择：

• 将报告测试用例附加到影响它们的模块的测试计划中(缺点:模块一起工作以生成报告；报告不能按模块划分)
• 编写一个带有特定先决条件的报告测试计划，它本质上是在其他模块中执行的任务指令列表，然后是测试用例，以测试报告是否正确地响应这些任务(缺点:非常复杂和冗长)。
• 为在专用的受控SQL数据库上使用集数据集报告编写一个测试计划(缺点:缺乏灵活性)

在我看来，第二个选择是最好的。这是时间最长的一次，但光是这一点并不能成为折价的理由。

有没有人有过纯粹为报告测试模块的经验，谁能提供一个最好的/行业标准的方法来做这件事呢？

提前感谢！

Answer 1

问自己一个有用的问题是：“这个测试的目的是什么？”有关不同测试类型的角色的详细信息，请查看敏捷测试象限。

​

(图片来源: Lisa Crispin)

备选方案1侧重于集成点本身，这对团队来说可能很有价值，因为它可以简化问题的诊断(考虑到一次只使用一个模块)，但无法测试系统，因为它实际上将被使用。在这个意义上，可能属于象限2。

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

选项3基本上是选项2的一个不那么灵活的版本，您也失去了与单个模块的大量交互，这些模块使得选项2变得非常有价值(因为它将整个系统作为一个整体进行操作)。一个足够“真实世界”的数据库可以使它成为一个Q3选项，但是您仍然在失去灵活性。

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

希望这能有所帮助。