问：谁应该为质量负责？
答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
问：那其他角色呢？
答：BA还好吧，跟质量的关系没那么大。
……

在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 …

为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。

因此，我们来看看质量到底是什么？

质量是什么

产品质量不是检测出来的，从产品生产出来后质量就已经在那了。

——著名的质量管理专家戴明

在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。

那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。

1. 外部质量

顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。

外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。

2. 内部质量

同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。

内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。

3. 内建质量

质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

• 自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
• 手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。

另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。

软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。

因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：

外部质量：用户反馈、Support的问题数量

内部质量：code review、结对编程、静态代码质量检查

内建质量：测试环境、生产环境缺陷，Support的反馈

了解了三个维度质量的含义，我们不难理解：

❌质量不是零缺陷，不是百分百的测试覆盖率，也不是没有技术债；
✅质量是快速反馈，任何改变能够快速验证，并且快速修复；
✅质量是把精力都集中在正确的事情上；
✅质量是团队在代码、设计和交付上有信心做出改变；
✅质量是团队对任何改变负责。

容易忽视的质量

从前面对质量的定义，广义的质量其实包括软件产品交付流程中的方方面面，每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容：

• 需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
• 忙于交付更多的feature，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
• 没有足够的测试覆盖，导致新增代码容易破坏已有功能；
• Dev提交代码后，就投入新代码的开发，对所提交代码缺乏关注，CI pipeline红了不能及时修复，可能影响后面QA的测试进度；
• 大面积的重构发生在release前夕，无法全面回归，带来很大的风险；
• 项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
• 技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
• 第三方组件评估不够充分，导致线上环境无法承载等；
• 开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引发问题；
• 开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
• 缺乏跨功能需求的关注，导致严重的安全或者性能问题；
• 对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
• ……

这样的问题还有很多很多，无法一一枚举。每个角色，每个环节都有可能出现纰漏，导致产品质量问题。

那么，谁该为质量负责是不是已经很清楚了？

谁该为质量负责

前面已经讲到，质量是贯穿项目整个生命周期的非常关键的部分，质量保障工作也是需要在每个环节加强关注，每个角色都需要为质量负责。

上表列出的是敏捷开发流程中的各个实践活动，它们都与质量有关，每个活动都要求多个不同的角色同时参与。

下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。

BA：Busines Analyst，业务分析师

BA主要负责业务需求的分析工作，要理解客户的业务，并将业务分解成便于Dev和QA理解的功能点，同时，还要能够帮助用户验证开发完成的软件系统功能，并展示给客户。需求作为软件开发的源头，是极为关键的。

BA视角的质量，主要是需求分析的准确性和清晰度，要帮助团队对需求有一致的认识，从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。

Dev：Developer，开发人员

Dev作为软件系统实现的主力，对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面，都有着不可替代的职责，每个环节都不可忽略。

因此，Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效的交付给最终用户。

QA：Quality Analyst，质量分析师

QA作为软件质量的倡导者，是唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作（手动、自动化、探索式、跨功能、非功能测试，以及生产环境的QA等）、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值，这些都是QA的职责。

三个主力角色中的BA一般都会有从用户旅程的角度去考虑，其实Dev和QA也需要同样的思维模式，不能把story或者AC割裂来看，而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。

除了三个主力角色，团队还有其他角色也都是要对质量负责的，比如：架构师要负责项目架构的健康，基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展，PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。

软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。

去年，我们在《数字化时代的软件测试》中看到了2017年软件质量方面的趋势和给测试人员的建议。又一年过去了，大家对软件质量保障和测试的关注有哪些变化呢？我们一起来看看这份质量报告《World Quality Report 2018-19》有些什么新的内容。

关键趋势

质量保障和测试的职责已从单纯的缺陷发现转变为客户满意度和业务成果的推动者了，这是个根本性的转变，它所带来的影响可以从今年这份质量报告的多个部分体现出来，而最能体现这个转变的是质量保障和测试的目标，受访者认为目前质量保障和测试策略的最高目标是“确保终端用户的满意度”。不断增长的以客户为中心推动的IT趋势也正在改变质量保障的目标和期望，比如业务数字化和敏捷、DevOps、云服务的采用。

以客户为中心要求我们的IT系统能够在速度、安全和便利性方面增加用户满意度，对应的关键IT趋势有以下几个方面。

1. AI在质量保障和测试中的作用

AI的发展对于质量保障和测试主要有两个方面的影响：一方面，AI会促使企业将测试转变成完全自生成、自执行和自适应的活动，也就是用AI技术来优化测试；另一方面，AI产品的开发需要一种新的特殊方法来验证和校验，就是对AI产品的测试。这两个方面正好是互补的，相互促进的过程。

AI在测试中的运用还处于初始阶段，有组织开始应用智能分析来制定关键决策以优化测试活动和早期的质量预测：

• 57%的受访者表示有项目引入了IT到质量保障中
• 45%的受访者在测试中采用AI做智能自动化
• 36%的受访者正在使用AI做测试的预测分析

对于AI产品的测试还没有具体的、广泛被采用的方法、指南或方案，57%的受访者表示正在试验AI和ML（机器学习）的测试方法。

将AI技术用于IT也存在不小的挑战，55%的受访者表示他们在定位哪些业务可以用到AI技术的时候遇到困难；将AI技术用于测试则可能需要一些新的角色，比如AI质量保障战略家、数据科学家、AI测试专家等。

尽管挑战重重，AI还是有望成为接下来两到三年内最大的趋势，组织需要从以下几个方面考虑AI策略：

• 要达到一定级别的自动化测试成熟度
• 要实施分析（Analytics）技术
• 实现能够自我学习、自我认知的系统并应用于测试中

2. 敏捷和DevOps

“速度上的质量”宣言推动着敏捷和DevOps逐渐被采用，有多达99%的受访者称他们至少有一些项目在采用DevOps。但是，有些组织以质量为代价去追求速度，这样是不妥的。也有的组织认为敏捷与瀑布共存的模式比较适合他们的组织、文化和业务的需求。

敏捷和DevOps的转型打乱了原来的质量保障和测试部门，所有人都分散到不同的敏捷团队中，这样使得技术、最佳实践和测试场景的跨项目共享很难，从而有不同团队重复造轮子的事情发生。以角色组成的社区（Community），比如QA社区，很好的解决了这个问题，可以在社区内做到知识共享、能力共建。

3. 自动化

质量保障和测试活动的自动化已经有十多年的历史，测试自动化也从测试执行的自动化发展到了采用基于模型的工具来自动化生成测试用例。自动化的目标也从缩短运行时间转变成了采用更有效的测试用例实现更好的测试覆盖。

但是，测试活动的自动化还是处于较低的水平，而且成为了企业成熟测试的头号瓶颈。自动化水平低下的原因有：

• 61%的受访者表示由于应用程序每次发布都在变化，很难构建出健壮的、适应性强的自动化测试方案
• 48%的受访者对于准备可预测的、可重复利用的测试数据和测试环境有挑战
• 46%的企业表示由于技能和经验的缺失导致自动化实现很难

自动化测试应该是朝着智能、认知的方向发展，构建能够自执行、自适应的自动化平台。

4. 环境和数据

近几年，质量保障和测试部门都在朝着敏捷和DevOps转型，测试环境和数据的管理却跟不上，大部分企业在数据管理和创建方面没有成熟的方案：

• 测试环境方面，31%的受访者主要还依赖物理机器环境
• 58%的受访者表示他们仍然依赖手工方式创建测试数据
• 66%的受访者用Excel等电子制表软件来手动生成测试数据
• 62%的受访者用生产环境数据的副本来执行测试

目前，测试数据和环境成为企业成熟测试的二号瓶颈。当然，我们也看到了这方面正在得以改进的新技术趋势：

• 不断增加的容器化测试环境的采用
• API经济的增长
• 零接触（Zero-touch）测试机器人的使用
• 开放数据项目（Open data projects）的发展
• 更好的数据采样智能方案的发展

5. 成本

在测试活动的成本和效能方面，我们看到两个有分歧的趋势：

• 大量的自动化测试和测试外包的方式，使得基于瀑布式的核心IT和遗留系统的成本下降；
• 数字化转型、迁移到云、敏捷和DevOps的采纳、质量保障和测试中自动化和分析技术的运用，使得在新的基础设施、工具、组织改组、工作流程重组方面的花销达到高峰

质量保障和测试的花费在2015和2016年分别占整个IT成本的35%和31%，在2017和2018年下降到了26%，并趋于稳定。但是，随着测试环境的虚拟化、测试数据的管理、测试自动化和测试生命周期分析技术使用方面的投资，在将来的两到三年内成本可能会升高到30%，并达到一个新的增长稳定的阶段。

推荐的应对策略

1. 以智能的、分阶段的方式提升基础测试自动化和智能测试自动化水平

自动化测试是质量保障和测试变革的瓶颈，因为：

• 自动化的核心角色是敏捷和DevOps转型的推动者，随着敏捷和DevOps被越来越多的采用，自动化对交付“速度上的质量”的重要性也在上升；
• 它也是AI、ML、分析等新技术的结果，这些技术在自动化可以带来的好处方面都具有很大的潜力；
• 调查结果显示基础自动化水平还很低，还有很大的发展空间。

因此，自动化（尤其是智能自动化）将会在接下来两到三年给质量保障和测试带来重大的变化，组织需要有自己的策略和路线图去应对，报告推荐了一个三步走的方案：

1. 优化测试
2. 实施基础的自动化测试
3. 采用智能的、自适应的测试自动化方案让自动化变得更加“智能”

2. 以非孤立的方式实施测试数据和测试环境的管理

53%的受访者表示在敏捷测试的数据和环境准备方面面临挑战。数据和环境的延迟使得云服务、敏捷和DevOps的采用所带来的效率不明显，这是一个需要特别引起重视的领域，建议采用集中的方式来管理。企业要开始生命周期的自动化，把测试自动化和数据、环境的准备工作一起开展，不要分离开来。另外，要采用更加智能的方式来管理测试环境和数据。

一定程度的集中化能够更有效的利用、共享各种知识、实践和经验，更好的风险管理，加速发布频率，缩减基础设施的开支，提高团队的生产力。

3. 构建超出测试开发（SDET）之外的质量工程技能

敏捷、DevOps、云、IoT、区块链和AI这些新趋势的发展，以及更加自动的、集成的质量保障方法的需求，企业需要关注新的质量技能。

推荐以下方式做好质量保障能力建设：

1. 第一优先级是吸引敏捷测试专家，需要具备功能自动化技能和领域测试技能，自动化测试将是每个质量保障人员的必备技能；
2. 第二优先级是吸引SDET，他们的必备技能要求有高级自动化测试、白盒测试、开发和平台构建能力，同时最好还有AI应用的基础算法应用能力和自然语言处理技能；
3. 第三优先级是吸引拥有一些特定QA技能集的人员，比如安全等非功能测试、测试环境和数据的管理技能等；
4. 第四优先级是吸引高级QA专家，需要有AI架构技能，以构建能够执行重复、智能任务的“智能资产”，这些技能由深度机器学习概念和算法组成，比如决策树、分类器、神经网络、高级统计学和数据优化技能。

当然，目前市场上还相对比较缺乏上面所列举的资源，建议组织要重点关注通过实习、专长培训、强制性的学习和发展计划来构建这些技能集。

4. 加强跟踪以优化各项花费

敏捷和DevOps模式下测试活动被多个不同角色承担，很难精确跟踪、掌握和优化质量保障相关花费。另外，对于云、虚拟化和容器化环境的投资回报也需要跟踪掌握。

因此，建议企业采用严格的、细粒度的跟踪机制来看各项预算分配到了哪里、各项开支都花在了什么地方。

5. 给AI解决方案开发一套测试方法

很多的企业开始开发AI产品，但是相应的质量保障方案并不成熟，有必要抓紧开发AI产品的质量保障策略和测试方案。组织应该意识到不正确的或者有缺陷的AI解决方案带来的业务和社会影响可能是巨大的。AI产品开发过程中校验和验证，以及自动化的持续监控都应该是AI质量保障策略的内容。

总结

通过前面的分析和总结，我们看到这次质量报告体现出的关键点主要有：

1. 终端用户的满意度第一次成为质量保障和测试策略的最高目标，要求在关注速度的同时绝对不能忽视质量，要以客户为中心，在安全、便利性和速度方面关注用户的满意度。
2. 低水平的自动化测试，以及测试环境和数据准备的挑战，影响了质量保障和测试效率的提升。要求组织加强自动化能力的提升、测试环境和数据的管理，让自动化朝着更加智能的方向发展。
3. 质量保障和测试人员的必备技能发生了改变，需要有超出SDET的更加全面的QA技能集。

注：以上大部分内容和图片均摘自这份《World Quality Report 2018-19》，更多详细内容请参考原报告。

摘要：本文总结几类项目中跟时区相关的问题，给大家分享一些基本的时区知识，以及如何在软件开发和测试中注意考虑时区因素，以避免因时区而导致系统功能的问题。

场景一

“小D，我发现调整不同的timezone（时区），咱们的KPI计算结果可能会有一天的误差…”

“啊！我看看什么原因。”

“嗯啦，KPI务必是准确的，可不能有误差…”

“小Q，我知道啦！咱们的工单任务完成时间记录的是UTC时间，是考虑了timezone转换的，但是缺失信息的记录并没有考虑… ”

“为什么缺失信息不记录UTC时间呢？”

“因为缺失信息只记录日期，并没有时间。”

蓝鲸项目的小Q和小D说的是啥呢？下面先来借助维基百科的解释来介绍时区和UTC的概念：

1. 时区（timezone）
   时区是地球上的区域使用同一个时间的定义。以前，人们通过观察太阳的位置决定时间，这就使得不同的地方的时间有所不同（地方时）。1863年，首次使用时区的概念，通过设立一个区域的标准时间部分地解决了这个问题。
2. UTC
   协调世界时（英语：Coordinated Universal Time，法语：Temps Universel Coordonné，简称UTC）是世界上调节时钟和时间的主要时间标准，它与0度经线的平太阳时相差不超过1秒。协调世界时是最接近格林威治标准时间（GMT）的几个替代时间系统之一。对于大多数用途来说，UTC时间被认为能与GMT时间互换，但GMT时间已不再被科学界所确定。

原来小Q和小D所在的蓝鲸项目正在开发一个全球性的系统，用户处于世界各地的不同时区。

系统的工单处理流程中每个任务的完成因为有先后依赖关系，当时记录的是完成时刻的UTC时间，以防不同时区的用户完成依赖任务的时候产生冲突。

比如：处于UTC+08:00时区的用户S在当地时间“2019-02-28 09:30”处理了任务1，系统记录的时间是“UTC 2019-02-28 01:30”，接下来处于UTC-0800的用户G在当地时间“2019-02-27 18:20”来处理任务2（必须晚于任务1完成），系统记录的是“UTC 2019-02-28 02:20”，这个时间就不会有问题。

在处理某个任务的时候如果发现有信息缺失，需要记录发现和收集到缺失信息的时间（可以是过去时间，由用户输入），而这个发现和收集完成的时间一般都是同一个用户来记录，本身不会有时区问题，另外这个时间跟工单处理流程中的任务完成时间并没有特别直接的关系，就对缺失信息部分只记录由用户输入的日期，而且是直接记录用户当地时间的日期，并没有记录时分秒，也没法根据UTC进行转换。

这样，同一个日期，比如，在东部时区的“2019-04-28”可能就是西部时区的“2019-04-27”，在西部时区的“2019-04-28”可能就是东部时区的“2019-04-29”，前后有相差一天的可能性。

但是，在做到KPI功能的时候，计算KPI需要结合工单任务处理时间和缺失信息记录时间，由于没有考虑时区问题，不同时区可能会造成KPI有一天的误差。

场景二

“我们这里有个线上用户报过来一个bug，合同签订日期签完以后打开编辑，在页面上变成了一个后一天的日期，没法保存”，R说。

“我们的合同签订日期最晚是签订当天的日期，的确不能用将来日期，这个业务上是这么要求的”，小B说。

“我们前端也有校验不允许存储将来日期。可是为什么会变成后一天的日期呢”，小D一脸迷惑。

“会不会还是timezone的问题？！” 小Q由于前一阵做KPI的时候测试时区相关问题花了不少精力去搞明白各种case，对时区也有了不少的研究，对此比较敏感。

“那个报bug的用户设置是什么timezone的？” 小B问。

“是东14区（UTC+14:00）！” R回答。

“竟然还有东14区，我一直以为都在正负12时区之间。”小Q很惊讶。

“那就对了！的确是timezone引发的问题！”小D沉思了一会，激动的跳起来。

这又是为什么呢？大家都在焦急地等待小D的解释。

原来，对于这种没有时分秒要求的时间，我们系统统一用当天中午UTC的12:00存入DB，这样做的原因是保证－12～＋12时区内都不会有问题，换算以后都是当天，但是没有考虑到正负13、14区的情况。

下面我们来举例说明为什么东14区的会有问题。

假设用户A和用户B分别处于东12区和东14区，A和B分别在当地时间的2019年04月28日的上午9:00签订了合同，那么系统记录的时间都是“UTC 2019-04-28 12:00”，在用户A的页面上显示的日期是“2019-04-28”（“UTC 2019-04-28 12:00”转换东12区的时间是“2019-04-28 24:00”>，这个时间的日期还是4月28日），而在用户B的页面上显示的日期应该是“2019-04-29”（“UTC 2019-04-28 12:00”转换东14区的时间是“2019-04-28 26:00”，也就是“2019-04-29 02:00”，这个时间的日期变成了4月29日）。

如下表，用户A、B、C、D的合同签订时间都是当地时间2019年04月28日的上午9:00：

同理，用户C和D处于西部时区，从上表我们可以看到处于-12的C的时间是跟实际日期一样，而处于-13的用户D的时间则比实际时间早了一天，也是有问题的。

至此，我们明白了为什么东14区会引起系统功能有问题。但是，一直以来以为时区都在正负12之间，为什么会有大于+12的时区呢？原来小D是早就知道的，他给我们解释了是下面两个原因：

1. 有些跨国际日期变更线的地区，为了保证该地区所有地方的时间都在同一天，就把时区设置成了大于+12的，比如基里巴斯。
2. 有些处于+12区的地区有夏令时，夏令时的时候时区会变成+13，比如新西兰。

其实，时区还有很多有意思的，有偏移量是半个小时的（如印度），还有45分钟的（如尼泊尔），不一定都是整点。更多详情可以参考维基百科的时区列表。

场景三

客户P发过来一封邮件：
“自2017年初以来，土耳其和白俄罗斯政府不再遵守夏令时（DST），因此这将改变这些国家的时区为GMT+3，而不是GMT+2。 目前，在我们系统伊斯坦布尔和明斯克都显示为GMT+2。”

这个问题听起来很简单，直接在DB里把对应的时区改一下就ok了。可是，正当小D准备去改数据的时候，发现了一个崩溃的事情：伊斯坦布尔和明斯克还跟另外两个地区的时区是绑定在一起的，见下图。当前系统中已经设置好的一些会议，没法判断真正需要的是哪个地区对应的时区… 已有数据无法修复！

在此先不解释如何修复的数据问题。

当时，我们正好要把时区引入到另外一个新系统，考虑到避免再出现类似的情况，采用了一个新的库，那就是每个地区对应一个时区。比如：GMT+08:00分别有上海、乌鲁木齐、重庆、香港、新加坡等时区。

场景四

“这个新的timezone里怎么有一些乱七八糟的时区？”

“乱七八糟的时区？”

“Etc什么的，好像还正负矛盾的。比如：‘(GMT+08:00)Etc/GMT-8’” 对时区敏感的小Q觉得这些时区不太顺眼。

“这个是咱们新的时区库引入的，不过的确挺奇怪的，不知道这个Etc时区是啥。” 小B也不是很明白。

原来，这个时区表示法里时区名字都是用“区域/位置”来表示，比如“Asia/Shanghai”，而前面的“(GMT+08:00)”是表示相对于GMT的一个偏移量。前面对话中提到的“Etc/GMT-8”只是时区名字而已。那为什么叫这么奇怪的名字呢？

下面引用维基百科的解释来说明：

区域分为大陆，海洋或“Etc”三类。 目前使用的大陆和海洋是非洲，美洲，南极洲，北极，亚洲，大西洋，澳大利亚，欧洲，印度和太平洋。

包括海洋的原因是一些岛屿很难连接到某个大陆，有些地理位置与一个大陆相连，在政治上却与另一个大陆相连。

“Etc”属于特殊区域，用于某些管理区域，特别是用于表示协调世界时的“Etc/UTC”。 为了符合POSIX样式，以“Etc/GMT”开头的区域名称的标志与标准ISO 8601惯例相反。 在“Etc”区域，格林威治标准时间以西的区域有一个正号，而以东区域的名称有一个负号（例如“Etc/GMT-14”比GMT早14个小时。）

总结

对于国际化的软件系统来说，时区还是需要特别关注的。根据所经历项目出现的时区相关问题，尝试总结以下几点供大家参考。

实现方面

1. 对于具体操作执行时间，这种都是包含时分秒的具体时刻，存储全部采用UTC时间，在显示的时候根据时区偏移量转换为对应的当地时间。不同模块之间传递的时间参数要以UTC格式。
2. 对于没有精确时间点的、由用户输入的日期，这种一般对时间要求没有那么精确，可以加上操作时候的时间戳存储到数据库。当然还需要结合业务对时间的具体需求来定不同方案。
3. 时区数据库单独一个位置作为一个时区的方式可以更方便修改对应位置的时区，比如：“(GMT+08:00)Asia/Chongqing”，而不是“(GMT+08:00) Beijing,Chongqing,Hong Kong,Urumqi”
4. 关于UTC时间的获取：可以用第三方工具获取客观的UTC时间，但是出于安全考虑，一般不用；而是直接从服务器获取UTC时间，所以需要保证服务器的客观时间点是正确的，如果服务器的客观时间点有错，将会导致计算出的时间有出入。
5. 有时候需要自定义一些时间段供用户使用，这种需要特别注意夏令时的影响。

测试方面

1. 对于过去时间、未来时间的测试，一定要测不同时区跨度看是否满足条件能够正确使用。
2. 显示时间：本地，不同时区切换能正确显示相应时间；输入时间：不同时区对应的日期边界值要重点考虑。如果只能输入未来时间，要考虑一些负时区的情况，比如 UTC-12, UTC-13等；如果只能是过去时间，要考虑UTC+12, UTC+14等。
3. 定时任务：如果设置成固定时间段（如：每隔一小时）执行，与时区无关；每天定点执行，要考虑不存在的或者多出的时间段。
4. 日志文件：时间戳命名的文件，不会由于夏令时导致文件名重复；文件内容涉及时间部分，不同时区显示正确。
5. 夏令时跳变时刻系统功能测试，对于多出来的一小时或者减少的一小时系统行为是否正常。

大家如果还有遇到过其他时区方面的bug，欢迎留言，谢谢！

“小光，今天那个诡异的生产环境问题找到原因了吗？”
“还是数据问题！之前做的一个功能有一部分数据迁移工作没有做好，导致生产环境有脏数据，委托人的联系人已经不为该委托人服务了，应该移除掉的…=-#~)@/-$*…”
“又是脏数据…@=@”
“嗯，好在不是代码问题。”

这是在蓝鲸项目发生的真实对话。其中提到的脏数据（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朋友们，请加强对脏数据的重视，善待脏数据！