(精品）20XX年测试ETL工具都应测试哪些方面.docx

1、是否支持流行的数据存储，比如各种关系型数据库，文件数据存储等2、是否在ETL过程中支持“事务”3、加载数据的性能，如十万条级别的数据的加载时间4、各种数据转换的功能，自动调度运行等等 测试分析 测试点： 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、 测试用例设计 测试用例可以单独设计，也可以采用调度的思想进行设计，采用调度方法进行设计时，能一次验证多个用例，另外也方便回归。这里说一下调度思想的测试用例的设计思路。 设计思路： 个人的一些想法: 就像文中所说的，由于每个人的配置不一样，可能你精通kettle ,所以你测试出来的结果kettle 会比较快，如果你精通talend ，可能talend 测试出来的比较快，所以一味的比较速度没有意思，没有办法在统一环境下测试. 另外就是个人觉得ETL工具的性能并不是ETL工具最先考虑的东西，功能和易用性和可管理性才是最重要的，kettle 在功能和易用性上得分比较高，可管理性则是很一般. 另外ETL工具中kettle 的性能一向都是很强的，早在kettle 被pentaho 收购之前，它在亚马逊云上的5 台服务器的集群速度就是4000 row * 5 , 而且由于kettle 配置集群又超级简单，而且是根据端口来区分节点，所以一台计算机上都可以配置几个从服务器, 上面给出的代码中就是这样的，不会配置的朋友可以看一下，（真的就是看一眼就懂了). ? 另外一个觉得很有意思的ETL工具就是oracle 的warehouse build 和data integration ,由于里面使用的是oracle 数据库专有的pl /sql , 不太清楚它的伸缩能力怎么样 (oracle 的hints 里面是可以控制并行度的，不知道pl /sql 会不会也有控制并行度的选项) ? 再加上kettle 的分区特性和正在做的"可配置并行度" , kettle 的伸缩能力是很强的. 所以性能问题一向都不是kettle 的弱项. 最后要说的就是还是最关心kettle 的可管理性，它的"transform 和 job " 的版本控制和 "Repository" 的全库导入导出不知道什么时候可以做好. 开源ETL工具kettle系列之常见问题 摘要：本文主要介绍使用kettle设计一些ETL任务时一些常见问题，这些问题大部分都不在官方FAQ上，你可以在kettle的论坛上找到一些问题的答案 1.?Join我得到A 数据流（不管是基于文件或数据库），A包含field1 , field2 , field3 字段，然后我还有一个B数据流，B包含field4 , field5 , field6 , 我现在想把它们 ‘加’ 起来, 应该怎么样做.这是新手最容易犯错的一个地方，A数据流跟B数据流能够Join，肯定是它们包含join key ,join key 可以是一个字段也可以是多个字段。如果两个数据流没有join key ,那么它们就是在做笛卡尔积，一般很少会这样。比如你现在需要列出一个员工的姓名和他所在部门的姓名，如果这是在同一个数据库，大家都知道会在一个sql 里面加上where 限定条件，但是如果员工表和部门表在两个不同的数据流里面