Testing 如何对ETL过程进行测试（单元测试）？

我知道有几家小公司不在ETL过程上进行测试，但从软件工程的角度来看，这似乎是次优的

人们通常如何对ETL过程进行测试/单元测试/功能测试

---

非常感谢

我们最近参与了一个项目，治理委员会要求“您必须进行单元测试”，因此我们尽了最大努力

对我们有效的是让每个ETL解决方案以QA/测试包开始和结束

这些包发现的任何意外情况都会记录到审核表中，然后引发失败包事件以停止整个作业-我们认为，使用昨天的良好数据运行比针对可能的“今天”不良数据进行风险报告更好

启动包将执行数据库模式和数据健全性检查。数据健全性涉及检查源系统中缺少引用完整性而导致的重复或缺失数据。架构检查确保检测到在持续集成期间未应用的任何架构更改

最终包将检查任何转换的结果。这些措施包括：

• 比较源与目标之间的记录计数
• 检查特定的转换（例如：所有日期值更改为适当的SK值，所有字符串值RTrimed）
• 确保填充了所有SK字段（-1而不是null）

大多数测试都是SQL语句，使用数据库的内置模式对象，因此它们的创建并不繁重

此外，作为开发过程的一部分，我们将创建具有我们所做的任何转换的最终结果的视图。我们将利用这些视图来验证我们的包转换

每项检查都在我们的特殊审计表中创建了一条记录。这样，我们就可以提供一个全面的列表，列出我们在流程的每次运行中所做的所有测试和检查，以满足治理人员的要求

---

（我们还有一套单独的软件包，通过创建虚拟表、填充它们、运行测试，然后确认编写了适当的审计记录，对每个QA测试进行单元测试。正如Nick所说，这是一项大量工作，几乎没有实际价值）

我们已经建立了一个系统，在该系统中，我们为每个ETL过程定义了一个输入数据集和一个预期结果数据集。然后，我们创建了一个系统，利用该系统为每个ETL过程运行三部分测试，其中第一部分将输入数据集插入源数据表，第二部分运行ETL，第三部分将实际结果与预期结果进行比较

这对我们来说非常有效，但有两个缺点：首先，我们为每个ETL过程手动创建测试数据集，这需要一些工作；其次，这意味着没有完成“意外”输入的测试

---

对于自动化单元测试，我们有一个单独的环境，可以在其中自动安装整个DW的构建。

测试ETL通常是一个问题。更准确地说，测试不是问题，问题是如何获得合理的测试数据。ETL通常在生产数据上进行测试。除了安全问题之外，生产数据的问题在于没有充分覆盖ETL的功能（通常约40%的业务规则未包含在生产数据样本中），而且处理时间太长

最近，我们开发了一个测试数据生成器（有关更多详细信息，请查找GTL QAceGen：Informatica Market Place上的业务逻辑驱动的数据生成器），它根据业务规则规范将测试数据生成到源表/文件中。该工具考虑了应用的任何外键，并且适用于任何主要ETL和/或数据库

---

此工具有助于将测试周期至少加快50%（与手动测试相比），覆盖了所有业务规则的100%。它还生成非常详细的报告，更重要的是，这些测试可以随时重复（即回归测试）

ETL过程中的测试分为以下几个阶段：

确定业务需求

验证数据源

准备测试用例

从不同来源提取数据

应用转换逻辑验证数据

将数据加载到目标中

报告分析

我们还可以将ETL测试过程分类如下： 产品验证 源到目标数据测试 元数据测试 性能测试 集成和质量测试 报告测试

您可以对ETL进行单元测试

端到端测试很好，但速度慢、成本高，而且难以构建和保持稳定

单元测试ETL非常希望能够测试所有的数据排列，但通常被放在太硬的篮子里。然而，为ETL编写真正的单元测试是可能的，它可以快速可靠地运行

我们发现，关键是将ETL分解为两个独立的部分。由于ETL是一个提取转换加载，关键是将T与E&L分离。生成一个将输入数据集转换为输出数据集的纯转换函数，然后从提取和加载模块调用此函数

提取和加载模块不适用于单元测试，因为它通常涉及外部数据源和接收器、访问令牌和用户权限等

但是所有的可测试逻辑都应该在转换组件中。从任何单元测试框架测试此函数-您将能够传入预定义的数据集，并根据预期结果测试转换后的输出。通过一些思考，我们甚至成功地创建了单元测试，测试彼此之间的数据集的多阶段更新

---

我们的具体实现是在Scala中的DataRicks上完成的，但是这个概念应该在任何平台上都可以使用。

您需要生成一个空的测试数据库，测试用例（在数据源中）