数据测试实践

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

功能性软件的测试

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

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

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

测试金字塔

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

测试金字塔分为三层，自下而上分别对应单元测试、集成测试、端到端测试。

单元测试是指函数或类级别的，较小范围代码的测试，一般不依赖外部系统（可通过Mock或测试替身等实现）。单元测试的特点是运行速度非常快（最好全部在内存中运行），所以执行这种测试的成本也就很低。单元测试在测试金字塔的最底端，占的面积最大。这指导我们应该构建大量的这类测试，并以这类测试为主来保证软件质量。

集成测试是比单元测试集成程度更高的测试，它在运行时执行的代码路径更广，通常会依赖数据库、文件系统等外部环境。由于依赖了外部环境，集成测试的运行速度更慢，执行测试的成本更高。集成测试在测试金字塔的中间，这指导我们应该构建中等数量的这类测试。集成测试在Web应用场景中也常常被称为服务测试（Service Test）或API测试。

端到端测试是比集成测试更靠后的测试，通常通过直接模拟用户操作来构建这样的测试。由于需要模拟用户操作，所以它常常需要依赖一整套完整集成好的环境，这样一来，其运行速度也是最慢的。端到端测试在Web应用场景中也常常被称为UI测试。端到端测试在测试金字塔的顶端，这指导我们应该构建少量的这类测试。

测试的范围非常广，实施方法也非常灵活。哪里是重点？我们要在哪里发力？测试金字塔为我们指明了方向。

一般软件的测试

为了更深入的理解一般软件的测试要怎么做，我们需要进一步深入分析一下测试金字塔。

测试带来的信心

上文中的金字塔图示有一个特点并没有反映出来，那就是，越上层的测试给团队带来的信心越强。这还算好理解，试想，如果没有单元测试，只有端到端测试，我们是不是可以认为程序大部分还是可以正常工作的（可能存在一些边界场景有问题）？但是如果只有单元测试而没有端到端测试，我们连程序能不能运行都不知道！

端到端测试能带来很强的信心，但这常常构成另一个陷阱。由于端到端测试对团队有很大的吸引力，一些团队可能会选择直接构建大量的端到端测试而忽略单元测试。这些端到端测试运行缓慢，一般也难以修改，很快就会让团队举步维艰。缓慢的测试带来了缓慢的持续集成，高频率的上线就慢慢变得遥不可及。

单元测试虽然不能直接给人很强的信心，但是常常是更有效的测试手段，因为它可以很容易的覆盖到各种边界场景。

测试金字塔是敏捷软件开发所推崇的测试原则，它是在测试带来的信心和测试本身的可维护性两者中权衡做出的选择。测试金字塔可以指导我们构建足够的测试，使得团队既对软件质量有足够的信心，又不会有太多的测试维护负担。

既然是权衡，那么我们是否可以以单元测试和集成测试为主，而根本不构建端到端测试（此时端到端测试的功能通过手工测试完成）呢？

测试集成度

对于一些没有UI（或者说GUI）的应用，或者一些程序库、框架（如Spring）等，很多时候测试金字塔中的三类测试并不直接适用。我们可以这样理解：测试金字塔并非只是三层，它更多的是帮我们建立了在项目中组织测试的原则。

事实上，对于通用的软件