去年，我们在《数字化时代的软件测试》中看到了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朋友们，请加强对脏数据的重视，善待脏数据！

最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍微服务架构下的测试策略，并结合分享在业务和架构演变过程中，一个历经九年的项目测试策略的演进。

关于微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务间采用轻量级通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体的业务进行构建，并且能够被独立部署到生产环境、预生产环境。

从微服务的概念可以看出它有如下好处：

• 每个服务可以独立开发
• 处理的单元粒度更细
• 单个服务支持独立部署和发布
• 更有利于业务的扩展

同时，独立开发导致技术上的分离，HTTP通信加上Queue的机制增加了问题诊断的复杂度，对系统的功能、性能和安全方面的质量保障带来了很大的挑战。另外，服务间的复杂依赖关系带来了很多的不确定性，要实现独立部署，对运维也提出了更高的要求。微服务架构的系统要特别关注这几个方面：

• 服务间的依赖、连通性
• 服务的容错、可用性
• 数据的最终一致性
• 独立部署
• 不确定性

测试策略的选择

谈到微服务的测试策略，很容易就想到了老马网站上Toby Clemson的文章《Microservices Testing》，该文推荐的微服务框架下的测试策略是这样的：

这个策略模型强调测试分层以及每一层的恰当覆盖，整体符合金字塔结构。它是最优的吗？

有人对此提出了质疑…认为策略模型应该是蜂巢形状的（请参考文章）：

这个模型重点关注服务间的集成测试，两端的单元测试和UI层E2E测试较少。

也有同事提出微服务下的测试结构应该是钻石形状的，服务间的集成依然是重点，单元测试较少，而顶层增加了安全和性能等非功能测试。

好像都有道理，到底选择什么样的策略模型好呢？不禁陷入了困境……怎么办？不妨先来听听我们项目的故事吧！

项目的故事

测试策略的演进

还是那个蓝鲸项目，不知不觉进入了第九个年头。在这九年里，随着业务的不断发展，系统架构也进行了多次演进和调整。相应的，测试策略也发生了有意思的演进变化。

最初单一用户系统、单体架构的时候，严格按照测试金字塔来组织各层的自动化测试。随着功能的扩展，大量mock的单元测试给重构带来了很大的不便。

企业系统开始开发的时候，我们调整了策略，减少单元测试的编写，增加UI层E2E测试的覆盖，测试结构由原来的金字塔演变成上面梯形下面倒三角的形式。

后来，架构调整，开始服务化。此时，大量的E2E测试渐渐暴露出问题：

• CI上的测试执行时间越来越长，而且定位问题的能力很弱，测试一旦失败需要很长时间修复，测试人员好几天也拿不到可以测试的版本，反馈周期过长；
• 由于服务化带来的不稳定因素增加，E2E测试没法很好的覆盖到需要的场景，测试人员就算拿到可测的版本也总有各种缺陷发生。

因此，项目引入契约测试，停止编写新的E2E测试，将测试下移，分别用API测试和契约测试取代。

随着功能的不断增加，虽然E2E测试的量并不增加，但是其不稳定性、维护难、定位难的问题有增无减，此时已经很难由自动化测试来保证产品的质量。为了平衡成本和收益，项目考虑去掉大部分E2E测试，只保留少量的Smoke测试，将更多的测试下移。

同时，技术雷达上新的技术“生产环境下的QA”出现，项目也开始关心生产环境，并且在QA测试阶段结合微服务的特点进行对应的探索式测试。

应对微服务的挑战

前文提到过微服务带来的挑战，下面来看项目是如何应对这些挑战的。

• 服务间的依赖、连通性

微服务架构下，独立开发的服务要整合起来最具挑战，如何保证服务间的依赖关系和连通性非常关键。前面已经讲过E2E集成测试有很大的挑战，并不适合，而消费端驱动的契约测试是个不错的选择。项目正是利用契约测试去保证服务间的连通性，取代一部分E2E集成测试。

• 服务的容错、可用性

在系统负荷达到一定程度或者某个服务出现故障的时候，微服务架构有两种技术来确保系统的可用性：服务的熔断和降级。服务的熔断是指当某个服务出现故障时，为了保证系统整体的可用性，会关闭掉出现故障的服务；服务的降级则是当系统整体负荷过载的时候，考虑关闭某些外围服务来保证系统的整体可用性。

对应的测试包括：

1. 熔断：从性能角度，当系统负载达到某个熔断状态的时候，服务是否能正确熔断；同时，从功能角度验证熔断后系统的行为是否跟预期相符；
2. 降级：从业务的角度，要能区分出核心业务和外围业务，在需要降级的时候不能影响核心业务；当某个服务降级后，从功能角度验证系统行为是否跟预期相符。

• 数据的最终一致性

数据一致性是微服务特别需要关注的。举个例子，电商平台某个订单支付成功以后，需要更新积分和订单状态，当订单服务或者积分服务其中有一个出现故障的时候，就会导致最终的数据不一致性。

测试这种情况，从业务的角度分析哪些服务会导致数据不一致性，制造对应的异常情况去测试数据的最终一致性。

• 独立部署

微服务的独立部署需要有CI、CD的支持，跟DevOps实践分不开。同时，更为关键的是需要契约测试来验证独立部署后服务行为的正确性。项目在这方面的工作，请参考王健的文章：你的微服务敢独立交付吗？

• 不确定性

微服务架构使得系统复杂度增加不少，很多的事情发生都是不可预测的，只能在其发生以后找到产生的原因。因此，也就没法在预生产环境通过测试去发现在真实生产环境才会发生的issue，我们需要把目光转移到生产环境，利用生产环境的不确定性、微服务的不可预测性来构建反脆弱的系统。

项目在这方面主要采用的技术是生产环境下的QA，请参考文章：生产环境下的QA

项目测试策略

从前面介绍的演进过程可以看到，项目测试策略在不同阶段结合参考了不同的策略模型：金字塔->近似钻石（除非功能测试外，类似于钻石模型）->蜂巢。后期全面服务化的时候，我们认为蜂巢模型是比较适合的。

当然，光有符合这个策略模型的自动化测试是远远不够的，我们项目还采用了针对微服务特点的探索式测试，保持持续交付节奏，践行DevOps实践，结合生产环境下的QA等技术把关注点右移到生产环境。

现在，项目整体测试策略演变成下图的形式：

1. 项目采用的是敏捷迭代开发和持续交付的模式，每四周一个发布周期。
2. 在开发过程中实现的自动化测试是分层实现的：底层少量的单元测试，中间量最多的是API测试（类似于老马推荐的策略模型里的组件测试），上面有一部分契约测试和少量的Smoke测试来保证服务间的契约和集成。除此之外，QA有手动的探索式测试，其中包括针对微服务特点进行的一些测试。整个测试结构是类似于蜂巢模型的。
3. 采用生产环境下的QA技术，利用生产环境，进行error监控、用户行为分析、用户反馈收集，从而来影响和指导预生产环境的开发和测试工作。
4. 利用DevOps实践，做到高效的部署和监控，跟生产环境下的QA结合，形成良性的环路，保证项目的正常交付。

测试策略再思考

项目上多次测试策略的调整，看似很简单，其实每次调整并不是一个轻松的过程，都是平衡利弊、综合考虑多个因素才做出的决定。

分析整个调整过程，最后突然发现：当我们面对多个策略模型不知道如何选择的时候，其实我们陷入了一个太过于关注测试结构的误区，忘记了最初的目标是什么。

影响测试策略的因素

跳出误区，回到原点，重新思考测试策略的目标。影响策略的最关键因素是业务价值、质量要求、痛点。

• 业务价值

带来更大的业务价值、帮企业赢得更多的利润，是软件系统的目标；软件测试是软件系统成功的保障之一，业务价值也是测试策略的终极目标。所有测试活动都要围绕这个目标开展，考虑业务优先级，有效规避业务风险。

• 质量要求

不同的系统、同一系统的不同利益干系人（参与的不同角色）对于质量的定义和要求都可能是不同的，这毫无疑问是影响测试策略的一个关键因素。

对于仅有内部用户的系统，关注的重心可能是系统的功能；而对外发布的产品，则要求更高，一个按钮位置的不恰当都可能带来大量用户的流失。

• 痛点

真正的痛点往往也是优先级最高，迫切需要解决的。那些可以通过测试策略的调整来解决的痛点，自然成为了关键的影响因素之一。比如，CI Pipeline出包太慢，为了提高出包的效率，一方面在Pipeline本身想办法，另一方面调整自动化测试的比例、执行频率等也是解决方案之一。

演进式测试策略

处在不同阶段的项目，在业务价值这个大目标下，其他影响因素也是会不一样的，跟技术架构的演进一样，测试策略也应该是演进式的。

从目标出发，综合所处阶段各个方面的影响因素，制定出适合当时的测试策略。随着时间的推移，对策略进行评估和度量，并进一步改进、提高，以更好的满足需求。这就是目标驱动的演进式测试策略。

总结

微服务架构下多个服务的整合是最具有挑战的，对此最重要的是契约测试。契约测试有效保证服务间的契约关系不被破坏，确保服务的连通性，有助于实现真正的独立部署和独立交付。

微服务架构引入的不确定性并不是坏事，可以利用这些不确定性，采用生产环境下的QA等技术，增强系统的反脆弱性，从中获益。

测试策略的影响因素不是唯一的，技术架构并不是最关键的因素。微服务架构下的测试策略跟其他架构下的并不会有本质的区别。

业务价值始终是我们的终极目标。在这个终极目标的驱动下，测试策略不是制定完了就可以束之高阁的，需要在整个软件系统构建过程中不断的度量和改进，是演进式的。

在经历了“七年之痒”后，蓝鲸项目进入第八个年头，项目的一切趋于稳定。团队倡导持续改进，可大家的感觉是已经尽力做到最好，这个时候似乎没有什么可以改进的了。为了突破这个局面，项目重新聚焦测试，从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型，本文就是跟大家分享一下这个模型。

测试原则

2012年澳大利亚敏捷大会（Agile Australia）上ThoughtWorks的非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则，这些原则是ThoughtWorks的同事们在多年软件测试经验基础上总结出来的。

1. 质量内建（Build quality in）

You cannot inspect quality into the product; it is already there.
— W.Edwards Deming

著名的质量管理专家戴明指出：产品质量不是检测出来的，从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚，修复的成本就越高。质量内建要求我们做好软件开发每个环节，尽早预防缺陷产生，以降低缺陷出现后的修复成本，要减少对创可贴式的补丁（hotfix）的依赖。

推荐实践： TDD、ATDD等

2. 快速反馈（Fast feedback）

每个环节的任何变化都能最快的反馈给需要的人，从而可以基于当下最新信息做出明智的决定，降低风险。这要求我们对系统进行频繁的测试，缩短回归测试的周期。

推荐实践：

• 符合测试金字塔结构的自动化测试，让每一层的测试都能发挥尽可能大的价值，给出最快速的反馈；
• 持续集成，尽早排查集成引起的问题，降低集成所带来的风险。
  

3. 全员参与（Involve everyone）

— 这次上线好多bug，QA是怎么测的？！
— 那个xxx组在上线前发现了很多的bug，他们的QA真给力！

成也QA，败也QA…如果还是这样的认识，那是极为片面的。测试不仅仅是QA的事情，团队成员要一起为质量负责，软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式，不仅可以使得测试的质量更高，同时还能最优化利用测试资源，做到价值最大化。

推荐实践：

• 自动化测试：QA和BA结对用DSL编写测试用例，QA和Dev结对编码实现测试，生成业务人员可读的测试报告；
• Bug bash（bug大扫除）：团队不同角色一起参与的一个找bug的测试活动

4. 测试作为资产（Tests as asset）

自动化测试帮助我们验证系统功能的正确性，好的自动化测试还有文档的功能，是宝贵的资产。如果每个项目都构建自己独立的自动化测试，没有跨项目共享，其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起，当做资产管理起来，在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率，更好的优化测试。

推荐实践：利用版本控制管理工具把测试代码和产品构建代码一起管理，都作为产品的一部分。

5. 更快的交付（Faster delivery into production）

任何一个idea越快做成软件产品交付给用户，给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节，不要在后期进行长时间的集中测试；同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线，而是把目标放在如何能够帮助团队尽快的让产品上线，让企业投资回报更早，也就是更快的赚钱。

推荐实践：自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

6. 清晰一致的测试视图（Clear and consistent view of testing）

可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量，对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式，将不利于项目间的信息共享和比较，无端增加复杂性，带来浪费。

因此，我们需要把状态报告做的尽可能简单、清晰，并且保持跨项目的指标一致性；同时，我们不应该为了让某个指标变得好看而改变我们的行为，整个报告要诚实开放，这样才能真实反映出项目的状况。

7. 优化业务价值（Optimize business value）

开发软件无疑是要给客户的业务带来价值，软件测试也需要为这个目标服务，测试要跟业务价值保持一致，帮助客户优化业务价值。要求做到：

• 测试不仅是保险，不仅是保证软件质量的；
• 要有目的的关注变化的特性，不要盲目的散弹枪式的对任何特性进行测试，要有优先级；
• 要能帮助企业驱动新的特性和功能；
• 帮助客户创造安全的尝试新点子的环境，提供快速的反馈。

推荐实践：

• 基于风险的测试，根据业务优先级需要调整测试策略，在测试过程中尽可能规避给业务带来的风险；
• 生产环境下的QA，通过收集生产环境的真实用户行为和应用使用数据，对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化，列出该原则对应的实践和行为，并给每个实践或行为设定0-5分的不同评分标准，最后统计各个原则的总分，形成类似下图的结果报告：

在项目中的应用

以Cristan分享的模型为基础，由Tech Lead和几个DEV、QA成立一个评估小组。

第一步：分别根据各自的理解给项目打分，结果是很有意思的，请看下图：

根据这些结果，可以看出大家的认识是不太一致的。

第二步：评估小组对模型中的每条细节进行review，做适当修改以更符合项目情况，并且在评估小组内大家达成共识。其中，所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步：根据更新过后的模型指标对项目上的一个Team做评估试点，详细分析该team对应到测试原则各个维度的well和less well部分，由评估小组成员一起打分，得到该team的评估结果图。

第四步：根据评估结果并结合项目目标排定需要改进的优先级，制定出改进action，并更新给试点team执行。

后续：试点一个周期后再次评估，并重新review评估模型，再推行到整个项目。同时，周期性的进行新的评估和制定新的action，以做到持续的改进和优化。

总结

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力，是帮助企业业务价值最大化的关键因素之一，一直是我们所追求的。

基于测试原则的评估模型，可以帮助我们在追求这个目标的道路上少走弯路，帮助我们持续的改进，以驱动出更加卓越的软件。