大数据项目测试4大原则
每次执笔想写一些简洁扼要的文字来分享自己的测试经验时，总会因笔墨淡浅戛然而止。
谈到大数据项目测试经验分享，我想给大家分享4条指导原则。
第一条最高原则、提早预防、尽早测试。
“提早预防、尽早测试” 这一条是所有项目的测试最高指导原则。
世界著名的质量管理专家戴明博士（W．Edwards．Deming）曾说过 ：不能通过检验（测试）来改变产品的质量，产品开发好了，质量就在那里。
换句说话，我们不能依靠大批量的检验来达到质量标准，检验出来已经太迟，次品已定，成本高且效益低。
接下来，回想一下整个开发过程，思考缺陷检出阶段与所耗费的成本的关系，见下图：
图1. 缺陷修复成本曲线
由上图可见，要想达到高质量标准，正确的做法应该是改良生产过程，质量内建。即，提早预防、尽早测试。
- 预防缺陷、削除解决缺陷成本
- 尽早测试、 及时反馈、降低成本
- 回归测试以时为单位，而不是以天或周为单位
细节这里不多赘述了，人人都知道的理论原则，重点是QA要在项目上引导团队好好贯彻落实，参见一幅旧图：QA实践，感兴趣的移步原文浏览。（来自《机器学习平台测试篇）。
图2. QA实践
第二条原则、分步、分解、再分层
“分解、分步、再分层”这一条是大数据项目特色原则。
做大数据项目的朋友都知道，大数据的处理通道比较长，经过一系列的处理加工，最终呈现给用户。由此，在测试过程中，不能再像普通项目那样，直接端对端看结果测试，否则，反馈周期长、成本高、问题定位难。正确的是在数据的每个阶段介入测试，每个阶段复杂的处理过程进行分解检验，检验的时候要从底层到顶层逐层验证。
- 分步
大数据有很多个阶段，最常见的：数据收集、数据集构建、数据预处理、数据特征工程、数据训练、数据预测、数据业务逻辑计算、数据展示。每步都要尽早参与验证，及早反馈。 - 分解
每个阶段的数据处理可能较为复杂多样，此时，建议复杂问题简单化后再进行测试。比如，在下图的FLOW中，数据集处理较为复杂，分支较多。此时，建议先对FLOW进行分解，一条条分支分别检验，一步步处理逻辑逐个验证。
图3. 复杂的数据Flow
- 分层
大数据项目中，数据集通常都是海量数据，原始数据会存储在集群中，如：Hadoop的HDFS；数据集的元数据信息、以及样例数据通常存放于其它数据库表当中；最后，才会展示于界面。
数据处理过程的测试要分层检验，从底层到顶层，逐层验证：
1)底层文件存储数据验证
2)中间元数据以及样例数据验证
3)顶层的界面展示验证。
第三条原则、先精准、后全量
大数据项目，实际当中，处理的都是大数据量。但在处理逻辑测试过程中，建议先用最小数据量进行精准测试；然后，再用贴近实际当中的全量数据进行验证。
- 精准测试
这里强调用最小数据覆盖验证更多Case，精准测试每一条逻辑。目的就是最少的数据量来验证正确性，准确测试、快速反馈。
原本认为这条不必讲，大家都是这么做。但在实际工作中，本人参与过三个大数据项目测试、也给几个数据项目做过测试远程咨询，了解到至少70%的人都是直接拿一份已有数据表或文件直接验证。
这样测试的弊端就在于：数据多反馈慢、定位慢、不直观、不简洁清淅。甚至，有时都不清楚这份数据量中的Case样本是否全面。更有人在自动化测试中也用的这样的数据， 这样导致自动化用时变长。
因此，这里再次强调，逻辑正确性测试，请用最小数据量精准测试，尽可能减少多余数据干扰。 - 全量验证
经过最小数据集的逻辑正确性验证后，再拿大数据量进行验证，目的在于发现数据量变大时引发的功能或性能问题。有真实脱敏数据最好，用真实数据实际性检验，进一步质量保障。
第四条、真实场景、尽早上线试测
大数据项目，线上的数据五花八门，会有我们预想不到的情况，风险很高。一但数据有问题，通常直接导致主流程跑不通，致命的缺陷，上线宣告失败。因此，强烈建议在正式开放给用户之前，进行提前上线测试或预上线打通验证，越早上线实验成本越低。
而且大数据项目，往往QA环境与生产环境资源相差甚大，线上数据量非常大，远比QA环境能处理的量级高几倍。比如，QA环境测到几十G的数据量时就资源不足，但生产环境有几百甚至更大量级的数据。所以，无论从数据的复杂性还是环境的差异来看，尽早上线试测非常关键。
图4. 利弊权衡
