（二）脏数据的预防及处理

 推荐原文：https://www.jianshu.com/p/0078e5dd1e61

（啊···我的排版好垃圾·····）

如何处理已产生的脏数据？
有那么多预防脏数据产生的方法，但相信脏数据的产生还是在所难免的。脏数据一旦产生，导致的系统行为也是不可预测的，可能无足轻重，也可能暴露非常严重的缺陷。该如何应对产生的脏数据呢？

脏数据产生以后有两种存在形式，一种是已经引起某些问题被发现了，另一种是还不被人知道，不知道哪天会发生什么样的问题。

• 已经暴露的脏数据

1. 首要的是对数据的快速修复，让系统恢复正常运转。对于专业的脏数据处理可以了解一下数据清洗（Data cleaning）技术。咱们平常对于脏数据的修复，可以根据业务需求，采用数据库脚本修复，或者在前端执行JS脚本来修复。
2. 修复数据需要特别注意不要引入新的脏数据，编写脚本之前要理清相关业务和数据之间的关系，编写好脚本之后要经过严格的测试才能在线上环境执行。
3. 修复数据的同时，需要进一步调查数据产生的原因，检查可以在哪个环节加固防御措施，以尽量减少类似数据问题再次发生的可能性。

• 未暴露的脏数据

这样的数据，其实我们并不知道它的存在，就像一个在黑暗处的幽灵，不知道什么时候会给系统带来麻烦。

由于系统环境的复杂性、用户行为的多样性，生产环境更加容易产生脏数据。尽早发现这种潜在危害的脏数据非常重要。推荐生产环境下的测试（Testing in production，TiP）的一些实践。

1.直接在生产环境测试
生产环境是高度受保护的，不可以随意测试，以免破坏生产环境的稳定性。在生产环境写入数据要特别谨慎，大批量的读操作也要注意对系统性能的影响。
有些可以隔离出来的功能或操作，相对来说是安全的，可以在生产环境直接测试。具体需要根据项目实际情况决定。

2.将生产环境数据清理后用于测试环境
生产环境数据含有PII（个人身份信息，需要保护的隐私信息）或者其他机密，通常不能直接用于测试环境。
将生产环境数据的PII和其他机密信息清除后用于测试环境，测试人员基于这些数据做测试，就能有效的提前去发现由于生产环境数据引起的问题。弊端：对于一些复杂的系统，数据库结构过于复杂，清理的成本太高，也是不太现实的。

写在最后

• 脏数据的防御是关键。这跟敏捷测试的质量内建原则是一致的。质量内建强调缺陷预防，在预防缺陷产生的同时，要加强对于脏数据的防御。根据敏捷测试的节奏，在敏捷开发生命周期各个环节做好脏数据的预防和处理工作，尽量减少脏数据给生产环境带来的危害。如果由于各种原因防御工作不到位，脏数据产生后也要分析总结，回过头来指导开发环节的工作，进一步加强防御。

 

• 脏数据都是有原因的，不挖掘出真正的原因，可能带来更加意想不到的后果。找出根因，做到防微杜渐，才是正道。
• 脏数据的存在不是可以帮我们背锅，而是可以帮助我们暴露程序潜在的问题，是做好系统质量保障工作、生产环境质量保证不可或缺的助手。

转载于:https://www.cnblogs.com/wchwch/p/11180079.html