本文档主要介绍ETL测试的流程，以及一般的项目情况来说明ETL的测试方法。
ETL测试流程图
测试环节
1、 需求分析
熟悉业务流程和业务规则，根据需求分析出源表与目标表以及之间的mapping关系，解析出业务的数据流图：
1、 测试分析
测试点：
ETL常规检查：
1.ETL脚本是否有运行错误，脚本运行时间(看执行计划)
2.ETL脚本的错误处理机制是否完整(代码review)
3.ETL脚本是否支持回滚
业务逻辑检查：
1.数据量的检查。核对记录数是否和预期一致
2.唯一性检查。
主键是否重复(cookie_id,member_id是否重复)
3.业务字段转换正确性检查。指标计算是否正确.抽样检查。
源表和目标表各取一定数量记录，判断字段映射是否正确(映射字段)。
指标计算是否正确(指标计算字段)
4.随机性验证(随机取几条数据，看是否有乱码，异常数据等。
测试重点
项目中的关键业务，复杂逻辑部分作为测试重点
用例划分说明:
按每个指标设计用例。
测试策略：
测试策略：增量测试(逐步提交测试)
测试方法：基于查询的测试(预期结果基于sql来展现，做到数据变化，结果不变。另外便于回归)
2、 标准数据集构建
造数据分2个方面，1个是直接抽取线上的数据1个是用脚本造异常数据。
3.1 利用dblink抽取线上的数据。抽取线上数据时，需要注意，测试数据的全面性。即测试数据全面覆盖。比如sex字段，在抽取线上数据时，需要抽取到male、female情况，而不能仅仅是male或female，这样测试数据就会缺失。对于有关联的表进行数据抽取时，可以先抽取主表，然后根据主表的数据有条件的抽取子表。
3.2 造异常数据，异常数据可以从下面几个方面进行考虑：字段类型、字段长度、空值、业务异常值、唯一约束值
3、 测试用例设计
测试用例可以单独设计，也可以采用调度的思想进行设计，采用调度方法进行设计时，能一次验证多个用例，另外也方便回归。这里说一下调度思想的测试用例的设计思路。
设计思路：
总调脚本：
CREATE OR REPLACE PACKAGE BODY PKG_KPI_TC IS
PROCEDURE SCHEDULER(
/*********************************************************************
*parameter:
*authoer XIANGMIN.MENGXM
*time 2009-6-26
*
*********************************************************************/
P_DATE IN DATE DEFAULT TRUNC(SYSDATE))
IS
V_DATE DATE := TRUNC(P_DATE);
BEGIN
DELETE FROM test_map WHERE yyyymmdd = v_date;
COMMIT;--调度之前先清空测试表
REF_KPI_TC_001(v_date);--用例1
REF_KPI_TC_002(v_date);--用例2
END;
END PKG_KPI_TC;
测试用例1
CREATE OR REPLACE PROCEDURE REF_KPI_TC_001(P_DATE IN DATE DEFAULT TRUNC(SYSDATE)) IS
V_id NUMBER;
V_DATE DATE := TRUNC(P_DATE);
BEGIN
SELECT a.id into v_id FROM src_a;
INSERT INTO test_map(YYYYMMDD,id,x) VALUES(v_date,v_id,x);
COMMIT;
END;
1、 测试结果验证
Exec procedure_();--得出被测脚本的结果
Exec REF_KPI_TC_001();得出测试结果
结果验证：
第一步先验证记录数是否一致，如果记录数不一致，则一定存在问题，检查问题，找出原因。
第二步在记录数一致的情况下，检查值是否正确。
方法1：巧用minus
SELECT * FROM target_a
MINUS
SELECT * FROM test_map;
--注意，此处一定要调换2个表的位置进行比较。Minus函数在进行比较时，以第一张表为准，找出第一张表中与第二张表不一致的地方。即：找出sumdt0表中与map表不一致的结果
方法2：写脚本进行验证
2、 发布后
在相关平台观察数据趋势，数据监控。项目发布后，我们可以观察数据的波动趋势，一般来说数据的波动是在一定范围，遵循一定原则的，如果发现数据波动超出了预计范围，这个时候就需要特别注意了。
