实战丨商业银行数据仓库类项目测试方法研究

Posted 2021-04-24 金融电子化

欢迎金融科技工作者积极投稿！

各抒己见！

投稿邮箱： 

[e-mail]

                                 ——金融电子化

本文节选自《金融电子化》2018年8月刊

李政  刘荆涛  何一帆

编者按

本文以某大型商业银行数据仓库类项目的测试经验为基础，开展对商业银行数据仓库类项目测试方法的研究，力争梳理出数据仓库类项目的测试重点和对应的测试方法，从而对今后测试人员的数据仓库类测试过程提供借鉴。

行业现状：信息技术的广泛应用使得商业银行的经营管理变得更加高效快捷，与此同时也沉淀了大量的数据。数据仓库作为一种高效集成的数据管理技术，能够帮助决策者提高金融决策水平，在复杂的经济局势和商业环境中做出精确的判断。数据质量是数据仓库建设中的重中之重，数据仓库的测试应成为确保数据质量、满足上层应用需求的关键环节，应该得到足够的重视。

数据仓库测试面临的难题

缺乏成熟的测试策略。传统项目测试时，一般遵循页面级—功能级—流程级的测试思路，层层递进。而对于数据仓库项目的测试，由于测试工作主要集中在后台，没有前台界面，因此传统项目的测试思路并不适用。

 

业务逻辑的复杂性。数据仓库中的数据集中了多个源系统、从源表到目标表一般都会经过多层次的加工，业务逻辑相较一般的科技系统需求更为复杂，对测试人员的业务水平要求更高。

 

需要手工编写SQL校验。数据仓库的测试不可避免的需要测试人员编写SQL协助对数据的验证，SQL语句的正确性很大程度上会影响测试的效果，对测试人员的编码能力要求更高。

 

一种双金字塔测试策略

为了进一步规范商业银行数据仓库的测试，为数据仓库的测试提供完整测试思路，本文提出一种双金字塔测试策略（如图1所示），该策略按照测试对象的不同，将数据仓库测试分为脚本级测试和数据集测试。

图1  数据仓库双金字塔测试策略

 

数据级测试的测试对象为数据仓库中的表、字段、记录数等内容，主要包括表的完整性测试、合理性测试、准确性测试三部分。测试的主要目标是保证处理后的入库数据能够达到业务人员的要求。

 

脚本级测试的测试对象为数据仓库脚本（ETL脚本、数据访问脚本等），主要包括了脚本走查、容错性检查、执行效率检查等三部分内容。首先从代码层面初步查看脚本是否实现了业务人员要求的处理逻辑，确保脚本能够正常执行和能在规定时间内执行完成。

 

数据级测试

1.数据完整性测试。数据完整性测试是指保证数据仓库中的所有表、表的所有字段没有遗漏。具体来讲，数据完整性测试又包含表的完整性检查、记录数完整性检查、字段完整性检查、主外键关系完整性检查四个方面。

 

（1）表的完整性检查。表的完整性是检查是否需要入库的目标表已经存在于数据仓库中，以防止有数据表的遗漏（见表1）。

表1 表的完整性检查

 

（2）记录数完整性检查。记录数完整性检查是指检查所有在库目标表的记录数，查看记录数是否在合理范围内（见表2）。

表2 记录数完整性检查

 

（3）字段完整性检查。字段完整性检查是指检查所有在库目标表的实际字段和预期设计字段是否一致（见表3）。

表3 字段完整性检查

 

（4）主外键关系完整性检查。字段主外键关系检查是指外键表中外键的取值必须在主键表中存在，否则在今后对外键表、主键表关联时，就可能会出现错误（见表4）。

表4 主外键关系完整性检查

 

2.数据合理性测试。主要从如下几方面介绍。

（1）主键重复检查。在一个表里，主键(或者联合主键)应该是不能重复的，否则在今后取值应用时会出现错误（见表5）。

表5 主键重复检查

 

（2）时间拉链检查。以在一个时间拉链表里，以StartDt（开始时间）字段来标识一个状态的开始,以EndDt字段来标识一个状态的结束。在数据仓库中，如果算法设计不好，很容易出现时间拉链表的断链（上一个状态的EndDt和下一个状态的StartDt无法衔接）、倒链（StartDt和EndDt写反）、交叉链（上一个状态的EndDt大于等于下一个状态的EndDt）的情况，因此需要在测试中对这些情况进行检查（见表6）。

表6 时间拉链检查

 

（3）字段取值范围检查。数据库表中每个字段的取值需要符合字典表的范围设置（见表7）。

表7 字段取值范围检查

 

（4）取值分布检查。正常情况下，即使某个字段允许为空，但是为空的字段也不能过多（如超过所有记录数的20%）。如果超过，则可能是数据在处理过程中出现了问题，需要检查，默认值同理（见表8）。

表8 取值分布检查

 

（5）日期字段检查。如果日期型数据在源表中是字符类型的，转换到目标表后就要做日期格式的校验，验证一下是否还是有效的日期格式（见表9）。

表9 日期字段检查

 

3.数据准确性测试。主要从如下几方面介绍。

（1）总体汇总校验。对于数值型字段，可以从整个表的层面，对其汇总数据进行整体校验，下面给出几种常见的校验情况（见表10）。

表10 总体汇总校验

 

（2）同比环比校验。对于一些同比环比数据，一般伴随的都是其绝对值数据，可以很容易的进行同比环比校验。如：2016年一季度基金销售总额同比增长=（2016年一季度基金销售总额—2015年一季度基金销售总额）/2015年一季度基金销售总额。对于同比环比校验，需要重点关注分母为0时的处理方式，一般情况下，分母为0时，同比环比数据置为NULL。

 

（3）采用双路比对进行校验。所谓双路比对，就是测试人员重新根据业务逻辑编写一遍ETL，生成结果表，将测试人员生成的结果表中的数据与开发人员的生成数据进行比对。此种测试工作量较大，对测试人员的编程能力要求较高，耗费时间长（见表11）。

表11 采用双路比对进行校验

 

脚本级测试

1.脚本走查。测试人员查看开发人员的ETL脚本，并找出其实现关键逻辑的语句，看语句是否实现了业务逻辑的要求（见表12）。

表12 脚本走查

 

2.脚本容错性测试。所谓脚本容错性测试，包含两层含义：一是脚本执行过程中由于严重的数据问题或者外部硬件原因，导致脚本无法继续执行的时候，是否能对数据仓库进行回滚操作，保证数据仓库的一致性。二是脚本处理一些低质量的数据（空值、格式不正确、数据缺失等），是否首先对这些低质量的数据采取清洗操作。

 

3.脚本性能测试。对于数据仓库的测试，一方面需要考查加载脚本的加载性能，另外一方面，对数据库的对外访问接口脚本进行性能测试，保证数据仓库的对外服务能力（见表13）。

表13 脚本性能测试

往期精选：

（点击查看精彩内容）

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧