报表测试系列之基于OLAP的报表测试

在2月的最后一个星期，经历了半年的设计、开发、测试的报表系统进入了UAT阶段。我是这个基于OLAP技术报表系统的测试人员，从系统需求分析、设计，到后来的IT、ST，还有现在的PT，我都一直参与其中。这个报表测试系列的总结，也是这个项目触发而来的。

 

OLAP (On-Line Analysis Processing)，联机分析处理，是一种用于组织大型商务数据库和支持商务智能的技术。在参与这个项目之前，OLAP相关的维度(Dimension)、Cube、Measure等概念，我完全没有认识。而现在的我也只是知其皮毛，而这些也是在项目的过程中，一点一点积累和恶补回来的。因此，在本文中，我更多地是站在一个测试人员的角度，去看基于OLAP的报表系统的测试。其中涉及到一些专业技术，可能会有误解，还请各位读者指正。

 

1．  了解系统架构

根据黑盒测试方法的原则，不管报表系统内部采用的是什么技术，我们只需要定义好Input/Output就能测试出系统是否正确运行。然而，这对于基于OLAP技术开发的系统，远不足够。了解报表系统架构，是指我们需要去了解系统的组件、每个组件的职能、组件之间的联系、数据流的走向。当有了清晰明确的概念后，我们才可以明确测试用例需要涵盖的范围；当遇到Defect时，就更容易追踪问题的根源了。

系统架构一般在FS中有概述，在ADS中有详细描述。对于测试人员而言，除了认真阅读这些文档外，还要在ADS的Review Meeting中仔细地听，并多发问。请不要认为自己的问题对于设计人员而言是简单而没有意义的。相反，你的发问，可以使设计人员反复地去思考设计。他解释的过程，也是理顺思路的过程。经得起推敲的设计，才是合理的设计。

2．  维度缺失测试

基于OLAP技术的系统，一般包含有两大组件Data Ware和Cube。Data Ware就相当于一个数据仓库，用来储存生成报表的源数据；Cube就是那个多维度的数据集，我们可以把它想象成一个魔方，每一条棱都是一个维度，而中间的方格就是维度切片下的各个数据。那么让我们想象一下，如果魔方没有了棱会如何呢？这个就是我们这里所说的维度缺失测试。

维度缺失，指的是事实数据找不到与之对应的维度值。这也属于异常数据的一种。例如，Data Ware中有营业点A的销售数据，然而维度中却没有营业点A的定义，那么这条销售数据应该放置在Cube的哪个地方呢？是暂时不处理，等待维度补全后再重新填入Cube；还是使用推断成员的技术，自动补充缺失维度呢？这是设计时需要确定，也是测试时需要关注的问题。

3．  测试点的选取

产品	区域	营业	Jan-11	Feb-11	Mar-11	Apr-11	Total
Iphone	大中华	中国大陆	10	10	10	10	40
		港澳	10	10	10	10	40
		Subtotal	20	20	20	20	80
	美洲	美国	15	15	15	15	60
		加拿大	15	15	15	15	60
		Subtotal	30	30	30	30	120
	Subtotal		50	50	50	50	200
Ipad	欧洲	英国	20	20	20	20	80
		法国	20	20	20	20	80
		Subtotal	40	40	40	40	160
	美洲	美国	25	25	25	25	100
		加拿大	25	25	25	25	100
		Subtotal	50	50	50	50	200
	Subtotal		90	90	90	90	360
Total			140	140	140	140	560

 

基于OLAP技术的报表系统中，我们选取数据测试点的原则：

n         维度的统计值

原因在于报表中每一行所应用的Measure都是一样的，所以说只要一行中的一个算对了，整一行都会算对。如上表所示，底色为黄色的统计值我们都需要验证。

n         Total值

Total值的测试主要是应用在统计值不是简单的求和的情况下。如，百分比，或者需要应用公式的统计值。这些Total值不是简单的将所有维度值进行相加，而是需要从源数据中重新抽取数据应用公式计算而来的。