您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 其他相关 > 正文

DevOps兴起意味着专职测试人员消失?

发表于:2018-06-13 作者:朱 少民 来源:质量屋

今天,咱们见证了DevOps被迅速采用,因为企业必须对市场变化作出更快的响应。借助DevOps,企业能够加快产品上市的时间,更好地响应并满足了不断变化的客户需求,帮助企业获得竞争优势和业务的快速增长。

DevOps可以看做是敏捷开发模式的延伸,将持续集成(CI)、持续部署、持续交付(CD)扩展到运维,打通开发与运维之前的壁垒,在整个生命周期中消除传统的孤岛,促进研发与运维的协作,从而缩短软件产品交付周期,提高软件服务质量。

DevOps强调构建、测试、部署和运维等工作的高度自动化,构建工具链或自动化全覆盖的持续研发的方法和工具,让基础设施、运维也成为产品代码的一部分,能够实现持续设计、持续编程、持续构建、持续测试、持续发布、持续部署、持续监控(持续-X / C-X实践)等,能够及早发现并更快修复缺陷,整个研发更具透明性、运维环境更加稳定,实现越来越快的软件交付,减少协作、测试和沟通成本。因此,DevOps不仅旨在持续交付价值,缩短产品上市时间,加快商业应用系统的开发和部署,而且旨在减少缺陷、改善质量和客户的满意度,以技术方法解决过去用流程要解决的问题,提高企业研发收益。

这里给出一组数据,不管你信不信:相对低性能的同行,高性能的IT组织遇到的失效减少为60分之一,失败后恢复的速度提高到168倍、部署频率提高到30多倍、从研发周期缩短为原来的200分之一。 

因此,最近有一股思潮,认为随着DevOps实践的兴起,测试需求正在下降。这个观点的支撑是:自动化方法已经足够先进,在整个研发、发布和运维过程中在很大程度上人为干预可以逐步减少,先进的、高度自动化的技术解决方案的速度和效率胜过了传统的、基于流程改进的QA/测试方法。

与之相反的观点,认为DevOps只是一个概念,上述想法只是理论上一种理想,难以落地实施。许多互联网企业由于能力和资源等限制做不了自动化全覆盖,而且工具发现缺陷的能力比较弱,即使能发现60~80%的缺陷,还有20~40%的缺陷会遗留到上线后,这样的质量对大多数应用(更不要说像银行、电信等关键系统)根本不能接受。其次,如果需求定义不规范、不可测或者需求不稳定,自动化测试就很难,还有诸如UI、移动体验之类的组件呈现出许多不可控或不确定的因素,这对于自动化测试来说更具挑战性,而人类测试者却很容易地完成这类测试(UI测试和易用性测试),自动化的代价反而大得多。再者,DevOps只能适用于SaaS(Software asa Service, 软件即服务)这类软件的研发与运维,非SaaS的软件研发很难采用。不同类型的产品、不同的用户和不同的研发团队,采用的软件开发模式和实践千差万别,DevOps在许多场合是不适用的,而适合自己的开发模式和实践才是最好的。

但是如果公司(如非关键系统的SaaS公司)采用了DevOps模式,有没有可能彻底消灭传统意义的软件测试专职人员?

  • 如果能,软件研发是怎样的一道风景?
  • 如果不能,软件测试或QA的地位是不是会下降?

DevOps这个名字绕过了“测试”,也许是对的,更强调“质量是构建的”。但做测试、做QA的人们一定会有意见,希望将DevOps改为DevQAOps,以纠正DevOps忽视QA的问题,有没有这个必要?甚至有没有必要增加一个新术语TestOps?可能都没有必要,彻底的DevOps也许是未来研发的趋势。

 

1.  适合采用DevOps的企业,传统意义的软件测试人员可以消失吗?
 

这完全是有可能的。Google、微软和一些欧美公司等的实践证明这是可行的。他们去掉了专职测试人员,没有“TestEngineer”角色,而是采用测试开发工程师 (SoftwareDevelopment Engineer in Test, SDET) ,或干脆像微软公司那样都叫软件工程师(Software Engineer,SE),你要知道,2014年前,微软公司还有一万多专制的测试工程师,而今天他们已经消失了,成为软件工程师。Google的SET (Software Engineer in test) 实际上也是一个开发角色,谷歌在我国有几百研发人员,但测试开发只有几十个。他们(SDET、SE、SET等)做的事情已经不同于传统的测试人员所做的事情,而是:

  • 开发测试工具,搭建和维护测试环境和测试框架;
  • 把不同层次的自动化测试集成到CI pipeline,改进和维护CI pipeline,维护整个研发的基础设施;
  • 指导开发使用这些测试工具或测试框架
  • 组织和指导团队制定自动化测试策略
  • ……

除此之外,SDET对软件开发的了解往往集中在可测试性、健壮性和性能等方面,基于这些理解,构建框架服务于整个团队。开发人员不仅做单元测试,还用SDET搭建的测试框架做系统测试、做手工测试,开发团队遵循持续交付和持续集成的原则,拥有独立的CI pipeline,借助良好的架构每个开发人员做的每个任务都不大、都可以通过这个CI pipeline独立发布,所有代码都会经过CI pipeline、再经历code review,最终合并到主干(master branch)上。总的来说,开发人员是自己写的代码的质量的主要负责人,也就是将之前的QA、Quality Engineer或测试的角色分配给DevOps团队,让每个成员承担起来。

之前,开发团队的每个任务只有通过了测试才能发布(release),但是问题来了:一个测试人员应对多个开发人员,质量问题很可能就落到这个测试人员身上,例如一旦发现上线遗漏bug,大家的第一反应是为什么QA(=测试)没有找到。这种情况漏掉比较多的Bug也比较正常,因为很难进行充分的测试。如果要充分测试,测试速度上不去,很容易成为瓶颈,无法实现快速交付。许多情况下,要么质量得不到保证,要么干得很苦。总的来说,过去那种做法(设置“测试工程师”角色)不利于整个团队作为一个整体提高质量意识、质量监控和测试能力等等。

在敏捷方法持续集成的环境(如基于Jenkins 完成全过程的自动调度)的基础上构建DevOps的研发、部署全生命周期自动化环境(如基于容器技术平台Kubernetes平台),向团队提供一键式DevOps测试环境和测试数据分析的解决方案,提供适应DevOps的统一的测试自动化框架和质量管理平台,在整个软件生命周期软件质量状态(如qualitydashboard)能够一目了然。

如果觉得不放心,如果团队还不够成熟、或者说团队测试能力还不够,可以在团队设置一个“测试教练(Testing Coach,TC)”、“测试顾问(Testing Consultant,TC)”或“质量助理(Quality Assistant,QA)”,他的主要任务包括:

  • 参与前期需求分析和定义验收标准
  • 帮助团队提高整体测试技术和知识
  • 帮助开发人员制定测试策略(策略执行还是团队)
  • 定期组织exploratory testing session(bug bash)
  • ……

现实中开发人员能力不够,不喜欢做测试,这就需要培养这种新的、敏捷/DevOps的质量文化,不断通过教育/培训、绩效考核加以引导。在招聘新人时,也要考察应聘者是否具有质量意识、是否愿意花时间提高自己写的代码质量。而且告诉他们来这公司需要自己测自己的代码。

其次,面向接口的编程、微服务架构等实践可以让自动化测试容易开展,使被测对象具有很好的可测试性,自动化测试快、效率高,自动化测试的覆盖率也很高,这样开发就比较容易接受测试工作。之前谈到,测试开发SDET会关注可测试性、健壮性和性能,这样自动化测试就有一定保障。但是,总有一部分UI测试需要手工进行的,这就需要团队在后期一起参与做测试,通过缺陷大扫除活动(bug bash session)来完成。

最终能做到这样,需要管理层和研发人员的共同支持,从上到下、由下到上形成合力,才能做到真正的“将质量构建于产品之中”的研发过程。

2.    测试会慢慢成为一项锦上添花的工作?
 

靠自动化测试、缺陷大扫除这样的实践,软件质量还存在较大风险。没有人工智能(AI)的、传统的自动化测试发现缺陷的能力还是很弱的,而且当我们把主要精力放在技术、自动化上面,就很有可能忽视业务、忽视用户的需求。如果采取ATDD、BDD实践,情况会有所改善,但是对于复杂的业务逻辑,ATDD/BDD就会面临较大的挑战,这时就需要专业的测试人员进行业务层、端到端的测试。单元、功能没有问题,不能代表系统能够完全满足业务的需求,而系统满足业务的需求才是终极目标。

其次,开发人员测试自己的代码或程序,会有心理障碍、思维障碍。如果开展TDD测试实践,测试在先、开发在后,这种障碍就不存在了。但现实中几乎难找到全程以TDD方式开发产品的公司。当然,开发人员也可以进行交叉测试,这时候,在短暂的时间区间内,开发人员在扮演专职测试人员的角色,也就是说,一个软件工程师经常交替扮演开发人员、测试人员等不同角色。

再者,软件开发的各项工作都是专业的事情,软件测试也不例外。每个开发人员能做测试,这有信心。但让大多数开发人员成为高水平的测试能手,依旧困难重重。许多开发人员的一项工作做得不够好,要把两项工作都做得很出色,就更困难。过去也是这样,但质量多了一道守护——专职测试人员的系统测试,质量会有一定的保障。对于极少数优秀的开发人员,的确可以相信,测试促进开发,开发促进测试,两者相辅相成,将开发和测试溶于一身,反而是有利的。

当我们说,质量由团队负责,从我国国情看,质量可能就没有人负责,有时还需要一、两个QA、TC或质量助理专职人员,他们全程监控研发过程,帮助开发人员消除不规范行为、尽可能避免产生缺陷,尽一切可能来评价系统的伸缩性和性能,不断寻求机会提高代码的可复用性和可预测性,积极影响开发的质量意识,和团队一起防止缺陷进入实际的运行环境中,在整个开发周期中进行质量跟踪、持续改进质量。这种预防,不仅是产品缺陷预防,而且包括过程问题的预防,持续揭示产品质量风险、改进软件研发和运维的过程。

从这些角度看,少量的专职测试人员暂时还离不开,特别是对质量有更高要求,希望获得更好的客户满意度。

3.    如果AI再助软件测试一臂之力,多数专职测试人员还可以回家
 

过去,我们谈到探索式测试,觉得这必须由测试人员亲自动手来做,正如前面所说,传统的自动化测试(TA)发现缺陷的能力比较弱,而人类测试工程师具有创造性,能够举一反三,能够不断深入探索下去。但是,随着AI的越来越多的应用,赋予传统的TA工具的智能特性,就有可能超过人类测试人员。虽然工具(这里指测试机器人)可能再优秀不能超过顶尖的测试人员(不到20%,也许只有5%),但完全可以超过80%~95%的普通测试人员。在今年举行的人机大赛中,差不多就证明了这点,稍微具有一点AI能力的单元测试工具evoSuite打败了绝大多数人类选手,虽然它最终输给最优秀的人类选手。

刚开始,人类选手需要较长学习时间,干不过任何工具


(这几位优秀选手都是很优秀的,他们是从几千个选手中选出来的)

很快人类选手打败随机测试工具,但还干不过低智能的AI工具

顶尖的人类选手可以打败低智能的AI工具

在之前,我将软件测试定义为一个公式:

过去,也许你还认为,有一块自留地(未知领域)交给我们手工测试(探索式测试),当我们引入AI技术之后,连这块自留地也不给人类测试工程师剩下,可以彻底实现完全的自动化。

前两天在中兴测试技术大会上分享了App游戏的UI自动化测试——借助蒙特卡罗树搜索算法、增强神经元网络算法,进行150次模拟后,就能够超过人类的游戏玩家。

今天,AI不仅可以模拟人工操作,而且还能应用到测试的其它方面,包括测试数据的产生、测试Oracle的建立。不仅可以进行功能性测试,而且可以进行安全性测试、可靠性测试。正如Gartner告诉我们,到2020年,普通人与机器人的交谈会比与他们的配偶更多!留给我们测试人员的时间只有三年,三年内必须转型,成为AI不能代替、更具智慧、创造性工作的专业人员。