网站建设技术难点,cd.wordpress.ncn,网站建设需求分析,wordpress本地到当有人问我做什么工作时#xff0c;我会说我是一名数据质量保证 (QA) 工程师。他们并不真正理解我的意思。“嗯#xff0c;我做数据测试#xff0c;”我试图解释#xff0c;但常常无济于事。我有一些从事技术和软件开发的朋友#xff0c;他们不太了解数据测试是什么#…当有人问我做什么工作时我会说我是一名数据质量保证 (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在数据管道之上分层了一套数据断言单元测试。
自动化
自动化是数据质量领域的一个关键原则也是数据质量六个维度的执行。例如结合使用单元测试和数据完整性测试数据质量工程师可以编写一个小型、快速的自动化测试来检查关键字段中的任何 NULL 值。数据管道中以各种方式检查关键数据质量维度的自动化测试越多数据工程师要做的工作就越少。
如果数据工程师不用生成表并每次使用 SQL 和数据库连接查看它而是拥有一个内置的回归测试套件来为她运行日常检查会怎么样这些是数据质量工程师所做的有用的自动化基础和测试工程。
总结
数据测试是一个每天都在增长和变化的独特领域。没有太多被广泛接受的数据质量标准甚至像数据质量的六个维度这样的标准也存在争议。机器学习和人工智能 (AI) 等更多数据科学领域正在不断发展并创造了验证数据准确性、一致性、完整性等的新方法。
我们所知道的是目前的数据质量在很大程度上取决于所请求的数据集的主观含义以及数据管道末端人员的需求。这使得很难找到正确的基准来测试和提高数据质量但仍然可以利用对有用测试类型和数据质量维度的了解来验证每天使用的数据。随着对如何使用数据的理解不断发展数据质量指标和对数据测试的理解也会不断发展。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走【文末自行领取】
这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
