其实大数据清洗的一个过程是比较复杂的，我这边抽了几个重要的部分，让大家了解一下，
一、数据清洗要做的：
1、数据过滤处理
2、数据不全处理
3、数据一致处理
4、数据合法处理
二、数据清理的走向
不同的数据源，格式上或者数据表现上会很不长一致，比如一个爬虫应用爬去运营商的通话记录我们会发现，电信怕下来的数据是A，联通的是B，移动的是C，我们会发现不同的源命名不一样，字段也不一样。所以我们会对这一类的数据进行规范的处理，这部分一般都是通过数据处理来完成的，这是我们分布式微服务里面的其中一个节点，那其中一个节点，并且还是比较偏下游的，刚才的例子是数据一致性处理。方便对后续的数据挖掘的处理。
清洗数据1是标准化，2是对无用的数据进行剔除，包含冗余的无用的剔除掉的过程，
给测试带来的挑战：
1、数据带来的字段非常非常的多，
2、清洗的业务处理，比较末端，从整体架构上处于相对末端的一个位置，给测试带来执行上成本非常的巨大，如果没有一定的策略却保证你的执行效率的话，你只能从源头开始，逐步生成一些数据流，最终通过清洗时间长。
3、用例结构的难度、数据准备特别麻烦，数据拉取也非常非常的多。
4、我们测试前要评估一些风险，比如漏测与风险。
三大点：风险点，关注点。
1、数据样本的一个问题，主要是位置样本，清洗内容，规则，策略等
2、一些清洗的规则，与其他规则的冲突，比如我们清洗一个表上的某个字段，但是这个字段又与其他字段相互关联，所以才导致冲突。
3、数据清洗规则影响的一些计算等等交叉关系规则。
解决方式：
针对第一点，针对清洗过程当中主要针对线上增加一些告警机制，添加监控，及时掌握一些新的样本，并且能够及时告知反馈，如果我们可能对比一些字段，这些字段可能会出现某种位置样本，那么我们采取一些比较宽松的清洗规则，不用说特别规定的特别严的那种规则，可以采用稍微宽松的规则。近期规则。
针对第二点，针对冲突的，基本上在发布前增加一些依赖关系的检测规则影响到其他规则，那么我们需要开发或者运营去确认的。
针对第三点，针对清洗规则的调整，可能对后续一些节点对吧，比如说数据指标等等的一些计算，相关的可能也会造成一定的影响，那么这一块其实也还是可以通过的DAG检测监控这样的情况。
降到DAG检测，就有一个依赖关系，我们清洗过程中，其实我们数据有时候说字段跟字段之间是有一定依赖关系的，基本上有两种依赖 一种是内部依赖，一种是外部依赖，我们刚擦的图有两种情况发生，比如左边第一个就是身份证号码跟性别，这两个字段，其实他们是有关联的，因为我们可以从身份证号码去推断出性别，这两个字段，其实他们是有关联的，或者说知道性别去推测出来身份证号码某些字段是不对的。
左边这种相对于比较检点点，右边的比较麻烦，是一个闭环，他的清洗规则是相互依赖的，三项，缴费比例，缴费金额跟缴费基数，可能确定能够去决定缴费比例，或者说缴费比率跟缴费基数要确定后能确定缴费金额，这三种谁也不能错。
所以我们在清洗的前期的一个工作，我们一定比如说在需求评审，或者说是对这个清洗规则的一个分析的过程当中，我们一定保证不能出现，就是左边类似的闭环储能出现这种闭环，如果出现这种闭环的话，就很难做清晰了，因为加入我们金额跟技术确定了，确定了以后，虽然可以推导出缴费比例，但是我们缴费比例和你推到出来的不一样，怎么办对不对，，但可能原始缴费比如说爬去下来的缴费比例是对的，等你算出来的事错的，你也无法确认说是击飞金额错了还是基数错了。
清洗规则是脚本写的还是直接工具对比所以加入说你妹遇到这种清洗的要求出现这种闭环的依赖的时候，我们会采取一种策略，就是是前置依赖，我们可以确定缴费比例作为缴费基数的前置依赖，那么作为缴费基数的一个前置依赖，这两部分数据全部确认没有问题了以后，并且成功清洗以后再去做，什么缴费基数的这一个清洗工作，所以会分为两步。
这还有一个好处，就是如果后续数据缺失了，我还能从前置依赖的数据中去补全，补全数据也是这样，会对其中数据根据规则进行补全。
哪些策略能帮我们更好的测试。
1、单个方式的数据覆盖，比如单个字段覆盖。会存在不能覆盖全，不能获取所有的样本。
2、准备的数据去测试，但是很多个字段非常耗费时间。主要是解决第一个问题，先解决上游的问题，从中间的环节去解决，数据太慢就是提升效率，
3、第三个策略数据工厂，存不同数据源的模板，有好几个样本，通过数据工厂，不同的数据源生成我所需要的数据
要造数据，引入数据工厂，某某数据下某个字段，需要多少条，只需要配置一下值就行了。如果前端开一个管理界面，造数据很方便，
同一个数据源其实你只要复制出来一条，用完了稍微改一下描述就行继续做其他的使用。
引入数据工厂然后在数据工厂提供的一个数据的一个层面上，改一下所需要的数据，按照你的测试用例设计的一些方式，去吧一些数据稍微改掉，就可以了，这样设计一个数据大概
通过数据工厂可以批量的生成数据，只要有一些数据丢失，你只需要配置一下就行了，就是我要让所有字段进行补全生成一个空的模板，相当于只有KEY没有VALUE，对我们的数据构造上是非常方便的。
第四点策略、策略比较贴合，有时候数据依赖会有很多数据表。也就是我们清晰的数据会参考很多数据与依赖信息，这个字段会麻烦很多，mock结果数据,怎样去找到中间数据。
其实做一个反向业务补充，生成测试用例，会根据现有的一条业务ID用它为基础，会反向插入这条数据会用到的业务数据。
自己去找的数据是每个表里面都有的，只需要复制表的信息只是更改需要更改的数据，让原生的为模板，插入到现在有的数据当中去。所有通过这种方式即便用了mock也可以吧其他业务表中的内容也都填充了，给人的感觉是比较真实的数据。
清洗后的模板匹配，不同的人给出不同的情况。
不同用户查询模板的正确性。
校验-独立开发校验脚本，借助一些 json比对工具，清洗算法测完以后，需不需要和开发根据原数据洗完的结果，数据做退避，-但是在整个用例设计管理和动用上，最好是独立开发一个后段框架，
源数据全部自己构造，要比对的，但是这个过程会在自动化断言中完成，因为我们每条用例只对一个jsonpath下的某个字段按照规则设计的。
1、清洗数据的开发是在源数据的基础上做了那个设计的亲戚算法，生成的结果数据的话，两个元素是不一样的那么对比性也没有了
收下开发拿到的数据也是保证数据完整，测试也是拿到一个完整的数据模板去进行比对，一旦模板不一样就没有测试的必要了。
2、金融领域测试过程测试数据准备比较好使，有没有比较好的方式，
首先了解那个层面上比较耗时，如果数据工厂不能进行解决，我们可以根据实际情况具体解决。
3、清洗表的数据一般根据数据业务计算出来的，我们看的是最终的结果值，用json对比工具，怎么对比？
使用json工具主要是保障数据的完整性，结果是验证某个字段，下吗计算出来的值应该是多少，根据你的业务表，你应该是比较知道的。
所以我说什么是反向，Json主要是看少了还是多了。
4、我们数据也是不完整的，数据算法开发人员就是在这份数据上开发的，这种情况是不是只能测试这边自己mock数据来测试开发的清洗算法？
还有朋友可以通过部署jacoco方式，吧自动化代码覆盖率给顺带做了
就这种平台化管理各个应用的覆盖率，方便补充使用例。
目前可能各位只能做全亮覆盖率的统计，我们这边开发了增量代码覆盖率统计，你们也可以研究一下，需要修改的jacoco源码探针的逻辑，增量代买覆盖对版本迭代覆盖率的统计有好处的，
原始数据没有做好哦，其实还是应该做好监控，及时做增量补充。
出了用例管理，覆盖率查看，还可以部署监控，都可以加进去，总的来讲就是一整套管理平台，后续cicd自动化监控环节，都可以走这套。------考虑结构全链路压测也可以做，用httprunner+locust结合。
权重可以配比，集成的grafama----常规的influxdb+grafama都可以配套去做，细的可以配合开发买点监控对接上去。
本期由杭州同盾科技K神--周志强分享项目经验，通过VIPTEST社群发起。
