報表測試中的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. 測試點的選取

　　基于OLAP技術的報表系統中，我們選取數據測試點的原則：

　　n 維度的統計值

　　原因在于報表中每一行所應用的Measure都是一樣的，所以說只要一行中的一個算對了，整一行都會算對。如上表所示，底色為黃色的統計值我們都需要驗證。

　　n Total值

　　Total值的測試主要是應用在統計值不是簡單的求和的情況下。如，百分比，或者需要應用公式的統計值。這些Total值不是簡單的將所有維度值進行相加，而是需要從源數據中重新抽取數據應用公式計算而來的。

原文轉自：http://www.anti-gravitydesign.com