目录
背景
无论是大数据项目、分布式项目、抑或是常见的电商、广告等等业务，几乎都会面临不同程度的脏数据问题。脏数据的来源多种多样，主要的几个来源：
- 上游业务问题，直接把脏数据同步过来了
- 代码问题，导致直接存储了脏数据。
- 数据修改引发的脏数据。比如，QA同学为了创造某个场景，直接修改了数据库，但并未将关联的数据进行完整修改
测试数据引发的问题
如同 ”兵马未动粮草先行“一样，测试数据准备应该在真正测试开始之前进行，否则会在测试过程中不断引发问题。那么，反过来，可以根据测试过程中的问题，来反过来判断你的测试数据是否合格。
当测试数据存在不合格的脏数据时，通常会出现以下 的问题：
- 出现数据层面的bug。通常的一种场景是，QA费力提了bug，结果开发人员经过”千辛万苦“排查后，发现是数据库里面的脏数据带来的；
- 耽误测试进度。测试周期紧张的项目中，由于脏数据引发的bug，无疑会影响整个项目的测试进度。
- 打击整个团队的质量信心。测试数据带来的问题，除了导致很多人力浪费外，还会减弱团队人员对质量的信心。
业务层面的不一致问题；
实现导致的数据同步；
测试数据准备目标
尽可能地接近线上数据。这里的接近包括两个层面：
- 数据量级上
- 数据场景覆盖上
测试数据准备实战
测试数据如何准备和持续维护，和业务需求、技术实现有很大关系。所以，在考虑测试数据的整体方案时，需要综合考虑业务、技术两个层面。
举例来说：
数据库数据来自上游系统的定期同步，是否有脏数据不完全受自己控制。这时，就有两个问题需要着重考虑：
- 脏数据如何鉴别。鉴别的手段很多，比如上游系统控制、SQL检查、接口自动化检查、线上巡检等。当然了，case by case 的方式，遇到一个解决一个，也是一个办法。
- 发现脏数据后如何处理。 处理的目标在于不干扰正常业务测试。具体的手段很多，比如直接SQL删除脏数据，数据打标签、数据修正