Sql server 报告系统测试计划

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

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

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

我的困境是如何接近报告模块的黑盒测试计划。在我看来，有三种选择：

• 将报告测试用例附加到影响它们的模块的测试计划中（缺点：模块一起工作以生成报告；报告不能像这样按模块划分）
• 为报告编写一份测试计划，其中包含指定的先决条件，这些先决条件基本上是其他模块中要执行的任务的说明列表，然后是测试用例，以测试报告是否针对这些任务正确生成（缺点：非常复杂且冗长）
• 编写一个测试计划，在专用的受控SQL数据库上使用集合数据集进行报告（缺点：缺乏灵活性）

在我看来，第二种选择是最好的。这是最冗长的演讲，但单凭这一点很难成为打折的理由

是否有人有过测试纯粹用于报告的模块的经验，谁有希望提供对实现此目的的最佳/行业标准方法的见解

---

提前谢谢

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

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

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

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

方案3基本上是方案2的一个不太灵活的版本。您还失去了与各个模块的大量交互，这使得选项2非常有价值（因为它将整个系统作为一个整体来运行）。一个足够“像真实世界一样”的数据库可以让它成为第三季度的选择，但您仍在失去灵活性

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

希望有帮助