分类目录归档:软件质量

软件测试人员的职业发展之路

在《关于软件质量,大家都在关注什么》一文中,我们了解到软件测试领域新的关键趋势主要体现在以下几个方面:

  • AI的发展与软件测试
  • 敏捷与DevOps
  • 自动化测试
  • 环境和数据
  • 成本与效能
图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

在这样的趋势下,测试人员的职业发展之路有什么变化呢?我们先来看看测试人员的技术发展方向有哪些。

技术方向

基于前面提到的新趋势,测试人员的职责由单一的测试软件系统是否工作、是否满足业务需求变得更加多样化,测试人员可以全流程参与软件开发,让测试活动贯穿软件开发整个生命周期。因此,测试人员的职业发展技术方向有:

  1. 敏捷测试专家
  2. 高级测试开发专家
  3. 专项测试专家
  4. QAOps专家

1. 敏捷测试专家

敏捷测试强调的是尽早测试和频繁测试,测试人员需要能够从需求分析阶段开始介入,全流程参与,跟整个团队一起实现团队为质量负责。对敏捷测试专家的技能要求有:

领域测试能力:测试人员需要丰富的业务知识、较强的业务敏感度和业务理解能力,熟悉各种不同类型的业务模式,包括新兴业务IoT、智能服务、区块链等,能够制定相应的测试策略,有效协助团队做好质量内建,实现交付价值最大化。

自动化测试能力:自动化测试是敏捷开展的必要条件,自动化测试技能是测试人员的必备技能。成为敏捷测试专家,要求测试人员了解不同的自动化测试框架的优缺点,能够指导项目自动化工具的选型;了解测试分层的思想,能够帮助团队制定合适的自动化测试策略;能够实现业务功能层的自动化测试,能够跟开发人员一起参与底层自动化测试(接口测试、单元测试等)的评审工作;了解持续集成工具,能够在持续集成流水线上配置和运行自动化测试。

沟通协调能力:敏捷测试要求团队为质量负责,测试人员作为主力,需要承担起质量的分析者和协调者的角色,要求有很好的跟不同角色沟通和协调团队合作的能力。

2. 高级测试开发专家

高级测试开发专家的必备技能要求有高级自动化测试、白盒测试、开发和平台构建能力,要求有很强的测试代码编写能力,能够自行开发自动化测试工具、搭建自动化测试框架、构建自动化测试平台和服务。

同时,最好还有AI应用的基础算法应用能力和自然语言处理技能,需要了解和掌握AI相关知识,以及AI知识在测试中的应用,以帮助实现自动化测试的智能化。

3. 专项测试专家

专项测试技能集包括安全、性能等跨功能测试技能,需要有扎实的计算机基础知识,了解安全问题的类型、安全测试工具的优缺点,能够提供安全测试解决方案;熟悉性能影响因素、性能测试关注点以及提供性能调优方案等。

专项测试技能也包括测试数据和测试环境的管理,要求熟悉虚拟化、云计算技术、数据匿名化等数据处理技术,能够提供测试数据和环境管理的方案。

4. QAOps专家

测试右移已经越来越被重视,这意味着测试活动需要右移到生产环境,需要测试人员跟Ops人员更紧密的合作,QAOps专家也应运而生。QAOps专家需要了解基础设施相关技术与实践,了解日志管理、日志监控以及日志分析技术,同时还要有用户行为分析能力,通过跟Ops的合作,充分利用生产环境的各种类型的信息来优化软件开发和测试流程,以实现最终优化业务价值的目标。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

管理方向

管理岗位在新的趋势下有些将不复存在,一般在相对传统的组织架构下才会有,但是目前来看还是有相当的企业是适用的,在此也简单聊一下。根据每个公司的情况不同,测试人员直接相关的管理岗位也会有些不同,大体有如下这些:

  1. 测试组长
  2. 测试经理
  3. 项目测试负责人
  4. 测试总监

1. 测试组长

测试组长一般带几个测试工程师, 负责任务分派和人员管理等工作。除了必备的测试技能外,测试组长需要的管理技能有:

任务优先级识别能力:需要能够识别任务的优先级,并根据当前工作合理分配给不同的人去完成。

培养团队成员的能力:带领团队需要对团队成员进行培养和发展相应的能力,需要能够识别不同人员的自身特点,有针对性的培养相应的技能。

沟通协调能力:要带领好团队,较强的沟通协调能力必定能事半功倍,让团队工作更顺畅。

2. 测试经理

测试经理一般是管理一个测试部门,下面可能有多个测试小组。测试经理除了需要关注技术外,还需要关注部门的发展、绩效等。需要的相应技能有:

技术洞察力:测试经理需要对技术趋势和先进测试工具有较多了解,需要能够帮助团队确定测试技术和测试工具的研究和使用,以提高团队的工作效能。

风险识别能力:测试经理需要能够很好的理解业务需求、识别项目风险,负责制定测试策略和具体的实施方案,并能进行总结、报告,及时反馈项目质量状态。

培养团队成员的能力:团队成员的能力培养非常重要,测试经理跟测试组长一样需要这个技能。

沟通协调能力:测试经理不仅需要协调测试部门内部的各种情况,还需要横向跟公司其他部门进行沟通协调,沟通协调能力更加重要。

3. 项目测试负责人

项目测试负责人主要负责一个项目的质量保障工作,需要有跟测试经理相似的技能:技术洞察力、风险识别能力和沟通协调能力

4. 测试总监

测试总监是测试经理的延伸,属于质量部门的最高负责人,需要负责公司所有项目的质量活动,所要求的的技能跟测试经理类似。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

易转型方向

除了测试直接相关的管理岗位外,根据测试人员的职业特点,以下两个岗位是比较适合转型的方向:

  1. 项目经理
  2. 产品经理

1. 项目经理

测试人员,尤其是敏捷团队的测试人员,涉及到项目质量相关的方方面面,自然有着能纵观大局的机会,成功转型项目经理的例子非常常见。相应的技能要求有:

团队管理能力:管理团队,包括人员风险识别、协调沟通等方面,需要掌握一定的人际关系相关的软技能。

客户关系管理能力:项目经理除了要搞定团队,还有最为关键的是要处理好跟客户的关系,客户关系管理技能特别重要。

决策能力:决策能力是一种综合的判断能力,即面对几个方案或错综复杂的情况,能够做出正确的判断并采取行动。

2. 产品经理

软件测试人员都需要能够很好的理解业务需求,一般都有很强的业务能力,转型当产品经理是一个不错的方向。产品经理相应的技能要求有:

用户需求挖掘能力:产品经理需要有包括挖掘潜在用户需求、确定需求优先级、构建用户画像的能力。

多维度思考能力:产品经理需要能够从基本维度、外在维度、核心维度和商业价值维度思考的能力。

抽象能力:产品经理不仅要能从事物本身进行抽象,还需要能够考虑不同层次的抽象;抽象完后,还需要把抽象的对象回归到展示层面,需要有抽象回归具象的能力。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

三个转变

测试人员要培养前面介绍的技能,首先需要实现下面三个转变:

1. 对测试的认知

测试活动不仅是验证系统功能,可以更加的多样化。比如,测试左移就包括对需要的澄清和验证,测试右移则包括生产环境的监控和信息收集等。

测试人员不是质量的把关者,好的质量意味着要交付更多的价值,而不是没有缺陷那么简单,测试人员不再是发现缺陷越多越有成就,而是要想着如何跟不同角色高效合作,使得交付的产品能够优化业务价值。

2. 对技术的关注

由于测试活动的多样性,不能只关心测试相关技术,要把视野扩展到软件开发过程中各个环节接触到的领域知识和不同类型的技术,不同业务类型、技术架构和基础设施等都会对测试有不同的影响和要求。

3. 测试不可以独立存在

测试不能再以独立部门自居,需要跟不同的角色更多的沟通和合作。比如,需求分析阶段需要跟需求人员有密切的沟通,实现自动化测试过程中可以跟开发人员结对或其他方式的深度合作,生产环境下的测试需要跟Ops人员紧密合作等。

同时,测试人员对于系统所采用的技术架构、技术方案的设计思路都需要有所了解,从而更好的理解开发的工作、理解架构演进对于测试的影响,更好的开展测试工作。

最后

了解了发展方向,如何才能让自己的职业生涯更圆满呢?更多的学习建议可以参考我去年在BQConf的演讲《BQConf演讲:软件测试人员该何去何从》里提到的那几个方面:

  1. 确定方向,目标驱动
  2. 持续学习,把知识变成技能
  3. 勇于突破,系统思考

愿各位测试同仁的职业发展之路更加顺畅!

一页纸测试策略

【摘要】测试策略文档通常是篇幅较长、文字为主的形式,编写成本较高,并且写完了很少有人去看,形存实亡。本文介绍可视化的方式,将测试策略用图来表达,并且在一页纸上搞定,这样的策略图非常清晰,关键信息一目了然,并且提供更大的讨论空间,防止僵化,真正能够发挥策略的作用。


“测试策略是什么样的?”

“测试策略嘛,还不是包括#&~+-=~*-+$这些…”

“你们项目的策略有什么特别的吗?”

“我们项目嘛,测试策略的内容有点多,从哪说起呢?”

前面那个场景有没有似曾相识?你是否清楚目前你们正在使用的测试策略是什么样的?

01. 常见测试策略

测试策略的内容与形式

我们都知道,测试策略包括以下两方面的内容:

  1. 测什么(What)? 测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。
  2. 怎么测(How)? 怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测,测试策略通常篇幅较长的文档,包含多个章节;以文字描述为主,只加上少量的配图。

常见测试策略目录结构

【图片来自网络:https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html

测试策略的痛点

长篇大论的文字给人带来居多不便:

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情,尤其是对于理工科出身的不是那么擅长写作的测试人员来说,更是比较麻烦,成本较高。

2. 不易阅读

长篇大论的测试策略文档,要从中快速找出关键信息可没那么容易,可能一不小心错过的细节就是最关键的部分,因为篇幅太长,通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变,这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好,随着时间推移,更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读,也不易维护和更新,事实上团队可能有很多人并不是很清楚策略文档上的内容,这样的策略文档形存实亡,不能真正起到策略的指南作用。

5. 反敏捷

敏捷开发强调的是缩短反馈周期,快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档,显然是不利于敏捷的,也是非常痛的。

测试策略的重要性不言而喻,是否可以找到一种更好的表达方式,让测试策略不那么痛呢?Jamie McIndoe在“Testing Stuff – A One-Page Test Strategy”中首次提出可以把测试策略图视化,用一页纸来搞定。

我们都知道,图示化的表达方式直观、清晰,容易识别关键信息,并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定,一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

02. 图示化测试策略

一页纸搞定

顾名思义,图示化就是用图来描述测试策略的内容,但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分,并且绘在一页纸上。

当然,一页纸的测试策略只是将关键信息以图示化的方式呈现出来,并不是整个测试策略的全部,在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识,是需要团队一起来做很多工作的。这种高度简化的呈现形式,是为了给团队更多的讨论空间,一页纸也更易于修改,从而更能适应变化,真正满足需求。

基于Jamie McIndoe的可视化测试策略思想,我建议的测试策略图包含下列信息:

  • 指导性原则:团队为质量负责
  • 如何测:测试左移、精益测试、测试右移,涵盖测试流程、测试类型、测试方法等
  • 测什么:包括功能、性能和安全等

下面将以蓝鲸项目为例来介绍这几个部分的内容。关于蓝鲸项目,是一个历经10年的离岸交付项目,采用的是敏捷开发的模式,每四到五周一次发布,遵循敏捷开发的各种实践。

例如,蓝鲸项目的测试策略如下图所示:

蓝鲸项目测试策略图

各部分详细介绍

下面,我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式,质量不是某个单一角色的事情,团队为质量负责是项目质量保障的指导性原则,需要所有团队成员对此有一致的认识,人人都要有关注质量的意识。更多关于团队为质量负责的内容,请参考我的博客文章说好的团队为质量负责呢

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试(Test early, test often),也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证,不仅要正确的构建产品,更重要的是构建正确的产品,这就需要把好源头需求这一关。因此,我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动,把质量融入到开发的每一个步骤,通过CI/CD等方式获取快速反馈,做好软件缺陷的预防,以减轻缺陷暴露太晚带来的大量修复成本。

蓝鲸项目的开发生命周期主要体现在下图的七个环节,每个环节都有相应测试活动的开展,并且每个活动都有不同角色的参与。

蓝鲸项目开发生命周期的测试活动

3. 精益测试

精益测试可以理解为以业务价值为目标,以尽量少的成本交付高质量的软件,也就是说测试要测在能体现价值的点上,要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试,分别是测试象限和测试分层。

测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试:测试人员与敏捷团队的实践指南》中,我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境,我在这里称之为测试象限。

测试象限矩阵一共四个部分,称为四个象限。下侧是面向技术的测试,上侧是面向业务的测试;左侧是支持团队的测试,右侧则是评价产品的测试。

1) 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码,起到明确需求、辅助设计的作用。其中,第一象限是面向技术的支持团队的测试,主要是TDD,帮助构建产品的内部质量,也就是代码质量的保障,比如单元测试和API测试等;第二象限则是面向业务的支持团队的测试,从更高层次以业务专家可以理解的方式确定系统期望的行为,做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息,并确保快速的解决问题,既指导了功能的开发,又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

2) 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过,但也可能没有产生客户真正想要的东西,因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试,通过模仿真实用户使用应用的方式,帮助确认是否构建了真正需要的产品;第四象限是面向技术评价产品的测试,主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性,并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧,并用于创建新的测试来驱动下一步开发,形成良性的增强环路。

3) 测试象限的使用

象限的顺序跟测试执行的顺序无关,敏捷开发往往开始于客户测试(面向业务的测试)。与测试执行时机相关的因素通常有:

  • 产品发布的风险
  • 客户方对产品目标的要求
  • 是基于遗留系统的开发还是从零开始构建的新系统
  • 可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架,可以根据项目具体情况,结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样,这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试,比如其中的安全测试就分为业务部分和技术部分。

测试分层

关于测试分层的思想,大家可能比较熟悉的是测试金字塔,主要是针对自动化测试,根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少,体现为底层单元测试较多,越往上层测试比例越少,呈现为金字塔结构。

越往底层的测试越接近代码,编写成本更低、执行速度更快、定位问题也更准确,但是离业务较远,不能很好的体现业务价值;越往上层的测试越接近业务,更能反应业务价值,但有着不够稳定、执行速度慢、实现成本较高的不足。因此,需要权衡利弊,根据项目具体情况,真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构,还是蜂巢结构或其他,并不是一定的,也不会是一成不变的,可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构,类似于蜂巢机构,那是因为基于微服务架构的特点,蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分,而对于单元测试和端到端测试的比例则都有减弱。更多的关于蓝鲸项目测试策略的详情,请参考我的博客文章微服务测试的思考与实践

4. 测试右移

由于软件系统所处生态环境越来越复杂,技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性,软件系统的质量保障在测试环境已经搞不定了,我们需要把目光右移到生产环境。这就是测试右移的思想,其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点,生产环境的QA并不是测试环境的QA的直接后延,而是需要利用其特点通过技术手段收集生产环境一切可利用的数据,包括日志、用户行为、用户反馈等,利用这些数据来分析和优化业务以及开发过程的开发和测试工作,形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作,更多相关的详细内容,请参考我的博客文章生产环境下的QAQA与Ops通力合作打造反脆弱的软件系统

5. 测什么

之所以把这个放到最后介绍,是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容,蓝鲸项目的测试内容主要有:功能、性能和安全。

这三个方面的测试类似,都是从需求分析到生产环境每个环节都要考虑相关测试,做到质量内建、安全内建和持续的性能测试。关于功能方面的质量内建,前面【测试左移与质量内建】部分有介绍,对于安全和性能方面的策略,可以参考如下图示,由于篇幅有限,本文不做赘述。

蓝鲸项目的跨功能测试

03. 测试策略的正确打开方式

一页纸搞定的测试策略,优势非常明显,比传统策略文档更加简洁、清晰,关键信息一目了然。我们再来看一下测试策略图示化以后,还有哪些需要注意的方面。

目标驱动

虽然上网搜索能找到很多测试策略模板,但测试策略不应该是千篇一律的,不可以死搬硬套通用的模板。测试策略受到多种因素的影响,比如:业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标,综合考虑各种因素,权衡利弊,找到最适合自己项目当前状态的策略。也就是说,测试策略应该是目标驱动的。

演进式

项目处于不同阶段会有不同的质量目标,同时随着架构的演进和业务的发展,对软件系统的质量保障工作也需要随之调整。因此,测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的,具有更大的讨论和发挥空间,在防止僵化、保持演进方面的优势明显。

04. 总结

测试策略举足轻重,内容很重要,需要以价值目标驱动,持续度量,并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式,利用图示化的方法,直观、清晰的表达,是非常好的组织形式,能有效克服常规文字为主的文档所带来的痛,推荐大家使用。

05. 延伸阅读

  1. Jamie McIndoe的Testing Stuff – A One-Page Test Strategy:https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
  2. 说好的团队为质量负责呢:https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
  3. QA in Production:https://martinfowler.com/articles/qa-in-production.html
  4. 蓝鲸项目测试策略之微服务测试的思考与实践:https://www.bylinzi.com/2018/06/28/microservices-testing/
  5. 生产环境下的QA:https://www.bylinzi.com/2016/06/13/qa-in-production/
  6. QA与Ops通力合作打造反脆弱的软件系统:https://www.bylinzi.com/2018/10/15/qaops/

新一代支持BDD的测试框架Gauge+Taiko

BDD是什么

BDD,Behavior Driven Development,行为驱动开发。

如果你不是很了解BDD,可以参考我四年前的一篇文章说起BDD,你会想到什么,其中介绍过BDD的理论和应用。

我们可以这样来概括BDD:

  • BDD采用统一的领域特定语言(DSL)来描述业务场景和用户行为,让团队各个不同角色对业务需求有一致认识,从而做到更有效的沟通和更高效的协作
  • BDD的目的不是自动化测试,但是BDD可以有效指导自动化测试,基于BDD的自动化测试相当于维护了一份需求活文档,对项目需求的维护和管理非常有价值。

BDD应用框架之Cucumber

BDD的应用

BDD是为解决下面三个方面的问题而生:

  1. 协作:多个角色在一个团队,如何从一致理解需求开始高效协作?
  2. 语言:不同的角色业务、开发和测试人员分别说自己的语言,如何统一语言,更有效的沟通?
  3. 文档:编写和维护的成本都很高,如何低成本的维护一份有价值的文档?

Cucumber是一款支持BDD的框架,有助于帮助团队解决以上问题。

Cucumber支持用自然语言描述业务场景,需要遵循Given-When-Then的格式,这样就可以容易的对应到自动化测试的3A步骤Arrange-Act-Assert,从而实现业务场景的自动化测试。

Cucumber的理想是将可执行的需求规范、自动化测试和活文档有机的结合,如下图所示:

理想很丰满,现实很骨感。Cucumber在实际应用中的情况又如何呢?

Cucumber的痛点

Cucumber框架实现Web自动化测试包括两个部分:Feature(特性)文件和Step Definition(测试实现),在实际应用中人们普遍感觉到它的复杂。

  • Cucumber特别强调的是协作,Feature文件通常由偏业务的人员来编写,要求遵循Given-When-Then的格式。这种固定的语法对编写人员要求较高,写起来比较费劲,尤其对新人不友好,很多团队反映要写出好的Feature文件特别费时费力。
  • Cucumber支持多种语言实现测试代码,但它本身并不能实现自动化,对于Web自动化测试需要跟其他自动化工具结合,比如Selenium-WebDriver。实现代码不仅复杂,还有着元素定位难、执行时间长、不够稳定的痛点。

Cucumber-js+Selenium WebDriver实现的代码长这样:

Feature定义:

Feature: Google Search
  Scenario: Finding some cheese
    Given I am on the Google search page
    When I search for "Cheese!"
    Then the page title should start with "cheese"

Steps实现

Given('I am on the Google search page', async function () {
    await driver.get('http://www.google.com');
});

When('I search for {string}', async function (searchTerm) {
    const element = await driver.findElement(By.name('q'));
    element.sendKeys(searchTerm, Key.RETURN);
    element.submit();
});

Then('the page title should start with {string}', {timeout: 60 * 1000}, async function (searchTerm) {
    const title = await driver.getTitle();
    const isTitleStartWithCheese = title.toLowerCase().lastIndexOf(`${searchTerm}`, 0) === 0;
    expect(isTitleStartWithCheese).to.equal(true);
});

新一代BDD框架

蓝鲸项目曾经就是用Cucumber+Selenium WebDriver实现的UI层自动化测试,由于上述痛点,大家觉得UI自动化测试越来越难写,我也因此对BDD丧失了信心。

自从遇到了两款新的工具Gauge+Taiko,我又重新对Web系统的实现基于BDD的自动化测试燃起了希望。

Gauge

Gauge是一款开源的轻量级跨平台自动化测试工具,它的愿景是用更少的代码、更少的维护工作实现更多的自动化测试,有如下特性:

  • 采用Markdown格式,支持用自然语言编写Spec,语法自由,编写工作简单易上手,不管是对业务人员还是技术人员都很友好;写出来的文档格式清晰,很好维护。
  • Gauge本身可以实现对Web页面的访问和控制,支持多种语言,各种API封装的很好,代码实现部分比Selenium要简单很多,尤其对于编程技能不是那么强的QA来讲非常友好,易上手,代码的可读性也更强一些。

Taiko

Taiko也是一款开源浏览器自动化测试工具,它的特性如下:

Taiko – REPL
  • 交互式的录制体验。Taiko提供类似于irb的REPL,直接输入命令,可以看到浏览器执行结果,同时后续还可以把成功执行的命令直接生成JS代码,非常方便。
  • Taiko不仅提供常见UI自动化测试工具那样根据Id、name、CSS、Xpath等方式选择页面元素的功能,还提供智能选择器(Smart selector),支持直接根据显示的文本来定位各种类型的页面元素,同时还有支持上、下、左、右这种根据某个元素的相对方位去定位元素的API,很好的解决UI测试页面元素定位难的问题。
  • Taiko采用隐式的等待(Wait)方式,也可以手动设置超时时间以防有些访问等待时间过长。这种隐式等待相比其他自动化工具需要手动设置等待时间的显式等待方式要更高效、更稳定。
  • 与Gauge的完美结合:Taiko在REPL里执行的浏览器操作步骤,可以通过一个简单的命令直接生产Gauge支持的Step,只需要再去简单的加上step名称就可以,操作及其简单。

Gauge+Taiko的代码长这样:

Spec定义

# Google Search

This is an executable specification file. This file follows markdown syntax. 
Every heading in this file denotes a scenario. 
Every bullet point denotes a step.
To execute this specification, use
    npm test

## Finding some cheese
* Goto Google search page
* Google for "Cheese!"
* Page title starts with "Cheese"

Steps实现

step("Goto Google search page", async function() {
    await goto("www.google.com");
});

step("Google for <query>", async (query) => {
    await write(query);
    await click("Google 搜尋");
});

step("Page title starts with <content>", async (content) => {
    await title().then((pageTitle) =>{
        assert.ok(pageTitle.startsWith(content));
    });
});

总结

协作是人的问题,工具可以起到辅助作用,但是不能解决根本问题,过于严格的工具缺乏灵活性,反而阻碍了高效协作的可能。

Gauge不强调协作,可以作为自动化测试工具独立存在,同时又支持高效协作、支持实现BDD,是一款灵活性更好的框架。它的秘密武器Taiko是一款优秀的Web UI自动化工具,两者的结合堪称完美,让需求规范、自动化测试和活文档的有机结合真正成为可能。

本文只是将Gauge和Taiko跟Cucumber框架从对BDD的角度做简单的对比,更多的关于Gauge和Taiko的高级特性,请参考【延伸阅读】部分相关文章。

延伸阅读

BQConf演讲:软件测试人员该何去何从?

本文根据11月23日第39届BQConf北京的演讲《软件测试人员该何去何从》整理,为了便于阅读,稍作修改并增加了不同级别的标题。

三个故事

01. 面试中的他

两年前的一个下午,天气有些雾霾,在三楼光线不是特别明亮的会议室里,我和另外一位工作年限跟我差不多的同事面试一位有着10年经验的候选人。

对于跟一位工作十年的候选人见面,我和同事都挺期待,提前沟通好,做好了充分的面试准备。走进会议室,看到一位身材高大、略显疲惫的男士,没有我想象的那种阅历丰富、干练自信的样子。

简单寒暄之后,我们正式进入面试流程。他介绍了自己的工作经历,详细描述了自己这些年所从事的工作的点滴,听下来并没有太多的亮点。出于对候选人负责,我们想尽力去挖掘他的一些加分项,但是,很难,最终无果…

他来自某大公司,多年一直处于一个部门,从事几乎没什么变化的手动测试工作,工作强度不大,对技能要求也不是很高,他在那里做的得心应手。不料,公司业务发展调整,需要部分裁员,他不得不另谋出路。

02. 屏幕那头的她

一年前,我写了一篇文章《微服务测试的思考与实践》。有位朋友看了我的文章,给我发来微信,她觉得我的文章内容对她很有启发,就文章内容跟我进行了咨询和讨论。

她对内容很认可,但是执行起来她觉得没那么容易。我俩聊着聊着,她开始跟我讲她现在的困境:她有简单的编码技能,但是对于更多底层技术、架构方面的知识比较缺乏,在项目团队想推进一些技术变革重重受阻。她做QA也有好些年了,这两年老觉得行业技术更新太快,自己的技术热情和时间有限。而随着工作年限的增加,别人(团队)对她的要求也就更高。

她是一位妈妈,一方面需要照顾家庭和孩子,一方面感觉到工作技能提升的压力,她感觉自己遇到了职业瓶颈。

03. 放弃测试的他们

两个月前,两位好友一起吃晚饭。很久没有相聚,自然是有很多话题聊的。

他们两个都是曾经做测试的,现在分别转做了开发和管理。席间我们聊到了这个话题,身边做QA或者测试的朋友转角色的还不少。我被问到是否考虑转角色的问题,同时,我也听到一个说法:大家都从QA转别的,毕竟QA的地位还是要低一些。

故事讲完了,大家有何感想?

我们来看一下故事里提到的测试人员面临的问题有哪些:

  • 多年重复手动测试,只是关注自己手头的事情,大公司的部门壁垒,跟别的角色、别的团队较少沟通,相对比较封闭。但这些似乎并不影响做好手头的测试工作,觉得自己是“能力够用”的,在这个舒适区待着很爽,自然没有学习提高的动力。
  • 长此以往,应对变化的能力会越来越弱,随着年龄的增长,本应该同样增长的技能却没有相应的增长,感受到外界的压力增加;如果还有身份的变化,成为上有老下有小的夹层,来自家庭的压力导致用于技能提升的精力减少,更加难以提高。
  • 得不到技能的提高,在团队的影响力减小,话语权降低,不被重视,甚至自己也在怀疑所做工作的价值…于是,只好选择换一个角色…

当然啦,有些朋友是真的觉得测试工作不适合自己,转做别的更适合的工作,这些朋友除外。比如跟我吃饭的那两位好友,他们现在都干的很好!

那么,软件测试人员真的有这么悲惨吗?
World Quality Report

由Capgemini、Micro Focus和Sogeti联合组织问卷调查,每年出具一份《World Quality Report》(全球质量报告),今年已经是第10期了。报告列出了大家关注的质量趋势,也会给出一些推荐的做法。报告内容非常多,每期都是70页左右的英文版文档,去年和今年的报告我都有写文章解读,大家感兴趣的可以参考我博客网站上的文章《数字化时代的软件测试》和《关于质量,大家都在关注什么》获取更多细节。

下面来看今年的这份质量报告给我们带来了什么。

我们知道,软件系统首要的是满足功能需求,所以功能是最为核心的内容,但已经不能止步于此,在功能的外层还有更高的质量目标。大家请看图,在功能需求外还有四个方面,分别是:

  • 安全: 信息化时代安全的重要性不言而喻,不仅指应用程序本身的安全、对用户隐私的保护,也包括软件开发过程的安全性和软件资产的安全管理。
  • 速度:互联网时代瞬息万变,都在追求速度上的质量。同样,速度不仅指应用程序本身的性能,也包括交付的速度,从idea到成品交付到用户手里越快越好,抢占先机!
  • 便利性:应用程序能给用户生活提供多大的便利程度,比如说打开一个外卖软件,可以多短的时间找到需要的餐馆,是用户非常看重的一个质量指标。
  • 体验:第四个是用户使用系统的综合体验好坏,易用性、页面的布局和配色等都会影响到用户是否愿意给应用买单。
最高质量目标:终端用户满意度

这四条围绕功能而高于功能的就是终端用户的满意度,是今年质量报告反应出来的大家的最高质量目标!

质量备受关注,对质量的要求越来越高,软件测试或QA工作的重要性不言而喻,我们大家所做的工作毫无疑问是非常有价值的!

同时,随着质量要求的提高,软件测试也不再是发现缺陷那么简单,对我们测试人员的要求也有很大的变化。

为了走出前面故事中的那些困境,我们需要行动起来。

行动起来

01. 学习

面临的问题

显然,最关键的行动一定是学习!说到学习,我们有必要先来看一下大家学习可能面临的问题:

  • 技术日新月异,太多的东西要学,我该从何学起呢?

的确是这样,信息化时代,学习渠道、学习的内容都是无穷的,要学习先要甄别哪一个是值得学的,无疑给学习提高了门槛,这也使得有部分人无从下手,就干脆不学了…

  • 不知道从哪学起,那么我们就先学一个东西再说,学了总比没学好!

这种做法在过去知识比较匮乏的时代,是可取的,学了一定会比没学要好,说不定哪天就能用的上了。但是,现在处在信息化的时代,有些知识是可以不需要花太多精力去学,可以从互联网简单搜索获得的。毕竟精力是有限的,如果花时间学习了这种本可以轻松得来的知识,是很大的浪费。

  • 目的性不强,学到了零散的知识,也很难真正派上用场,最后这个知识还是会被遗忘。

比如说,现在Python很热,小学生都在学Python编程了,觉得我们要还不会就落伍了。可是呢,学了半天,也没有实际用上,过一段时间发现也记不得多少了…这样进行几次之后,会严重影响学习的积极性,发现学了也没用,好像还不如不学。久而久之,就放弃学习了…

学习这么麻烦,我们该怎么学习呢?

学习的过程

我们先来了解一下学习的过程。学习面对的是海量的知识,我们需要从中挑选自己需要的部分,进行加工和提炼,变成自己掌握的知识。到这是不是就结束了呢?并没有。还有最后非常关键的一步,那就是把学到的知识应用到不同的领域,或者总结分享出来供他人学习和使用。

学习的过程

也就是一个完整的学习过程应该包括三个部分,分别是:知识输入、加工提炼、知识输出。缺失其中任何一步,都不是正确的学习。

讲到这里,我想问今天到场的各位朋友一个问题:平常大家都会读很多书,请问大家怎么定义读完了某本书?

答1:我会根据书上介绍的做Demo在团队演示。

答2:我会总结书里的内容在团队分享。

前面两位朋友回答的都非常棒!我想介绍我的一位朋友的做法,他对读完一本书的定义是必须有输出,输出可能但不限于下列的一项或多项:

  • 写读书笔记分享;
  • 提炼书中观点,结合自己的经验总结成博客文章发出;
  • 运用书中理论到工作实践中,在团队以工作坊或小型演讲方式分享;
  • 或者以演讲的方式到大会上分享给更多人。

就是在这样不断反复学习、总结、分享的经历之后,他成为了某技术领域的专家!

学习的正确姿势

了解了学习过程,我们还需要了解学习的正确姿势,以确保学习是真正有效的。关于学习的正确姿势,我认为有两个比较关键的。

首先,根据前面讲的学习过程,最终是要把学到的知识应用起来的。我们可以先搞清楚要把学到的知识应用到哪里,也就是我们学习的目标,搞清楚这个目标,然后利用目标倒逼输入,再进行学习的正向过程,也就是以终为始的做法。

比如:目前工作的项目上需要某项技术,我们有针对性的去学习这一门技术,这样的效果会比较好,能够达到事半功倍的效果。

又或者,目前工作中暂时用不上,但是自己很感兴趣的技术,可以作为学习目标,深入学习和研究,最终的输出可以是集结成文,或者演讲的方式分享出来。这样,不仅可以让他人获益,更重要的是对知识总结提炼的过程,加深了自己对知识的掌握,最获益的还是自己。

目标驱动、以终为始的学习

这就是我要说的第一个正确姿势:目标驱动,以终为始

这里,我们要搞清楚三个问题,也就是

  • Why – 为什么要学?输出是什么?
  • What – 要学什么内容?输入是什么?
  • How – 如何学?学习的方式,对于不同的内容需要采用不同的学习方式。

第二个学习的正确姿势是持续学习。这一点,其实没有太多可讲的,知识在发生着日新月异的变化,现在是特别需要活到老学到老的时代,不然很容易落伍,跟不上变化的步伐。

可能有朋友会说,我在目前工作中的技能已经完全够用了,我也没有很明确感兴趣的方向,该如何提升自己呢?

接下来,我们来看如何确定学习目标的问题。

学习的方向指导

对于目标不是很明确的朋友,不太知道如何从海量知识选择自己需要学习的内容,可以多关注一些趋势性的内容,以此作为自己学习方向的指导。

比如,前面我们提到的全球质量报告(World Quality Report)就是一份很好的趋势方面的内容。

质量报告里提到大家关注的质量趋势集中在五个方面:AI和测试、敏捷和DevOps、测试自动化、环境和数据,以及质量保障方面的成本投入问题,报告分别列出了这几个方面的现状以及未来几年的发展趋势。

同时,报告还给出了一些推荐的应对策略。我们拿其中的质量工程技能方面的策略来详细介绍一下,包括以下几个方面的技能:

质量工程技能策略建议
  • P0 – 敏捷测试专家,包括必备的自动化技能和领域测试技能。敏捷和DevOps的越来越普及,使得对敏捷测试专家的需求成为最高优先级的。一方面,自动化测试是敏捷的基础,要求敏捷测试人员必备自动化技能;另一方面,敏捷测试提倡测试左移,测试人员需要在需求分析阶段开始介入,对领域知识和业务理解能力有相当的要求。
  • P1 – 测试开发技能,处于P1的优先级,要求必备高级自动化、白盒测试、开发技能和平台构建能力,同时,对于AI方面的基础算法应用处理和自然语言处理技能是个加分项。
  • P2 – 接下来的是专项技能集,包括安全、性能等非功能测试、测试环境和数据的管理技能等。前面提到过安全、性能的迫切需求程度,同时报告也指出测试环境和数据的管理水平低下,导致这些专项技能的培养的优先级还是很高的。
  • P3 – 最后一个是高级QA专家,主要是AI架构技能,要求能够构建执行重复、智能任务的“智能测试资产”。鉴于目前AI技术的运用水平,对于这方面技能的培养可以稍缓,但的确是未来的一个发展方向。

下面再给大家推荐一个非常值得关注的技术趋势类读物,那就是ThoughtWorks的技术雷达。ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,每年为技术者产出两期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

关于技术雷达,也有朋友说上面跟测试相关的条目越来越少,对测试人员的参考价值不大。我们来一起看一下今年上半年发布的第20期技术雷达。

技术雷达V.20与测试人员关系密切的条目

技术雷达是按照技术、平台、工具、语言&框架四个维度,根据每个维度技术条目的成熟度分成暂缓、评估、实验、采纳四个环。乍一看,带测试字眼的条目较少,但这不代表跟测试相关的内容少。我尝试按如图所示的思维导图的方式做了一个总结,摘出测试人员需要关注的几个方面,并列出对应的技术条目。大的方面有DevOps&基础设施、微服务、自动化测试、线上监控与分析、安全、数据分析与机器学习、区块链等,对于每一块我们都可以相应的思考测试人员需要关注的点有哪些,这里就不详细讲了,更多的细节大家可以参考我的博客文章《软件测试人员的挑战与机遇》。

除此之外,还可以多关注一些技术社区、技术大会、技术类公众号,了解别人都在做什么、有什么新的技术等。相信大家也会有不少这方面的关注,欢迎一起来分享。

02. 沟通

学习是提升自身能力的途径,要想职业生涯更加顺畅,还有很关键的一个行动是需要增加跟他人的沟通,不可以独自处于封闭的状态下闷头学习。

首先,项目团队内跟不同的角色的沟通

我们一直在讲团队为质量负责,但是团队不同的角色对质量的理解可能不够透彻、对质量关注的意识也会不太够,作为团队的QA,是需要承担起质量协调者的角色的,需要把自身对质量的理解、当前项目产品的质量状态及时的跟团队反馈,需要跟不同角色有足够的沟通,让团队不同的角色能够更好的一起为质量负责。

当下流行的全流程测试,更是强调测试人员在各个环节的参与,跟不同角色的合作,比如说需求分析阶段需要跟业务分析人员合作,自动化测试需要跟开发人员合作,在生产环境下的QA又需要跟Ops的人员合作等。

在跟不同角色的合作过程中,不仅可以从对方角色那里学习到自身欠缺的技能,以丰富自身能力;同时,也可以让跟你合作的角色从你身上学习到测试考虑的角度,更好的做好质量的每一步。这是一个双赢的过程,1+1>2。另外,合作多了,大家也走得更近,工作更好开展,自然在团队的影响力就会增加,地位感也随之增加了。

团队内跨角色沟通

其次,更大范围的沟通

项目团队的充分沟通,有利于项目工作的顺利开展,但是,团队还是太小,需要扩大到更大范围。比如说,多参与技术社区、技术大会、技术讨论微信群等。相信今天来到现场的朋友们都是体会到这个方面的优势的,都非常积极的参会。

这里,我们要注意一点,如果只是看或者听别人分享的话,参与感是不太够的,效果不会太好。要多发表自己的看法,或者抛出自己的疑问,多跟人沟通,不是单向的吸收。除了一对一沟通,可以参与群体的讨论,或者对一些技术文章、所读书籍发表评论、读后感,还可以通过写文章、演讲的方式分享自己的经验所得。

请记住,有输出才会有收获。这个非常关键!

03. 突破

刚接触测试的从业人员,可能非常关键的一项技能就是要能尽可能的发现bug,于是我们有着很大的一个优势就是比较容易发现很多细节上的问题。这也同样带来一个问题,那就是有的测试人员过度关注细节,导致工作好几年还是容易抠细节,看不到大局。因此,我们的第三个行动是需要跳出来,做到突破,要有破局思维!

突破

首先,要培养系统思考能力。世间万事万物都是有联系的,构成众多大小不一的系统。

小的系统比如目前正在做的产品,当你发现某个功能有bug的时候,它真实的问题可能出在另一个你想象不到的模块,这个时候如果只是停留在你发现问题的模块,可能就浪费很多时间也难以定位问题;或者你发现一个bug,觉得它很严重需要紧急修复,但是当你结合市场情形、业务发布优先级、对终端用户的真实影响、修复所需成本以及开发人员手头其他工作的优先级综合来看,最后可能发现那个bug的优先级低了很多…

这是系统思考的两个简单的例子,由于系统思考不是我今天要讲的重点,在此就不多讲了。大家感兴趣的可以找相关资料,运用前面所介绍的学习方法去获取相关知识。

其次,需要扩大视野。前面讲到的关注技术趋势、参加技术讨论等都是扩大视野的途径。通过吸收这些信息,视野变大了,个人看问题的角度就会变的不一样,也就更容易去发现问题或者提出建设性的解决方案。

最后,遇到问题时,要运用系统思考的能力,跳出单一的小系统,利用曾经吸收到的各类有价值的信息,逐步建立自己的大局观

这几点,我认为都是测试人员非常需要培养的能力,也是帮助我们拓宽职业之路的有力助手。

前面讲到这么多,有些是通用的适合所有人,但是,我们还是需要结合自身特点去选择适合自己发展的方向和提升的方法,要结合自己的兴趣特长、性格特征来选择。如果没有跟自己兴趣特点匹配的也不用太过担心,相信兴趣特点也是可以培养的。我想送大家两句话:

选自己所爱,爱自己所选!

坚持就是胜利!

回顾与总结

今天通过三个我亲身经历的故事,我们看到了测试人员可能面临的问题。同时,给大家分享了我们可以采取的三个行动。最后总结一下,希望大家能够记住下面几个关键词:

  • 以终为始,持续学习
  • 沟通交流,让知识翻倍
  • 勇于突破,系统思考
  • 选自己所爱,爱自己所选

今天分享的这些是我在学习、摸索中的一些总结,我不是什么成功人士,所以这也只是抛砖引玉,希望大家更多的来一起分享和讨论,愿我们各位测试同仁们都有一个好的职业发展的明天!

一起离奇数据丢失案件引发的思考

最近生产环境出了一起数据离奇丢失案件,调查过程很曲折,几度进入死胡同…下面跟大家分享整个事件的来龙去脉。

数据丢失案件

8月初,用户批量导入了一批(300+)委托人数据,导入后检查过数据都没有问题。最近(10月中),处理那些委托人的时候,发现所有委托人的某几个列表(list)类型的自定义字段的值都没有了…

这是用户报过来的问题,客户对此特别紧张,涉及到数据丢失,那是优先级非常高的!

团队随即展开调查。

背景信息

委托人的信息存在于两个系统中:从A系统导入,存入A系统的数据库,同时会有同步机制把数据同步到B系统的数据库;在B系统也可以修改这些数据,修改完会同时写入A、B两个系统。

问题排查过程

  1. 团队第一反应是怀疑双写和同步之间出了问题,但仔细想想好像没法成立…
  2. 怀疑B系统的用户有不当操作,把数据抹去了。但是,通过检查数据变更event,没有发现来自B系统的event…况且,现在是一批数据都没有了,B系统并没有批量操作的入口…
  3. 是不是A系统进行过批量操作,导致数据被重写?开发人员看代码,测试人员尝试重试各种相关场景,也是没有成功。同时,从event里也没有找到跟这批委托人相关的任何可疑event…
  4. 会不会是第三方的系统写入导致数据没了?随即查看第三方的api和相关event,也是没有找到任何可疑迹象…
  5. 能想到的用户相关操作都试过了,也没有任何相关event的记录,难道是直接运行SQL脚本了?客户的相关人员不会无故去运行脚本,怀疑可能我们提供的某次修复生产环境问题的脚本搞得鬼…查看最近这段时间的脚本记录,大家放心了,没有脚本会导致数据丢失!
  6. 真的是见鬼了!怎么可能数据就这么莫名其妙的丢了呢?!调查小组几经折腾已经筋疲力尽了,请来了小陈同学。
  7. 小陈同学听了前面的排查过程,好像真的天衣无缝,但他还是不甘心,决定再去看看event和log。他重新查了前面提到的那些委托人相关的event,的确没有发现任何可疑。又仔细看了看用户报过来的问题,竟然只是list类型的值丢失了!这一定有什么不对!他赶紧去查看那几个list字段相关event,终于真相大白了!原来是有用户把list里的选项删除又重新以不同顺序添加了一遍,从而导致原来用这些选项的字段值都没有了!(该用户应该是觉得原来顺序不合适……)

我的思考

找到了罪魁祸首,这个案件也就侦破了,日子又恢复了往日的平静。作为QA的我,除了记录下这个过程,也想分享一下我的思考:

  1. 数据丢失通常都会比较严重,一般不可恢复或难以恢复,给企业和用户都会带来损失。团队接到这种问题务必引起重视,投入足够的人力去进行调查,如果一波人查到走投无路的话,要及时求助外部力量,往往旁观者清,可能会事半功倍,带来不一样的效果。
  2. 调查过程需要结合业务、开发和测试人员的力量,考虑可能会影响的业务场景,从界面操作和系统代码两方面入手,同时排查各种可能性。前面的调查过程大家看着可能觉得挺轻松的,事实上排查各种可疑场景不是一件轻松的事情,因为对于一个复杂系统来说,不是很容易想到每一个场景的…
  3. 对于丢失数据的字段本身也是可由用户添加删除的情况,一定要想到还有可能是字段本身被删除了!同时,这里也暴露一个设计和实现上的问题,对于这种字段选项的调整会导致数据丢失的情况,竟然不给用户任何提示…这是需要注意的,后续再有类似的字段一定不可以由用户自由的删减!
  4. 日志记录非常重要,而且要记录足够的、清晰的信息,方便对问题的调查。
  5. 数据库脚本用版本控制工具管理非常有必要,出问题的时候,执行过的任何脚本都有利于帮助排查可疑情况。

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

问:谁应该为质量负责?
答: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. 自动化测试与线上质量的关注

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

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

  • Humio

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

  • Honeycomb

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

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

6. 新兴领域不容忽视

(图片来自网络)

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

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

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

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

写在最后

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

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

(图片来自网络)

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

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

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

关于软件质量,大家都在关注什么?

去年,我们在《数字化时代的软件测试》中看到了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,欢迎留言,谢谢!

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

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

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

缺陷预防

说到缺陷预防,通常能够想到的就是测试前移(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个“为什么”来提问,以找出其根本原因。根据实际情况,问题的数量不一定要限制在五个,可多可少,适当调整。