标签：
二、ETL测试过程：
在独立验证与确认下，与任何其他测试一样，ETL也经历同样的阶段。
1）业务和需求分析并验证。
2）测试方案编写
3）从所有可用的输入条件来设计测试用例和测试场景进行测试
4）执行所有用例直到满足退出标准
5）书写总结报告和测试过程结束。
三、ETL测试的规则：
测试数据的正确性、一致性、完整性
四、ETL测试的方法
1.数据量统计：
源表和目标表数据量统计
2.转换规则测试
首先是数据格式的合法性。对于数据源中时间、数值、字符等数据的处理，是否符合数据仓库规则，是否进行统一的转换。
其次是值域的有效性。是否有超出维表或者业务值域的范围。
第三是空值的处理。是否捕获字段空值，或者需要对空值进行替换为其他含义值的处理。
第四是主键的有效性。主键是否唯一。
第五是乱码的检查。特殊符号或者乱码符号的护理规则。
第六是脏数据的处理。比如不符合业务逻辑的数据
3.关键字段测试
通过转换规则，查询关键字段是否正确。比如保费收入字段，看其是否乘以汇率，共保比率等;
一般表中会添加时间戳，时间戳数据和数据格式是否正确
4.抽样测试
通过抽样，测试源表和目标表映射是否正确。
5.加载规则测试
一般加载方式有两种：全量加载和增量加载
增量加载一般是先删后插（delete and insert）。
全量加载一般是先清空再插入（truncate and insert)，但也要分情况，我们做的项目，源-->ODSSGA层为先清空后插入，向外提供的接口数据则为先删后插，这需要根据不同的情况不同对待。
增量加载方式
对于增量抽取，捕捉变化的数据有如下几种：1)采用快照方式。需要业务系统建立insert,update,delete触发器。2)时间戳方式，在业务系统表建一个时间戳字段，一旦数据发生变化，则修改此字段。3)全表删除插入方式，每次ETL操作先将目标表数据删除，然后抽取。4)hash比对，是全表比对的一个扩展，通过计算主要业务字段的MD5校验码存入hash维表，通过与hash维表的比对进行抽取。5)日志表方式，跟进业务系统的日志表进行数据抽取。6)oracle变化数据捕捉，通过分析数据库自身日志判断变化的数据。
由于我们采取的是时间戳方式，这里就只介绍这种方式的测试方案。
1）测试结果是否遗漏数据，如果为时间戳方式，要尤其注意时间戳是否带时分秒
2）增量规则是否正确
对于源表做好足够的数据探查，明白源表中的数据的增量是怎么回事，必要时需要讨论，然后根据业务规则做增量规则方案。
3）监控增量数据
因为项目在上线前一般都会试运行一段时间，所以在这段时间，就要每天做表中数据量的的监控。
对于日全量表的监控：只要看源表和目标表数据量是否一致就可以
对于增量数据量监控：看全量+增量的数据是否与源表数据量是否一致。根据不同的业务规则，查看是否正确。
然后通过多日监控，可以发现不管是增量还是全量，数据量基本都会处于一个值左右，幅度不会太大，如果出现特殊情况，就要去考虑检查一下它的正确性了。
4）监控增量运行时间
通过监控增量的运行时长，可以发现性能问题和批量数据的运行是否成功。对于时间浮动比较大的增量表，可以第一时间发现问题并解决问题。
全量加载方式
由于我们采取的是全量加载+增量加载（采用时间戳方式），我这里指的全量加载即数据仓库中数据的初始化。
全量加载的测试方案相对要简单些。
1）测试源和目标表的数据量的一致性
2）运行1,2,3,4测试测试方法测试一般来说即可。
6.性能测试
确保数据在规定和预计的时间内被加载到数据仓库中，以确认改进的性能和可扩展性。
7.测试用例
项目中的关键业务，复杂逻辑部分作为测试重点
基础数据：可以为真实数据，也可以单纯手工造数据。因为ETL数据量较大，并且表中字段数量比较多，各表关联比较大，所以本人觉得还是用真实数据效率比较高。
测试用例的编写：测试用例可以单独设计，也可以采用调度的思想进行设计，采用调度方法进行设计时，能一次验证多个用例，另外也方便回归。
8.发布实施后
1）.测试informatica中源、目标映射是否一致
2）.测试开发库和生产库中ETL程序是否一致
3）.监控增量数据和增量运行时间。
增量数据监控：项目发布后，我们可以观察数据的波动趋势，一般来说数据的波动是在一定范围，遵循一定原则的，如果发现数据波动超出了预计范围，这个时候就需要特别注意了。
增量运行时间监控：往往项目上线后，比较在意的是性能问题，以确保在规定的时间内，完成跑批。我们要通过监控增量运行时间，及时发现程序的性能问题。
标签：
原文地址：http://www.cnblogs.com/zourui4271/p/5025855.html
