和实际输出结果集进行比对。一致则OK，不一致则bug。
但是这样有一个问题就是，这个预期结果集的构造比较麻烦，而且对于测试人员来讲，完全够造这么一个测试集工作量和风险都很大，得不偿失。
因此，我们采取另外一种策略：我们不会构造一个完整的预期输出结果集，而是对实际输出结果集的一些维度进行分别测试 ，这些维度一般来讲是简单的，容易度量和生成预期值的。
?比如说，我们检查实际结果集的数据量（count）是否和预期一致，构造完整的预期结果集困难，但是预期的数据量（count）构造则很容易。
?在比如说，唯一性，通过分析，我们得到结果集中某几个维度，或某些个维度是唯一键。我们就可以针对实际结果集进行检查，看这些维度是否满足唯一性。
这些都是对结果集的特征属性进行校验，这些特征属性是结果集正确的必要条件。
对于结果集的值校验，我们也不必要构造完全的预期结果集进行比对，我们可以将结果集按照字段进行分类，
?将容易计算的，逻辑简单的字段分在一起，我们写一些简单的，不容易出错的SQL生成这几个字段的结果集，和实际结果集进行比较。
?对于计算逻辑复杂的字段，我们采取单个处理，各个击破的策略搞定 俗话说，大事化小、小事化了就是这个道理，哈哈。
这第三点可以说是ETL测试与传统过程是程序测试的本质区别所在。
传统的测试逻辑是以设计输入为主的，即一个测试用例主要是考虑：该用例的输入数据对于程序逻辑的覆盖程度，而起结果验证则是相对简单的 。我这里姑且称之为：单维度导向的测试 。
而ETL测试，则多加了一个方面，对输出数据的验证逻辑也同样需要合理的设计 ，否则就无法准确判断输出结果是否正确，也就谈不上正确测试了。既需要考虑输入数据的逻辑覆盖情况，又需要合理设计输出数据的验证逻辑 。我这里姑且称之为：双维度导向的测试 。
讲到这里，ETL测试逻辑基本上就清楚了。
接下来我们需要讲讲实际操作的问题了，实际操作主要面临两个问题：
1.数据构造 2.结果集验证
分别对应上述的第一、三点。
对于数据构造，我们在第一点中已经说明，以真实数据为主，结合构造数据的方式。 数据的构造可以通过修改真实数据和完全构造业务数据两种方式实现。
对于结果集的验证 ，我们需要针对设计的结果集的各个验证维度上分别编写两个SQL。一个SQL从输入数据中计算该维度的预期值，例如数据量等。另一个SQL从实际结果集中计算该维度上实际结果集的值 。然后将这两个SQL的结果进行比较，一致，则测试用例通过，不一致则Bug。
有时候一个复杂的结果集可能会有很多个验证维度。那就意味着需要写很多个SQL，那这些SQL如何保存，如何执行。有没有一种简单、方便、高效的方式进行管理。以及这些SQL的执行是手动将SQL写到数据库里执行，手工比对结果呢？还是有其他的方法，可以自动化的批量执行和自动比对？
这就是我们下一篇该主题的博客要讲的，ETL测试的自动化执行 。
ETL测试过程中，构造标准数据集往往是很关键和复杂的一个环节。 目前我们的标准数据集的构造通常包括两个部分：
一部分是造一批基础数据，包括空值，边界值，中文，乱码，特殊符号，负数，小数等。 一部分是造业务数据。
针对第一部分，如果是单纯手工造数据，效率不高，且还容易出错，这里我写了一个比较通用的过程，用来批量造数据。