DevOps 敏捷测试之道(上)

阅读数:2 2020 年 3 月 20 日 21:25

DevOps敏捷测试之道(上)

本文介绍企业在敏捷和 DevOps 的逐步转型过程中,测试如何应对挑战,有的放矢进行测试,建立适合产品自身发展阶段、产品特点的敏捷测试能力。

敏捷和 DevOps

敏捷和 DevOps 转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈,新商业模式的创新和变现时间窗口越来越短,催生更多的企业采取精益创业的方式,捕捉市场需求后,尽量缩短 TTM 产品面世时间,快速推出 MVP 产品并快速响应客户需求迭代产品。

以华为为例:

在 2008 年左右的时候,华为的项目还是采用传统的交付方式,例如在年初开始一个项目,在项目立项之初就会把客户的需求全部收集好,包括一些用户的反馈,并把需求做了全年的排序。

年中的时候发布产品给用户,两个月之后再出一个补丁,最终年底出一个正式的版本。

当时版本交付的节奏还是比较慢的,但是对质量要求比较强。因为产品发布给客户以后,下一个补丁需要两个月,如果用户在这个期间发现产品问题,他们只能再等两个月,而在这期间如果用户不接受我们的产品,会导致项目前功尽弃,所以就对产品的质量有严格的要求。

产品逐渐向敏捷方向发展,这时有一部分研发工具平台已经陆续转到云上去了,一些测试类的工具也需要转型。

之前产品的交付是半年、两个月发一次,转型之后变成一个月,甚至两周发一次,但这时的转变并不彻底,与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型,这个时候一些商业模式发生了根本性的变化,也就是说当需求上云了以后,用户更加快速的介入进来。

基于云平台,把一些功能快速的开发出来,然后频繁的和用户去商量,听取客户意见,牵引产品做快速迭代,这种交付方法使得交付周期一下变快了,之前是半年交付一次,现在是一周、两周,更有甚者,可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化,基本做到了小步快跑,快速试错。

测试债务

从瀑布到敏捷再到 DevOps,在开发和测试生产率和需求交付效率提升的过程中,不同的组织或多或少面临一些积压问题没有解决,影响测试能力和测试价值的持续提升。

从对测试的重视程度上看

有的公司存在重开发、轻测试的情况,测试人员职业发展受限;手工测试人员不熟悉编程,开发人员对测试重视不足;测试工作量高,但人员配比低。

从部门组织和流程和文化上看

测试人员对需求理解不足,测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足,质量向速度过分妥协,以及忽视敏捷文化和价值观的培养塑造。

从测试和产品技术和方法上看

产品耦合度高、可测试性差,测试过于依赖黑盒功能测试,测试策略、方法不恰当,测试环境部署时间长,频繁升级等。

测试的焦点:业务价值的质量

测试首先就是一个质量活动,做测试就是要保证质量,其次是一个工程性的活动,即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度,需要有一个焦点,就是业务价值的质量,也就是产品“对客户呈现的价值”的质量。

测试围绕业务价值去做,确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级,而不是说一个测试上来之后,就把测试相关的关系点、关联点全部做测试。

让我们来看几个例子:

例如现在正在做一个线上支付的功能,对这个功能最关心的方面肯定是安全,所以相关的测试用例关键点就应该围绕安全大做文章,一定把安全保证好。

再比如,现在要做一个线上商城,面向用户是老百姓,不仅要让年轻人会用,也要让老人都会用,那么就要关注易用性。

除此之外,电商举办大规模抢购促销活动,那就还需要关注性能。

所以测试要求瞄准了产品本身的业务价值,确定产品的目标,相应的制定质量关键点,制订相关的测试策略,然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环,校验整体的测试过程是否达到预期结果,这就是我们的测试焦点。

自动化测试金字塔

自动化测试金字塔最早是由 Mike Cohn 在 2009 年的著作《Succeeding with Agile: Software Development using Scrum 》(《Scrum 敏捷软件开发》)中提出。

最早提出来的时候是一个三层的金字塔,从上到下分别是 UI 界面 /Service 服务 /Unit 单元测试,随着敏捷测试的不断推进,测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字,在服务化软件架构中 Service 层也可以理解为 API 测试。

这种下宽上窄的三角形结构,代表在各层自动化的建议投入分配比例,越接近底层的单元测试建议的投入最多,接口测试居中,界面层建议的投入最少。

Martin Flower 关于测试金字塔有这样一段评论:


GUI 测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。

你可以放弃录制的方法来解决这个问题,通过写 GUI 测试代码,但是这样效率非常低。就算你已经很精通了 GUI 测试代码的编写,端到端的 GUI 测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于 GUI 的自动化测试是脆弱、耗时(包括用例维护和执行)的。

所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI 测试用例能覆盖到主业务流程即可。

测试金字塔中每层中涉及的测试技术均有自己的优势和局限性,由于上层 GUI 测试的脆弱(不稳定性)、耗时(执行效率)问题,以及问题表现位置(UI)和问题根因位置(代码)距离太远的问题,测试金字塔由关注测试数量转向关注测试质量,推荐增加底层的测试投入。

  • 层次越靠上,运行效率越低,延缓持续集成的构建 - 反馈循环

  • 层次越靠上,开发复杂度越高,如果团队能力受限,交付进度受影响

  • 端到端测试更容易遇到测试结果的不确定性

  • 层次越靠下,单元隔离性越强,定位分析问题越容易

原则上单元测试需要开发人员承担,很多团队中开发人手不足,优先保障功能的实现,在单元测试的投入不够,并且很多开发人员的单元测试经验不足,导致很多团队中不做单元测试或者被动执行流于形式,有人提出了金字塔结构的反模式:蛋筒冰激凌模式和纸杯蛋糕模式。

本文转载自华为云产品与解决方案站公众号。

原文链接: https://mp.weixin.qq.com/s/NQ65enngFnL-ParxbsaRFA

评论

发布