ETL测试过程

前阵子在博客中总结了关于ETL测试的来龙去脉，简单粗浅地明确了ETL测试是做什么的，以及为什么需要ETL测试的问题。今天我们再来讲讲ETL测试怎么做，以及怎么做会比较好，效率高。

 

首先，谈到了测试，通俗讲无外乎就是通过设计一定的输入、经过被测对象的运算之后，对生成的输出数据的正确性进行校验。如果发现所有的测试输入，得到的测试输出，都和预期的一致，那么测试就是通过的。否则就是被测对象的逻辑出现了问题，就是我们说的发现了bug。

 

 

那么对于ETL测试来讲，输入是什么呢？如何设计输入数据才能充分地测试被测对象呢？

 

一、测试数据的构造：

 

如果你记性好，一定还记得在软件工程课程中，讲到针对某个功能如何设计测试用例的逻辑吧。

我们知道，测试数据讲求逻辑的覆盖，而覆盖又分为什么分支覆盖、条件覆盖什么的。

 

对于一个分支，我们需要设置两种数据分别来是的这个分支为真和为假来测试分支逻辑是否正确。

只不过对于像java这样的语言，分支都是一个个if

而对于SQL分支就是一整个where子句。

 

而每个分子中可能有很多个条件，比如if(A && B && C)等，A、B、C就是这个分支的条件。为了测试各个条件，我们需要是的每个条件都出现一次为真或为假的覆盖，这就是通常说的条件覆盖(应该是这样的，呵呵)。而在SQL中，所谓的条件覆盖想必你已经清楚了，就是是的一个where子句中的每个条件都有一次为真和为假的机会。

 

那我们在设计测试输入数据的时候就要遵循这样的原则。 (其实还有一种条件组合覆盖，更加负责，我认为一般没必要哈哈 )

 

当然这只是我们在设计数据时候的原则，有时候我们也会使用真实的业务数据来进行测试。真实的业务数据有个好处是：1，数据量大；2，存在真实业务环境中的各种数据情况。

 

一般来讲，我们会结合两种方式进行数据准备：以真实数据为主，结合构造数据的方式。 数据的构造可以通过修改真实数据和完全构造业务数据两种方式实现。

 

 

二、执行被测逻辑，生成测试输出数据。

 

这一步很简单，就是将开发提测的代码在准备的数据环境中执行，会生成相应的输出数据。而这个输出数据就是我们要进行验证的。

SQL和其他语言的区别在于，如果是Java，每一条测试数据、每一个测试用例都要单独执行。每条测试输入数据会生成对应的测试输出数据。而对于SQL，如果你用过SQL的话一定明白，它一下子就能处理了你所构造的所有的数据，它是一种从数据集到数据集的操作。有时候，这个数据集的大小回事万级、也可能时百万级、千万级。

 

三、测试输出数据的校验

 

这个是测试执行中的核心步骤，在传统的测试中，一个输入数据——>一个输出数据，验证该输出数据 ，这就构成了一个测试用例，即我们说的TestCase。对应与ETL测试中，是数据集到数据集的行为，而且数据量很大，因此一条一条测数据的思路并不可取。我们只能通过验证一个数据集是否正确来决定测试用例是否执行成功以及测试是否可以通过。

 

可以想到的一个简单的思路是，我们也构造一个输出结果的数据集，成为预期结果集，然后和实际输出结果集进行比对。一致则OK，不一致则bug。

 

但是这样有一个问题就是，这个预期结果集的构造比较麻烦，而且对于测试人员来讲，完全够造这么一个测试集工作量和风险都很大，得不偿失。

 

因此，我们采取另外一种策略：我们不会构造一个完整的预期输出结果集，而是对实际输出结果集的一些维度进行分别测试 ，这些维度一般来讲是简单的，容易度量和生成预期值的。

 

• 比如说，我们检查实际结果集的数据量（count）是否和预期一致，构造完整的预期结果集困难，但是预期的数据量（count）构造则很容易。
• 在比如说，唯一性，通过分析，我们得到结果集中某几个维度，或某些个维度是唯一键。我们就可以针对实际结果集进行检查，看这些维度是否满足唯一性。

这些都是对结果集的特征属性进行校验，这些特征属性是结果集正确的必要条件。

对于结果集的值校验，我们也不必要构造完全的预期结果集进行比对，我们可以将结果集按照字段进行分类，

• 将容易计算的，逻辑简单的字段分在一起，我们写一些简单的，不容易出错的SQL生成这几个字段的结果集，和实际结果集进行比较。
• 对于计算逻辑复杂的字段，我们采取单个处理，各个击破的策略搞定

俗话说，大事化小、小事化了就是这个道理，哈哈。

 

 

这第三点可以说是ETL测试与传统过程是程序测试的本质区别所在。

 

传统的测试逻辑是以设计输入为主的，即一个测试用例主要是考虑：该用例的输入数据对于程序逻辑的覆盖程度，而起结果验证则是相对简单的 。我这里姑且称之为：单维度导向的测试 。

 

而ETL测试，则多加了一个方面，对输出数据的验证逻辑也同样需要合理的设计 ，否则就无法准确判断输出结果是否正确，也就谈不上正确测试了。既需要考虑输入数据的逻辑覆盖情况，有需要合理设计输出数据的验证逻辑 。我这里姑且称之为：双维度导向的测试 。

 

 

讲到这里，ETL测试逻辑基本上就清楚了。

 

接下来我们需要讲讲实际操作的问题了，实际操作主要面临两个问题：

1. 数据构造
2. 结果集验证

分别对应上述的第一、三点。

 

对于数据构造，我们在第一点中已经说明，以真实数据为主，结合构造数据的方式。 数据的构造可以通过修改真实数据和完全构造业务数据两种方式实现。

 

对于结果集的验证 ，我们需要针对设计的结果集的各个验证维度上分别编写两个SQL。一个SQL从输入数据中计算该维度的预期值，例如数据量等。另一个SQL从实际结果集中计算该维度上实际结果集的值 。然后将这两个SQL的结果进行比较，一致，则测试用例通过，不一致则Bug。

 

 

有时候一个复杂的结果集可能会有很多个验证维度。那就意味着需要写很多个SQL，那这些SQL如何保存，如何执行。有没有一种简单、方便、高效的方式进行管理。以及这些SQL的执行是手动将SQL写到数据库里执行，手工比对结果呢？还是有其他的方法，可以自动化的批量执行和自动比对？

 

这就是我们下一篇该主题的博客要讲的，ETL测试的自动化执行 。