一、需求理解

数据仓库系统是为决策制定过程提供支持的所有类型数据的战略集合，是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合。它接入全行所有外围系统数据，是一个具有全行业务视图，面向各种管理系统的统一应用数据平台。
启动数据仓库新一期建设，主要完成进一步完善数据范围，丰富汇总及指标数据，改进基于指标数据的报表开发方式，优化调度、数据加工及报表处理应用架构，实现多级存储备份策略，构建应用数据集市等内容。

二、测试目标

检测数据正确性测试：验证数据服务层内各区的加载正确性
检测后台各 ETL 脚本的各项技术指标是否符合要求；
检测各数据层间的接口正确，数据能正常流转传递；
检查系统上线初始化、建表及导数语句正确性；
检查系统调度依赖关系配置是否正确。
检查流程调度测试，检测 ETL 任务触发依赖关系的正确性
数据流架构
源数据层 -> ods层 -> 基础层 -> 中间层 -> 应用层 -> 集市层

三、测试方法

ETL 脚本测试

1. 主键重复检查
   检查目标表记录中是否有主键字段出现重复的现象。
2. 主索引分布均匀程度
   主索引值的分布情况直接影响到主索引的使用效率。所以数据模型测试需要检验主索引的分布均匀程度，从而验证模型的主索引设计的准确性。这类指标可以从平均值和数量标准差两个指标来分析。
   平均值反映了平均每个索引值所对应的记录数，该值 1 为最佳值，表示所有索引值都只对应一条记录，这样的索引效率最高。
   数量标准差用于考察整个主索引中记录的分布偏离平均值的情况，这个值越小越好，值越小说明每个索引值所对应的记录数越靠近平均值，分布越均匀。
   经常需要将这两值综合起来考虑，考虑两者之间的倍率情况，数量标准差超过平均值一倍为不均匀现象。
3. 拉链表的状态
   在数据仓库中可能存在着大量的拉链历史表，由于拉链算法本身的复杂性，导致许多对拉链表进行操作的作业有可能会隐藏着许多潜在的问题。但是因为做测试环境的数据量有限，不可能积累长时间的历史数据，导致对拉链表的测试存在很大的困难。
   对于测试主要从以下几个步骤进行：
   1) 将拉链表 END_DATE 字段值为最大日期的记录拿出来与源表对比，检查找出值不一致的记录；
   2) 如果有两天以上的数据，可分别执行源表与数据仓库中的表的连接；
   3) 检查倒链，主要是检查是否存在开始日期小于和等于结束日期的记录。
4. 代码检查
   因为代码字段在从源系统进入数据仓库系统这个过程中，可能会存在着对代码进行转换的操作，测试需要检验这种转换是否会改变代码业务含义。这种转变可能会存在两种不同的方式，包括：一对一转换，多对一转换。其中一对一指将源系统代码的编码方式转换成数据仓库系统内部的编码，这类的代码的种类范围都和源系统的代码一致，同时每类代码在所有代码中的占比也是一致的。另外一种就是多个源系统代码合并成数据仓库系统中的一类代码，这类转换需要分析它的转化规则然后再检验代码的转换是否正确：
   1) 代码的取值种类和代码的范围与源系统的一致性；
   2) 每种代码的占比是否与源系统中对应代码占比保持一致。
5. 记录数一致性
   源系统的记录数与进入数据仓库系统的记录数是否一致（剔除根据需求不需要进入数据仓库系统的数据）。
6. 作业重复执行性
   检查作业是否能够重新执行特定日期的任务，并且保证重新执行后的数据能准确地放映当时历史时点的数据状况。
7. 删除的数据正确性
   由于数据仓库系统对数据更新的操作一般为先删除后插入的方式，所以基本上作业都会存在对旧数据进删除的操作。所以测试需要验证在操作了这种删除和插入之后不会导致记录的丢失。
8. 特定字段的约束检验
   对于特定的字段，可能存在着具体的业务约束或特征，如：取值种类，取值范围，记录唯一等。在测试时，需要根据具体的业务规则和约束对具体的字段进行验证。
9. 总分关系延续性
   总分约束关系主要是针对在源系统中存汇总表与明细表之间必须保持一致的关系。具体表现为：汇总表中的总数值要与明细表中该类数据的合计保持一致。在银行的账户类数据中存在着大量这样的情况。对于这类关系的处理也是通过对比数据来实现对作业的检测。
10. 主外关系延续性
    主外约束关系主要是针对在源系统中存在表与表之间的主键与外键的约束关系。这类关系的特征就是，一个表某个字段的内容依赖于其它表的特定字段。具体表现为：依赖字段的取值一定要在被依赖字段中存在。
11. 复杂算法的正确性
    对于复杂的数据处理原则，测试需要对其算法进行验证。这种算法需要从需求出发，提炼算法规则，并将符合此类规则的数据提取出来，运用算法加工这部分数据并将结果与作业结果进行对比。

另外，在基础层 -> 应用层的数据测试过程中采用以下 5 种测试方法从业务角度出发来验证数据的准确性：

1. 指标核对法
   针对某一指标，以已有业务系统该指标值为标准值，分析造成当前业务系统该指标值（待核对值）与标准值的差异的原因；
2. 抽样检验法
   根据一定的抽样检验方案，抽取从源到目标一系列过程中的相关数据进行检验，以判断数据加工规则是否正确；
3. 趋势分析法
   将两期或多期连续的相同指标进行同比和环比对比，得出它们的增减变动方向、数额和幅度，进而分析数据是否正常；
4. 极值法
   统计某些业务指标在一定条件下的极值，根据业务意义判断这些指标值是否正常；
5. 分户账核对法
   根据不同业务系统中，相同机构、相同科目、相同币种下，分户账余额汇总值的差异，分析其原因，从而找出数据加工过程中存在的问题。

建表 / 视图、数据初始化语句或导数语句测试

1. 验证建表 / 视图、数据初始化语句与前一版本的差异，主要通过文本比较工具进行比较；
2. 新旧模型字段的差异性，验证模型字段是否出现删减情况，如果出现该情况需要向设计人员确认；
3. 建表 / 视图、数据初始化语句与脚本之间的相互验证，验证相应的脚本在新的建表 / 视图、数据初始化语句上运行是否正确，一般空跑即可；
4. 验证导数语句是否正确，验证目标表与源表的结构、数据是否一致。

作业调度测试

1. 验证调度是否能正常运行；
   每个调度都有一个开始作业,中间不进行其它操作,观察调度能否正常跑完；
2. 任务的命名是否合乎规范，与脚本名是否一致；
   根据仓库规范，调度任务名和原脚本名称要保持一致，否则任务将执行错误，根据出错的任务，可检查出任务的命名是否符合规范；
3. 验证废弃任务是否被剔除；
   检查调度模板中类型为删除的任务，查找该任务在调度工具调度是否中还存在，如存在，即调度配置错误；
4. 验证任务的依赖是否正确、是否覆盖完全；
   分析系统脚本，得出一份脚本的依赖关系列表，再与调度进行核对，每个脚本在调度中都有一个任务名，首选从主脚本开始查找脚本在该调度中的任务名称，在依赖关系列表中进行记录，如果在调度中无法查到，说明该依赖被遗漏。然后再查找该脚本在调度中的依赖是否与关系中的依赖相同，用这种方法逐个脚本的往下核对，可以测试出调度依赖是否正确、覆盖是否完全；
5. 验证调度运行频率、翻牌是否符合设计；
   在某一业务日期的调度全部执行完毕后，并能正确进行下一业务日期的执行，则表明调度的翻牌符合设计要求。目前调度工具调度按照脚本运行频率分组设计，让调度多翻牌几次，查看运行日志，检查调度的业务日期与脚本的执行日期是否一致，如一致则表明运行频率正确；
6. 验证任务出错时是否影响调度的正常运行；
   调度工具调度在运行时，作业会因库空间不足、SPOOL空间不足、数据质量、脚本问题等原因导致执行失败。针对此类情况，可以用人为干预的方法导致要测试的作业执行失败，例如可以在脚本中设置语法错误、修改测试数据等，用来测试在该任务失败后，后续依赖任务是否可以继续执行，调度是否能够翻牌；
7. 验证调度执行完毕后，检查结果数据是否符合要求：
   调度正常执行完并翻牌一次后，可用集成测试的案例的执行来检验结果数据是否符合要求。此类检查不要求执行全部的案例，只需选择优先级高或者测试范围大的案例来执行，须尽量保持检验的粗粒度。
   通过查看日志（日志产生的时间先后，日志内容）来确定调度运行时间、调度依赖是否正确。
8. 验证调度是否重复配置。
   调度工具调度的任务写入后台数据库调度表，可以用查找调度表的方法,来检查任务是否重复配置，如果查询结果为两条或以上,表明此任务已经重复配置,调度配置错误。

前台应用测试

1. 数据准备性测试
   a) 子表与父表的对比测试
   b) 数据库数据分析与实际统计结果对比测试
   c) 输出数据格式的正确性测试
   d) 明细表与汇总表的一致测试
2. 报表格式的测试
   a) 报表整体风格测试
   b) 报表标题测试
   c) 报表页面测试
   d) 报表分页测试
3. 报表权限的测试
   a) 不同权限查看的报表名称测试；
   b) 不同权限查看报表数据的测试
4. 报表输出结果测试
   a) 报表打印测试
   b) 报表导出测试
   c) 报表预览测试

上线演练测试
制定上线演练流程：根据生产上线的实际过程编写上线演练流程，流程中的每一个步骤必须是可操作的语句；
环境搭建：测试环境要尽量和生产环境一致，模拟生产环境的相关表和数据；
验证方式：检查调度是否能成功运行，包括能否正常翻牌等。检查调度跑完之后数据交换平台中各部分中的数据是否正确，检核卸出的数据是否正确。

四、大体流程

前期数据准备过程中采用脱敏后生产数据，避免数据数据间的关系性丢失。满足日期要求（包括月末、年末等特殊时），各源系统采用同一分行、同一时点（同一会计日期）测试数据。

单元测试的阶段主要是针对数据映射文档的静态测试以及和 ETL 有关的测试，包括临时区数据加载测试、基础区数据加载测试、汇总和集市区的加载测试。数据映射文档的静态测试主要针对加载算法选择是否正确、字段映射是否正确；关联条件正确性检查。临时层加载主要关注加载数据完整性、数据类型转换正确性、字符编码转换正确性，基础区数据加载主要关注源表、目标表记录数匹配检查、目标表的主键重复检查、历史拉链算法加工后的目标表是否存在断链、交叉链、倒链等问题。汇总和集市区数据加载测试主要做的是：结合映射文档检查脚本内容，逻辑上是否保持一致，数据异常检查（包括空值、异常值），金额相关内容核对，复杂算法的正确性验证。

五、测试策略

不断探索和尝试数据质量的各类测试方法，不断提升测试质量和效率；对报表准确性测试主要采用新旧比对、抽样比对、 表间勾稽关系比对（同口径不同维度的报表互相验证）、双路比对、总分关系延续性检查等方法 ；其中双路比对测试从 ODS 层取数，写出符合口径的 SQL ，按其计算余额，与报表展示数据（比如监管报送系统）比对、分析其差异。

六、常见问题

发现问题主要类似有明细汇总余额无法与科目余额一致， 源业务数据不全导致报表无数据。取数口径问题、码值转换问题、权限控制不合理、日常增量批次的指标值中 T 日值和 T-1 日值浮动比率超过阈值范围，模型设计时源系统到目标系统字段不一致导致转换后字段被截断等问题。数据有效性问题（贷款状态为结清，但贷款余额大于零导致关联字段不匹配），总分不一致（贷款合同中贷款余额不等于贷款支用金额之和），字符型的字段没有作TRIM，left outer join 没有做空值判断。