分析仪表板的QA测试策略

时间:2009-10-13 21:35:00

标签: qa dashboard cognos

我的团队正在使用Cognos为SaaS /多租户应用程序构建分析仪表板。我遇到的问题是正确的测试策略。

现在,测试一个包含开始和结束日期过滤器的报告(以月/年格式),一维过滤器和两个用于选择度量的控件(有7个度量,可以表示为总和或不同的计数)

此外,用户可以将生成的报告中的点钻取到详细的交易数据。

隐含也是一个租户的报告不显示不同租户的数据。

所以,这就是问题所在。对这个简单报告的测试需要两周时间,涉及数百个测试,包括大量的过滤器和度量组合。这对我来说似乎有点过分。

是否有“策略”可用于可靠地减少搜索空间并避免过度重复测试?

3 个答案:

答案 0 :(得分:1)

好问题! 当我们通常发布(或想要)基于Tableau的新报告时,我们通常会要求某些人充当超级用户组来使用报告,就像在生产中一样。虽然这可能不需要一段时间,但是说你只有2天的时间来测试它,但会在几周内继续。与此同时,可以进行错误修复或更改并将其重新分配到同一组,而无需花时间停止测试人员,让他们等待修复,然后继续。

不要误解我的意思,限期发布日期仍然是理想的,但实际上报告实际上是在一个小组内进行循环 - 通常有助于比通过每个参数测试用例更快地移动事物。

答案 1 :(得分:1)

听起来他们正在尝试测试报告可以使用的“每种可能的组合”。对于一些最能代表典型或关键报告的选择报告,这样做可能是明智的。这将有助于消除设计,体系结构或实现中的严重缺陷。

但是,试图为每个报告测试每个可能的组合,以期找到每个bug都是不可能的。 Ajdams建议很有意义,并且是所需的“妥协”的典型。这完全取决于时间,资源以及最适合这种情况的因素。

所以我建议将两者结合起来(选择一小部分报告进行大量测试,但要确保他们专注于发现可能被其他报告共享的错误)。然后使用ajdams等技术测试每个报告。

答案 2 :(得分:0)

真正有助于您的测试赶上速度和可靠性的是实际准备包含报告所需功能的测试脚本。正如之前所建议的那样,测试用户组将帮助您在beta测试时发现错误和设计缺陷。