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