《ETL测试方法.doc》由会员分享，可在线阅读，更多相关《ETL测试方法.doc（5页珍藏版）》请在三一文库上搜索。
1、一、 ETL测试方法论根据 ETL各个阶段的不同特点，可以将ETL测试分为：物理数据测试和逻辑数据测试。物理数据测试：是指纯粹从技术上保证数据的有效性，与业务无关。逻辑数据测试：是从业务逻辑上，对原始指标以及最终产出的业务指标之间的逻辑平衡性监控。通过这些监控，能让底层etl 技术人员第一时间的发现数据问题并且解决问题，同时也能根据这些监控提前知道可能产生的结果，为后续产生的业务分析报告作出进一步的修正，从而保证数据仓库的数据的是有效的是能真正反应事实的。（引用adolph ）在 ETL测试过程中，根据实际情况可以将ETL的这些环节拆分或组合成多个测试面，根据不同的测试面进行不同重点的测试。目
2、前可以将ETL环节拆分成以下4 个测试面：源数据-odl 、 odl-adl 、 idl-adl 、源数据-adl测试面，其中源数据-bdl侧重物理数据测试，bdl-adl侧重逻辑数据测试。各个测试面的关注点如下：1. 源数据到 odl 的测试主要关注以下几个方面（侧重物理数据测试）：对 ETL抽取方案的测试。首先是抽取方案稳定性，如果源体系表结构有改变，需要保证ETL抽取方案不变或者微变。其次数据传送接口方案合理性。源系统以何种形式把数据提供给目标系统，源系统推送或者目标系统主动抽取。数据日期、数据大小、记录数、增量or 全量。对于抽取策略的测试。检测抽取策略的合理性。目前常用的抽取策略有全
3、量抽取、增量抽取。对于增量抽取，捕捉变化的数据有如下几种： 1)采用快照方式。需要业务系统建立insert,update,delete 触发器。 2)时间戳方式，在业务系统表建一个时间戳字段，一旦数据发生变化，则修改此字段。3)全表删除插入方式，每次ETL操作先将目标表数据删除，然后抽取。4)hash 比对，是全表比对的一个扩展，通过计算主要业务字段的MD5校验码存入 hash 维表，通过与hash 维表的比对进行抽取。5)日志表方式，跟进业务系统的日志表进行数据抽取。 6)oracle 变化数据捕捉，通过分析数据库自身日志判断变化的数据。对转换规则的测试。首先是数据格式的合法性。对于数据源中
4、时间、数值、字符等数据的处理，是否符合数据仓库规则，是否进行统一的转换。其次是值域的有效性。是否有超出维表或者业务值域的范围。第三是空值的处理。是否捕获字段空值，或者需要对空值进行替换为其他含义值的处理。第四是主键的有效性。主键是否唯一。第五是乱码的检查。特殊符号或者乱码符号的护理规则。第六是脏数据的处理。比如不符合业务逻辑的数据，数据孤岛。加载策略的测试。首先是加载策略的合理性。目前常用的加载策略有如下几种：1) trunctae and insert. 直接清空目标表，然后把新的数据加载进去。2) append. 先根据规则清除当天的记录，然后把当天的新数据追加进去。3)update an
5、d insert. 用新数据与目标表中的历史数据进行比较，有变化的则更新，新记录则直接插入到目标表中。4) keep history change. 保持历史的变化，通常是拉链记历史的方式实现。2. 第二面是odl 到 adl 的测试。主要关注以下几个方面（物理数据测试+逻辑数据测试）：对转换规则的测试。首先是数据格式的合法性。对于数据源中时间、数值、字符等数据的处理，是否符合数据仓库规则，是否进行统一的转换。其次是值域的有效性。是否有超出维表或者业务值域的范围。第三是空值的处理。是否捕获字段空值，或者需要对空值进行替换为其他含义值的处理。第四是主键的有效性。主键是否唯一。第五是乱码的检查。特
6、殊符号或者乱码符号的护理规则。第六是脏数据的处理。比如不符合业务逻辑的数据，数据孤岛。对 delta 测试。Delta 记录的是变化的数据，通过今天与昨天数据的比对找出变化的记录。对拉链历史测试。主要是检查是否存在断链的记录，生命周期是否交叉。对数据趋势测试。首先是数据趋势要趋于平稳，即波动是否有规律，且波动范围在设定的阀值之间。关于阀值的设定不同的业务指标有不同的标准。对业务逻辑测试。根据业务规则验证业务正常流。指标口径的一致性，如对于有效cookie 的定义是否统一口径。如从行业维度考察各个行业的上架产品数，需要注意区分行业以及上架产品的概念。各行业的LPV，根据平台的情况，各个行业的LP
7、V 大致的区间范围。各行业的 DPV，根据平台的情况，各个行业的DPV 大致的区间范围。理论上LPVDPV。根据业务规则验证业务异常流。如上架产品数对于 produc_id的异常处理，考虑行业不存在的情况等等。程序编译是否通过，是否支持重复调度以及回滚。根据业务是否需要记历史。验证记录平衡，从浏览明细表统计出的行业LPV,DPV根据业务是否平衡。唯一性，目标表中行业维度是否唯一，是否存在重复性记录等等。3.第三面是 idl 到 adl 的测试。主要关注以下几个方面（物理数据测试+逻辑数据测试）：对业务逻辑测试。根据业务规则验证业务正常流。指标口径的一致性，如对于有效cookie 的定义是否统一
8、口径。如从行业维度考察各个行业的上架产品数，需要注意区分行业以及上架产品的概念。各行业的LPV，根据平台的情况，各个行业的LPV 大致的区间范围。各行业的 DPV，根据平台的情况，各个行业的DPV 大致的区间范围。理论上LPVDPV。根据业务规则验证业务异常流。比如上架产品数对于produc_id 的异常处理，考虑行业不存在的情况等等。程序编译是否通过，是否支持重复调度以及回滚。根据业务是否需要记历史。验证记录平衡，从浏览明细表统计出的行业LPV,DPV根据业务是否平衡。唯一性，目标表中行业维度是否唯一，是否存在重复性记录等等。对数据趋势测试。首先是数据趋势要趋于平稳，即波动是否有规律，且波动
9、范围在设定的阀值之间。关于阀值的设定不同的业务指标有不同的标准。4.第四面是源系统到adl 的测试。主要关注以下几个方面：上述的综合ETL测试是一个持续的过程，数据仓库每天都会定时进行ETL的抽取，因此ETL 测试并非是一次性的工作，必须要持续进行，才能保证数据的质量，因此ETL持续集成测试是有必要的。ETL测试分层ETL测试分层：针对ETL 过程的特点，将ETL 过程划分成不同的层级，针对层级特点来实施不同的测试方案，达到测试代码的复用以及提高测试效率的目的。从图上可以看出，ETL 过程存在很清晰的等级分层情况。在进行ETL 测试的过程中，可以将ETL 过程划分为：源数据 -odl （ 1）
10、 ,odl-bdl （ 2） ,bdl-idl （3） ,idl-adl （ 4）4 个层级， 4 个层级分别是 4 个零件块，针对每个零件块进行测试代码的开发与维护，最终组合成一个整体。在业务模型以及物理模型丰富的企业中，底层相对稳定，主题域的划分细致、明确，因此多数应用能通过 idl 主题域来进行实现，此时ETL测试工作的重点集中在第四零件块上，针对第四零件块进行测试代码的开发与维护，通过调用第一零件块，第二零件块，第三零件块，从而达到整体测试。在业务模型不丰富的企业中，一些应用的实现需要从最底层向上逐步刷取，此时ETL测试工作的重点分布在四个零件块上，需要进行第一，第二，第三，第四零件块
11、的测试代码的开发与维护，通过相互调用达到整体测试。在实际项目过程中，我们需要结合具体情况进行ETL过程拆分。将ETL分层测试与 ETL持续集成结合起来，形成一套强有力的ETL测试体系。二、测试数据的准备ETL测试的具体实施博客分类：ETL测试方法数据仓库ETL测试 ETL测试过程ETL测试实施数据仓库测试设计OraclePostgresql. 前阵子在博客中总结了关于ETL测试的来龙去脉， 简单粗浅地明确了 ETL测试是做什么的，以及为什么需要ETL测试的问题。今天我们再来讲讲ETL测试怎么做，以及怎么做会比较好，效率高。首先，谈到了测试，通俗讲无外乎就是通过设计一定的输入、经过被测对象的运算
12、之后，对生成的输出数据的正确性进行校验。如果发现所有的测试输入，得到的测试输出，都和预期的一致，那么测试就是通过的。否则就是被测对象的逻辑出现了问题，就是我们说的发现了bug。那么对于 ETL测试来讲，输入是什么呢？如何设计输入数据才能充分地测试被测对象呢？一、测试数据的构造：如果你记性好，一定还记得在软件工程课程中，讲到针对某个功能如何设计测试用例的逻辑吧。我们知道，测试数据讲求逻辑的覆盖，而覆盖又分为什么分支覆盖、条件覆盖什么的。对于一个分支，我们需要设置两种数据分别来是的这个分支为真和为假来测试分支逻辑是否正确。只不过对于像 java 这样的语言，分支都是一个个if而对于 SQL分支就是
13、一整个where 子句。而每个分子中可能有很多个条件，比如if(A & B & C) 等， A、 B、 C 就是这个分支的条件。为了测试各个条件，我们需要是的每个条件都出现一次为真或为假的覆盖，这就是通常说的条件覆盖(应该是这样的，呵呵 )。而在 SQL 中，所谓的条件覆盖想必你已经清楚了，就是是的一个where 子句中的每个条件都有一次为真和为假的机会。那我们在设计测试输入数据的时候就要遵循这样的原则。(其实还有一种条件组合覆盖，更加负责，我认为一般没必要哈哈)当然这只是我们在设计数据时候的原则，有时候我们也会使用真实的业务数据来进行测试。真实的业务数据有个好处是：1，数据量大；2，存在真实
14、业务环境中的各种数据情况。一般来讲，我们会结合两种方式进行数据准备：以真实数据为主，结合构造数据的方式。数据的构造可以通过修改真实数据和完全构造业务数据两种方式实现。二、执行被测逻辑，生成测试输出数据。这一步很简单，就是将开发提测的代码在准备的数据环境中执行，会生成相应的输出数据。而这个输出数据就是我们要进行验证的。SQL和其他语言的区别在于，如果是Java，每一条测试数据、每一个测试用例都要单独执行。每条测试输入数据会生成对应的测试输出数据。而对于SQL，如果你用过SQL的话一定明白，它一下子就能处理了你所构造的所有的数据，它是一种从数据集到数据集的操作。有时候，这个数据集的大小回事万级、也
15、可能时百万级、千万级。三、测试输出数据的校验这个是测试执行中的核心步骤，在传统的测试中，一个输入数据一个输出数据，验证该输出数据，这就构成了一个测试用例，即我们说的 TestCase。对应与 ETL测试中，是数据集到数据集的行为，而且数据量很大，因此一条一条测数据的思路并不可取。我们只能通过验证一个数据集是否正确来决定测试用例是否执行成功以及测试是否可以通过。可以想到的一个简单的思路是，我们也构造一个输出结果的数据集，成为预期结果集，然后和实际输出结果集进行比对。一致则 OK，不一致则 bug。但是这样有一个问题就是，这个预期结果集的构造比较麻烦，而且对于测试人员来讲，完全够造这么一个测试集工
16、作量和风险都很大，得不偿失。因此，我们采取另外一种策略：我们不会构造一个完整的预期输出结果集，而是对实际输出结果集的一些维度进行分别测试 ，这些维度一般来讲是简单的，容易度量和生成预期值的。?比如说，我们检查实际结果集的数据量（ count ）是否和预期一致，构造完整的预期结果集困难，但是预期的数据量（ count ）构造则很容易。?在比如说，唯一性，通过分析，我们得到结果集中某几个维度，或某些个维度是唯一键。我们就可以针对实际结果集进行检查，看这些维度是否满足唯一性。这些都是对结果集的特征属性进行校验，这些特征属性是结果集正确的必要条件。对于结果集的值校验，我们也不必要构造完全的预期结果集进
17、行比对，我们可以将结果集按照字段进行分类，?将容易计算的，逻辑简单的字段分在一起，我们写一些简单的，不容易出错的SQL 生成这几个字段的结果集，和实际结果集进行比较。?对于计算逻辑复杂的字段，我们采取单个处理，各个击破的策略搞定俗话说，大事化小、小事化了就是这个道理，哈哈。这第三点可以说是ETL测试与传统过程是程序测试的本质区别所在。传统的测试逻辑是以设计输入为主的，即一个测试用例主要是考虑：该用例的输入数据对于程序逻辑的覆盖程度，而起结果验证则是相对简单的。我这里姑且称之为：单维度导向的测试。而 ETL 测试，则多加了一个方面，对输出数据的验证逻辑也同样需要合理的设计，否则就无法准确判断输出
18、结果是否正确，也就谈不上正确测试了。既需要考虑输入数据的逻辑覆盖情况，又需要合理设计输出数据的验证逻辑。我这里姑且称之为：双维度导向的测试。讲到这里， ETL测试逻辑基本上就清楚了。接下来我们需要讲讲实际操作的问题了，实际操作主要面临两个问题：1.数据构造2.结果集验证分别对应上述的第一、三点。对于数据构造，我们在第一点中已经说明，以真实数据为主，结合构造数据的方式。数据的构造可以通过修改真实数据和完全构造业务数据两种方式实现。对于结果集的验证，我们需要针对设计的结果集的各个验证维度上分别编写两个SQL。一个SQL 从输入数据中计算该维度的预期值， 例如数据量等。 另一个 SQL从实际结果集中
19、计算该维度上实际结果集的值 。然后将这两个 SQL的结果进行比较，一致，则测试用例通过，不一致则 Bug。有时候一个复杂的结果集可能会有很多个验证维度。那就意味着需要写很多个SQL，那这些SQL如何保存，如何执行。有没有一种简单、方便、高效的方式进行管理。以及这些SQL的执行是手动将SQL写到数据库里执行，手工比对结果呢？还是有其他的方法，可以自动化的批量执行和自动比对？这就是我们下一篇该主题的博客要讲的，ETL测试的自动化执行。ETL测试过程中，构造标准数据集往往是很关键和复杂的一个环节。目前我们的标准数据集的构造通常包括两个部分：一部分是造一批基础数据，包括空值，边界值，中文，乱码，特殊符号，负数，小数等。一部分是造业务数据。针对第一部分，如果是单纯手工造数据，效率不高，且还容易出错，这里我写了一个比较通用的过程，用来批量造数据。