数据质量测试实战：从数据流转到数据质量保障

用户看到一行数据，背后可能经过五层加工

业务数据通常要经过源数据库、抽取任务、清洗转换、数据仓库、接口与缓存，最后才出现在页面、报表或AI应用中。任何一层出错，都可能让最后的数字看起来合理、实际上却是错的。

各层职责与测试重点

ETL 测试的目标

• 数据没有无故丢失、重复或被错误过滤。
• 字段、类型、金额精度和业务状态转换正确。
• 明细、汇总、接口与页面使用同一指标口径。
• 跑批失败、重复执行和迟到数据都能被安全处理。
• 异常可追溯到具体批次、规则、业务键和数据层。

每个阶段分别测什么

字段映射表示例

Mapping 表至少包含

• 源系统、源表、源字段与数据类型。
• 过滤条件、转换公式、字典映射和默认值。
• 目标表、目标字段、主键、分区和精度。
• 空值、异常值、重复值与无关联数据的处理方式。
• 规则负责人、需求版本和生效日期。

核心验证矩阵

数量不一致时不要直接判Bug

源表100000条、目标表99998条，只能证明存在2条差异。还要结合合法过滤、去重、异常分流和软删除规则，定位是抽取失败、转换过滤还是加载失败。

转换规则用例设计

不良资产规则示例

规则：逾期天数大于90天时，资产状态标记为 BAD。

select loan_id, overdue_days, asset_status
from dwd_loan
where (overdue_days > 90 and asset_status <> 'BAD')
   or (overdue_days <= 90 and asset_status = 'BAD');

测试原则

• 从业务规则反推输入，不只抽查生产数据。
• 每个比较符号都测试边界两侧和边界本身。
• 金额、利率和比例明确精度与舍入方式。
• 异常数据必须有去向：拒绝、默认、隔离或告警，不能静默消失。

增量任务必须覆盖的场景

水位线测试

• 起始时间是否包含边界，结束时间是否排除下一批次。
• 时间字段使用创建时间、更新时间还是业务日期。
• 时区转换、跨日、月末和节假日跑批是否正确。
• 水位线推进必须与任务提交成功保持一致。

幂等的判断标准

同一批次执行一次和执行多次，最终业务结果必须相同。不能只看任务返回成功，还要核对行数、唯一键、金额总额、版本号和下游汇总是否保持不变。

六个数据质量维度

质量阈值要分层

• P0：资金、余额、贷款本金等控制总额必须零差异。
• P1：关键字段完整率、唯一率必须达到明确阈值。
• P2：非关键描述字段允许少量异常，但要进入趋势监控。
• 任何阈值都要有业务负责人和处置动作，不能只展示红绿灯。

数据血缘

当ADS报表数字错误时，必须能反查到DWS聚合、DWD明细、ODS原始记录和源系统。测试报告应记录表级、字段级血缘以及对应规则版本，避免只知道“数字错了”，不知道从哪一层开始查。

贯穿验证

• OCR准确性：合同金额、客户、日期和编号与原件一致。
• 结构化入库：类型、精度、必填字段和重复合同处理正确。
• 风险规则：逾期天数、贷款余额和担保信息计算正确。
• 控制总额：源贷款余额、DWD资产余额、报表总额零差异。
• 页面与AI：展示指标来自正确版本的数据，AI引用的资产事实可追溯。

高风险场景

• OCR把500000识别为50000，格式合法但金额错误。
• 同一合同重复上传，导致资产金额重复累计。
• 迟到的还款数据没有回补，风险等级长期偏高。
• 旧维度数据覆盖新客户状态，导致清收策略错误。
• AI分析使用过期ADS快照，却没有展示数据时间。

适合自动化的检查

• 按批次核对源、过滤、目标数量。
• 唯一键、必填字段、枚举和数值范围。
• 金额、数量和余额控制总额。
• Mapping规则和差异SQL回归。
• 重复跑批、断点重跑和迟到数据回补。
• 质量阈值越界时阻断或告警。

自动化边界

脚本擅长发现差异，不擅长决定差异是否符合业务。指标口径变化、监管规则和异常数据处置仍需要产品、数据开发与测试共同确认。

ETL 测试报告