软件测试人员该何去何从？

发表评论

“好多QA转PM，因为QA（的地位）始终是要低一些”

“我现在做的事情跟几年前没有区别”

“资深QA在项目上做的事情新来的毕业生也能做”

上面的话你是不是也有同感？我相信大部分人会这么认为，因为这些表面上看起来的确是这样的！

那么，软件测试人员或者说QA真的有这么惨淡吗？

对于开篇引用的几句话，我们一一来分析一下。

测试工作的价值不容置疑

“好多QA转PM，因为QA（的地位）始终是要低一些”

说这话是没有看到QA所做工作带来的价值。相反的，我认为QA之所以可以转PM是QA工作过程中获得的锻炼挺多的，不仅可以转PM，可以转PO，技术型的QA还可以转Dev。

其实，QA和PM并没有地位高低之分，只是分工和职责不一样，QA转其他角色并不是地位的改变，可能只是更加适合自己。积极主动的做好本职工作，都能为团队带来很大价值；做的不好的话，都同样的不能带来价值。况且，做的不好的PM可能影响到整个团队，所带来的价值远不如一个优秀的测试人员带来的价值大。

团队协作才能成功

我们应该以合作的心态看待这个问题，一直强调的团队为质量负责，需要每个人都有团队的意识，有分工只是因为兴趣特点和擅长领域不同而已，并没有高低贵贱之分。

质量越来越受到各行各业的关注，质量问题不容忽视。软件质量的保障工作，软件产品的测试当然也是非常重要有价值的，这一点根本不用怀疑。

只是，质量的好坏带来的价值不是那么直接可见的。反而需求人员多分析了几个需求，开发人员多开发了几个功能点，又或者多写了几个自动化测试，这些都是显而易见的，似乎带来的价值更大，更容易被人认可和重视。而另一方面，需求的验证、测试的设计、质量状态的关注、风险的把控、快速的发现和定位问题，这些是不容易被量化的，也就不容易被重视或尊重。

能力提升是关键

无限风光在险峰

“我现在做的事情跟几年前没有区别”

这是只看到所做的事情似乎没有差异，比如说都是一起分析需求、设计测试、测试story、写自动化测试等，可能的确几年前就做这些事情，现在还是做这些事情。但是，我相信只要你在做每件事情都能认真对待，有自己的思考和总结，就不会一样。比如：

  • 同样的分析需求，几年前可能只看到BA写出来的需求，看看有没有边角case漏掉了；而现在的你可以从行业业务角度去看待这个需求整体考虑的合理性，是不是能给用户带来价值、能给企业带来竞争力。这两者还是有很大的区别的。
  • 同样的测试story，几年前可能只是根据验收标准和自己想到的一些边角case去测试，一个story需要一天才能测试完；而现在的你，利用自己对于领域知识的掌握、技术的了解、系统功能的熟悉，结合自身这么多年阅历和增加的常识，半天估计能测试包含几个story的一个feature，或者一个junior测试人员测试过的story，你拿过来一下就能发现一些问题。这就是成长，这就是价值！

“资深QA在项目上做的事情毕业生也能做”

如果只是看所做的事情，可能还是停留在表面，跟上一条讲的几年前的自己和今天的自己一样。

当然，有很重要的一点，资深QA不能仅仅是工作年限长，得是有真正的能力，不然的话可能还不如优秀的毕业生。

QA能够随着年龄和工龄的增长，让自己的能力也能不断的提高，才能让测试工作有更多价值的体现。因此，能力提升至关重要！

那么，能力该如何提升呢？

能力提升路径

能力提升路径

看似相同的事情，不同能力的人做出来的效果不一样。为什么他解决问题的能力那么强？我们来了解一下学习提升的过程。

第一阶段，知识积累

通过阅读、听课、观看视频等方式可以获取到知识点，将这些知识点总结归纳之后，变成自己理解的知识。

这是第一阶段知识积累的过程。

第二阶段，经验积累

将所学知识进行试验，进一步用于实际项目，获取实践经验，不断反复的实践可以获得经验的积累。

这一阶段还不够，还没变成真正解决问题的能力。

第三阶段，能力提升

在实践中坚持回顾和总结，对实践过程进行批判和改进，并且举一反三的运用所学知识，将会实现能力的积累。

到此，就实现了知识到能力的转变过程。

积累和分享很重要

前面每个阶段都可以获取新的知识，然后经历同样的知识-经验-能力的转变，不断的积累，将会实现能力的提升；每个阶段都可以把知识或经验分享给他人，在帮助他人获得相应知识的同时，更是自身能力提升的一个非常好的方式。

多次反复的知识-经验-能力的转变，达到一定积累之后就会带来惊人的效果，这不是一个线性的增长。

在整个过程中不断发掘自己的兴趣点，将学习、兴趣有机结合起来，会达到事半功倍的效果。

终身成长

了解了能力提升路径，很重要的一点还有可能是我们需要转变固有的思维模式。这里给大家推荐我非常喜欢的一本书《终身成长》，书中讲到两种思维模式：固定型思维模式和成长型思维模式，具备成长型思维模式的人将更容易获得成功。我们需要更多的关注自身的成长，而不是关注外界、跟外界进行比较。

《终身成长》

前面所讲并不只是跟软件测试人员相关，可以适用于任何角色、任何职业的朋友，只是同样作为质量工作者，听到不少人的担忧，才撰写此文。

相信积累多了，就会发生质变！

最后，让我们一起多阅读、多学习、多实践、多思考、多总结、多分享，做到终身成长！

高效会议的13条军规

发表评论

每天的会议太多了，我都没有时间写代码了…

最近天天各种讨论，我有好多story都没测了…

在蓝鲸项目经常能够听到这样的声音。这也难怪，团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。

前同事李光磊写过一篇《极限会议》就是讲的怎么提高会议效率，写的非常好。但其中的原则要真正实践起来可能还是不那么容易让所有人都能快速理解并实施。

本文通过故事的方式分享日常会议的常见问题，并试图从会前、会中、会后三个阶段来列一些相对比较基础的、比较容易落地执行的规则。

会前

场景一：突如其来的会议

一天早上，小青看了看时间，已经是9点半，半个小时后有个面试，这是上周HR就约好了的，他把候选人的简历拿出来看了看，想提前准备一下。

“小青，咱们几个去开个会，头脑风暴一下下周跟客户的catch up XXX的内容！” 突然听到有人叫他，小青回头一看，原来是老王。

“大概要多久？我十点有个面试呢。 ”

“看进度吧，估计得一个多小时，我半个小时前给你们几个发了邀请了。”

“那我肯定不行！我只有半个小时，你不提前看下日历么？再说你现在才发邀请，也没有提前准备啊，我对XXX不是很了解，感觉我没啥可以输入的…”

“快来不及了，时间不好安排，最近大家都忙。要不你先参加半个小时吧！”

小青没办法，只好去参加会议了，大家陆陆续续来到会议室，等人都到齐已经是9:40了…

小青非常不爽，对于老王来说，似乎这一切很正常，因为这样的情形在项目上并不少见。

从这个场景，我们看到有几个方面的问题：

  • 会议没有提前预定参与人员的时间，也没有查看参会人员的时间是否有冲突；
  • 会议没有准时开始；
  • 没有时间提前准备；
  • 小青可能不是合适的参会人员

场景二：Feature kickoff

BA组织某个team做feature kickoff，这是一个在原来某个复杂feature上的功能扩展，由于业务需要，对原feature的设计有改动。在讲解新feature的设计过程中，大家发现BA目前提供的设计可能有些问题，于是大家开始讨论和澄清原来feature的相关设计是什么样的，时间过去了一个小时，还没有正式回到新的feature的kickoff上来…

这个场景存在这样的问题：

  • 会议的目的是kickoff新的feature，但是新feature的设计并没有相关人员的确认（这种确认并不需要全team的人参加），而导致全team人都在的情况下，浪费了很多时间来讨论设计的合理性。这是会议之前没有足够准备的原因。
（图片来源：https://www.smartlinkin.com.tw/article/3137）

从前面两个场景的问题，我们来总结一下会前的规则有哪些：

1. 确定会议目标：每次会议一定会有一个目标，只有明确目标，这是会议高效的前提。目标不明确的会议，可能没有开展的必要。

2. 确定会议议程：根据会议目标，把会议议程定义清楚，这样才能在开会的时候严格按照议程，准时结束。

3. 确定参会人员：尽量准确的确定参会人员。如果是讨论，要求参会人员都能有输入；如果是宣布某个决定，确保参会人员是需要被通知到的。如果邀请了不一定要在场的人员参会，对双方都是一个浪费。

4. 提前通知参会人员：定好会议时间、地点，要尽早发出邀请，这样有利于参会人员提前安排好其他工作或会议。同时，在发出邀请的时候，需要告知参会人员是否需要有提前准备的内容，比如组织某个讨论可能要提前收集、思考讨论的素材，组织workshop需要提前准备环境或者相关知识等。

5. 准备好会议需要的东西：不管是组织者还是参会人员，对要提前准备的材料、环境等都务必提前准备好，有时候可能还需要准备一些物料等。一旦有其中一人或者某一件东西没有ready，都会影响会议的高效开展。

会中

场景三： 某会议室10来人约两个小时的讨论

某team正在会议室开会讨论A话题，讨论已经进行到快两个小时，看得出来屋子里的人都有些疲惫，只剩下少数人还在说话讨论，其他有几个人在看手机或电脑，还有昏昏欲睡的。会开了这么久，原本要讨论的A话题没有得出结论，现在大家已经跑题到讨论B了。

“咱们原定时间是一个小时，现在超时太严重了！再这样下去也不会有结果…先结束吧！”终于有人受不了了。

组织者也发现大家有些失控，只好草草结束了会议…

小明本来很想参与A话题的讨论，但是跟另一个会议冲突，他没能参加。赶在会议结束时刻来到会议室，想了解一下大家讨论的结果。没想到并没有得出结论，想找组织者问问是否有大家发言的记录，他想整理一下看是否有什么发现，结果也令他失望，并没有记录…

从这个场景，我们可以看到会中的几个问题：

  • 严重超时
  • 没有控制大家的讨论范围
  • 有部分人并没有全身心投入到讨论中
  • 没有板书或者记录
  • 会议草草结束，没有结论，没有下一步行动计划

因此，总结会中的规则如下：

6. Timebox：严格控制每项内容的时间，避免会议超时。

7. 如果会议不能围绕目标展开从而没有价值，组织者应该提前结束会议；如果某参与者贡献有限或者没有贡献，TA可以选择提前离开后者组织者请TA离开。

8. 严格按照议程进行：讨论过程中很容易走偏，要注意及时拉回来，如果有新的需要讨论的内容，可以记下来下次再讨论。

9. 集中精力参会：非必须要用的情况下，所有参会人员盖上电脑和手机，专心参与会议内容。既然已经承诺可以参会，就不要担心其他工作被此次会议耽误，修build也不是会上看电脑的理由。如果真的有比会议更紧急的事情，可以不参会。（经常有code review或者feature kickoff的时候，有同学带着电脑一直低头忙着，不知道是在听会议内容，还是在忙什么。这样的情况需要尽量避免。）

10. 确定下一步行动计划：每次会议都需要在会上确定下一步行动计划，如果没有该次会议相关的下一步计划，也需要明确。

11. 做好会议记录：清晰记录会议的内容很关键，不仅可以share给没能参会但需要了解的人，也可以作为后续参考用。最好是在开会期间有人直接记录，而不是会后会议再记，这样能够记得清晰也更省事。

会后

场景四：某team的回顾会议

按照惯例，回顾会议开始都先回顾一下上一次的action。今天的组织者是小树，他找了半天没有找到上次回顾会议的总结邮件，也不知道上次有什么action… 原来是上次的组织者在回顾会议结束之后，忘了发邮件了，好在当时拍的照片还在。对照着照片上的action，发现其中有两三个并没有完成…

这个场景的问题是：会议总结没有在会后发出，action也没有好好执行。

由此，我们可以得出会后需要遵循的规则有：

12. 发出总结：组织者需要针对会议结果进行总结，并且发送给所有需要知晓的相关人员。总结需要包括会议讨论事项、讨论结果、action及其owner等内容。

13. 执行相应的action事项：所有参会人员都要按照会上讨论的结果，执行好自己own的action，不要到下一次会议的时候发现action还没有做，这样非常影响会议的效果。

写在最后

大团队的沟通成本很高，高效沟通非常关键，而涉及多人的会议或讨论更是需要高效开展。前面描述的规则执行起来并不难，但是需要大家都能有这个意识，齐心协力，严格执行。

说好的团队为质量负责呢？

1条回复

问：谁应该为质量负责？
答：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要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

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

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

软件测试人员的挑战与机遇

发表评论

“我们公司的测试好多都转业务或开发了，还有的转管理了，测试做不长久…”

“现在好多公司已经不招测试人员了，感觉测试没有什么前途…”

“ThoughtWorks技术雷达上都是开发相关的内容，测试相关的内容越来越少…”

软件测试总是被看做没有技术含量、没有前途的工作，很多做软件测试的朋友也比较迷茫，表示发展受限。在这个技术飞速发展的时代，各行各业都在实行数字化转型，各种高新技术似乎离测试人员越来越遥远…

那么，测试人员真的是前途渺茫吗？本文将根据ThoughtWorks最新发布的第20期技术雷达来分析当前流行的技术给软件测试人员带来的影响是什么，有哪些机遇与挑战。

技术雷达上的内容涵盖有技术、平台、工具和语言&框架四个维度，我观察到其中跟测试人员关系比较紧密的主要有以下几个方面：

1. 支持快速、持续交付的基础设施与DevOps实践

质量和速度是最关键需求，为了适应各行各业对速度的要求，配套的支持快速、持续交付的基础设施与DevOps实践是成功之必备。技术雷达上与之相关的条目有很多，比如：Terraform生态系统和四个关键指标等。

  • Terraform生态系统

Terraform是一种安全有效地构建、更改和版本化基础架构的工具，可以管理现有和流行的服务提供商以及定制的内部解决方案，正在迅速成为通过声明式定义来创建和管理云基础设施的首选工具。本期雷达Terraform相关的内容重点包括Terratest（用于测试基础设施代码)，以及GoCD的新提供商（可以使用Terraform配置GoCD)。

基础设施不仅是Ops或者开发人员需要关注的领域，作为测试人员，同样需要加强这项知识的掌握：

  1. 了解了基础设施知识，结合已有的测试sense，测试人员可以和开发或Ops一起测试基础设施；
  2. 了解基础设施特点，可以指导测试的设计，在测试的时候更有针对性的关注比较脆弱的节点、环节，规避风险，增强系统的反脆弱性；
  3. 利用基础设施知识，可以指导测试环境的搭建和维护、自动化测试数据的准备和管理等。
  • 四个关键指标

埃森哲发布的DevOps报告指出组织绩效跟软件交付性能关系紧密，而衡量组织绩效的四个关键指标分别是前置时间、部署频率、平均修复时间(MTTR)和变化失败率。本期技术雷达采纳了这项技术。

作为测试人员，我们需要了解每个指标的真正含义，并且思考我们测试策略是否需要做某些调整来提供对应的指标值。比如说为了提高部署频率，可能不需要那么高的E2E自动化测试覆盖率，而是达到覆盖效果和执行效率最佳平衡的一个状态即可。

2. 支持业务灵活扩展的微服务架构

引入微服务令我们受益匪浅，使用微服务，团队可以扩展那些独立部署和维护的服务的交付，从而方便业务的灵活扩展。微服务架构正在逐渐被越来越多的企业采用。我们看到技术雷达上应对微服务的相关条目有服务网格、混沌工程、API测试框架Karate等。

  • 服务网格（Service Mesh）

服务网格是一种安全、快速、可靠的运行微服务生态系统的方式。这种方式为轻松地大规模采纳微服务奠定了基础。它提供了检测、保障、跟踪、监控和故障处理功能。它提供的这些跨功能能力无需共享API网关等资产或将很多依赖库纳入到每个服务中。

  • 混沌工程（Chaos Engineering）

混沌工程是对系统进行试验的一门学科，旨在建立对系统抵抗生产环境中不确定条件的能力的信心。在去年，我们看到混沌工程从一个备受关注的 、想法，转变成公认的主流方法，来改善并保证分布式系统的弹性。主要用于以下几类故障时增强系统的弹性：基础设施故障、网络故障和应用程序失败，对应的工具有Gremlin和Chaos Toolkit等。

  • Karate

Karate是一款API测试框架，其特色在于，直接使用Gherkin来编写测试，无需依赖常用编程语言来实现测试行为。Karate是一个领域特定语言，用来描述基于HTTP的API测试。虽然该方法很有趣，可以为简单的测试创建非常易读的规范，但用于匹配和验证负载的专用语言可能会变得语法晦涩、难以理解。从长远来看，使用此风格编写的复杂测试是否将可读且可维护，仍有待观察。

微服务带来灵活性的同时，也带来很多的复杂性和不确定因素，尤其是对质量保障带来了挑战，因此微服务系统的测试也备受关注。作为测试人员，只有了解了微服务架构与服务网格的特点及其对测试的影响、混沌工程对质量保障的帮助、API测试的框架选择与测试优化等，才能更好的做好微服务系统的测试。

3. 多样化数据形态的支持

随着数据源的增加、数据规模的扩大、数据种类越来越多，相应的数据形态也呈现出多样性，包括NoSQL、时间序列、像CockRoachDB和Spanner这样提供全局一致性的SQL存储，以及提供聚合日志文件查询功能的事件流。不再是关系型数据库解决一切存储的时代了，要考虑真实需求，采用合适的策略和工具。

数据形态的变化，必然对测试也提出不同的要求。作为测试人员，需要了解不同的数据规模、不同的存储形态、不同的数据类型分别该如何验证、测试该如何设计、测试数据该如何准备，还有数据安全、数据匿名化、数据分析等数据相关技术对测试的支持等。比如，对于大量数据处理的项目，测试人员需要了解数据处理的技术与处理逻辑，分别从功能层面验证处理逻辑的正确性，以及从非功能方面考虑大量数据处理的性能、数据处理的安全规约等。

（图片来自网络）

4. 网络安全始终是重中之重

网络给我们生活带来便利性的同时，其安全性也是备受关注。2018年欧盟颁布了GDPR法令，使得众多企业不得不紧急调整系统功能做好个人身份信息的保护工作。网络安全始终是质量保障的重中之重，绝对不容忽视。本期技术雷达推荐的安全相关条目有密码即服务、容器安全扫描、密钥销毁技术等。

  • 密码即服务（Secrets as a service）

在构建和运维软件的价值流中，密码凭据在多个场合都需要使用：构建流水线需要使用密码来与容器注册中心等安全基础设施进行交互，应用程序需要使用API密钥作为密码凭据来获得业务功能访问权限，而服务间通信则需要以证书和密钥作为密码凭据来保护其安全，这些密码凭据不建议通过源代码的方式管理，而是采用密码即服务的技术来存储和访问。利用这种技术，可以使用Vault或AWS Key Management Service(KMS)等工具来读写HTTPS端点上的密码凭据，同时实现精细的访问控制。

  • 密钥销毁技术（Crypto shredding）

密钥销毁是指主动覆盖或删除用于保护敏感数据的加密密钥，以保护敏感数据不被读取。对于审计应用程序或区块链这样不应该或不能删除历史记录的系统来说，密钥销毁技术对于隐私保护和GDPR合规非常有用。

  • 容器安全扫描（Container security scanning）

围绕Docker的容器革命显著减少了应用在跨环境迁移时的阻力，并推动持续交付和持续部署的采纳。但尤其是后者，对于传统的投产控制带来了相当大的漏洞。容器安全扫描技术是对该威胁载体的必要响应。构建流水线中的工具，会自动检查流水线中的容器是否存在已知漏洞。

作为测试人员，对于上面的安全相关技术可能不需要掌握的很深，但是需要了解有这样的一些技术，以及对应的使用场景。这样，才能对于系统整体的安全质量有更好的把握。此外，测试人员需要了解相应的安全测试技术，需要关注业务方面的安全需求，了解不同领域的安全规范和要求，从需求阶段做好威胁建模开始，跟团队一起在软件开发生命周期做到安全内建（Build Security in）。

5. 自动化测试与线上质量的关注

要快速交付，必然离不开自动化测试，而要做好自动化测试，更是离不开相应工具的支持。本期技术雷达上列出的Cypress、TestCafe和Puppeteer被誉为后Selenium时代的Web UI测试的三驾马车，值得关注。这三个工具不同于WebDriver时代的自动化测试工具，具有更加轻量级、更加稳定、速度更快的优点。

随着技术架构的演进和业务领域的发展，软件系统生态越来越复杂。过于重视预生产环境的测试，不仅不能很好的保证生产环境的质量，而且影响交付速度。因此，我们要把质量关注点拓宽到生产环境，做到测试右移。本期技术雷达列出的相关工具有：日志管理工具Humio，Honeycomb，以及前面提到的混沌工程相关条目等。

  • Humio

在日志管理领域，Humio是一款相对较新的工具。该工具完全从零开始构建，通过基于定制设计的时序数据库的内置查询语言，在日志提取和查询方面性能非常快。从提取、可视化和报警提醒的角度来看，该工具能够与几乎所有工具相集成。

  • Honeycomb

Honeycomb是一个可观测性工具，它从生产环境中提取出丰富的数据，并通过动态采样使其可管理。开发人员可以记录大量丰富的事件，并在之后决定如何划分和关联它们，这对于大型分布式系统的问题诊断很有帮助。

作为测试人员，自动化测试成为了必备技能，需要关注自动化测试工具的发展，了解新工具的特点与适应场景，更好的让自动化测试工作发挥最大的价值。另外，测试右移的思想也越来越被大家接受，需要测试人员更多的了解基础设施相关技术、线上监控技术等，跟Ops紧密的合作，做好QA in production。同时，利用生产环境的数据，为预生产环境的测试设计和数据准备等提供帮助，构建反脆弱的软件系统。

6. 新兴领域不容忽视

（图片来自网络）

最火热的新兴领域当属AI，这也是未来的发展方向。本期技术雷达上列出的有机器学习和神经网络训练等内容，比如：机器学习持续交付模型、NLP的迁移学习和fastai等。

另一个热门新技术是区块链，技术雷达上区块链相关技术条目有智能合约、超越以太坊的EVM和企业版以太坊Quorum等。

技术雷达上还提到一个新的内容，那就是随着社会对科技的依赖程度日益增长，建议软件开发团队在制定决策时必须考虑道德问题，思考自己所构建的软件会在未来产生什么影响。相应的工具有技术塔罗牌和道德风险手册。

作为测试人员，这些都是大家可以关注并深入了解的方向。新兴领域必然会对测试有不同的要求，比如：关于AI的测试需要考虑两个方面，一个是对于AI产品的测试，另一个是把AI技术运用于测试中，比如自动化测试的智能化、生产环境数据的智能分析等。另外，对于区块链，需要考虑它对测试带来什么挑战、有什么样不同的测试方法来支持；对于道德风险的把控，我们软件测试人员又该注意些什么？能够提供哪些支持呢？

写在最后

前面列的这几项，除了自动化测试工具以外，其他的内容通常被认为跟测试人员没多大关系。其实，软件测试已经不再是那个简单的通过模拟用户行为点击去验证功能是否满足的时代了，测试人员的眼光要放更开阔一些，考虑更多的质量相关因素。对于前面总结的这些项目，我认为不是跟测试人员没有关系，而是给测试人员带来了新的挑战，提出了新的要求。同时，机遇跟挑战并存，这些挑战同样也给测试人员带来了很多新的发展机会。

那么，在众多机会面前，测试人员该如何把握呢？推荐大家可以根据T型能力模型去提升自己的能力。

（图片来自网络）

T的横表示能力广度，T的竖表示能力深度。前面提到的方方面面都属于广度，包括不同技术和不同业务领域的扩展，而深度就是对于其中一个领域进行深入的学习研究，发展对应的测试技能。

广大的测试朋友们可以结合自己的兴趣特点，找到最适合自己的那个领域，深入发展。了解足够的相关知识，通过实践将知识转换为经验，然后总结归纳、不断锻炼，以获得利用经验解决问题的能力，拥有一技之长。

同时，要拓宽视野，了解更多领域的知识，做到广度和深度协调发展。

关于软件质量，大家都在关注什么？

2条回复

去年，我们在《数字化时代的软件测试》中看到了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”属于特殊区域，用于某些管理区域，特别是用于表示协调世界时的“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，欢迎留言，谢谢！

RPA工具初体验

发表评论

引子

一年前，在一次客户(老外)的演讲中，晕晕乎乎的在一大段英文中听到了RPA这个词，当时大概查了一下，了解到RPA是机器人流程自动化（Robotic Process Automation)的简称，跟自动化有些关系，但是当时也没搞太明白。

半年前，听说客户的IT部门开始培训大家用RPA工具UiPath来做自动化测试，但是遇到了一些麻烦，问我们这边是否有相关经验。还真不好意思，没有接触过，于是决定研究一下RPA到底是个什么玩意。

RPA初印象

首先看到的是埃森哲的《Getting Robots Right》文章，介绍了RPA的常见误区、案例分享，以及RPA的关键成功因素等，都是高大上的介绍，对于我这个没有接触过的人来讲还是有些云里雾里，只是对RPA有了大概的认识。

什么是RPA

文章提到RPA是使用软件来完成重复的、结构化的、基于规则的任务，从而大规模地自动化业务流程，最终实现企业级智能自动化，它是基于办公室的等效生产线机器人，基础技术是机器学习和人工智能。

简而言之，RPA就是用机器人（软件）来取代人完成工作任务。

文章还介绍了RPA可以做的事情，有处理事务、操纵数据、触发响应，以及与其他数字系统通信。其实就是像人工作那样操作不同的系统，处理不同的任务。

理想的可以用RPA工具来操作的应用程序可以在财务、人力资源、采购、供应链管理、客户服务/经验和数百个行业特定业务流程（例如保险索赔处理）中找到。

RPA用在哪里

到此为止，感觉还是很抽象，了解到RPA主要是用来自动化业务流程的，但是不清楚RPA具体是什么样的。

因此，还是先体验一下RPA工具吧。

RPA工具初体验

下载了目前市场占比最大的工具UiPath试用版，尝试使用它提供的录制回放功能录制了一个简单的步骤，的确可以工作，但发现对于复杂的、有条件跳转的还不能这么简单的实现。

通过研究入门手册，琢磨着编写了几个程序实例：一个是猜数字游戏，有两个版本；另一个是从网站查询指定城市的实时天气。它们长这样：

UiPath示例

左边的游戏是序列（sequence）形式，右边两个是流程图（Flow chart），跟平时画的流程图非常的类似，很直观可读。好像有点意思！

这是怎么做到的呢？麻烦吗？

UIPath工具提供一个图形化的编程界面UIPath Studio，由三个主要部分组成，Activities（默认在左边）、Properties（默认在右边）、中间是编辑和展示上图中那样的序列或者流程图的地方。

Activities里有各种活动的控件，比如：Input Dialog、Write Line等输入输出控件，以及If、While/Do While等条件/循环判断控件。将活动控件拖拽到中间编辑区域，设置跟其他已有控件的关系。FlowChart里可以通过箭头连接不同控件来设置其相应关系，而Sequence里则是按照控件摆放的上下顺序为先后顺序。

然后，选中编辑区域的控件，可以在右侧的Properties里设置对应的控件属性，比如：猜数字游戏，判断输入的数字跟实际数字的大小以确定弹出不同的消息内容，这些都可以在Properties里对应的设置。

同时，还支持设置相应的变量，比如猜数字游戏中的实际数字和输入数字都可以用变量代替，方便多次使用做比较。

因此，在UiPath里通过拖拽和相应的属性设置，全部在图形化界面上完成，就可以实现一个程序的编制，并不需要有编码工作，对编程技能没有什么要求。对于普通的业务工作人员来说，也是非常简单的。

UiPath Studio

这个简单实现业务流程自动化的工具似乎跟传统的UI自动化很有相似之处，是不是真的可以像我们客户那样用来做自动化测试呢？

RPA与UI自动化

研究了一阵UiPath的用法后，我给团队做了一个分享，用前面做的程序给大家演示UiPath的使用的时候，本来工作的好好的获取天气程序竟然挂了…原因是网页上的元素有了变化，重新修改获取新的元素路径才得以通过。

由此可见，RPA工具也跟UI自动化工具一样受到UI元素影响较大。

UiPath提供的图形化编程界面，对于没有编码技能的人来说，新建一个工作流拖拖拽拽就能完成，的确很方便。

但是，UI自动化测试都会随着UI的变化需要做相应的修改，通过图形化界面修改流程感觉还是有些麻烦的（或许是因为我还不够熟练使用这工具），作为QA，我更喜欢通过代码的方式来修改。而UiPath后台存储的是Xaml格式，可读性一般般，要改代码也没那么容易的感觉。

UiPath代码

另一方面，UI自动化测试最好跟持续集成工具集成起来，而主流的RPA工具都是不能在CI pipeline上运行的。

不像UI自动化工具那样运行于测试环境，RPA工具主要是适用于生产环境，基于相对稳定的系统来实现流程自动化。

当然，开源RPA工具TagUI，可以编程，也支持命令行运行，但是这个工具不太像是RPA工具，更像是被RPA耽误的UI自动化工具。

RPA工具用于UI自动化测试不仅没有太多的优势，反而带来很多不便，有杀鸡用牛刀之嫌，不合适。

对于自动化测试还是要基于测试分层理念，考虑尽可能把UI层自动化测试下移，对于必要的UI自动化测试也可以用更轻量级更适合的工具来做。

由于各种不适，我们客户用RPA工具做自动化测试的事情当然是没能达到很好的效果。

既然RPA不适合做自动化测试，我们来看看它的真正用途吧。

RPA技术的真正用途

RPA技术可以模仿各种基于规则而不需要实时创意或判断的重复流程，在电脑上不间断地执行基于规则的各种工作流程，它不仅比人类更快，还可以减少错误和欺诈的机会。简言之，就是“像人类一样工作”，“把人类进一步从机械劳动中解放出来”，让人类自由地开展更高价值的工作。这是RPA技术的初衷，是RPA技术的真正用途。

基于上述特点，RPA技术目前在财务领域应用比较成熟。财务是一个强规则领域，财务领域内的很多事务流程和报告流程大多是可重复、有规律可循的，因此也最易于实现流程自动化。在财务决策过程中相对标准化、有清晰的规则和可重复的活动，也可以应用RPA技术。

把财务相关的输入- 处理 – 决策 – 输出的流程进行分析、拆解，再用机器人软件模拟人的操作，把原本要在各种软件平台——包括会计软件、ERP软件、报表软件，甚至是CRM软件和税务软件上需要很多人力完成的填写、报送、执行命令、菜单点击、输出报表等动作，交由机器人来完成。这就是RPA技术在财务领域的应用场景。

其他基于规则的结构化的业务流程，也可以应用RPA技术，比如HR领域、保险报销流程等。目前，国内外已经有不少成功应用案例，例如：四大会计师事务所的财税机器人、阿里云RPA等。

PwC Robot

(图片来源：https://www.pwccn.com/zh/tax/tax-robot-solve-aug2017.pdf)

RPA，需谨慎前行

RPA技术可以用于结构化的基于规则的业务流程自动化，因此被认为是可以把人类从重复劳动中解放出来的技术，是一个完美的、高效的、低成本的数字化转型方案，被众多企业所青睐。

但是，RPA技术尽管颇具吸引力，目前的RPA产品仍存在明显的技术局限性，阻碍RPA项目发挥完全价值。 这些挑战包括：

  • 非数字流程输入的转换
  • 识别非结构化文档格式中目标数据字段的能力
  • 相对轻松地适应不断变化的规则或业务逻辑的能力
  • 从自动化流程的事务性数据中生成洞察的能力
  • 根据上下文解释和理解机器活动上游指令集的能力

RPA技术要跟AI技术结合，利用认知和智能识别技术来应对这些挑战，才能较好应用于数字化转型。

另一方面，仅从业务层去考虑利用RPA技术来实现数字化，容易忽略底层支撑系统的技术改造，并不利于整个IT环境的改造与企业的彻底数字化转型。2018年11月ThoughtWorks发布的第19期技术雷达，RPA第一次上榜，但是被置于“暂缓”环，正是这个原因。

RPA在技术雷达

技术雷达建议：

RPA这种仅关注自动化业务流程而不解决底层软件系统或功能的方法的问题在于，引入额外的耦合会使底层系统更改起来更加麻烦。这也会让未来任何解决遗留IT环境的尝试都变得更加困难。 很少有系统能够忽视变化，因此RPA的进展需要与适当的遗留系统现代化战略相结合。

同时，也有德勤、安永等咨询专家表示，就许多企业客户的流程管理与系统的基础能力现状来看，仍存在着大量的基础建设工作有待开展。不用着急实现RPA，首要的还是把自身的流程管理和系统构建好。

因此，RPA生态还不够成熟，暂不能作为理想的数字化工具。RPA要怎么用还是要根据企业自身特点和具体需求，谨慎前行，不可冒进。

缺陷分析如何帮助质量内建

发表评论

质量内建的关键是缺陷预防

近几年，软件开发过程中的质量内建正在逐渐被大家所重视。越早发现的软件缺陷，修复成本越低。质量内建要求在软件开发生命周期的每个阶段做好质量保障工作，预防缺陷的产生。

缺陷预防

说到缺陷预防，通常能够想到的就是测试前移（QA从需求阶段开始介入、TDD/ATDD等）、Code Review等实践，正向的来预防缺陷的产生。

但是，软件系统的生态环境越来越复杂，不确定性增加，缺陷预防的难度也在增加。如果缺陷已经产生，是否还能被利用来帮助质量内建呢？

在《软件缺陷的有效管理》一文中介绍了基本的缺陷分析方法，接下来我们一起探讨一下如何利用缺陷分析来帮助质量内建。

缺陷分析与质量内建

缺陷分析最为关键的是根因分析，找到根因，能够减少缺陷重复出现的可能性，在后续阶段做到缺陷预防，帮助质量内建。

分析根因

引起缺陷的原因主要有下面这几个方面：

  • 需求缺失或者需求不清晰
  • 设计问题
  • 编码错误
  • 测试不够
  • 环境相关（硬件、软件、配置等）

利用5 Why分析法[1]根据缺陷的表象，多问几个为什么，找出根因。下面是一个真实生产环境缺陷的根因分析过程：

上图的根因还可以继续细分，比如为什么这么设计，可能还会有更深层次的问题；同样的，进度紧张导致的需求没有实现，也可能还有更详细的内情可以分析的。最好能一直分析，直到找出真正的根本原因。

定位阶段

找出根本原因之后，同样利用5 Why分析法，基于软件开发生命周期由外往内的问为什么，从而定位引发问题的薄弱环节，找出是哪个环节做的不好导致的问题。拿生产环境的缺陷为例，下面是可能（不限于）的问题列表：

1. 为什么在预生产环境没有发现这个问题？
2. 为什么测试环境没有测出这个问题？
3. 为什么Desk Check没有发现这个问题？
4. 为什么Code review没有发现这个问题？
5. 为什么单元测试没有覆盖到这个问题？
6. 为什么在需求评审的时候没有发现这个问题？
7. ……

定义改进action

找出了根因，并且定位了引发缺陷的最可能阶段，接下来就是通过“What”问题来确定对应的action，预防类似缺陷再次发生，从而帮助质量内建。

不同的根因对应的可能actions有：

总结

质量内建的关键是缺陷预防。

除了正向的考虑加强每个环节的质量保障工作可以预防缺陷，通过分析缺陷的根因、定位问题出现的薄弱环节、制定可行的对应改进措施，可以帮助我们更有的放矢的做好缺陷预防工作，更有效的做好质量内建。

注1：5 Why分析法
所谓5 Why分析法，又称“5问法”，也就是对一个问题点连续以5个“为什么”来提问，以找出其根本原因。根据实际情况，问题的数量不一定要限制在五个，可多可少，适当调整。

QA与Ops通力合作打造反脆弱的软件系统

发表评论

软件系统的脆弱性

伴随着不断演进的软件技术和架构，日趋复杂的软件系统基础设施，以及大量增加的业务和数据，开发和运行环境中不稳定的因素也在增加，系统行为变得不可预测，同时软件系统的不确定性日益严重。

人们无法通过预先设定的测试场景和测试脚本去测试软件，预生产环境已经不够用，软件系统的质量保障工作受到挑战，软件系统变得脆弱。

软件系统的脆弱性

面对复杂的环境和脆弱的软件系统，该如何保障软件的质量呢？借用反脆弱[1]的概念，我们可以把软件的质量保障工作延伸到生产环境，利用这些不确定因素，从中受益，构建反脆弱的软件系统。

生产环境下的QA就是利用系统在生产环境的不可预测性，通过监控预警等方式收集生产环境的信息，总结分析以指导软件开发和测试过程，从而提高软件系统的健壮性、优化业务价值。其中，日志处理是最为关键的一个部分。

日志处理的常见误区与改进思考

提到日志处理，通常都会想到Ops（可能有Ops和开发人员组成，下面简称Ops）团队，认为日志处理是Ops该做的事情，往往关注的都是利用什么工具、什么技术来监控和分析，很少听到有对仅仅Ops人员处理日志的质疑。

作为QA，想从QA的角度来考虑一下，如果QA能够参与日志处理，跟Ops人员合作会有什么惊喜发生呢？

当然，并不是质疑Ops人员的能力，我们相信Ops人员在监控分析方面的专业技术能力是完全没有问题的，但是受限于不同的思维模式，Ops人员处理日志还是会有局限性的：

1. Ops人员主要关注的是系统运行的稳定性和系统资源使用情况，做日志监控也会着重关注这些方面，比如内存、CPU利用率等等，缺乏对系统整体质量的关注

2. Ops也会对业务有所了解，但肯定比不上业务分析和QA人员，在做日志监控和分析的时候容易漏掉高业务风险的日志，没有及时止损，导致给业务带来损失。

3. Ops人员很难把生产环境日志信息做详尽的分析，并把结果共享给开发团队来指导上线前的开发和测试工作，难以做到最优化利用日志信息。

QA与Ops一起处理日志

凭着对业务的了解、对系统的熟悉以及对整体质量的关注，QA参与日志处理有着独特的优势。

  • 质量反馈

敏捷QA有一项非常重要的职责就是在每个环节做好质量分析、掌握质量状态，并把质量信息反馈给团队。QA利用生产环境的日志信息，能够更好的了解产品的质量状况，更好的掌握系统易出错的薄弱功能点，对于后续的开发和测试工作有很好的指导意义。

  • 分析优化

QA作为质量的倡导者，不会放过任何有利于做好质量保障的环节。当QA参与日志处理，发现日志处理过程中存在的可改进空间，定会促使优化日志处理，最大化利用日志信息。

  • 业务敏感度

QA是团队里对系统最了解的角色里边业务敏感度最高的，QA参与任何活动都会以用户角度出发，考虑业务价值和业务风险。

QA参与日志处理，对于业务优先级较高的日志会比较敏感，能够更有的放矢的关注日志信息，让日志处理更有效。

同时，QA分析生产环境的日志信息，了解到真实业务的运行状况，从而可以更好的帮助优化业务价值。

下面通过一个项目上日志处理的故事来分享QA与Ops合作做好日志处理的实践。

项目的故事

项目背景

蓝鲸项目是一个历经九年多的离岸交付项目，团队不同阶段有50-80人不等，有三个系统同时并行开发，包括企业系统、客户系统和用户系统。随着业务的不断扩展、微服务的规模化，系统的不确定因素也开始暴露出来，生产环境下的缺陷增多、错误日志增长迅速，日均新增错误日志数达到几千条。

加强日志监控和处理迫在眉睫。

被动日志分析

刚开始项目上的一个Ops人员专职处理生产环境的日志，分析的方法是在Splunk里按Punct[2]查询错误日志重复出现的数量排序，每天处理重复出现数量比较多的一部分日志。这个阶段没有QA介入。

Punct实例
  • 时间和精力原因，每天新增的日志并没有办法全部覆盖到；
  • 分析日志的同事的业务敏感度不够，没法基于风险优先级来处理，可能导致某些关键业务的错误信息漏掉；
  • 没有可能进行详细的总结分析，对后续的处理没有指导意义；
  • 虽然参与处理日志的同事越来越专业，但没有很好的将日志信息共享给团队，形成信息孤岛。

这是一个被动分析日志的过程，处理过程本身存在很多的问题：

在这个过程中发现了很多当时日志记录本身存在的问题：级别定义不清晰、记录信息不够用、记录格式不一致等。

这个时候，QA也想参与，可是心有余力不足，主要是因为以下几个方面的痛点：

  • QA没有权限接触生产环境；
  • 由于没有接触过，对生产环境的基础设施并不了解；
  • 日志记录的信息QA理解起来很有难度。

主动出击内建日志

意识到前一阶段日志处理的问题，团队决定投入更多的精力来加强日志处理。

首先，利用结构化日志技术，优化日志记录本身的问题。同时，QA从流程上把关做好日志内建，控制好每个环节，确保该有的日志能够正确的记录下来。

同时，QA、Tech lead跟Ops人员一起讨论识别出业务风险较高的特性，在监控面板设置对这些特性相关的前端和API的监控，并设置好一些定时Alert，每天通过邮件的方式告知性能和故障情况。每个特性团队的再派出开发人员加入Ops团队，兼职负责对监控得到的信息进行诊断，QA则负责跟踪通过日志信息定位出来的缺陷问题的修复。

另外，也对测试环境的日志进行监控，QA开始分析测试环境的日志信息，尽早发现问题。

这一阶段团队开始主动出击，有了业务优先级，不再是从茫茫日志大海去分析，这一举措给忙季带来很好的效果，顺利度过了忙季。

但是随着忙季的过去，也开始暴露出问题：错误日志在不断减少，团队对此的关注也越来越少，原来加入Ops团队的开发人员主要关注点也是在新的特性开发商，邮件收到的定时Alert也渐渐地被忽视…对于突然出现的错误日志并不能第一时间发现处理。

QA主导进一步优化

错误日志不能及时发现，导致用户报过来的生产环境缺陷也在增加。

项目日志处理的优化

QA作为生产环境支持的主要负责人，承担起处理生产环境缺陷和加强日志监控两项职责。

1. QA组织跟参与日志处理的Ops人员的访谈，收集痛点，针对性的优化Alert机制，改为错误触发，不再是定时的，减少噪音；

2. QA从流程上督促各特性团队Ops人员分析和查看自己组内负责的监控信息，关注Ops处理日志的进度状态更新；

3. 对于Ops人员比较抓狂难以定位的问题，QA也会参与一起pair分析，或者根据Ops人员提供的信息去在测试环境尝试重现；

4. QA对于一些特别重要的特性，定期查看是否有相关错误出现，以免漏掉相关错误信息。 比如，系统有个专供大老板发邮件的功能，某天突然挂掉了，这个错误日志信息在监控里边也有，但是并没有引起重视，QA查看的时候发现了才把优先级提上来赶紧处理；

5. 优化整个生产环境支持流程，把日志处理纳入其中。周期性的对日志处理结果进行分析和回顾，把日志信息跟业务关联起来，识别出易出错的业务功能点，在后续的开发和测试过程中重点关注，同时也进一步优化现有的监控预警设置。

这个阶段QA不管是流程上还是实际日志分析上都有参与，日志处理更高效、生产环境缺陷发现更及时，生产环境的支持收到客户的好评。

项目故事回顾

前面故事主要分享的是随着业务和架构的演进，生产环境缺陷和错误日志都在大量增加，项目团队如何一步步优化日志处理、利用日志信息加强质量保障工作。从QA不参与、QA参与到最后QA主导，QA在整个日志处理过程中承担着以下几个非常关键的作用：

  • 监督协调，流程把控
  • 基于业务风险的分析和优化
  • 日志处理与开发过程形成闭环，持续改进
项目日志处理的演进

写在最后

软件系统所处生态环境的复杂性、不确定性并不是毫无益处，生产环境下的QA技术就是利用这种不确定性，并从中受益，从而增强软件系统的反脆弱性。

QA参与日志处理，主要承担的是分析者和协调者的角色。QA参与，持续的分析、优化，利用生产环境的日志信息来指导和优化软件开发和测试过程，最大化业务价值，是生产环境下的QA最核心内容之一。

同时，QA利用开发和测试过程中对系统的了解，以及对业务的敏感度，可以进一步指导和协调日志处理过程的优化和改进。QA与Ops团队的合作，生产环境日志处理会更高效，也更能体现其价值。

这样，生产环境和预生产环境形成了良性循环，打造出一个反脆弱的软件系统。

注1：反脆弱

脆弱的反面是什么？是坚强？是坚韧？《反脆弱》这本书给出了这样的解释：

脆弱的反面并不是坚强或坚韧。坚强或坚韧只是保证一个事物在不确定性中不受伤，保持不变，却没有办法更进一步，让自己变得更好。而脆弱的反面应该完成这个步骤，不仅在风险中保全自我，而且变得更好、更有力量。

做一个类比的话，坚强或坚韧就像一个被扔到地上的纸团，不会摔坏，但是也只是维持了原貌，这还不够。

和纸团相反，乒乓球扔到地上非但不会摔坏，反而可以弹得更高。乒乓球拥有的就是脆弱反面的能力，也就是反脆弱。

注2：PUNCT

PUNCT是Splunk提供的一个功能，就是将日志信息的第一行的所有字母和数字去掉，剩下的标点符号，其中空格用下划线代替。

都是脏数据惹的祸

发表评论

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

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