• 0
  • 0
分享
  • 我为何从开发转测试,并坚持了16年?——软件测试圈
  • 曼倩诙谐 2022-12-05 11:17:15 字数 3499 阅读 869 收藏 0

  51Testing行业调查问卷正在进行中,填问卷领价值398元的测试课程,参与一下吧~ 链接:http://vote.51testing.com/ 


  聊到自动化测试,我们做 GUI 自动化测试的过程当中,以前就只要把这个自动化做起来就好了,但随着你的用例,用的数量越来越多之后,你不单单是把一个场景自动化就可以了。因为随着你的用例变多之后,你所有的用例设置,包括你的代码的结构,都要考虑这个东西的可维护性,因为可维护性一直是 GUI 自动化测试很大的一个痛点。我们在后面的 GUI 测试过程中,就会去考虑,怎么来做分成?怎么来做基于可重用的脚本?怎么来做基于页面的对象模型?甚至到后面还有 BDD,就完全是业务,用户行为驱动的这种测试。那么,从这些概念当中,可能你已经听出来了,不管是你之前有没有接触过这些概念,你都能够发现一个很重要的信息点,自动化测试没你想的这么简单,也完全不是一个简单的录制,或者回放。

  所以说,我自己当时在转型的过程中(从开发转向测试),我就是看到了这些点,觉得这里面的学问,或者说可以做得东西,尤其在当时的大环境下,是非常多的。因为当时没有人去做这块,而且当时是没有有开发经验背景的人会去专门做这一块的东西。我也是看中了这样一个机会,后来事实证明,转型并没有错。

  随着时间的发展,后来就越来越证明整个自动化测试到后期的一些基于 API 测试,或者现在很多一些新的测试技术越来越多,而且整个测试地位也越来越高,从早年的并不受重视,或者是一些比较弱的开发去做测试,到现在一个优秀测试工程师可能是比一个开发人员更懂开发代码。因为如果他不懂代码,或者不懂开发是怎么来做得,你让他怎么去发现开发当中的一些问题?这个过程是相辅相成的。

  其实我们很多测试已经分为了三大块。

  一块是 所谓的传统意义上的基于业务功能的测试, 基于手动测试,或者现在非常流行的,基于探索式测试,也就是说基于一些错误猜测,以及基于一些你做了哪些测试,你假定哪些地方有可能会出错,而且做进一步测试,这样一个过程,所以说这是一部分做业务测试的同学。

  那么 第二块是做自动化测试的同学, 自动化测试的同学对业务了解程度并不是很深入,但是他所做的事情是把一些手动的脚本,很方便得把它翻译成一些自动化的脚本,可以让机器去执行,那么他的主要技能是主流的一些 GUI 的 Framework,比如说现在主流的像 Mobile 端的可能就是 API,或者是不同框架的这种自动化开发技术,这是第二类。

  第三块是很大的一块,就是现在意义上的叫测试开发。 测试开发并不是传统去做自动化用例的开发,他会去做一些测试平台、测试服务,或者一些测试基础架构的开发。你可能会问,这些基础架构包含什么东西?我可能举两个例子,你可能就知道了,你现在要跑测试,你要跑一个 Web 端的,或者跑一个 API 手机上的一个 Mobile Native 的 app 测试,你肯定一定要有执行环境,你如果是手机端的,你一定要有手机,要有安卓的 Device,或者有 IOS 的 Device,去让你跑这些测试,那么这些手机你怎么来?单个来拿吗?你肯定会去建一些机群,甚至建一些私有云,像国外的 Lab 服务,其实包括国内的一些其他服务器,类似云测的服务,就是把这些设备集中在一起。

  那么这部分工作是谁做的?就是现在的测试开发去做。

  软件测试对于学历的要求高吗?

  茹炳晟:反问下大家,你在学校里面学的东西是什么呢?你真正去看,学校里面出来,你上了工作岗位之后,学校里的东西立马能用的有多少?我觉得基本上是在 10% 以下的,所以说我觉得学校里面学的是什么呢?我个人认为更多学的是一些思想方法,就是说你面对一项新事物的时候,你会用什么样的方式,如何在很短的时间内用自己的方法,把整个这件事物的来龙去脉搞清楚,并且你能够接受它并且你能够运用它,这是个很重要的点。

  所以说跟学历没有必然的关系。像乔布斯这种公司,它不注重你的出生,或者你是从哪个方面去做这个事情,他看中的是你的思维方式,你的能力。 这又让我想到另外一个点,现在讲到面试,我个人是十分反对刷题的。 因为我们碰到过一些同学,面试过程中,你给他一个算法去做一下,如果他能立马给出一个最优解,那这个肯定是有问题的。因为我的理解,正常的情况下,你不可能一下子就找到这么一个非常好的最优解,你能找到这个最优解的前提一定是你之前看到过这样的算法,或者是你看到过这样一个最优的解法。

  我们想看到的是一个什么样情况呢?你不是给我一个最优解,而是你给了我一个方法,这个方法不一定完美,但在我们的引导下,你逐渐把它完善,逐渐发现你这个算法的问题在哪里,哪些地方可以去做更多的改进,然后把这个算法逐渐变完美。 这个是我们想看到的,我们是想看到的是你在面对一个有挑战事物的情况下,你是怎么把一个大问题化解成一个小问题,每个小问题又是如何去解决,最终解决这个大问题,解决了这个大问题之后,再去回顾一下,你在解决这个大问题的过程当中,有哪些地方是可以改进的,是可以优化的。我们是想看到的是这种过程,所以是这样一个情况。

  去 QE 时代,测试工程师该如何修炼?

  茹炳晟:首先我想先解释一下,什么是“去 QE”。“去 QE”这个概念在国内还是非常新,但是在一些像 Facebook、Google、Ebay 这样的公司,已经都在做这些事情,而且有很多都已经真正落地了。首先我先表明我的一个观点,我并不是“去测试”这样模式的推崇者,因为去不去测试根本的原因不在于说,你觉得能不能去,而是完全取决于你的组织上下文、你的组织成熟度、你成员的水平、你工具的成熟度、你的体系、你的上下文、你生态的成熟度。

  那为什么 Google 能做?

  因为 Google 拉任何一个测试工程师出来,直接去做开发是没有任何问题的,但在国内,你让测试去做开发通常是比较难的, 所以你面对的上下文、面对的环境,差异性就非常大。这种情况下,你说去 QE 一定好,或者去 QE 一定不好,都是没有一个定论的。

  我的观点在于,并不是一定要说那个好,而是我们应该面对一个特定的项目,或者面对某一个组织,我们怎样去两边取各自的长处,两边去各自的短处,有机地结合在一起。这也就是现在所谓的“去 QE”,就是“没有测试工程师,开发自己做测试”这种架构。

  那么哪些情况下是适合让开发自己去做测试的?哪些情况下还是需要一些专业的测试人员来做测试的?

  传统的测试策略,更多的是一个金字塔模型,也就是说 UT 会做的比较多,中间层,像 API 的集成,或者是集成测试会做的相对少一点,最上层的 UI 一般是更少,是个轻量级。

  但在现在互联网的时代,尤其是一些去 QE 的公司,他是怎么玩儿呢?他会把整个三角形变成一个类似于菱形这样的一个架构,也就是说 UT 这块是非常的少了,中间层,API 这一层,由于微服务化,这层会非常的厚,上层的 UI,会做的相对比较少,而且更会去做端到端的,面向对终端用户的这种测试。除此以外,这个菱形的顶上还飘了一朵小的云,这朵小的云就是现在非常流行的 ET,也就是所谓的探索式测试。

  没去 QE 之前,整个架构是金字塔,底部 UT 是开发做,API 测试跟 UI 测试都是测试人员来做,但是在去 QE 之后,是什么样的一个架构呢?UT 开发做,API 测试也是开发做,UI 测试还是开发做。 唯一是测试人员可以做的是哪里呢?是顶上飘的那块小云,也就上面那个 ET,探索式测试。 因为这一块需要更多的是一些发散性的思维,而且需要你对业务有非常好的理解。这还需要你除了理解业务外,还要明白产品内部的一些实现,以及它的架构,才能比较有针对性的去做一些探索性的测试。

1-1.jpg

  面对这样一个大的变革,你可以看到有点类似于把测试上移了,就是你原来的测试工程师只是做上面的 ET 部分,但是原来的那些像下面的 API 测试,或者 UT,或者基于 UI 测试,这些测试谁做呢?由开发做,但是由开发做不表示这个活没有,测试这个活还是在的,只不过是换了一批人去做这个事情,本质上并没有根本性的变化。根本性的变化就在于可能从组织架构的角度来看,现在可能不再有集中的一个测试团队了,这些负责测试业务的测试工程师会打散到各个开发团队里面去,而且他承担的角色也不一定是全职的测试,他有可能会做一部分开发,也会去做一部分的测试。



作者:佚名    

来源:http://www.51testing.com/html/11/n-4478011.html

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   测试人员应该为项目做什么?这可能是每个测试人员都会思考的问题。  角色是一种关系,虽然你不能控制自己的角色,但可以控制自己角色锁承担的职责。只有清楚了自己的角色,才能给自己的角色设定合理的期望值。并且在因为产品质量问题受到责(背)备(锅)时,进行反驳。  那么,测试人员应该如何正确看待自己的角色呢?  测试人员服务多个“客户”  测试是一个服务角色,服务意味着客户,你的成功主要取决于你如何满足客户的愿望和最大的利益。  而测试人员有很多“客户”,在项目开发中,你的客户主要是“项目经理”、“开发人员”和“终端用户”。他们都有自己的需求,而且他们的共同需求不一定一致:  项目经理  指导项目是...
            0 0 1226
            分享
          •   苹果公司已经批准了UTM SE,这是一款用于模拟电脑运行经典软件和游戏的应用程序,几周前苹果公司拒绝了这款应用程序,并禁止它在欧盟的第三方应用程序商店进行公证。但现在,这款应用程序现在可在 iOS、iPadOS 和 visionOS 上免费使用。  今年 6 月,苹果公司拒绝了这款应用,开发商表示不会继续尝试,因为这款应用"体验不佳"。 今天,UTM 感谢 AltStore 团队的帮助,并称赞另一位开发者"其 QEMU TCTI 实现对此次无 JIT 构建至关重要"。  UTM SE 不包含任何虚拟机,但可以帮你找到它们。  与App Store 上...
            0 0 485
            分享
          • 1.移动APP安全风险分析*1.1安全威胁分析安全威胁从三个不同环节进行划分,主要分为客户端威胁、数据传输端威胁和服务端的威胁。1.2面临的主要风险1.3Android测试思维导图1.4反编译工具有两种反编译方式,dex2jar和apktool,两个工具反编译的效果是不一样的,dex2jar反编译出java源代码,apktool反编译出来的是java汇编代码。dex2jar主要是用来把之前zip解压出来的classed.dex转成jar包的jd-gui主要是用来打开Jar包的2本地客户端安全2.1反编译保护2.1.1问题描述APP源代码对于一个公司是非常重要的信息资源,对APP的保护也尤为重要...
            0 0 779
            分享
          • 引言谈到性能测试,部分公司连专门用于性能测试的环境都没有,更别提性能测试框架/平台了。下面,笔者就“基于Jmeter的性能测试框架搭建”这个话题,谈谈自己的一些想法。 工具Jmeter Influxdb Grafana Telegraf Jenkins Ant Gitlab理念测试人员只需专注脚本编写及性能结果分析。脚本提交Gitlab后自动触发构建,性能结果实时展现。 性能测试脚本统一管理。   实现方法依赖Jmeter的Backend Listener监听器及Telegraf,采集tps,响应时间,cpu,内存等信息至Influxdb时序数据库,然后再通过Grafana展现性能...
            1 3 3108
            分享
          • 最近在工作中协助研发进行了ES优化,效果还是非常明显的,几乎翻倍。除了通过各种业务接口测试ES性能以外,还可以直接请求ES接口,绕过服务,这样应该数据回更加准确。所以,ES Client学起来。准备工作首先,先准备了一个ES服务,这里就不多赘述了,大家自己在尝试的时候一定主意好ES Server和ES Client的版本要一致。 其次,新建项目,添加依赖。学习资料搜一下,能搜到很多的ES学习资料,建议先去看看大厂出品的基础知识了解一下ES功能。然后就可以直接看ES的API了。 下面是ES官方的文档地址: https://www.elastic.co/guide/en/elasticsearch...
            0 0 2302
            分享
      • 51testing软件测试圈微信