更新时间:2023-01-04 GMT+08:00
分享

DevOps敏捷测试之道

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

敏捷和DevOps

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

以华为为例,在2008年左右的时候,华为的项目还是采用传统的交付方式。例如,在年初开始一个项目,在项目立项之初就会把客户的需求全部收集好,包括一些用户的反馈,并把需求做了全年的排序。年中的时候发布产品给用户,两个月之后再出一个补丁,最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的,但是对质量要求比较强。因为产品发布给客户以后,下一个补丁需要两个月,如果用户在这个期间发现产品问题,他们只能再等两个月,而在这期间如果用户不接受我们的产品,会导致项目前功尽弃,所以对产品的质量有严格的要求。

产品逐渐向敏捷方向发展,这时有一部分研发工具平台已经陆续转到上云,一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次,转型之后变成一个月,甚至两周发一次,但这时的转变并不彻底,与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型,这个时候一些商业模式发生了根本性的变化,也就是说当需求上云了以后,用户更加快速的介入进来。基于云平台,把一些功能快速的开发出来,然后频繁的和用户去商量,听取客户意见,牵引产品做快速迭代,这种交付方法使得交付周期一下变快了,之前是半年交付一次,现在是一周、两周,更有甚者,可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化,基本做到了小步快跑,快速试错。

测试债务

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

  • 从对测试的重视程度上看,有的公司存在重开发、轻测试的情况,测试人员职业发展受限;手工测试人员不熟悉编程,开发人员对测试重视不足;测试工作量高,但人员配比低。
  • 从部门组织和流程和文化上看,测试人员对需求理解不足,测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足,质量向速度过分妥协,以及忽视敏捷文化和价值观的培养塑造。
  • 从测试和产品技术和方法上看,产品耦合度高、可测试性差,测试过于依赖黑盒功能测试,测试策略、方法不恰当,测试环境部署时间长,频繁升级等。

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

测试首先是一个质量活动,做测试就是要保证质量;其次是一个工程性的活动,即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度,需要有一个焦点:业务价值的质量,也就是产品“对客户呈现的价值”的质量。测试围绕业务价值去做,确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级,而不是说一个测试上来之后,就把测试相关的关系点、关联点全部做测试。

让我们来看几个例子:例如现在正在做一个线上支付的功能,对这个功能最关心的方面肯定是安全,所以相关的测试用例关键点就应该围绕安全大做文章,一定把安全保证好;再比如,现在要做一个线上商城,面向用户是老百姓,不仅要让年轻人会用,也要让老人都会用,那么就要关注易用性;除此之外,电商举办大规模抢购促销活动,那就还需要关注性能。因此,测试要求瞄准产品本身的业务价值,确定产品的目标,相应的制定质量关键点,制订相关的测试策略,然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环,校验整体的测试过程是否达到预期结果,这就是我们的测试焦点。

常规安全与弹性安全

在我们常规的设想中,通常是哪个地方不安全,就一定要把所有不安全的因素找出来、清除掉。这是常规的做法,但却偏向于理想,在实际工作中是不可能把整个系统中不安全的因子全部识别到的,这其中涉及能力、架构等各方面的原因。

因此,在此基础上演变出了弹性安全,即通过场景模拟的方式将不安全因素尽量展现出来,从而基于这种不安全场景,给出快速的修复方案弥补这个不安全因素,从用户角度来讲是感知不到的。从产品来讲,它的商业目的和质量目的都可以达到,这就是所谓的弹性安全,即便发生了错误,能够及时快速的修复漏洞或者自我修复,达到正常工作的目的。

测试左移和测试右移

左移就是前移,尽量把活动向前移。例如BDD(Behavior Driven Development,行为驱动开发),基于场景直接设计出符合这个场景的用例,来匹配这个设计;契约测试,服务和服务本身之间有耦合,我们可以通过契约测试解耦,以防导致问题。

测试右移是指要把测试活动的覆盖范围尽量向后蔓延。通常的测试只进行到了版本发布之前,测好之后发布一个软件包,而测试右移要把软件包发布到生产环境,以及到线上运营环节,都要去做测试。

在这两个方面也有一些相应的实践,例如线上拨测,主动线上监控用户的一些行为,并从行为轨迹里面快速捕捉相应的问题,主动推送给相关的责任人,让他去关注并且解决。线上的过程可以通过一些测试手段,不断的反馈给真正的开发人员,让他知道当前产品的整体表现,开发人员就会快速的针对产品作出应对方案。

产品发展不同时期的测试策略

是否在团队组建之初,就要把整个自动化测试的能力构建起来呢?其实这有一个过程,下面从软件的成熟周期的角度,看一下如何构建测试自动化的能力。

在软件初期探索阶段,产品是一个不确定的状态,从前端的风格和整体的布局到后端的API都时刻在变化当中,而且变化比较频繁,由于自动化用例的生命周期比较短,所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段的产品,往往特性是可控制的,只有几个测试,因此可以以手动为主,不考虑自动化,让产品能够快速识别错误点,让用户能用起来。

到了产品扩张阶段,用户认可产品,这时候会出现两个现象:第一是用户量增长,第二是需求数量增长。这时候必须要考虑自动化,因为在这个阶段每一次迭代的全量验证成本会越来越大,而交付的速度也会越来越快。我们不可能每一轮上线的时候都全部用手工做测试,这时候旧的模块就需要自动化用例去保证。

到产品提取阶段,产品已经到了需求的饱和期,产品的利益增长也到了饱和期,这时候要严格控制产品需求,自动化用例的职责变成守护,不允许变动引入额外的风险点、大的特性变动,导致对成熟的用户造成攻击。

团队规模对测试建设的影响

当团队规模在5个人以下,团队处于探索阶段,这时质量活动可以仅仅局限于测试的自组织阶段,只是做一些基础类测试管理活动,把缺陷管理起来,做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制,并没有接触到自动化测试。

随着项目的进一步扩大,逐渐增长到5-10人的团队规模,这时测试工作量突然增加,可能会有专门的测试人员进来,这个测试人员会去和开发人员进行串联,把需求转化成自动化测试的用例,搭建持续集成,逐步演进一些测试手段。——这个阶段已经开始做一些自动化的尝试。

团队进一步增大,一个人可能搞不定工作量的时候,会招聘更多的测试人员,成立专门的测试团队,这个团队就从自动化测试转向测试自动化,把更多的管理工作做进来。在这个管理过程中,我们会做一些产品的对接,包括开发专门的工具,实现自动化的整体能力,不仅仅是自动化执行了。

经过上面几个演进周期之后,测试团队具备了很多的测试自动化经验,这个时候可以进行面向云化的转型,现在很多团队都在进行DevOps转型,最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么?原有10-15人的测试专项团队做什么?在这个阶段团队要把测试专项能力向服务化能力转型:测试专员会在团队创建初期进行赋能,包括测试工程搭建、早期的测试用例怎么写、标准化模板的编制、针对非功能性测试的专项能力的赋能;所有团队进行测试流程的评审,包括测试策略、测试计划、测试用例的评审,再看一下整个团队里面流程上还有哪些改进的;从各个方面整个专项测试团队向服务化进行转型,帮助所有团队完成自动化转型。

自动化测试和测试自动化

这里要澄清一个概念,就是测试自动化(Test Automation)。

测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行(Automated Testing),还包括其它所有可以减人力投入的活动,例如自动化创建测试环境、自动化部署被测系统、自动化监控、自动化数据分析等。很多自动化测试只是测试的执行部分,例如把一些测试执行的人工测试手段做成自动化测试。但是测试自动化不仅仅是只是执行,还包括了从环境的获取到生成测试数据、执行自动化测试,最终生成结果。如果有问题,会自动推送给相关的人,对应的组织解决。自动生成测试报告,测试人员直接拿到测试结果。

分享:

    相关文档

    相关产品