今天和大家分享下我作为大数据测试工程师对ETL测试的一些认识。
一、ETL测试工程师的主要责任
对于一个ETL测试工程师而言，其关键的责任有三大类：
1. 源数据分析（包含：数据库表、文本等类型数据分析）
2. 业务转换逻辑实现（包含：code diff，目标表全量数据的逻辑实现验证）
3. 将经过转换的数据载入至目标表的各维度与指标数据与对标数据进行对标验证其一致性
二、ETL测试场景和测试用例
1. 根据对应的映射文件验证"源"与"目标数据仓库"的表结构
2. 验证"源"和"目标数据的类型、长度、格式一致或源长度不应大于目标数据类型长度"
3. 约束验证目标表中的约束关系满足我们的期望设计
4. 数据一致性问题
<1>. 要防止语义定义相同，但特定属性的数据类型和长度不一致的问题
<2>. 完整性约束、主键不可以重复、异常数据处理方式等
5. 完整性问题
<1>. 要确保所有期望的数据都已经完整的加载到目标表中
<2>. 要比较源和目标数据的个数（即确保计数上的完整）
<3>. 检查出现的任何不合格的记录
<4>. 检查目标表列中的数据没出现被截断的情况--针对的是窜列的情况。比如comments里的内容含有列分隔符，被分隔开了。
<5>. 对边界值进行分析检查
6. 要检查比较目标数据仓库和源数据的关键字段的唯一性和正确性问题[主键一致]
<1>. 数据要没有拼写错误或不准确的记录。
<2>. 无超出业务许可范围的数据记录存在
<3>. 数值型验证，验证是否为数值类型
<4>. 日期型验证，验证是否为日期格式，并且在所有日期类型数据的格式应该统一
<5>. 精度验证，小数点的精度要满足期望的精度
<6>. 数据检查：检查数据的正确性，完整性
<7>. null检查
<8>. 转换验证转换逻辑的正确性
7. 拷贝验证
<1>. 验证目标表中业务要求所有惟一性指标均正确的实现（例如主键、惟一标识的键、或其他任一惟一表示的列）
<2>. 验证从源数据多列合并而成的数据是正确的
<3>. 验证仅仅根据客户要求对源数据进行了多列合并至目标表中
8. 日期验证是ETL开发过程中常用的数据，主要用于：
<1>. 了解数据创建的日期，分区日期和业务日期要分清楚。
<2>. 用于识别活动记录
<3>. 根据业务需求透视表确定活动记录
<4>. 便于基于时间插入、更新记录
9. 数据完整性验证在验证源和目标表中的数据集的完整性时，我们需要用到交集运算，以确定目标数据的完整性
10. 数据清理对于不需要的列在载入至数据仓库前应该进行删除
11. 结果集验证：
<1>. 通常使用的是全量数据验证方法，应用层的目标表数据验证时，则使用汇总层的表再left join各种维度表，拿到对应的维度的值后再与应用层的目标表进行join，
根据需求中同一个维度或指标的不同场景，进行case设计，从而在case执行时，体现在一个个查询sql上的不同，找出sql查询出的异常数据值，单条数据进行验证后，
如果确认是测试查询sql的问题，则需要修正测试sql，再继续执行，如果确认是实现的结果不符合需求，则提bug给到对应的开发。
<2>. 但针对一些特殊的需求，我们不会去构造一个验证集去对比结果集，因为代价太高了。当然如果有对标数据是另外一种情况。我们可以简化为从几个维度去验证跑出来的结果集。
比如，总量维度，结果集的数据量是否符合某个数量级。 酒店维度，某些个指标是否包含了所有酒店数。数值维度，某指标的全量和是否符合预期。
三、ETL的bug类型
bug类型描述说明
1. 用户接口bug
<1>. 主要涉及应用的GUI
<2>. 字体、样式、颜色、对齐、拼写错误、导航等等
2. 边界值bug数据的边界值范围
3. 等价类划分bug有效和无效类
4. 输出/输出bug
<1>. 未接受的有效值
<2>. 无效的值被接受
5. 计算类bug
<1>. 数学计算错误
<2>. 最终输出错误
6. 载入条件bug
<1>. 不运行多用户操作
<2>. 不运行用户载入期望的数据
7. 性能的bug。达不到业务要求时间。
ETL测试与数据库测试的不同
1.验证数据是否按照预期进行了移动主要验证数据是否遵循了设计预定的数据模式规则或标准
2.验证数据经过业务转换后是否满足预定的转换逻辑以及验证源和目标数据计算是否一致主要表的主、外键等约束是否正常
3.验证ETL过程数据表的主外键关系是否保存验证没有冗余表，数据库最佳化
4.验证已载入的数据拷贝是否满足预期验证需要的是否缺少数据
————————————————
一、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).开发实现需求的设计文档。