How to test a datawarehouse(ZZ)

译者不详，转自这里。
http://qzone.qq.com/blog/85505526-1216539937
英文原文
http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310594,00.html

这篇文章是应一位读者关于如何测试数据仓库的问题而写。他的问题是：“在数据仓库环境下进行测试时如何处理需求与质量的关系？”虽然数据仓库的测试是 一个惊奇而神秘的过程，但实际上它与其它测试项目并无多大区别。基本的系统分析和测试过程在这里仍然有效。我们来看一下其中的几个步骤，并研究如何在数据 仓库环境中应用。

分析源文件

　　与其它项目一样，测试数据仓库部署时，通常都会有一份相关的说明文件。虽然这些文件对于创建基本的测试策 略非常有用，但经常会缺少一些关于测试开发与执行的详细资料。有时会有一些其它文件解释技术上的细节问题，即从源到目标的转化（source-to- target mappings）说明文件。这些文件详细说明了数据的来源、如何对数据进行操作，以及存储到哪里。如果能拿到这些文件，关于系统设计的文件在设计测试策 略时也会变得更加有用。

开发策略和测试计划

　　分析了各种各样的源文件后，就要开始创建测试策略。我发现从生命周期和质量的角度来看，增 量测试是测试数据仓库的最好办法。这从本质上意味着开发团队会从开发过程的早期开始，将各种小组件交付给测试团队。这个办法的主要优点是避免交付让人吃惊 的“大块”组件，可以从早期开始检验缺陷，并使调试变得简单。此外，这个方法还有助于在开发与测试周期中建立详细的过程。具体到数据仓库测试，即是对数据 获取分段表，然后是增量表、基本的历史表格、BI视图等的测试。
　　另一个制定数据仓库测试策略的主要问题是基于分析（analysis- based）的测试方式和基于查询（query-based）的测试方式的选择。纯基于分析的方法是让测试分析师通过分析目标数据和相关标准计算出 预期结果。基于查询的方法有相同的基本分析步骤，但更进一步，用SQL查询语言编写预期结果。这为将来建立回归测试过程节省了很大精力。如果测试是一次性 的，那么用基于分析的方式就足够了，因为通常这种方式较快一些。反之，如果企业对回归测试有持续的需求，那么基于查询的方式会更为合适。

测试的开发与执行

不管在测试执行过程之前还是之后进行测试的开发，要根据上行需求的稳定性和分析过程决定。如果情况变动比较频繁，那么早期进行的测试开发可能大部分都会被 废弃。这种场合，实时进行的整合的测试开发和执行过程通常会更有效果。不管怎样，在设计测试开发和执行过程的框架时，参考一下测试分类总是有用的。比如， 一些数据仓库的测试分类可能有：

• 记录计数（预期与实际对比） [Y:For CDC(A & D) is pretty good.]
  
• 副本记录
• 参考数据有效性[Y: Data Cleanse??]
• 参照完整性
  
• 错误与异常逻辑
  
• 增量过程与历史过程 [Y:For CDC(C) is pretty good.]
• 控制栏值与默认值
  

除这些分类外，还可以参考缺陷分类学，比如Larry Greenfield的分类。测试执行时，准确的状态报告过程是经常被忽略的一个方面。在确定团队里的其他人明白你的方法的前提下，测试分类和测试进度可以保证他们对测试状态也有一个 清楚的概念。有了详细的规划并坚持到底，以及良好的沟通，就能建立一个数据仓库测试过程，帮助项目团队取得满意的成果。

关于作者：Baher Malek目前在财富杂志排行前100的公司任质量与测试总工程师，帮助传统的项目团队采用敏捷方法进行软件测试。Baher还经常参加IWST和WOCST研讨会并发言（即印第安纳波利斯软件测试研究小组和软件测试员开放认证研讨会，详见http://www.iwst2008.com/与http://www.freetestingcertification.com/workshops.html）。