专栏首页ThoughtWorks都是脏数据惹的祸

都是脏数据惹的祸

“小光,今天那个诡异的生产环境问题找到原因了吗?”

“还是数据问题!之前做的一个功能有一部分数据迁移工作没有做好,导致生产环境有脏数据,委托人的联系人已经不为该委托人服务了,应该移除掉的……”

“又是脏数据……”

“嗯,好在不是代码问题。”

这是在蓝鲸项目发生的真实对话。其中提到的脏数据(Dirty data),也叫坏数据(Bad data),通常是指跟期待的数据不一样、会影响系统正常行为的数据。

蓝鲸项目的QA会定期分析生产环境的缺陷,当定位某个缺陷为脏数据引起之后,往往就到此为止了。生产环境下的缺陷分析流程是这样的:

调查分析生产环境缺陷,到最后定位是数据问题的时候,总是让人浑身轻松... 于是,“脏数据”就跟测试的“随机挂”一样,成为了光荣的“背锅侠”!

脏数据 ≠ 代码问题,真的是这样吗?先来深入了解一下脏数据。


脏数据是怎么回事?

脏数据产生的原因多种多样,有的甚至很难解释清楚到底发生了什么…

通常,以下原因可能造成脏数据:

  1. 脏读:读了事务处理中间状态的数据
  2. 重复插入了相同的数据:多次点击同一个按钮导致
  3. 不能为空的字段存为空:数据库字段没有验证,或者对于历史数据没有做好迁移处理
  4. 人工录入不合法的数据:比如电话号码含有特殊字符
  5. 运行SQL脚本插入了不合法数据:比如不同实体id搞混等
  6. 存入了多余的空格
  7. 测试环境可能由于部署了半成品产生一些不合法数据
  8. ……

因此,脏数据跟代码有关,脏数据的产生是因为没有做好防御工作!


脏数据有哪些危害?

根据不同的系统、不同的业务,脏数据带来的危害也会不一样。

  • 脏读产生的数据往往是错误的,导致数据不真实性,或者数据的不一致性;
  • 重复和其他不合法数据则可能导致系统行为的不正常,有时候还可能导致非常严重的故障,甚至有些没有暴露的脏数据可能带来不可预知的致命错误,危害可能是相当大的。

脏数据带来的危害很难估量,有很大的不可预测性,对于脏数据的预防至关重要。

那么,如何能够防范于未然呢?


如何预防脏数据的产生?

尝试对脏数据引起的生产环境缺陷做进一步分析,总结出脏数据的几种类型,可以在敏捷软件开发生命周期的不同阶段对其进行防御。

业务需求分析阶段

在业务分析的时候,根据业务需求,明确业务相关数据的特定要求:

  1. 不能为空的字段
  2. 不能重复的数据
  3. 日期范围
  4. 电话号码可以有“ext.”、“+”和“-” 但不能有其他字符
  5. 特殊字符的限定
  6. 功能升级的时候考虑已有数据的迁移
  7. 还有一些跟常识不同有特定业务含义的数据需求
  8. ……

数据库和代码实现阶段

明确了数据的需求,可以根据需求定义和软件使用常识,在实现层面对数据进行严格的约束和校验:

  1. 数据库表的主外键、字段类型、是否允许为空,事务处理隔离等
  2. 前后端对数据进行严格的校验,防止各种手段存入不合法的数据,包括需求定义的数据和常识性的数据,比如身份证号码最多18位等
  3. 考虑多用户同时处理可能带来的并发问题
  4. 防止按钮或者链接被重复多次点击,可重复点击通常在网速较慢时可能存入重复数据
  5. 程序读取数据的时候进行处理,比如去掉多余空格、去重、大小写不敏感数据的处理
  6. ……

测试的进一步保障

有了需求定义和实现层面的校验,大部分的不合法数据被阻止了,但是还是会有漏网之鱼,在测试的时候继续采取相应的措施来进一步防御。

  1. 业务需求规定的数据:这个毫无疑问是需要测试的,有底层的单元测试覆盖会更好
  2. 常识性的数据:由于不同的人可能有不同的常识,这些问题在测试的时候还需要特别关注
  3. 探索隐藏边界:关于隐藏边界的概念大家可能不是很熟悉。咱们通常说的等价类、边界值分析方法设计测试用例,都是根据可见的边界来考虑的,其实咱们程序后台可能还存在一些隐藏的边界,也是很有可能会导致数据问题的,需要在测试过程中进行探索发现它们并进行验证。

关于隐藏边界,可以参考John Ruberto的文章《Uncovering Hidden Boundary Values in Testing》,里边提到了四种隐藏边界:数据类型边界、信任域边界、特殊数据值、复活节彩蛋。除此之外,咱们平常测试过程中可以多积累,总结出还有哪些可能会导致数据问题的隐藏边界。

对线上用户的培训

做了前面一层层的防御,如果最终用户在使用的时候能够按照规范操作数据,对减少脏数据的产生会很有帮助。

下面两个措施可以培训用户更规范的操作数据:

  1. 在界面上给出清晰的提示,告诉用户某些数据输入的要求
  2. 给用户培训或者提供用户手册,告诉用户该怎么正确使用系统

如何处理已产生的脏数据?

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

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

已经暴露的脏数据

对于已经暴露的脏数据,首要的是对数据的快速修复,让系统恢复正常运转。对于专业的脏数据处理可以了解一下数据清洗(Data cleaning)技术。咱们平常对于脏数据的修复,可以根据业务需求,采用数据库脚本修复,或者在前端执行JS脚本来修复。

修复数据需要特别注意不要引入新的脏数据,编写脚本之前要理清相关业务和数据之间的关系,编写好脚本之后要经过严格的测试才能在线上环境执行。

修复数据的同时,需要进一步调查数据产生的原因,检查可以在哪个环节加固防御措施,以尽量减少类似数据问题再次发生的可能性。

未暴露的脏数据

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

由于系统环境的复杂性、用户行为的多样性,生产环境更加容易产生脏数据。尽早发现这种潜在危害的脏数据非常重要。

蓝鲸项目就是这样。在跟客户做支持的同事沟通过程中,最大的担忧就是生产环境的数据总能发现问题,如何能够让这些问题尽早暴露出来?

推荐生产环境下的测试(Testing in production,TiP)的一些实践。

  1. 直接在生产环境测试 生产环境是高度受保护的,不可以随意测试,以免破坏生产环境的稳定性。在生产环境写入数据要特别谨慎,大批量的读操作也要注意对系统性能的影响。 有些可以隔离出来的功能或操作,相对来说是安全的,可以在生产环境直接测试。比如,蓝鲸项目的邮件服务,常会在生产环境部署单独的服务器来测试。 需要根据项目真实情况去做决定。
  2. 将生产环境数据清理后用于测试环境 生产环境数据含有PII(个人身份信息,需要保护的隐私信息)或者其他机密,通常不能直接用于测试环境。 将生产环境数据的PII和其他机密信息清除后用于测试环境,测试人员基于这些数据做测试,就能有效的提前去发现由于生产环境数据引起的问题。 这个方案很好,但是要权衡ROI。对于一些复杂的系统,数据库结构过于复杂,清理的成本太高,也是不太现实的。
  3. 利用蓝绿部署等TiP实践 蓝绿部署是一种通过运行两个相同的生产环境“蓝环境”和“绿环境”来减少停机时间和风险的技术,是TiP非常典型的一个实践。 在任何时候,只有一个环境是活的,活的环境为所有生产流量提供服务。通常绿环境是闲置的,蓝环境是活的。部署新的版本到绿环境,可以先进行测试,而不会给真正在使用的蓝环境带来影响。完成部署和测试以后,再进行蓝绿环境的切换。 此技术可以消除由于应用程序部署导致的停机时间。此外,蓝绿部署可降低风险:如果新版本在绿环境上发生意外情况,可以通过切换回蓝环境立即回滚到上一版本。这样就有机会提前发现脏数据可能引起的问题。

类似的技术,还有金丝雀发布等,也有助于提前发现脏数据的问题。


写在最后

脏数据的防御是关键

这跟敏捷测试的质量内建原则是一致的。质量内建强调缺陷预防,在预防缺陷产生的同时,要加强对于脏数据的防御。根据敏捷测试的节奏,在敏捷开发生命周期各个环节做好脏数据的预防和处理工作,尽量减少脏数据给生产环境带来的危害。

如果由于各种原因防御工作不到位,脏数据产生后也要分析总结,回过头来指导开发环节的工作,进一步加强防御。

脏数据让我们又爱又恨

恨的是脏数据的产生总是会导致系统行为的不可预测,让系统质量保障变得复杂。尤其是一些脏数据不停的出现,还总是找不到原因的时候,很让人抓狂!总想到此为止,让脏数据来背锅。

但这不是明智的做法,脏数据都是有原因的,不挖掘出真正的原因,可能带来更加意想不到的后果。找出根因,做到防微杜渐,才是正道。

爱的不是因为脏数据可以帮我们背锅,而是它的存在可以帮助我们暴露程序潜在的问题,是做好系统质量保障工作、生产环境下的QA不可或缺的助手。

QA朋友们,请加强对脏数据的重视,善待脏数据!

本文分享自微信公众号 - ThoughtWorks洞见(TW-Insights)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-04-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 数字化企业的数据自服务

    什么是数据自服务 数据在企业中的处理过程,能清晰地映射出康威定律对IT系统的影响。在各个部门分别建设IT系统、组织内部大量存在信息筒仓(silo)的年代,数据的...

    ThoughtWorks
  • 大数据项目中的QA需要迎接新的挑战

    根据IDC全球半年度大数据和分析支出指南的最新预测,到2022年全球大数据和业务分析解决方案的收入将达到2600亿美元。在大数据和业务分析解决方案上投资增长最快...

    ThoughtWorks
  • 数据质量管理的一些思考

    在近期的项目当中,我们为客户落地实施了数据资产平台。随后,在数据平台中接入了客户子公司的一个业务系统的明细数据。客户希望在我们的数据平台上通过数据探索和数据分析...

    ThoughtWorks
  • 大数据应用:10大行业应用痛点及解决策略

    大数据已经成为这几年中大部分行业的追捧热点,随着大数据继续渗透到我们的日常生活中,围绕大数据的概念热点正在转向实际使用中的真正价值。

    挖掘大数据
  • 分析了10个垂直行业后,告诉你大数据应用面临哪些挑战

    本文转自网络,如涉侵权请及时联系我们 大数据已经成为过去几年中大部分行业的游戏规则,行业领袖,学者和其他知名的利益相关者都同意这一点, 随着大数据继续渗透到我们...

    CDA数据分析师
  • 深耕数据挖掘,实现互联互通,在银行风控管理中 ,我国大数据技术应用举足轻重 | 大咖周语录

    当前,大数据已成为科技、经济、社会等各领域的关注焦点。在我国,80%的数据掌握在政府手中,如何激活政府数据,通过数据资产运营进行数据价值激活,将成为支撑国家大数...

    数据猿
  • 大数据行业洞察:未来2-3年或迎数据时代的真正高潮

    从2012年的“用户标签”到2014年的“用户画像”,从2015年的“大数据”到2017年的“人工智能”,大数据正在从神坛走向现实。“标签”到“画像”,代表着数...

    DT数据侠
  • 能源大数据建设面临的问题与解决方案

    6月24日,在第四届世界智能大会城市能源大数据高峰论坛上,发布了国内首个城市能源大数据发展白皮书--《天津城市能源大数据发展白皮书2020》。

    数据前沿
  • 【大数据】大数据时代的数据资产管理

    伴随着大数据时代的悄然来临,对数据的重视提到了前所未有的高度。套上大数据的光环后,原本那些存放在服务器上平淡无奇的陈年旧数一夜之间身价倍增。按照世界经济论坛报告...

    小莹莹
  • 数据湖 | 一文读懂Data Lake的概念、特征、架构与案例

    本文包括七个小节:1、什么是数据湖;2、数据湖的基本特征;3、数据湖基本架构;4、各厂商的数据湖解决方案;5、典型的数据湖应用场景;6、数据湖建设的基本过程;7...

    王知无

扫码关注云+社区

领取腾讯云代金券