我知道有几家小公司不会对 ETL 流程进行测试，但从软件工程的角度来看，这似乎不是最理想的。
人们通常如何对ETL流程进行测试/单元测试/功能测试？
【问题讨论】：
标签： testing etl data-warehouse
我们最近参与了一个项目，治理委员会要求“您必须进行单元测试”，因此我们尽了最大努力。
对我们有用的是每个 ETL 解决方案都以 QA/Test 包开始和结束。
这些包发现的任何意外情况都会记录到审计表中，然后引发包失败事件以停止整个作业 - 我们认为使用昨天的良好数据运行比针对可能的糟糕“今天”数据进行风险报告更好.
起始包将执行数据库架构和数据完整性检查。数据健全性涉及检查由于源系统中缺乏参照完整性而导致的重复或丢失数据。架构检查可确保检测到在持续集成期间未应用的任何架构更改。
最终包会检查任何转换的结果。其中包括：
这些测试大多是使用我们数据库的内置模式对象的 SQL 语句，因此创建起来并不繁琐。
此外，作为我们开发过程的一部分，我们将创建具有我们正在进行的任何转换的最终结果的视图。我们将利用这些视图来验证我们的包转换。
这些检查中的每一项都在我们的特殊审计表中创建了一条记录。这样，我们就可以提供一份完整的列表，列出我们在每次运行流程时所做的所有测试和检查，以满足治理人员的要求。
（我们还有一组单独的包，它们通过创建虚拟表、填充它们、运行测试然后确认写入了适当的审计记录来对每个 QA 测试进行单元测试。正如尼克所说，这是很多工作，没有什么实际价值）
【讨论】：
ETL 的测试通常是个问题。更准确地说，测试不是问题，问题是如何得到合理的测试数据。 ETL 通常在生产数据上进行测试。除了安全问题之外，生产数据的问题在于它没有充分涵盖 ETL 的功能（通常大约 40% 的业务规则没有被生产数据样本涵盖）并且需要太多时间来处理。
最近我们开发了一个测试数据生成器（有关更多详细信息，请查找 GTL QAceGen：Informatica Market Place 上的业务逻辑驱动数据生成器），它根据业务规则规范的源表/文件生成测试数据。该工具考虑了应用的任何外键，它适用于任何主要的 ETL 和/数据库。
此工具有助于将测试周期加快至少 50%（与手动测试相比），并涵盖 100% 的所有业务规则。它还会生成非常详细的报告，更重要的是，这些测试可以随时重复（即回归测试）。
【讨论】：
我们已经建立了一个系统，我们为每个 ETL 过程定义了一个输入数据集和一个预期结果数据集。然后我们创建了一个系统，利用Robot Framework，为每个 ETL 过程运行三部分测试，其中第一部分将输入数据集插入源数据表，第二部分运行 ETL，第三部分比较实际结果符合我们的预期。
这对我们来说效果很好，但也有一些缺点：首先，我们为每个需要一些工作的 ETL 过程手动创建测试数据集，其次，这意味着对“意外”输入的测试是没做完。
对于自动化单元测试，我们有一个单独的环境，我们可以在其中自动安装整个 DW 的构建。
【讨论】：
您可以对 ETL 进行单元测试。
端到端测试很好，但速度慢、成本高且难以构建和保持稳定。
单元测试 ETL 非常需要能够测试所有数据排列，但通常被放入太难的篮子中。但是，可以为能够快速可靠地运行的 ETL 编写真正的单元测试。
我们发现关键是将 ETL 分解为两个单独的部分。由于 ETL 是提取-转换-加载，因此关键是将 T 与 E&L 分开。制作一个将输入数据集转换为输出数据集的纯 Transform 函数，然后从 Extract and Load 模块调用此函数。
Extract and Load 模块不适合单元测试，因为它通常会涉及外部数据源和接收器、访问令牌和用户权限等。
但是所有可测试的逻辑都应该在 Transform 组件中。从任何单元测试框架测试此功能 - 您将能够传入预定义的数据集并根据预期结果测试转换后的输出。经过一番思考，我们甚至设法创建了单元测试，用于测试数据集的多阶段更新。
我们的特定实现是在 Scala 中的 Databricks 上完成的，但这个概念应该适用于任何平台。
【讨论】：
ETL过程中的测试分为以下几个阶段：
我们还可以将 ETL 测试过程分类如下： 产品验证 源到目标数据测试 元数据测试 性能测试 集成和质量测试 报告测试
【讨论】：