• 0
  • 0
分享

  有道是:“观史知今当思进退,读书养志可识春秋”。

  列数最近十年的重要进展,其目的还是要我们带着发展的眼光,来预测未来几年测试领域的发展,提前做好准备。

  所以为了让大家阅读此文后有尽可能强烈的获得感,本文行文结构如下:

  一、回顾软件测试发展的五个重要时期:

  ·1957之前 - 以调试为主:独自承担需求分析,设计,研发,调试,也就是Debug。

  · 1957-1978 - 以证明为主:确保程序解决它该解决的问题,证明软件是否符合需求,证明确实是有缺陷的。

  · 1979-1982 - 以破坏为主:在符合需求的情况下,通过异常测试的方法,明确软件应该做什么,不应该做什么。

  · 1983-1987 - 以评估为主:分析、评审、验证、确认。由测试评估产品软件是否符合需求质量。形成目前已知岗位雏形,形成独立的学科,制定软件测试国际标准。

  · 1988-至今 - 以预防为主:预防问题发生,从需求开始介入,贯穿软件开发生命周期。

  二、最近10年,测试领域的重要进展

  软件测试行业发展,受益于经济转型,产业升级,软件基础平台同云计算大数据相结合,测试行业在我国正处于高速发展成长期。

  最近十年测试领域用一句话总结:软件测试职位的发展逐渐细化。

  · 08到12年国内已经有的测试岗位分别是:功能测试、性能测试、安全测试、测试经理、测试总监。随着技术的发展,工种也变得越来越细。

  · 12到13年开始出现大数据测试工程师。

  · 14年多了python自动化测试工程师,及测试架构师。

  · 15年至今出现java自动化测试工程师和测试开发工程师。

  相对来讲不同的职位对应的薪资水平也不一样,目前对应平均薪资水平如下图:

1.jpg

  随着互联网逐渐渗透到国企,加上最近10年物联网的发展,软件测试在整个研发体系中,担负的责任越来越大,越来越被重视。

  那么这十年软件测试领域有什么重要的进展呢?

  我的结论:软件测试对整个产研体系内,协作效率的提升及质量内建。

  为什么会得出上述结论,讲述下依据:

  1、从个人过往的经验看,传统测试下,产、研、测、维,曾出现严重的部门墙

  以传统手工测试为例:相对于整个测试体系来讲是最基础的,同时也是最独立的。在整个产研团队中,都保持着特立独行的节奏。

  但在产研进行敏捷研发的今天,通过手工进行测试已经面临较为严重的效率瓶颈。比如,我刚从事测试工作时,测试团队常因为排期不同步,不断与产品、研发冲突。

  因为测试时间内,长期被临时插入的需求占用测试时间,上线后又面临持续复盘。导致测试周期长,发布频率低。比如手工测试过程中,往往研发5天开发量,到测试团队,测了半个月还测不完。

  长周期下,又会偶发需求调整,或者紧急插入新需求,导致无人力支持大面积回归,上线事故率高,潜在风险大,项目风险不可控。

  事故方界定不清晰,事故无法追责,导致产研各个团队中相互不信任加大。在下一轮需求展开时,往往在需求评审中进行扯皮,旧事重提,实施阶段各团队之间相互掣肘。

  当时我们总结经验教训后,采取如下措施:

  1)进行各部门团队建设,明确测试范围,测试分工。

  2)增加绩效考核标准,量化工作产出。

  3)完善准入准出规则,建立一整套提测流程,制定统一化的文档编辑标准。

  4)每天编写产出内容文档,流程中增加更多审批节点。

1-1.jpg

  以上措施就解决问题了吗?并没有,还衍生出了新问题。

  举例“增加绩效考核标准,量化工作产出”这个环节:规定测试团队个人,一天需要写多少条case,执行多少条case。还要求一次迭代至少要发现几个bug为达标,发现几个优先级高的bug为优秀。线上事故追责到个人,每次发版闹的人心惶惶。

  而在这一系列繁文缛节的流程背后,看似清晰有据可查,实际导致工作内容极其繁琐,产研团队之间嫌隙加大。

  产研团队彼此只追求考核目标,只关注需求文档本身,而忽略了实际业务,导致无共同目标,无效沟通增加。

  遇到事故,彼此在复盘中相互甩锅,互相指责,每次都像“律政俏佳人”一般在打官司。其实在无形之中不断挑起产品、研发、测试、运维部门的对立,形成部门墙。

  2、后来敏捷开发流行,传统测试团队曾是整个产研团队中的短板

1-2.jpg

  而逐渐流行的敏捷开发,导致研发迭代发布速度持续加快。但测试无法让手工测试效率也加快。因为对于测试团队来讲,每次迭代不仅要保证本次迭代功能质量,还要至少回归相关联的模块。

  提高测试效率,测试团队只有不断的加人。但加人不代表能够提高效率,也无法有效的保证质量。从而测试团队成为整个产研团队中的短板。

  随着业务高速增长、团队快速扩张的情况下,质量问题极易被放大化,如果不能及时得到处理,后续解决成本会越来越高。

  如何有效解决测试效率低的问题,成为了当时测试领域的重点及难点。

  3、配合敏捷开发,测试团队引入测试敏捷化思想

  通过敏捷开发的成功实践,测试团队也引入了敏捷测试的概念,目的是为解决以下目标:

  · 测试不再是独立于整个研发体系,而要和产、研融合,成体系化建设;

  · 建立和测试密切相关的:质量目标、流程规范、测试策略、实践标准等;

  · 做好缺陷分析,分析客观原因即可,无需追责到人;

  · 测试人员应尽早的介入全流程;

  · 敏捷开发模式下质量的保证需求

1-3.jpg

  为解决全生命周期流程的构建和执行能力,进行全阶段的持续测试,测试团队需要通过:自动化测试、持续交付、DevOps来实现。

  敏捷测试理念搭配自动化、持续交付、DevOps 落地分别解决的问题是:

  通过自动化解决迭代速度;

  通过持续集成去交付;

  通过DevOps来进行部署;

  自动化、持续交付、DevOps 落地后分别需要达成的测试目标是:

  全生命周期流程的构建和执行能力;

  使用各种自动化测试框架,同持续集成流水线相互关联;

  实时监控平台的搭建,对质量风险和严重缺陷进行智能预测和告警;

  4、为实现敏捷测试,当前中大型企业普遍流行的测试团队体系介绍

  1)思想上摒弃工作量化

  通过价值观体系的培养,将各个团队通过“组织”的结构形式,使彼此高效率协同。

  2)明确整个产研的质量目标,并让全体成员知晓形成统一共识

  以质量目标,驱动各个职能部门间的合作,增强全员对质量负责的意识。做好缺陷的预防。

1-4.png

  3)质量保证团队建设及组成

  · 外包测试团队:负责基础功能的测试;

  · 测试团队:手工测试、自动化测试、持续集成;

  · 测试开发团队:一种是跟业务的测试负责测试中台化,另一种利用测试技术赋能测试与研发团队;

  · 外部测试服务:提供对外的测试服务。

  4)质量保证团队的核心业务:

  · 前台验收测试:Web、App、Gui兼容;

  · 前台用户体验测试:性能、安全、电量、流量、稳定性;

  · 中后台功能测试:性能、安全;

  · 流程管理:持续集成、持续交付、DevOps;

  · 质量分析:监控平台、数据分析平台、Ai辅助平台。

  三、测试领域可预见的未来是怎样的?

  在可预见的未来,产研团队依旧遵循

  1)从产品提需求,开发实现,测试验证,运维部署原则。

  2)继续打破传统软件研发体系中的部门墙,让整个流水线更顺畅。

  每隔几年,产研团队会围绕产、研、测、维几个环节,在不断的摸索实践中,解决各自业务的痛点难点,拿出最优解,从形成新的概念和理念。而其中的本质上也就是要打通产、研、测、维这几个环节。

  所以,如何使测试团队提高测试效率,测试质量,将成为了测试领域重中之重。

1-5.jpg

  在持续集成、敏捷、DevOps时代下,对测试人才的标准也将越来越高。

  这也是为什么近些年测试领域职位,不断被细化的原因。

  这也是手工测试在当前,虽保持着独立化,但同时也在产研核心中被边缘化,面临被淘汰的命运。

  未来,只有掌握自动化测试,才能进入核心的研发流程中,牢牢占据敏捷测试这一环。只有这样才能完成整个研发流程的打通。

  所以在当前,对于测试人员来讲,学习自动化知识,转身走向自动化测试越来越重要。

  四、面对测试趋势,我们应该如何准备?

  毫无疑问,每个测试人员,都要立即转身奔向自动化测试,不要犹豫。

  若你是功能测试(也叫手工测试),应该立即学习编程语言,java或者python,学习接口测试,UI自动化测试,性能测试,甚至是测试开发;不然你离职后,还只会功能测试,那就很难再重新找到工作(不相信,你作为非应届生可以投简历试试)。

  若你是测试新人,千万不要止步于功能测试,还要继续学习编程知识(python或Java),学习接口、学习UI自动化....



作者:佚名    

来源:http://www.51testing.com/html/69/n-6657869.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 今天简单分享下,我们做的项目中碰到的一些相对经典的bug,这些bug的出现应该都不是偶然,大部分是开发人员的思维或者开发习惯不太好导致的。一、大bug 按照目前的开发模式很容易出现的问题,完全信任的话不容易发现开发思维是拿别人写好的过来用,有的时候不会细看需求,基本都是改改字段,但是别人写这个照片上传的时候没有可以同时上传6张的情况。所以他这块就有问题。二、小bug,开发理解的和产品想要的不一样产品的意思,0的时候就不要展示那个提醒,类似消息,没有未读消息的时候就不用展示数字,开发更干脆,直接把入口隐藏掉了。三、礼品卡这个版本,对于商品这块没有什么影响,但是对于原有的订单流程,很多改坏了。按照...
            1 1 12834
            分享
          •   微软公司昨日(10 月 9 日)发布新闻稿,宣布为 Microsoft Teams 应用推出新功能,限制和阻止前线员工在下班时间访问 Teams 账号。  前线员工(Frontline Worker)是指那些直接与客户、客户或其他服务对象接触的员工,他们在工作中不坐在办公桌前,而是参与到实际的操作中,例如超市的收银员、餐厅的服务员、医院的护士、快递员和仓库工人等。  援引官方新闻稿,微软概述了企业可能需要该功能的一些原因:  · 前线员工可能在工作时间之外访问工作应用程序,后续可能会以此要求加薪。  · 根据当地法律要求,限制前线员工在下班时间访问工作应用。  新的 Teams ...
            0 0 309
            分享
          • 常用的Android自动化测试框架包括UIAutomator、Appium以及Monkeyrunner等;其中,UIAutomator是谷歌在发布Android4.1版本时推出的一款基于Java语言的UI测试框架,由此,UIAutomator只能运行在4.1及其以上版本中。本篇文章将为大家介绍如何搭建基于Java+UIAutomator的测试环境。一、UIAutomator简介首先,作为Google自家推出的一款开源的UI自动化测试框架,其稳定性和可靠性可以得到极大的保障,运行时也有更多的权限。其次,UIAutomator可以跨进程操作,运行速度较快;但是UIAutomator不支持Andro...
            0 3 2955
            分享
          • 前言随着软件测试技术的发展,人们已经从最初的纯粹的手工测试转变为手工与自动化测试技术相结合的测试方法。近年来,自动化测试越来越受到人们的重视,对于自动化测试的研究也越来越多。背景项目版本功能日趋增加,系统模块越来越多,功能趋于完善,此一、外系统经常更新,测试人员无法满足多模块的测试需求,测试压力日渐增大,尤其在做回归测试时,无法确保每次更新后系统都得到完整的回归测试。一、自动化测试基础知识什么是自动化测试把人为驱动的测试行为改成机器执行,通过设计的测试用例,由机器按照测试用例的执行步骤对其进行自动操作,输出结果,由测试人员进行比较。自动化测试往往通过一些测试工具或框架,编写自动化测试用例,来模...
            2 2 3491
            分享
          •   欧盟将强制 iPhone 改用 Type-C 接口这事儿,想必这会儿都已经知道了吧?  起因是欧洲理事会批准了有关 “ 统一充电器接口 ” 的法案,要求从 2024 年底开始,欧盟地区出售的数码产品都必须统一使用 Type-C 接口。  这意味着不出意外的话,2025 年发布的 iPhone 17 大概率会用上 Type-C。  对此网友们当然是喜闻乐见,毕竟只用一根线就能给手机、平板还有电脑充电它不香么?  要知道无论是 iPad 还是 MacBook,它们如今都已经用上了 Type-C 接口,现在唯独就差 iPhone 迟迟没上。  至于原因么,不用我多说相信大家也都能猜得到,MFI ...
            0 0 861
            分享
      • 51testing软件测试圈微信