测试模型工具版本：
版本内容提交人更新内容
1.0陈林儿初始版本
1、什么是ETL
E-T-L代表Extract-Transform-Load。用来描述将数据从来源端经过抽取、转换、加载至目的端的过程；（数据清洗）
Extract为提取相关数据；Transform根据规则对数据进行处理与转换；Load为将数据加载到对应的仓库。
2、什么是ETL测试
保证经过E T L全过程后，从源加载到目标仓库的的数据准确无误且符合目标需求。
3、ETL测试点
围绕ETL的实现过程和分层测试的思想，ETL测试重心包括：数据源测试、转换规则测试、加载测试。为了确保需求驱动，我们还额外设置了集成统一测试。
根据软件测试左移的思想，我们需要尽量将一些可以前置的测试事情提前完成，以达到缩短工期、减小成本的目的。
因此我们将针对不同的测试阶段进行不同的测试。
需求测试
如果不想看详细说明就看这张表：
阶段测试场景测试指标详细说明
需求阶段需求测试清洗规则是否符合原始需求按照清洗规则是否可以得到原始需求需要的数据
是否过多--未过滤无效数据
是否过少--少考虑某些业务场景
清洗目标是否符合上下游要求清洗目标字段定义、值定义是否符合上下游要求
清洗规则是各种项目、业务通用清洗规则服务所有项目，但各个项目数据源格式、业务规则不同。
清洗规则是否清晰数据源，转换规则，load定义
数据源测试数据源设置是否清晰，全面。各个项目数据源格式是否符合清洗规则预期
根据语法测试数据源是否存在脏数据根据无效字符，字符模式，大小写不正确等报告脏数据
根据数据模型检查数据是否符合预期根据清洗规则建立数据模型，数据应该具备什么特点（数字检查、日期检查、精度检查、空检查）
需求阶段，即在需求确认提出阶段，测试就可以开展的工作。
ETL的需求一般由三个重要部分组成：数据源 、 清洗规则 与 清洗目标。整体的ETL需求测试也是围绕着这三个方向来完成。
1、数据源需求测试
1）数据源设置是否清晰，全面。
在需求中，关于数据源的描述务必清晰准确。注意不可含糊不清，不可出现二义性。指定的数据源也需要确保可靠与全面。
eg：在某ETL需求中，数据源指向某个数据库的某张表。我们继续调查这张表的来源，是来自另一个ETL程序，那么我们就需要结合上一个程序的逻辑来考虑数据源的稳定性与风险。
eg：在某ETL需求中，一个基础数据要求得到用户持有的所有资源，在需求的数据源设定中，仅要求获取用户背包资源，但是在不同游戏项目中，资源的存放地多种多样，而不仅仅存放在背包中。
2）根据语法测试数据源是否存在脏数据
程序上对于脏数据的处理通常是容错然后丢弃。虽然在后续测试中会涵盖脏数据的兼容测试，但是在需求提出时我们就需要对脏数据进行调查。评估脏数据的大概量级和出现的可能性也作为后续的测试参考。
我们根据无效字符，大小写不正确、空字符等报告脏数据。
3）根据数据模型检查数据是否符合预期
当我们拿到清洗规则时，可以根据清洗规则建立数据模型（这里的数据模型指数据源所具备的统一结构特征，例如：数字检查、日期检查、精度检查、空检查、数据含义检查），去调研当前数据源下有没有不符合该数据模型的数据或者存在非法数据的可能性。
后期甚至需要进行持续的监测。
eg：某ETL需求中，要求从“ 超级牛逼-EN-换预览图 - 副本 (23842702728410179)”这样的一个数据结构中取出后面的数字串。那么我们需要调查当前数据源中是否所有数据都匹配这种数据结构
eg：例如delete字段为1表示已经被删除的记录，那么在后续规则清洗的时候需要过滤这部分记录。
2、清洗规则需求测试
继承上方数据源需求测试得到的信息后，我们开始清洗规则需求测试。
1）清洗规则是否符合原始需求预期
原始需求指需求提出方希望通过使用我们的数据产品得到数据。我们需要评审我们的产品（这里指的是策划角色）产出的清洗规则的最终产物是否符合原始需求的要求。这要求测试人员能够充分了解原始需求，而原始需求往往具备较强的业务性。
我们可以通过了解行业统一指标、使用对应类比竞品、了解用户使用场景来提高自己的业务理解能力。
例如：某原始需求是希望可以得到用户历史付费最高额度，清洗规则中简单的说明了通过数据源中的price字段值group by uid后取出max（price）。但是在实际的业务场景中，部分付费信息日志是由测试人员通过特殊渠道测试产生，需要进行过滤。(这部分需要结合上方的数据源调查才得以发现)
2）清洗规则是各种项目、业务通用
3）清洗规则是否清晰
这两个部分的测试同理数据源测试
3、清洗目标需求测试
1）清洗目标是否符合上下游要求
在完整的数据产品中，不是ETL产生了结果，就结束了，往往会伴有后续的业务逻辑，对这些产出的数据进行处理。因此对清洗目标的考察还需要考虑她是否符合上下游业务的要求。
例如在一些BI报表类应用中，该报表期望展示的是一个具体的项目名称“xx项目”，但是我们在清洗结果中仅仅提供了项目ID.那么没有做好约定的话就会出现中间断层
开发设计测试：
如果不想看详细说明就看这表：
阶段测试场景测试指标详细说明
开发阶段结构测试根据清洗规则验证源表和目标表结构（类型、长度、名称）监测目标表字段定义类型、数值长度
约束验证确保按预期为特定表定义约束主键、外键、检查、默认、唯一、非空约束
设计评审分析设计漏洞
了解程序路径
1）目标表结构验证
通常在清洗开始之前，需要对目标加载的仓库进行建表。根据清洗规则验证源表和目标表结构（类型、长度、名称），通过源目标数据结构+清洗规则我们可以得出目标表结构要求结论，因此可以对目标表和源表做个结构上的对比验证。
例如：某原始需求是希望可以得到用户历史付费最高额度，清洗规则中简单的说明了通过数据源中的price字段值group by uid后取出max（price），可以推断出price字段未进行任何加工，所以目标表结构中price字段的定义应该和源表一致。
2）目标表约束验证
同理上方。确保按预期为特定表定义约束，包括：主键、外键、检查、默认、唯一、非空约束。
3）开发设计测试分析
了解开发脚本设计思路，评估是否符合需求规则实现，通过数据源分析、需求分析收集到的异常数据、脏数据进行开发设计漏洞寻找。
同时通过了解程序路径，进行异常、正向场景数据流设计，提供给后续测试使用。
例如：上文所述的源数据数据模型分析，在数据源表扫描过程中发现id出现重复，那么需要程序增加进行去重处理。
4）调度策略设计分析
关于测试脚本如何调度，清洗规则需求中通常不会明确说明。因此需要充分评估调度策略是否符合需求，时间差需求是否接受。
模块测试、
阶段测试场景测试指标详细说明
模块测试
一致性验证特定属性的数据类型和长度可能在文件或表中不同，但语义定义相同。业务正常流：口径一致，逻辑正确
业务异常流：考虑业务中存在的异常场景
完整性验证数据从条数、长度、大小上都不应缺失。1、比较源和目标之间的记录计数。
2、检查任何被拒绝的记录
3、检查数据不应在目标表的列中被截断
4、检查边界值分析
转换转换规则正确
数据精度正确
按照清洗规则实现了转换规则
数据清理在加载到暂存区域之前，应删除不必要的列临时数据及时清理
重复检查检查从源中的多个列提取并组合成一列的任何列中是否存在任何重复值
异常测试设计异常数据、场景覆盖测试对象根据业务需求设计异常数据
根据程序实现设计异常数据
增量ETL此测试是通过添加新数据来检查旧数据和新数据的数据完整性。增量测试验证插入和更新是否在增量ETL过程中按预期进行处理。
数据表现分析评测清洗结果的数据表现，来评判系统的好坏数据趋势要趋于平稳，波动具备规律，波动范围在设定的阈值之间
加载规则加载策略的合理性清空重置、覆盖更新
模块测试指的是独立的ETL任务测试。这部分的测试思路主要可以分为两个部分。
1、面向过程的测试思路
1）数据源的测试
指定正确，正确的按照需求实现了源数据的抓取。
抓取策略合理，通过增量/全量策略来抓取。验证插入和更新是否在增量ETL过程中按预期进行处理。
异常测试，通过输入开发设计阶段分析、需求评审阶段产生的数据流，验证程序的容错性。
2）转换规则测试。
数据精度处理正确，正确的按照需求实现了转换规则。
转换规则正确，通过输入正向的业务数据流来验证规则的正确性。
3）目标数据加载测试。
数据加载正确，正确的按照需求加载处理的结果到指定数据仓库中。
加载策略合理。使用了正确的加载策略，例如部分指标的加载策略应该是清空表重置加载数据，部分指标则需要覆盖更新部分即可。
2、面向结果的测试思路
1）一致性验证
部分字段的数据类型和长度可能在不同表中不同，但口径一致/逻辑正确。
口径一致：在不同的两个仓库中同个用户拥有的资产应该一致。
逻辑正确：例如清洗结果中的周报表与月报表具备逻辑上的关系，可以用来加以验证（比如有些业务 周报表相加=月报表）
2）完整性验证
将整个ETL过程黑盒看待，经过这个过程后，数据从条数、长度、大小上都不应缺失。
比较源和目标之间的记录计数。
检查任何被拒绝的记录
检查数据不应在目标表的列中被截断
检查边界值分析
3）重复检查
检查从源中的多个列提取并组合成一列的任何列中是否存在任何重复值
4）数据表现
分析评测清洗结果的数据表现，来评判系统的好坏。例如根据用户清洗结果数据趋势来判断结果的正确性，举个比较粗暴的例子：用户拥有资产在过去的七天都是日均一万。今日突然为0.则大概率有问题。
集成测试
阶段测试场景测试指标详细说明
集成测试
脚本运行策略时间差分析
脚本初始化支持
脚本冲突分析
脚本依赖分析
资源分配分析
部分脚本上线需要进行初始化支持
部分脚本依赖其他脚本清洗结果。需要再调度策略上予以满足
脚本运行稳定性观察长时间调度运行观察
仿真数据模拟测试
异常容灾
持续性调度情况观察，这里可以采用上述的数据表现监控手段进行测试。
仿真数据模拟，在仿真数据环境进行脚本运行情况监控。
异常容灾： 脏数据处理、数据源库连接失败重试策略、数据仓库写入失败重试、备份策略
1）脚本运行策略
时间差分析
脚本初始化支持：部分脚本上线需要进行初始化支持
脚本冲突分析
脚本依赖分析：部分脚本依赖其他脚本清洗结果。需要再调度策略上予以满足
资源分配分析
2）脚本运行稳定性观察
持续性调度情况观察，这里可以采用上述的数据表现监控手段进行测试。
仿真数据模拟，在仿真数据环境进行脚本运行情况监控。
异常容灾： 脏数据处理、数据源库连接失败重试策略、数据仓库写入失败重试、备份策略
4、测试手段
看完上述这么长的验证点，那么一个ETL验证过程显然需要花费很长的测试周期。这个性价比上显然是不高的。所以当方案有了以后接下来面临的难点是我们需要采用什么样的测试手段。
首当其冲的就是自动化测试。显而易见的，上述测试的规则性都很强这为自动化测试奠定了良好的基础。那么思路上如何实现呢？
测试手段的演变历史
简单来说，当我们接收到命题 需要测试开发从某个库里 查询一些结果的时候需要如何测试呢？
首先想到的是通过review开发SQL语句来进行相应测试。但如果这个是比较复杂的嵌套语句呢？通过简单的检查首先不可保证结果，其次耗费时间。
而后想到的是我们惯用的使用预期结果进行结果比对验证，那么预期结果哪里来呢（这里划重点，期末要考）？
实现验证实现
与传统测试不同的是，传统的功能测试结果有限，我们仅需人脑判断就可以知道预期结果应该是什么。
但是ETL不一样，结果多样数据量大，实现验证实现的思路来源于我们需要去实现同样的思路来获取预期结果。如上文的查询，那么我们也需要通过编写select进行预期结果的获取。
这样就变成了两套实现程序的碰撞。这种方法虽然傻，但是可以帮助测试人员更加深入思考实现。
数据驱动
实现验证实现的方法显然存在短板；比如实现成本高，测试人员技能要求高，测试悖论等等。
于是我们又寻求了另外一种测试思路，就是数据驱动。我们将被测试的ETL看做一个盒子，将“精心”设计的数据流/数据环境注入这个黑子中，在结果处设置预期值对比。（数据流是我们设计的，那么我们定然知道应该产出的结果；如果还不知道结果的需要参考下文介绍的数据评测）数据流的设计规则参考上文介绍的各种验证点。需要提醒的是，这里的测试不是传统的黑盒测试，数据驱动测试是否完善，取决于数据流设计的是否完善，我们需要深入了解到开发代码的每一行程序路径来设计覆盖数据流。
当我们把底层注入对比实现全自动化后，ETL测试只剩下分析与数据流设计（相信我，部分数据流设计也可以自动生成）
数据驱动+数据监测
显然数据驱动的方案也是存在弊端的，取决于数据流设计的完善性。因此我们再加了一把锁。做数据监测。也就是上文提及的面向结果的测试。
下篇预告： BI报表测试模型
ETL自动化测试
网友评论