在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值不是简单的将所有维度值进行相加,而是需要从源数据中重新抽取数据应用公式计算而来的。