用测试金字塔指导数据应用的测试

由于数据应用开发和功能性软件系统开发存在很大的不同，在我们实践过程中，在开发人员和质量保证人员间常常有大量关于测试如何实施的讨论。下文将尝试总结一下数据应用开发的特点，并讨论在这些特点之下，对应的测试策略应该是怎么样的。

功能性软件的测试

先来回顾一下功能性软件系统开发中的测试。

测试一般分为自动化测试和手工测试。由于手工测试对人工依赖程度很高，如果主要依赖手工测试来保证软件质量，将无法满足软件快速迭代上线的需要。现代软件开发越来越强调自动化测试的作用，这也是敏捷软件开发的基本要求。有了全方位的自动化测试保障，就有可能做到每周上线，每日上线甚至随时上线。

这里主要讨论自动化测试。

测试金字塔

我们一般会按照如下测试金字塔的原则来组织自动化测试。

可见这两种测试方式都不是好的测试方式。

测试构建原则

那么有没有什么好的原则呢从实践中总结出了几点比较有价值的思路供大家参考。

• 将脚本分为简单和复杂（可以通过代码行数，数据筛选条件多少等进行衡量）。简单的通过代码评审或结对编程来保证代码质量，不做自动化测试。复杂的通过建立集成测试来保证质量。
• 由于集成测试运行较慢，可以考虑：
  • 尽量少点用例数量，将多个用例合并为一个来运行（主要是将数据可以合并成单一的一套数据来运行）
  • 将测试分级为需要频繁运行的测试和无需频繁运行的测试，比如可将测试分级P0-P5，P3-P5是经常（如每天或每次代码提交）要运行的测试，P0-P2可以低频（如每周）运行
  • 开发测试支持工具，使得运行时可以尽量脱离缓慢的集群环境。如使用读写本地表
• 考虑将复杂的逻辑使用自定义函数实现，降低脚本的复杂度。对自定义函数建立完整的单元测试。
• 将复杂的脚本拆分为多个简单的脚本实现，从而降低单个脚本的复杂度。

加深对业务和数据的理解

我们在实践过程中发现，其实大多数时候脚本的问题不在于代码写错了，而在于对业务和数据理解不够。比如，前面文章中的空调销售的例子，如果我们在统计销量的时候不知道存在退货或者他店调货的业务实际情况，那我们就不知道数据中还有一些字段能反映这个业务，也就不能正确的计算销量了。

想要形成对数据的深入理解需要对长时间的业务知识积累和长时间对数据的探索分析（业务系统通常经历了长时间的发展，在此期间内业务规则复杂性不断增加，导致数据的复杂性不断增加）。对于刚加入团队的新人，他们更容易由于没有考虑到某些业务情况而导致数据计算错误。

加深对业务和数据的理解是进行高效和高质量脚本开发的必由之路。

有没有什么好的实践方法可以帮助我们加深理解呢几点是我们在实践中总结的值得参考的建议：

• 通过思维导图/流程图来整理复杂的业务流程（或业务知识），形成知识库
• 尽量多的进行数据探索，发掘容易忽略的领域业务知识，并通过第一步进行记录
• 找业务系统团队沟通，找出更多的领域业务知识，并通过第一步进行记录
• 如果有条件，可以更频繁的实地使用业务系统，总结更多的领域业务知识，并通过第一步进行记录
• 针对第一步搜集到的这些容易忽略的特定领域业务流程，设计自动化测试用例进行覆盖

SQL自定义函数的测试

在基于的分布式数据平台环境下，自定义函数通常通过或编写。由于这些代码通常对外部的依赖很少，通常只是单纯的根据输入数据计算得到输出数据，所以对这些代码建立测试是十分容易的事。事实上，我们很容易实现100%的测试覆盖率。

在组织测试时，我们可以用单元测试的方式，不依赖计算框架。比如，以下编写的自定义函数：

在建立了单元测试之后，一般还需要考虑建立少量的集成测试，即通过框架运行来测试此自定义函数，一个示例可以是：

如果自定义函数本身十分简单，我们也可以直接通过测试来覆盖所有场景。

从上面的讨论可以看出，自定义函数是很容易测试的。除了好测试之外，自定义函数还有很多好的特性，比如可以很好的降低复杂度，可以很方便的被复用等。所以，我们应该尽量考虑将复杂的业务逻辑通过自定义函数封装起来。这也是业界数据开发所建议的做法（大多数的数据开发框架都对自定义函数提供了很好的支持，如 等，大多数开发工具也都支持自定义函数的开发）。

数据工具的测试

数据工具的实例可以参考文章《数据仓库建模自动化》和《数据开发支持工具》。

这些工具的一大特点是，它们是用于支持开发的，仅在开发过程中使用。由于它们并不是在产品环境中运行的代码，所以我们可以降低对其的质量要求。

这些工具通常只是开发人员为了提高开发效率而编写的代码，存在较大的修改和重构的可能，所以，过早的去建立较完善的测试必要性不高。

在我们的实践过程中，这类代码通常只有很少的测试，我们只对那些特别复杂、没有信心能正确工作的地方建立单元测试。如果这些工具代码是通过的方式编写的，通常其测试会更多一些。

在持续集成流水线中运行测试

前面我们讨论了如何针对数据应用编写测试，还有一个关于测试的重要话题，那就是如何在持续交付流水线中运行这些测试。

在功能性软件项目中，如果我们按照测试金字塔的三层来组织测试，那么在流水线中一般就会对应三个测试过程。

从上面的讨论可知，数据应用的测试被纵向分为四条线，如何对应到流水线上呢我们采用同一个代码库管理所有的代码，可以考虑直接将流水线分为四条并行的流程，分别对应这四条线。如果是不同的代码库，则可以考虑对不同的代码库建立不同的流水线。在每条流水线内部，就可以按照单元测试、低集成测试、高集成测试这样的方式组织流水线任务。

一、独立的流水线

对于代码的测试，有一个值得思考的问题。那就是，脚本之间通常独立性非常强，相互之间没有依赖。这是由于代码常常由完善的领域特定语言开发而成，与或等通用编程语言编写的代码不同，文件之间是没有依赖的（如果说有依赖，那也是通过数据库表产生依赖）。

既然如此，假设我们修改了某一个文件的代码，是不是我们可以不用运行其他的文件的测试呢不仅如此，我们甚至可以单独上线部署此，而不是一次性部署所有的。这在一定程度上还降低了部署代码带来的风险。

有了上面的发现，我们可能要重新思考数据应用的持续交付流水线组织形式。

一个可能的办法是为每一个文件建立一个流水线，完成测试、部署的任务。此时每个可以理解为一个独立的小程序。

这样的想法在实践中不容易落地，因为这将导致大量的流水线存在（常常有上百条），从而给流水线工具带来了很大的压力。常用的流水线工具，如，其设计是难以支撑这么大规模的流水线的创建和管理的。

要如何来支持上面这样的流水线呢需要我们开发额外的流水线工具才行。

二、云服务中的流水线

现在的一些云服务厂商在尝试这样做。他们通常会提供一个基于的开发工具，同时会提供工具对当前的的编写测试。此时，开发人员可以在一个地方完成开发、测试、上线，这可以提高开发效率。

对于这些数据云服务厂商提供的数据开发服务，如果可以同时支持通过代码和界面配置来实现数据开发，那将能得到更多开发者的喜爱。这在我看来是一个不错的发展方向。

总结

由于数据应用开发有很强的独特的特点（比如以为主、有较多的支撑工具等），其测试与功能性软件开发的测试也存在很大的不同。

在最后，结合我们的实践经验，给出了一些数据应用中的测试构建实践。将数据应用分为四个不同模块来分别构建测试，可以很好的应对数据应用中的质量要求，同时保证有较好的可维护性。最后，我们讨论了如何在持续集成流水线中设计测试任务，留下了一个有待探索的方向，即如何针对单个构建流水线。

数据应用的质量保证是不容易做到的，常常需要我们进行很多的权衡取舍才能找到最适合的方式。想要解决这一问题，还要发挥团队中所有人的能动性，多总结和思考才行。

文/Thoughtworks 廖光明

原文链接：用测试金字塔指导数据应用的测试 – Thoughtworks洞见