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