脏数据（Dirty data），也叫坏数据（Bad data），通常是指跟期待的数据不一样、会影响系统正常行为的数据。
生产环境下的缺陷分析流程是这样的：
调查分析生产环境缺陷，到最后定位是数据问题的时候，总是让人浑身轻松… 于是，“脏数据”就跟测试的“随机挂”一样，成为了光荣的“背锅侠”！
脏数据 ≠ 代码问题，真的是这样吗？先来深入了解一下脏数据。
脏数据是怎么回事？
脏数据产生的原因多种多样，有的甚至很难解释清楚到底发生了什么…通常，以下原因可能造成脏数据：
- 脏读：读了事务处理中间状态的数据
- 重复插入了相同的数据：多次点击同一个按钮导致
- 不能为空的字段存为空：数据库字段没有验证，或者对于历史数据没有做好迁移处理
- 人工录入不合法的数据：比如电话号码含有特殊字符
- 运行SQL脚本插入了不合法数据：比如不同实体id搞混等
- 存入了多余的空格
- 测试环境可能由于部署了半成品产生一些不合法数据
- ……
因此，脏数据跟代码有关，脏数据的产生是因为没有做好防御工作！
脏数据有哪些危害？
根据不同的系统、不同的业务，脏数据带来的危害也会不一样。
脏读产生的数据往往是错误的，导致数据不真实性，或者数据的不一致性；
重复和其他不合法数据则可能导致系统行为的不正常，有时候还可能导致非常严重的故障，甚至有些没有暴露的脏数据可能带来不可预知的致命错误，危害可能是相当大的。
脏数据带来的危害很难估量，有很大的不可预测性，对于脏数据的预防至关重要。
那么，如何能够防范于未然呢？
如何预防脏数据的产生？
尝试对脏数据引起的生产环境缺陷做进一步分析，总结出脏数据的几种类型，可以在敏捷软件开发生命周期的不同阶段对其进行防御。
- 业务需求分析阶段
在业务分析的时候，根据业务需求，明确业务相关数据的特定要求，如：
- 不能为空的字段
- 不能重复的数据
- 日期范围
- 电话号码可以有“ext.”、“+”和“-” 但不能有其他字符
- 特殊字符的限定
- 功能升级的时候考虑已有数据的迁移
- 还有一些跟常识不同有特定业务含义的数据需求
- ……
- 数据库和代码实现阶段
明确了数据的需求，可以根据需求定义和软件使用常识，在实现层面对数据进行严格的约束和校验：
- 数据库表的主外键、字段类型、是否允许为空，事务处理隔离等
- 前后端对数据进行严格的校验，防止各种手段存入不合法的数据，包括需求定义的数据和常识性的数据，比如身份证号码最多18位等
- 考虑多用户同时处理可能带来的并发问题
- 防止按钮或者链接被重复多次点击，可重复点击通常在网速较慢时可能存入重复数据
- 程序读取数据的时候进行处理，比如去掉多余空格、去重、大小写不敏感数据的处理
- ……
- 测试的进一步保障
有了需求定义和实现层面的校验，大部分的不合法数据被阻止了，但是还是会有漏网之鱼，在测试的时候继续采取相应的措施来进一步防御。
- 业务需求规定的数据：这个毫无疑问是需要测试的，有底层的单元测试覆盖会更好
- 常识性的数据：由于不同的人可能有不同的常识，这些问题在测试的时候还需要特别关注
- 探索隐藏边界：关于隐藏边界的概念大家可能不是很熟悉。咱们通常说的等价类、边界值分析方法设计测试用例，都是根据可见的边界来考虑的，其实咱们程序后台可能还存在一些隐藏的边界，也是很有可能会导致数据问题的，需要在测试过程中进行探索发现它们并进行验证。
关于隐藏边界，可以参考John Ruberto的文章《Uncovering Hidden Boundary Values in Testing》，里边提到了四种隐藏边界：数据类型边界、信任域边界、特殊数据值、复活节彩蛋。除此之外，咱们平常测试过程中可以多积累，总结出还有哪些可能会导致数据问题的隐藏边界。
- 对用户的培训
做了前面一层层的防御，如果最终用户在使用的时候能够按照规范操作数据，对减少脏数据的产生会很有帮助。
下面两个措施可以培训用户更规范的操作数据：
- 在界面上给出清晰的提示，告诉用户某些数据输入的要求
- 给用户培训或者提供用户手册，告诉用户该怎么正确使用系统
原文地址：https://www.cnblogs.com/wchwch/p/11180074.html