正如陈雷在《MIS系统中的报表测试》中所言,在报表中,我们很难直观地通过某个数据项,看到它的算法和数据源。在报表测试用例设计中,第一步就是分析报表的数据源和算法。
不同业务报表之间的区别是很大的,特别是在不同行业之间。在分析报表前,首先,我们要提高对业务的熟悉程度。对于某些系统,如计费系统等统计精度较高的系统,我们甚至需要达到精通的程度。那么,是不是报表的分析就全无规律可循呢?不是的。下面将介绍我在分析报表时惯常使用的几个切入点,希望对大家有一定的启发。
1、源数据的来源
源数据,即保存在报表数据库中的数据。源数据的来源,大致可分两大类:
A、由业务系统生成
报表数据库中的数据是由前台业务系统插入的。报表系统和业务系统是关联着的,甚至它们根本就在使用同一个数据库。如此一来,前台的操作即直接反应在报表的统计值上。在这种情况下,我们测试用例的设计,重点放在影响报表统计值的前台业务场景的设计上。
例如,某点播系统中的点播率报表,其报表统计值有效点播次数的源数据,就是点播业务所关联的点播数据库表。在测试用例设计中,我们重点考察不同场景的点播对报表统计值的影响。而场景的设计除了考虑前台业务规则外,更重要的是考虑报表的统计规则。如例子中,有效点播次数的统计规则是,视频购买后1分钟内的重复点播不计入有效点播次数中。这样一来,场景的设计就不能只是点播一次和点播多次这么简单。
B、来源于第三方数据库
有些报表系统与业务系统是分隔的,各自独立的。这样的设计,更多地出现在大型系统中。如此设计,既可以确保业务系统和报表系统各自的性能,又可以提高报表系统的扩展能力,即使用一个报表系统对不同业务系统的数据进行整合和分析。当然这个设计也有不足之处,即报表的实时性。
在这种情况下,测试用例设计的重点应该放在报表数据库源数据的设计上,重点考察第三方数据到报表数据库传递的正确性,源数据的完整性,以及不同业务源数据的相互影响。
2、报表的算法
算法,是指源数据演变成统计值的过程。报表的算法应详细清晰地记录在Functional Specification中。根据算法的复杂程度,我将报表划分为三大类: