我的团队正在使用 Cognos 为 SaaS/多租户应用程序构建分析仪表板。我遇到的问题是正确的测试策略。
现在，使用开始和结束日期过滤器（月/年格式）、一维过滤器和两个用于选择度量的控件测试一份报告（有 7 个度量，可以表示为总和或不同的计数） .
此外，用户可以通过生成的报告中的点钻取详细的交易数据。
隐含的是，一个租户的报告不显示不同租户的数据。
所以，这就是问题所在。测试这个简单的报告需要两周时间，涉及对大量过滤器和度量组合的数百次测试。对我来说，这似乎太过分了。
是否有一种“策略”可用于可靠地减少搜索空间并避免过度重复测试？
【问题讨论】：
好问题！ 当我们通常发布（或想要）基于 Tableau 并命中 SSAS 多维数据集的新报表时，我们通常会要求某些人充当超级用户组，以像在生产环境中一样使用报表。虽然这可能不需要固定的时间，假设您只有 2 天的时间来测试它，但会持续几个星期。与此同时，可以进行错误修复或更改并将其重新分配给同一组，而无需花时间停止测试人员，让他们等待修复，然后继续。
不要误会我的意思，有一个截止发布日期仍然是理想的，但让报告在一个小组中实际发布通常比通过每个参数测试用例更快地推动事情。
【讨论】：
听起来他们正在尝试测试可以使用报告的“所有可能的组合”。对于最能代表典型或关键报告的一些精选报告，这样做可能是明智之举。这将有助于消除设计、架构或实施中的严重缺陷。
但是尝试为每份报告测试每一种可能的组合以希望找到每一个错误是不可能的。 Ajdams 的建议很有道理，是典型的“妥协”要求。关键在于时间、资源以及对情况最有意义的因素。
因此，我建议将两者混合使用（选择一小部分报告进行广泛的测试，但确保他们专注于发现可能与其他报告共享的错误）。然后使用 ajdams 等技术测试每个单独的报告。
【讨论】：
真正帮助您的测试赶上速度和可靠性的方法是实际准备包含报告所需功能的测试脚本。如前所述，Beta 用户组将帮助您在进行 Beta 测试时赶上错误和设计缺陷。
【讨论】：