(啊···我的排版好垃圾·····)
如何处理已产生的脏数据?
有那么多预防脏数据产生的方法,但相信脏数据的产生还是在所难免的。脏数据一旦产生,导致的系统行为也是不可预测的,可能无足轻重,也可能暴露非常严重的缺陷。该如何应对产生的脏数据呢?
脏数据产生以后有两种存在形式,一种是已经引起某些问题被发现了,另一种是还不被人知道,不知道哪天会发生什么样的问题。
- 已经暴露的脏数据
- 首要的是对数据的快速修复,让系统恢复正常运转。对于专业的脏数据处理可以了解一下数据清洗(Data cleaning)技术。咱们平常对于脏数据的修复,可以根据业务需求,采用数据库脚本修复,或者在前端执行JS脚本来修复。
- 修复数据需要特别注意不要引入新的脏数据,编写脚本之前要理清相关业务和数据之间的关系,编写好脚本之后要经过严格的测试才能在线上环境执行。
- 修复数据的同时,需要进一步调查数据产生的原因,检查可以在哪个环节加固防御措施,以尽量减少类似数据问题再次发生的可能性。
- 未暴露的脏数据
这样的数据,其实我们并不知道它的存在,就像一个在黑暗处的幽灵,不知道什么时候会给系统带来麻烦。
由于系统环境的复杂性、用户行为的多样性,生产环境更加容易产生脏数据。尽早发现这种潜在危害的脏数据非常重要。推荐生产环境下的测试(Testing in production,TiP)的一些实践。
1.直接在生产环境测试
生产环境是高度受保护的,不可以随意测试,以免破坏生产环境的稳定性。在生产环境写入数据要特别谨慎,大批量的读操作也要注意对系统性能的影响。
有些可以隔离出来的功能或操作,相对来说是安全的,可以在生产环境直接测试。具体需要根据项目实际情况决定。
2.将生产环境数据清理后用于测试环境
生产环境数据含有PII(个人身份信息,需要保护的隐私信息)或者其他机密,通常不能直接用于测试环境。
将生产环境数据的PII和其他机密信息清除后用于测试环境,测试人员基于这些数据做测试,就能有效的提前去发现由于生产环境数据引起的问题。
这个方案很好,但是要权衡ROI。对于一些复杂的系统,数据库结构过于复杂,清理的成本太高,也是不太现实的。
3.利用蓝绿部署等TiP实践
蓝绿部署是一种通过运行两个相同的生产环境“蓝环境”和“绿环境”来减少停机时间和风险的技术,是TiP非常典型的一个实践。
在任何时候,只有一个环境是活的,活的环境为所有生产流量提供服务。通常绿环境是闲置的,蓝环境是活的。部署新的版本到绿环境,可以先进行测试,而不会给真正在使用的蓝环境带来影响。完成部署和测试以后,再进行蓝绿环境的切换。
此技术可以消除由于应用程序部署导致的停机时间。此外,蓝绿部署可降低风险:如果新版本在绿环境上发生意外情况,可以通过切换回蓝环境立即回滚到上一版本。这样就有机会提前发现脏数据可能引起的问题。
类似的技术,还有金丝雀发布等,也有助于提前发现脏数据的问题
写在最后
- 脏数据的防御是关键
这跟敏捷测试的质量内建原则是一致的。质量内建强调缺陷预防,在预防缺陷产生的同时,要加强对于脏数据的防御。根据敏捷测试的节奏,在敏捷开发生命周期各个环节做好脏数据的预防和处理工作,尽量减少脏数据给生产环境带来的危害。
如果由于各种原因防御工作不到位,脏数据产生后也要分析总结,回过头来指导开发环节的工作,进一步加强防御。
- 脏数据让我们又爱又恨
恨的是脏数据的产生总是会导致系统行为的不可预测,让系统质量保障变得复杂。尤其是一些脏数据不停的出现,还总是找不到原因的时候,很让人抓狂!总想到此为止,让脏数据来背锅。
但这不是明智的做法,脏数据都是有原因的,不挖掘出真正的原因,可能带来更加意想不到的后果。找出根因,做到防微杜渐,才是正道。
爱的不是因为脏数据可以帮我们背锅,而是它的存在可以帮助我们暴露程序潜在的问题,是做好系统质量保障工作、生产环境下的QA不可或缺的助手。
原文地址:https://www.cnblogs.com/wchwch/p/11180079.html