一、接到这个项目的时候我脑子是懵的先交代一下背景。我们做的这个数据中台项目底层是Oracle信创要求国产化改造版。需求方提了个需求两万张表总共一千万个字段。当时我刚拿到这个需求的时候脑子里只有三个字怎么测两万张表什么概念假如你每天手动测10张表要花2000天整整5年半。等你测完业务都迭代了不知道多少轮了。后来我们把这个需求拆解了一下落地是这样的每张表500个字段Oracle硬限制1000列我们留了一半余量给自己留点缓冲两万张表 × 500字段 一千万字段分了8个表空间存储按业务域划分用户、商品、订单、物流、营销、风控、财务、客服我作为测试负责人第一件事就是跟团队说别想着手工测想都别想。我们必须把测试自动化不然这个项目做不完。二、数仓测试到底测什么很多人一听说数仓测试第一反应是写几个SQL看看数据对不对。这话对了一半但远远不够。在两万张表面前你得想清楚一件事数仓测试的本质是什么我在项目里总结了三句话数据从哪来、经过谁、到哪去—— 路径要对数据进来多少、出去多少、丢没丢—— 数量要对数据算出来跟业务预期对不对得上—— 逻辑要对这三句话对应到我们项目的分层测试策略是这样的层级数据对象测什么怎么测ODS层贴源数据抽取完整、字段映射对不对行数对比 字段哈希DWD层明细数据清洗逻辑、去重、空值处理业务规则校验SQLDWS层汇总数据指标计算、多维度统计交叉验证 数据回溯ADS层应用数据报表、接口下游对比 UAT这个表格看着简单但实际上我们花了两周才把每一层的测试点定下来。因为每一层的数据特征不一样测试重点也不一样。ODS层最怕的是丢数据DWD层最怕的是洗错了DWS层最怕的是算错了ADS层最怕的是给出去的跟算出来的对不上。三、测试环境搭建从3天到2小时测试环境的搭建是我们遇到的第一个大坑。第一次建环境DBA手动建库、建表空间、导入元数据。8个表空间两万张表的元数据折腾了整整3天。中间还翻了一次车表空间分配不均导致建到第8000张表的时候报ORA-01688: unable to extend table只能重来。那次重来又花了一天。后来我们痛定思痛写了一套自动化建环境的脚本bash#!/bin/bash # 一键创建测试环境的脚本 # 1. 创建8个表空间 sqlplus / as sysdba EOF CREATE TABLESPACE TBS_USER DATAFILE /u01/data/user01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_ORDER DATAFILE /u01/data/order01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_PRODUCT DATAFILE /u01/data/product01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_LOGISTICS DATAFILE /u01/data/logistics01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_MARKETING DATAFILE /u01/data/marketing01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_RISK DATAFILE /u01/data/risk01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_FINANCE DATAFILE /u01/data/finance01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; CREATE TABLESPACE TBS_SERVICE DATAFILE /u01/data/service01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; EOF # 2. 从元数据表读取表结构生成建表DDL python3 generate_ddl.py --envtest --total20000 # 3. 分批建表每批100张间隔3秒防止数据字典锁 python3 batch_create.py --batch100 --sleep3 # 4. 插入测试数据每张表插入1000行 python3 insert_test_data.py --rows1000这套脚本跑完之后环境搭建时间从3天压缩到了2小时。这个效率提升是决定性的。你想想如果每次环境出问题都要等3天重建这个项目根本没法推进。后来我们每次跑完一轮测试就直接用脚本重建环境确保每次测试都是从干净的状态开始不会因为上一次测试残留的数据干扰结果。四、测试数据怎么来测试数据的问题是第二个大坑。生产数据不能用因为有敏感信息手机号、身份证、邮箱直接拉生产数据到测试环境是违规的。但完全用造数工具生成的数据又跟生产特征差太远。你用假数据测出来的性能指标到了生产上完全不适用等于白测。我们最后采取的策略是生产脱敏 边界构造双轨并行。第一步生产数据脱敏从生产库抽取样本数据每张表抽10万行经过脱敏处理后再导入测试环境。脱敏的核心逻辑很简单sql-- 对敏感字段做脱敏 UPDATE customer SET phone 138**** || SUBSTR(phone, -4), id_card **************** || SUBSTR(id_card, -4), email user_ || ROWNUM || test.com, name 用户_ || ROWNUM WHERE ROWNUM 100000;手机号只保留前3位和后4位身份证只保留后4位姓名替换成用户_序号。这样既保留了数据的分布特征比如不同地区号码段的比例又不会泄露真实信息。第二步构造边界数据光有脱敏数据不够你还得主动制造一些脏数据来测试系统的容错能力。我们专门构造了几类边界数据python# 边界测试数据 test_cases [ {scenario: 空值, data: None}, {scenario: 字段最大长度, data: A * 4000}, {scenario: 特殊字符, data: #%……*——}, {scenario: 负数边界, data: -99999999}, {scenario: 日期边界, data: 9999-12-31}, {scenario: 科学计数法, data: 1.23456789e10}, ]这些边界数据后来真的帮我们发现了一个大问题某个字段在源库是VARCHAR2(4000)但数仓建表的时候设成了VARCHAR2(255)结果长文本被截断了。要不是我们主动造了长文本的测试数据这个问题可能要等到生产上线、业务方发现数据对不上才会暴露。五、测试执行分层推进测试执行我们分了四个阶段每个阶段都有明确的准入准出标准。简单说就是上一层没测通绝不下到下一层。阶段一ODS层数据接入测试验证数据从源系统到ODS的抽取是否完整。实际操作中我们对比源库和目标库的行数sql-- 对比源系统和ODS的数据量 SELECT COUNT(*) FROM source_orderdblink WHERE dt 2026-01-15; -- 返回3,847,291 SELECT COUNT(*) FROM ods.ods_order_dtl WHERE dt 2026-01-15; -- 返回3,847,235 -- 差异56条差异率0.00145%差异率控制在0.01%以内就算通过。但为什么会有差异我们后来排查发现那56条是源库在抽数过程中被删除了导致数据不一致。跟业务方确认后这种情况允许存在。我们踩过一个很严重的坑源库有一张表是月分区表但抽数脚本的WHERE条件里没指定分区结果只抽了当月数据历史数据全丢了。当时ODS层的数据量突然少了一大截我们花了两天才排查出来。后来我们加了一条强制性规则所有抽数SQL必须显式指定分区范围否则脚本直接报错退出。阶段二DWD层清洗逻辑测试验证ETL过程中的数据清洗、转换、去重逻辑是否正确。比如订单状态字段源系统存的是代码0/1/2数仓要转成中文待支付/已支付/已取消。我们的测试SQL是这样的sql-- 验证状态转换逻辑是否正确 -- 源库状态0应该对应数仓的待支付 SELECT COUNT(*) FROM dwd.dwd_order_detail WHERE source_status 0 AND target_status ! 待支付; -- 这个查询应该返回0如果有数据说明转换逻辑错了如果查询结果大于0就说明状态映射配置错了或者漏配了。阶段三DWS层汇总指标测试汇总层的测试是最复杂的。一个指标可能涉及多张明细表、多层嵌套查询、复杂的CASE WHEN逻辑。我们的策略是把复杂的多维度指标拆成单维度SQL分别计算再跟汇总表对比。举个例子GMV商品交易总额这个指标sql-- 从明细层手工计算GMV按日期、按渠道分别汇总 SELECT dt, channel_id, SUM(order_amount) as gmv_calc FROM dwd.dwd_order_detail WHERE order_status 已支付 AND dt 2026-01-15 GROUP BY dt, channel_id; -- 对比DWS层汇总表 SELECT dt, channel_id, gmv_dws FROM dws.dws_order_gmv WHERE dt 2026-01-15;如果两边对不上就得逐层下钻排查——是明细层的数据丢了还是汇总逻辑写错了还是JOIN条件漏了。有一次我们发现GMV差了50万排查到最后发现是明细层过滤条件写错了order_status 已支付写成了order_status 已付款而源系统存的是已支付三个字导致一大批订单没被算进去。阶段四ADS层应用数据验证最后一步验证数据产品、BI报表展示的数据对不对。这部分我们直接让业务用户参与UAT用户验收测试。因为有些业务逻辑只有他们最清楚比如这个指标在什么情况下应该包含什么、排除什么这些规则技术团队很难完全掌握。六、自动化测试框架前面说了手工测两万张表是不可能的。我们开发了一套轻量级的自动化测试框架核心就是三个函数pythonclass DataWarehouseTest: def test_row_count(self, source_table, target_table, tolerance0.001): 行数校验 src_cnt self.query(fSELECT COUNT(*) FROM {source_table}) tgt_cnt self.query(fSELECT COUNT(*) FROM {target_table}) diff_rate abs(src_cnt - tgt_cnt) / src_cnt assert diff_rate tolerance, f行数差异率{diff_rate}超过阈值{tolerance} def test_field_hash(self, table_name, key_columns): 字段哈希校验 hash_sql f SELECT MD5(CONCAT_WS(|, {,.join(key_columns)})) FROM {table_name} return self.query(hash_sql) def test_business_rule(self, rule_sql, expected_result): 业务规则校验 actual self.query(rule_sql) assert actual expected_result, f规则校验失败: {rule_sql}每天早上8点Jenkins自动触发测试任务跑完生成HTML测试报告。如果发现异常结果自动推送到钉钉群。这套框架跑起来之后我们的测试效率提升了一个数量级。以前手工测10张表要半天现在全自动跑两万张表只要两个小时。七、几个关键的经验教训教训一测试环境一定要跟生产隔离我们一开始图省事测试和生产共用了一套环境。结果有一次测试脚本写错了误删了生产环境的5张表。还好有前一天的备份但那次事故让我们全员加了三天班补数据。从那以后测试环境和生产环境严格物理隔离。测试环境的数据库服务器跟生产都是分开的网络也不通。教训二行数对得上不代表数据没问题我们遇到过一种情况ODS层和源库的行数完全一致但某个字段的值被截断了VARCHAR2长度不够。行数对得上但内容少了后半截。后来我们在哈希校验里加入了字段长度分布检查才抓到这类问题。sql-- 检查字段长度分布发现异常截断 SELECT LENGTH(order_desc) as len, COUNT(*) as cnt FROM ods.ods_order GROUP BY LENGTH(order_desc) ORDER BY len DESC;正常情况下字段长度应该呈正态分布。如果突然在255这个长度上出现一个巨大的峰值说明有数据被截断在255了。教训三测试用例要版本化管理两万张表的结构不是一成不变的。业务方经常改字段——今天加一个会员等级明天改一个订单来源。如果测试用例跟表结构脱节测出来的结果就没有意义。我们把测试用例跟表结构元数据绑定在一起。每次表结构变更自动触发对应的测试用例更新。这样能保证测试用例始终跟生产保持一致。八、写在最后数仓测试跟传统软件测试最大的区别在于传统测试是验证一个确定的结果数仓测试是验证一个不确定的过程。你写一个单元测试输入11期待输出2结果确定。但数仓里几亿条数据经过多层转换、多表关联、复杂计算最终出来的结果是什么没有标准答案只有合理和不合理。所以数仓测试的核心能力不是写SQL而是理解业务逻辑、设计合理的校验方法、建立自动化的测试体系。我们的这套方法论是在两万张表、一千万字段的极端规模下被逼出来的。希望对正在做类似项目的你有帮助。有什么问题欢迎评论区交流