为什么数据需要 QA 流程

当有人问我做什么工作时，我会说我是一名数据质量保证 (QA) 工程师。他们并不真正理解我的意思。“嗯，我做数据测试，”我试图解释，但常常无济于事。我有一些从事技术和软件开发的朋友，他们不太了解数据测试是什么，为什么它是必要的，或者它在编程世界中的位置。这是可以理解的，因为数据科学是一个全新的领域，即使是每天与数据打交道的人也必须对处理工作方式的任何变化保持开放的态度。

要了解数据测试的工作原理，必须首先了解什么是数据工程。然后就可以研究数据质量以及如何衡量它。

数据工程和分析

要了解数据测试从哪里开始，需要先知道数据是如何设计的，以及它与其他类型的编程（例如软件开发）的不同之处。让我们从什么是数据开始。数据是保存在业务工具中的某种聚合信息。该工具是电子表格还是数据库取决于业务，但创建数据的原始位置才是开始的地方。

源中的原始数据对任何人来说都没有多大用处，这就是数据工程的用处。在数据工程中，将获取数据并使其有用的过程称为提取、转换、加载或 ETL。从源中提取数据后，可以根据业务需求对其进行转换并加载到业务分析工具中。业务分析师和财务分析师有机会使用数据集来创建报告、图表和其他所需的指标来为业务决策提供信息。

T 代表转换，转换可能是数据工程过程中最关键的点。这里以拥有多家商店的零售企业为例。假设有几家老店使用过时的POS系统，而新店则运行更现代的系统。每种类型的 POS 系统中的交易记录和存储方式都不同，存储在不同的数据库中。如果企业主想要查看每周的销售报告，则需要汇总两个系统的交易。

为此，必须有一个转换过程，可以从每个 POS 系统获取交易信息，并以有意义的方式将它们整合在一起。最重要的是，有关交易数据及其与销售报告的关系的问题很快就会出现。这里问一个问题：每个系统中的退货与实际销售如何计算？

接下来更进一步地讨论这个例子。原来的 POS 系统将所有内容存储在与新 POS 系统的数据库不兼容的数据库中，因此无法简单地加入信息。现在，转换阶段必须包括某种数据转换，然后才能将事务整合在一起。最终，企业主只是想在报告中接收汇总的销售信息，这在一开始听起来很简单。

对数据（销售报告）的需求以及将其转换为有意义的内容所需的技术工作（将不同的系统组合在一起）是定义数据集含义的两个关键要素。在例子中，寻找“销售”的含义，然后需要一份关于它的报告，这种模糊且主观的业务定义会让测试数据变得非常棘手。

测量数据质量

现在已经了解了数据和数据工程是什么样子。如果没有某种基准来衡量，就无法定义数据质量，并且通常在测试过程中，基准是各种可报告的指标。那么如何在数据世界中找到可衡量的东西来验证产品呢？

数据质量的六个维度

当前数据验证的行业标准是使用数据质量六个维度的某种形式来测试数据模型、管道、架构等。这些数据质量指标最初是在数据管理协会 (DAMA) 英国分会于 2013 年撰写的名为“数据质量评估的六个主要维度”的数据质量论文中定义的。这六个维度是一个得到广泛认可的系列用于检查任何给定数据集质量的验证指标。他们帮助数据质量工程师和数据工程师创建可以改进的可衡量的验证指标。

这六个维度是：

• 一致性：如果数据跨多个数据库、系统、表和报告进行复制，则数据应该保持不变，从而保持一致。例如，无论在哪里找到客户当前的邮政编码，都应始终为相同的五位数。
• 准确性：也许是最模糊的数据质量指标，准确性是相关数据代表现实世界事件或对象的程度。假设表中有一列代表所有客户交易的总美元金额，另一列代表交易总金额。这些值中的每一个都应该能够清楚地追溯到来源，从而可以证明总数对于发生的现实世界交易是准确的。
• 有效性：在数据集中的任何给定字段中，可能存在某种数据类型要求。永远不会期望在州字段中看到数字，其中字段限制是美国州（例如 NY、CA 或 IL）的两个字母表示形式。如果该字段中存在整数，则会破坏数据的有效性。
• 唯一性：对于数据库中预期的每条唯一记录，应该有一个字段来唯一标识每条给定的记录，例如在线购物数据库的客户帐号。该帐号的唯一性对于识别单个客户帐户的重复交易可能至关重要。
• 完整性：如果缺少任何关键字段，则数据不完整。也许在业务交易记录中，每笔交易都应该有一个时间戳。如果该时间戳丢失，则交易数据集不完整。
• 及时性：对每份报告接收新数据的期望是什么？数据的及时性是由业务需求定义的。例如，如果需要每天刷新一个数据集，那么该数据集的及时性测试指标也是每天刷新。

对于任何给定的数据集，数据测试和验证应涵盖每个维度。特别是自动化单元测试，但我们稍后会讨论。

工程过程中的数据测试

现在我们了解了数据质量的六个维度、数据工程的一般工作方式以及数据需求的业务定义的至关重要性，接下来的任务就是将所有这些内容整合在一起以创建测试计划。数据质量工程师是数据工程流程的核心；他们支持工程师的技术工作以提供所需的数据集，并与业务分析师合作验证该数据。

数据 QA 测试的类型

在软件测试领域，有几种常见类型的有用质量测试，可以识别错误、确认工作组件并调查软件的预期行为。这些类型的测试在数据测试领域仍然非常有用，因此如果对这些测试类别有所了解，那么你已经了解了有关数据测试的一些知识。

这些包括但不限于：

• 单元测试：嵌入数据建模代码中的小型测试，用于识别基本功能所需的关键代码块内的小断点。例如，也许有一列数据中不应存在 NULL 值。快速单元测试可以检查字段中是否存在 NULL 并确保不存在 NULL。
• 集成测试：这些测试寻找程序或数据管道的全部部分而不是其中的一部分来工作。在数据管道示例中，集成测试将检查整个 ETL 流程是否可以从头到尾成功执行。
• 冒烟测试：快速测试用于有效检查数据管道中最重要且通常常见的部分是否存在故障。该术语起源于计算机硬件测试，当时第一个初始测试是将机器插入电源并查看是否有任何机械部件产生烟雾。如果没有，则硬件通过测试。然而，如果有烟雾……正如你可以想象的那样，他们会关闭机器并重试。
• 回归测试：用于检查程序核心操作的一系列测试，称为“回归”，因为测试套件着眼于代码中永远不应该更改的标准功能部分。通常是在产品发布之前使用的主要套件。就数据而言，回归通常涵盖关键任务转换。
• 功能测试：用于检查在当前发布的操作之上添加到程序中的任何新组件（“功能”）的测试。如果新功能对于生产版本至关重要并且应该保持不变，那么这些功能就会添加到回归测试套件中。

这些都是许多软件开发团队定期使用的常见、有用的测试类型。它们可以并且被应用于数据测试。

单元测试作为数据验证的秘密武器

与几乎每个 QA 角色一样，数据 QA 工程应该为工程团队的工作增加价值，并以有用的方式提供反馈。数据质量保证几乎总是从手动测试开始，特别是在拥有遗留数据库和数据仓库技术的企业中。数据 QA 工程师的笔记本电脑上可能有数百个过多的 SQL 脚本。但手动测试仍然需要有效检查数据质量的六个维度，而不成为生产发布的瓶颈。综上所述，数据测试自动化是完全可能的，尤其是在单元测试和断言方面。

根据我的经验，数据 QA 工程师最重要的角色之一是宣传数据管道中内置的单元测试。当数据工程师在数据转换开发期间实施时，单元测试可以在数据 QA 工程师查看数据集之前捕获数据错误。通常，数据工程师不习惯单元测试，因为这更多的是一种软件开发实践，但我并不是唯一一个认为数据工程在文化上需要更多单元测试的人。数据构建工具（dbt）等流行的开源框架具有内置的单元测试，可以防止完整性、唯一性和及时性方面的问题。其他开源验证工具（例如 Great Expectations）在数据管道之上分层了一套数据断言单元测试。