数据集成测试支持工具

在前一篇文章中，我们探讨了数据应用如何做测试的问题。在数据测试中，ETL脚本的测试是个难题。一般而言，采用高集成度的测试方式（即运行ETL并比对结果，下文称集成测试）是更有效的做法。但是，这类测试的编写和维护却有较高的成本。如何降低ETL集成测试的成本呢？本文尝试从数据工具的角度分享一些我们的经验。

ETL集成测试的痛点

ETL集成测试的编写和维护成本高在哪里呢？

我们先来看如何编写一个ETL集成测试。

对于某一个ETL任务，其工作过程一般是三个步骤：读取数据、处理数据、将数据写入新表。为构建这样一个集成测试，我们需要完成这样几步：

• 为ETL测试构建一个运行环境；
• 创建ETL需要读取的表，并将准备好的数据写入；
• 创建ETL的正确输出结果表，并将准备好的数据写入；
• 针对测试环境中的表运行ETL（可能需要做一定的修改，因为表名、数据库名可能不一样）；
• 比对ETL任务生成的数据和第三步中构造的数据，如果两者一致，则测试通过。

一般而言，为了保证测试的有效性，我们希望构建一套类生产环境的ETL测试运行环境。如果额外搭建一套大数据平台环境，这带来的搭建和维护成本就比较高了。同时它还会带来一定的资源消耗，比如我们至少要准备3个节点的计算资源，且需要配置的CPU和内存还不能太低。

如果我们直接使用生产环境作为测试环境使用，这节省了集群的搭建和维护成本，但我们需要配置好运行ETL测试的用户权限，以防止在测试运行过程中错误的将数据写入了生产环境的数据库表。使用一套环境还有一个缺点，那就是在运行测试之前我们需要修改ETL脚本中的数据库名或数据表名，将它们指向测试对应的库或表。这也是一件麻烦事，而且极容易出错。

如果需要创建测试用的输入输出表，我们需要在准备测试用例时编写不少建表语句代码。同时，还需要注意数据表的Schema变化，比如某一天由于业务需要，我们将字段名字或类型做了修改，此时测试也不得不跟着修改。

比对数据这一步，也可能存在问题。由于并行计算的存在，ETL的输出结果中的数据很可能每次都不一样，是乱序的。此时我们在做比较的时候，需要注意将数据顺序对齐，这一般可以通过order by所有字段来实现。

ETL集成测试支持工具设计

从以上ETL集成测试痛点分析可以看出，如果不借助任何工具，只靠运维的手段来构建测试，将会非常复杂，且极易出错。如何解决这些痛点呢？我们可以考虑编写一个工具应用来做支持。

愿景

我们希望这个测试工具是轻量级的，简单可用。它不能直接产生价值，因此不能投入太多的精力。同时这个工具应当是易用的，尽量使得团队所有人都能一看就懂。这个工具还需要能辅助完成（或避免）前面痛点分析中的大部分复杂易错的操作。

需求及设计

要实现以上的愿景，第一个需要回答的问题是，使用者（开发人员或测试人员）应当如何和工具交互。

交互工具

在前面的文章数据仓库建模自动化中，我们使用Excel电子表格作为交互方式。这里可以参考前面的做法，依然使用电子表格来让用户构建测试。

电子表格不仅是大家常用的熟悉的工具，还是天生的编辑表格数据的工具，用来构建测试用例应当是非常合适的选择。而且现在很多可以协同编辑电子表格的工具，如Google Spreadsheet等，使得我们可以多人协作进行测试用例的设计和编写。

模板

电子表格可以非常灵活的编辑数据，为了使得用户可以创建测试用例，我们需要设计一个固定的模板。

测试文件和测