BI测试

 BI概念：

商业智能（Business Intelligence 简称BI），指数据仓库相关技术与应用的通称。指利用各种智能技术，来提升企业的商业竞争力。是帮助企业更好地利用数据提高决策质量的技术，包含了从数据仓库到分析型系统等。这些分析有财务管理、点击流（Clickstream）分析、供应链管理、关键绩效指标（Key Performance Indicators, KPI）、客户分析等。
BI实际上是帮助企业提高决策能力和运营能力的概念、方法、过程以及软件的集合，其主要目标是将企业所掌握的信息转换成竞争优势，提高企业决策能力、决策效率、决策准确性。
确切地讲，BI并不是一项新技术，它将数据仓库(DW)、联机分析处理(OLAP)、数据挖掘(DM)等技术与客户关系管理（CRM）等结合起来应用于商业活动实际过程当中，实现了技术服务于决策的目的；Mark Hammond从管理的角度看待BI，认为BI是从“根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或者知识），并且在恰当的时间通过恰
当的手段把恰当的信息传递给恰当的人”。

BI测试：

BI定义 BI是Business Intelligence简称，中文释为商业智能，又称商务智能。通常理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。商业智能的概念于是1996年由加特纳集团（Gartner Group）最早提出：“商业智能描述了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的制定。商业智能技术提供企业迅速分析数据的技术和方法，包括收集、管理和分析数据，将这些数据转化为有用的信息，然后分发到企业各处。” 目前，学术界对商业智能的定义并不统一。

BI的发展趋势：

• 功能上具有可配置性、灵活性、可变化性 
• 从单独的商业智能向嵌入式商业智能发展
• 从传统功能向增强型功能转变
• 加强了绩效管理功能
• 产品模块的集成
• 加强处理结构化和非结构化数据的能力
• 加强了预测分析功能

国际BI厂商

BI测试范围：

• 数据源—数据仓库：增量、全量数据加载测试；
• 数据仓库—数据集市：基础层脚本测试、应用脚本测试、任务/作业调度测试；
• 数据集市—前端展现：前端展现测试、业务验证测试。

数据仓库测试（以HOLAP数据仓库测试为例）：后台数据库的测试 结构测试（分为3部分）

• 测试表是否存在：使用测试用 例（Test Case）如下SQL所示：  如果运行结果返回0，则说明目的表不存在与当 前后台数据库中，如果返回值为1，则表明目的表存在于当前后台数据库中。   Select Count(1) from dbo.sysobjects where id = object_id(N’表名’ ) and  objectproperty(id, N’IsuserTable’) =1测试表是否完整正确：表的完整性测试主要是指表的结构必须和ER 图相一致，在这个测试部分必须测试 以下几个部分：  首先，需要验证目的表的字段是否和ER图相同，目的表不能增加也不能丢失任何 字段；  其次，需要对每一个字段的数据类型进行验证，如INT不能是BIGINT类型，或者 CHAR不能是VARCHAR类型；再次，对每一个数据类型的长度进行验证，数据类型 长度太长会降低系统的性能，而数据类型太短则会影响数据的精度。最后，必须对每一个字段的约束进行验证，如该字段是否允许为空，是否是能自增 长等。 在SQL2000系统中，可以使用“SP_HELP 表名”得到测试表的结构信息。

• 测试表的主外键是否正确： 众所周知，表的主键是定义了表的记录完整性，而外键则表明了参照完整性，因而 表的主外键在表中是非常重要的，所以必须单独从其它测试部分分离出来，作为一 个独立的测试模块进行验证。   同样，在SQL2000系统中，可以使用“SP_HELP 表名”得到测试表的主键和外键的 信息。 关系测试 数据仓库中各种表之间存在这一种关系。这种关系即是人们早已熟知的“参照完整性”。“参照完整性”测试是数据仓库测试的一个重要模块。“参照完整性”也称为“引用完整性”（在本文中统一称为参照完整性），参照完整性指添加，修改或删除记录时，表间的关联性不可破坏。在SQL Server中，参照完整性基于主键与外键或唯一键（Unique）与外键的关系。参照完整性确保在各个关联的表中的值是一致的【1】。      对于数据仓库，存在着事实表（Fact Table）和维度表（Dimension Table），如果删除维度表中的某条记录，那么对应的事实表也必须删除相关记录， 如果事实表插入新的记录，那么维度表也必须插入相关的记录。

如下图所示，有一个事实表和五个维度表（维度表A，维度表B，维度表C，维度表D，维度表E），这六个表通过主外键关系相关联。事实表和维度表A通过A_ID建立参照完整性的关系；同样，事实表和维度表B通过B_ID建立参照完整性的关系；事实表和维度表C通过C_ID建立参照完整性的关系；事实表和维度表D通过D_ID建立参照完整性的关系；事实表和维度表E通过E_ID建立参照完整性的关系。因此，作为测试人员必须至少写5个测试用例来测试这个参照完整性。

可以用如下5个测试用例来验证上图中数据仓库的星型模型中事实表和维度表的参照完整性： •  Select  count (1) from 事实表nolock  where A_ID not in (select A_ID from 维度表A nolock)  Select  count (1) from 事实表nolock  where B_ID not in (select B_ID from 维度表B nolock)  Select  count (1) from 事实表nolock  where C_ID not in (select C_ID from 维度表C nolock)  Select  count (1) from 事实表nolock  where D_ID not in (select A_ID from 维度表D nolock)  Select  count (1) from 事实表nolock  where E_ID not in (select A_ID from 维度表E nolock)  如果以上5个测试用例返回不等于0的值，则说明不满足参考完整性，前端立方体（Cube）必定会刷新失败。

数据测试：数据仓库的核心是大量的数据，数据在进入数据仓库之前必须对数据进行预处理，包括抽取，转换和加载（ETL）。测试人员必须测试这些数据是否准确，精度是否丢失，是否符合需求说明。如下图中一个简单的数据转换和传输例子，数据源的数据必须经过稍微的变换后加载到目的表中。数据源的字段A和关联表关联后得到字段A1加载到目的表中，其他数据源字段B，C ，D和Value1，Value2，Value3直接加载到目的表的B，C ，D和Value1，Value2，Value3。

 

可以用如下几个测试用例来验证上图中数据仓库的数据传输后的数据准确性：   Select  count(1) from 数据源  inner join 关联表 on数据源 .A =关联表.A  Inner join 目的表 on关联表.A1 =目的表A1  And  数据源.B=目的表.B   And  数据源.C =目的表.C  Where  数据源.Value1 <>目的表.Value1  Select  count(1) from 数据源  inner join 关联表 on数据源 .A =关联表.A  Inner join 目的表 on关联表.A1 =目的表A1  And  数据源.B=目的表.B   And  数据源.C =目的表.C  Where  数据源. Value2 <>目的表.Value2  Select  count(1) from 数据源  inner join 关联表 on数据源 .A =关联表.A  Inner join 目的表 on关联表.A1 =目的表A1  And  数据源.B=目的表.B   And  数据源.C =目的表.C  Where  数据源.Value3 <>目的表.Value3  Select  count(1) from 数据源  inner join 关联表 on数据源 .A =关联表.A  Inner join 目的表 on关联表.A1 =目的表A1 And  数据源.B=目的表.BAnd  数据源.C =目的表.C  Where  数据源.Value4 <>目的表.Value4  或者可以用一个SQL语句实现如上所有的功能：  Select  count(1) from 数据源  inner join 关联表 on数据源 .A =关联表.A  Inner join 目的表 on关联表.A1 =目的表A1  And  数据源.B=目的表.B   And  数据源.C =目的表.C  Where  数据源.Value1 <>目的表.Value1  Or  数据源.Value2 <>目的表.Value2    Or数据源.Value3 <>目的表.Value3   Or 数据源.Value4 <>目的表.Value4  对于精度误差问题，可以用“ ABS(数据源.Value -目的表.Value) <0.001” (注：假设0.001是允许误差)来代替“数据源.Value <>目的表.Value”  如果以上测试用例返回不等于0的值，则说明数据传输和转换失败或错误。

数据仓库测试（以HOLAP数据仓库测试为例）：

前台立方体的测试

维度测试

1、维度结构测试

 

以地理维度为例子，见图2.1，该维度有3个级别，分别是Big Area Name，Region Name和Country Medium Name。因此，对结构的测试分为2个小部分：  按照需求说明书验证该维度是否是3个级别，在验证每个级别是否和需求一致。  必须验证有无拼写错误。 

 2、维度数据测试

 

对于每一个级别，必须要验证数据的准确性，所以，对于Big Area Name，必须在 后台数据库中运行如下SQL语句:   Select distinct [Big Area Name] from GeographyDim nolock   把得到的结果和如下图2.2.1维度值展示红色部分的结果进行比较，如果一致则说 明Big Area Name没有错误。   接下来进行Region Name的测试，必须在后台数据库中运行如下SQL语句:  

elect distinct [Region Name] from GeographyDim nolock   where [Big Area Name] = ‘N.America’   把得到的结果和如下图2.2.1维度值展示绿色部分的结果进行比较，如果一致则说 明Region Name没有错误。   最后进行Country Medium Name的测试，必须在后台数据库中运行如下SQL语句:   Select distinct [Country Medium Name] from GeographyDim nolock   where [Big Area Name] = ‘N.America’  And Region Name = ‘Canada’   把得到的结果和如下图2.2.1维度值展示蓝色部分的结果进行比较，如果一致则说 明Region Name没有错误。

3、级别间关系测试

众所周知，数据仓库一般会有很多个数据源，因此常常会遇到这样一个问题，某个 国家在A系统属于亚洲部分，在B系统属于欧洲部分，但在数据仓库中是不允许 出现这样的数据，数据必须保持一致，不能出现一个孩子拥有多个父亲的现象出现， 否则会导致该该数据仓库中地理维度的分类错误。当然可以使用如下SQL语句进 行每一个级别间的关系验证。   Select  国家 from(  Select  国家，区域 from GeographyDim nolock  Group by国家，区域) A Group by国家  Having count(1) >1   如果上面的SQL返回任何国家，则说明这些国家属于多个区域，意味这数据有问题。

数据仓库测试（以HOLAP数据仓库测试为例）：

前台立方体的测试

立方体度量测试

1、立方体度量结构测试

结构测试包括度量的个数，数据类型（货币，字符，整型，精度），显示的格式，所在文件的路径都必须符合需求说明书的定义。 在图2.2 度量展示中，按照需求说明书的定义，度量Sell In Sales Unit 的路径必须是Sell In Sales FactSell In Sales。数据显示格式为#,#，数据类型为整型。

2、立方体度量值测试

对度量值的测试必须紧密的结合每一个维度。 如上图2.2.2度量值和维度结合展示数据 所示，度量值Sell In Sales Unit结合了时间维度（红色区域），地理维度（蓝色区域）和产品维度（绿色区域）进行数据的显示。可以使用下面SQL模板实现数据的验证，来检验前台立方体的数据是否准确。  Select by [Big Area Name],[ProductName], sum(Sell In Sales Unit) [Sell In Sales Unit]from 销售事实表 A Inner join 时间维度表 B  on A.DateId = B.DateID Inner join 产品维度表 C on A.ProductID = C. ProductID Inner join 地理维度表 D on A.GeoGraphyID = D. GeoGraphyID Where FiscalYear = ‘2008’ Group by [Big Area Name],[ProductName] 

BI测试策略 ：

*模型建表语句或导数语句测试

• 验证与前一版本的差异
• 新旧模型字段的差异性
• 模型与脚本的相互验证
• 验证导数语句是否正确

*ETL脚本测试

• 源表目标表数据量核对
• 拉链表拉链逻辑检查
• 标准代码转换
• 总分关系延续性

*任务/作业调度测试

• 废弃任务是否被删除
• 调度作业是否符合设计
• 调度是否重复配置
• 依赖是否覆盖完全

*数据口径验证

• 规范口径规则说明书
• 第三数据比对
• 业务主导双路比对
• 新旧系统对比

 BI测试方法：

黑盒测试

• 以脚本跑通出数为重，检查脚本内出现较为严重手工编码错误

白盒测试

• 主要检查脚本ETL程序代码，包括表表关联检查、特列字段计算公式检查、case when条件语句是否正确

指标测试

• 检查数据加载完后目标表的各项技术指标是否正确，包括PI值检查、空值检查、规范性检查等

性能测试

• 数据容量测试、数据时间窗口期测试、数据处理的连续性和持续性

BI测试工具：

黑盒测试 -- 场景测试脚本

白盒测试 -- 开发/生产环境

指标测试 -- 测试脚本

性能测试 -- LoadRunner