浅谈ETL测试（二）

　　今天继续和大家分享下作为大数据测试工程师对ETL测试的一些认识。ETL测试认知续篇。

　　一、ETL测试类型

　　Production Validation Testing

　　---该类型的ETL测试是在数据迁移至生产系统时进行的。为了保证生产业务的正常运营，生产系统中的数据必须以正确的顺序进行排序。在该ETL测试类型中要注意从数据层面进行自动化测试和管理能力的植入。

　　Source to Target Testing(Validation Testing)

　　---该类型的测试主要由源转换的数据是否满足预期的转换目标。

　　Application Upgrades(升级测试)

　　---该类型的ETL测试是可以自动生成的，能节省大量的测试开发时间。主要检查旧应用或存储库中提取的数据是否与新的应用或新的存储库中的数据完全相同。

　　Metadata testing(元数据测试)

　　---元数据测试包括数据类型检查、数据长度和索引/约束检查。

　　Data Completeness Testing(数据完整性测试)

　　---当把所有期望的数据从源加载到目标表时，就算完成了数据完整性测试。在数据完整性测试过程中，我们还可以进行一些简单的转换或无转换的源与目标之间的计数、聚合和实际数据比较和验证的测试。

　　Data Accuracy Testing(数据准确性测试)

　　---该类型测试验证数据正确地完成加载和按预期目标进行转换。

　　Data Transformation Testing(数据转换测试)

　　---测试数据转换是一个复杂的过程，并不是简单地写一个源SQL查询并与目标表进行比较来实现的。可能需要为每个验证case写较复杂的SQL联合查询，来验证转换规则。

　　Data Quality Testing(数据质量测试)

　　---数据质量测试包含语法和基准测试。为了避免在业务过程中由于日期或唯一编号(例如订单号)引起的错误，进行数据质量测试。

　　Incremental ETL Testing(增量ETL测试)

　　---该类型测试主要验证旧数据和新数据的完整性，并添加新数据。增量测试验证增量ETL过程中，插入和更新是否满足预期的要求。

　　GUI/Navigation Testing

　　---该类型测试主要检查生成的大数据报告的UI\导航方面是否正常。

　　语法测试：根据无效字符、字符模式、不正确大小写、顺序等出具脏数据测试结果

　　基准测试：基于数据模型检查数据，例如

二手手机靓号购买

客户ID数据质量测试，包含：数字检查、日期检查、精度检查、数据检查、零校验等等

　　二、ETL测试的方法

　　1.数据量统计

　　源表和目标表数据量统计。全量的加工表跟对标数据表之间的指标/维度数据值的量级、条数等

　　2.转换规则测试

　　<1>.数据格式的合法性。对于数据源中时间、数值、字符等数据的处理，是否符合数据仓库规则，是否进行统一的转换 ----收数的时候走统一的校验逻辑。

　　<2>.值域的有效性。是否有超出维表或者业务值域的范围。---目前价格等数值型的，统一使用(22,6)精度的规则。

　　<3>.空值的处理。是否捕获字段空值，或者需要对空值进行替换为其他含义值的处理。

　　<4>.主键的有效性。主键是否唯一。

　　<5>.乱码的检查。特殊符号或者乱码符号的处理规则。---在解析文本文件时使用统一的分隔符，规则是字段值不会出现类似这样的字符串，如使用分隔符：#￥%&*，保证其唯一性，否则在解析文件入库时会出现串列现象。

　　<6>.脏数据的处理。理论上收数层做完之后，不存在数据规格问题的脏数据。但是目前依据数据系统情况看，还无法完全避免。所以一些重要指标的计算逻辑需要考虑到可能会有脏数据的问题。

　　3.抽样测试

　　通过抽样，测试源表和目标表映射是否正确。

　　4.加载规则测试

　　一般加载方式有两种：全量加载和增量加载

　　<1>.增量加载方式，为了避免收数时个别数据源问题导致可能会断更几天的情况，我们通常使用滑块窗口方式增量，当数据源问题恢复后自动补全了滑块内缺失的部分。

　　对于增量抽取，捕捉变化的数据有如下几种：

　　1).监控增量数据

　　因为项目在上线前一般都会试运行一段时间，所以在这段时间，就要每天做表中数据量的的监控。

　　对于日全量表的监控：只要看源表和目标表数据量是否一致就可以

　　对于增量数据量监控：看全量+增量的数据是否与源表数据量是否一致。根据不同的业务规则，查看是否正确。

　　然后通过多日监控，可以发现不管是增量还是全量，数据量基本都会处于一个值左右，幅度不会太大，如果出现特殊情况，就要去考虑检查一下它的正确性了。这种通常要根据线上的业务监控来实现。

　　2).监控增量运行时间

　　通过监控增量的运行时长，可以发现性能问题和批量数据的运行是否成功。对于时间浮动比较大的增量表，可以第一时间发现问题并解决问题。

　　运行时间监控：对于业务性能要求高的情况。比较在意的是性能问题，以确保在规定的时间内，完成跑批。我们要通过监控增量运行时间，及时发现程序的性能问题。

　　<2>.全量加载方式

　　由于我们采取的是全量加载+增量加载(采用时间戳方式)，我这里指的全量加载即数据仓库中数据的初始化。

　　全量加载的测试方案相对要简单些。

　　1).测试源和目标表的数据量的一致性

　　2).运行1,2,3,4测试方法测试一般来说即可。

　　5.性能测试

　　确保数据在规定和预计的时间内被加载到数据仓库中，以确认改进的性能和可扩展性。

　　6.测试用例

　　项目中的关键业务，复杂逻辑部分作为测试重点

　　基础数据：可以为真实数据，也可以单纯手工造数据。因为ETL数据量较大，并且表中字段数量比较多，各表关联比较大，所以本人觉得还是用真实数据效率比较高。

　　测试用例的编写：测试用例可以单独设计，也可以采用调度的思想进行设计，采用调度方法进行设计时，能一次验证多个用例，另外也方便回归。

　　三、怎么创建ETL测试用例

　　<1>.ETL测试的目的是确保在业务转换完成后从源加载到目标表的数据是正确无误的。

　　<2>.ETL测试同样还涉及在源和目标表之间转换时的各个阶段的数据的验证。

　　<3>.在从事ETL测试时，有三份文档是ETL测试人员实时使用的：

　　1). ETL映射表：一个ETL映射表包含源和目标表的所有的信息，包括每个列及其引用表等约束关系。ETL测试人员需要以此为依据来编写测试SQL查询语句，因为在ETL测试各阶段可能需要编写具有多个连接的大查询来验证数据。ETL映射表在为数据验证编写查询时提供大量的有用的信息。

　　2). 源、目标数据库模式：该模式应该便于验证映射表中的所有细节。

　　3). 开发实现需求的设计文档。