• 【华为云技术分享】【测试微课堂】DevOps敏捷测试之道


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

    敏捷和DevOps

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

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

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

    测试债务

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

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

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

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

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

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

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

    自动化测试金字塔

    自动化测试金字塔最早是由MikeCohn在2009年的著作《Succeeding withAgile: Software Development using Scrum 》(《Scrum敏捷软件开发》)中提出。最早提出来的时候是一个三层的金字塔,从上到下分别是UI界面/Service服务/Unit单元测试,随着敏捷测试的不断推进,测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字,在服务化软件架构中Service层也可以理解为 API测试。

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

     MartinFlower关于测试金字塔有这样一段评论。“GUI测试用例还很脆弱,如对系统的一些修正可能导致很多用例的失败,这时候你需要重新录制。你可以放弃录制的方法来解决这个问题,通过写GUI测试代码,但是这样效率非常低。就算你已经很精通了GUI测试代码的编写,端到端的GUI测试用例也很容易出现不可预期结果的问题-一些用例成功一些用例失败,因此,基于GUI的自动化测试是脆弱、耗时(包括用例维护和执行)的。所以测试金字塔要表达的是:底层应当有更多的单元测试和接口测试和逻辑测试,GUI测试用例能覆盖到主业务流程即可。”

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

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

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

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

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

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

    常规安全与弹性安全

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

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

    测试左移和测试右移

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

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

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

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

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

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

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

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

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

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

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

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

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

    自动化测试和测试自动化

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

    HDC.Cloud 华为开发者大会2020 即将于2020年2月11日-12日在深圳举办,是一线开发者学习实践鲲鹏通用计算、昇腾AI计算、数据库、区块链、云原生、5G等ICT开放能力的最佳舞台。

    欢迎报名参会https://www.huaweicloud.com/HDC.Cloud.html?utm_source=&utm_medium=&utm_campaign=&utm_content=techcommunity

  • 相关阅读:
    C#磁吸屏幕窗体类库
    准备
    我写的诗
    How to turn off a laptop keyboard
    How to tell which commit a tag points to in Git?
    Why should I care about lightweight vs. annotated tags?
    How to get rid of “would clobber existing tag”
    Facebook, Google and Twitter threaten to leave Hong Kong over privacy law changes
    The need for legislative reform on secrecy orders
    Can a foreign key be NULL and/or duplicate?
  • 原文地址:https://www.cnblogs.com/huaweicloud/p/12229619.html
Copyright © 2020-2023  润新知