针对我们产品线的某些模型产品的需求，开始展开大数据测试，对大数据测试仍然属于摸索和尝试的阶段，大家感兴趣的欢迎拍砖。
一、 模型产生的过程
· 信息收集：需明确项目目标和业务需求，根据确定的数据分析对象，确定分析对象所需要的特征信息，以及特征信息的计算方法；这个过程业务方会做很多的准备工作，会拉数据去证明哪些特征信息与我们的数据分析对象是有关联的；
· 数据准备： 从数据仓库中获取数据构造用于模型分析的数据集，包括选择数据、格式化数据、数据清理、数据整合等过程，是整个数据挖掘过程中最耗时的环节，甚至占据整个模型项目一半以上的工作量。而数据是整个数据挖掘的根基，数据的质量直接决定模型分析的结果的准确性；
· 建立模型：选择合适的建模技术和算法，将最终得到的数据集是作为模型的输入进行训练，同时对它们的参数进行校准以达到最优值。
· 模型评估： 通过模型的训练会最终得到一个分析结果，需要对它们进行验证和评价，证明其合理性和准确性。一般对模型进行评估的方法有：业务上抽样数据验证、计算模型的准确率、信息分布、 K-S 值、 Gini 值等；
二、 数据测试的范围和难点
针对模型产生的这一过程，可以确定我们的测试范围和重点是数据准备这个环节，就如上所述，数据是整个过程最重要和最关键的一个环节，需要确保数据的质量。
测试对象：开发人员开发数据的 HiveSql 脚本及脚本产出的数据集合；
我们产品的数据特点：
1. 大部分字段有比较复杂的计算逻辑；
2. 无需求说明文档，加大了理解字段的难度；
3. 无设计文档，即无执行计划，表关系、计算逻辑、源表只能通过分析代码获得；代码在划分模块、编写风格上，不同开发有不同特点；
三、 数据测试技术 & 方法
公司有一些 BU 在做数据的测试，目前大家一起筹备在做大数据测试的共建。
· 相关的技术 ：
1. 规则扫描技术：对数据集合的字段列配置一些校验规则，自动进行扫描；
2. 静态代码扫描：目前有列顺序扫描、代码规范扫描等；
3. 单元测试：数据准确、单元脚本的执行。提供单测平台，驱动开发去做 hivesql 的单元测试，测试人员主要是 review 开发的单测脚本校验规则是否齐全和正确；
4. 数据对比：数据集合的对比；
等等 。。。。。。应用到我们模型数据测试中的技术有规则扫描、列对比、数据对比等技术，比较适用，发现的数据类 bug 比较多；
· 关于数据测试方面的沉淀和方法比较零散，没有形成体系；且各个 BU 因为业务的差异性，测试方法也存在不同。针对我们产品的数据特点，我整理了一些过程中用到的 测试方法 ：
1. 结果数据比对方法，主要做数据量的比对、数据取值是否和源数据仓库中的数据一致；
2. 抽样数据验证：此方法主要用于校验有比较复杂计算逻辑的字段数据是否正确；计算逻辑比较复杂，编写自动化脚本做大批量数据的比对代价会比较大，需要产生很多中间表，因此，做抽样数据验证，大大提高了效率，也易于发现 bug ；
3. 代码静态分析和 code review ，会发现一些业务上和筛选条件上的错误；
4. 造测试数据，验证计算逻辑；
5. 数据列顺序对比；
· 校验的场景：
1. 数据量；
2. 记录是否唯一；
3. 数据区间和分布（ min 、 max 、 avg 等）；
4. 数据中 null 值的替换及格式化特征；
5. 数据边界；
6. 数据是否一致、存在丢失；
7. 列顺序是否正确；
8. 数据的精度和格式化信息；
四、 测试工具
过程中，运用的测试工具有：
1. Hivetest
既可做 sql 与 sql 的比对，也能做 sql 与值的比对测试，平台包括数据准确、同步、脚本的模版、执行等；
2. 规则扫描工具：主要是对字段列配置规则进行扫描；
3. 表关系生成工具；
还有一些工具，例如 Slowly 平台、一淘的单元测试平台、 BI 的 checklist 数据对比工具、单元测试平台，没有进行适用， Slowly 目前只支持支付宝的集群，一淘的目前还未做权限开放，当然想用的话，仍然可以联系灵石做处理； BI 的单测平台目前只支持云梯 2 ，而我们却在云梯 1 ......
总体感觉，在大数据测试这块，大数据对比、规则扫描、代码静态扫描、表关系生成、执行计划自动生成、单测平台会有比较大的应用前景，大数据的比对是难点。
五、 常见 bug 分类
尝试做了 2 个模型的数据测试，发现的 bug 不多，大体上集中在：
1. 记录不唯一；
2. Null 值替换问题；
3. 过滤条件不正确；
4. 数据不一致和丢失；
5. 列顺序错误；
