• 0
  • 0
分享
  • 什么样的测试工程师更受HR青睐?——软件测试圈
  • 曼倩诙谐 2021-07-29 10:57:30 字数 2393 阅读 1830 收藏 0

  同样是测试人员,交代的任务也能按时完成,为什么受欢迎的程度会有所不同呢?

  先来说说不同的测试人员有什么不同吧。

  责任心不同

  对于一个测试人员来讲,责任心是很重要的一点。既然你测了这个功能,那么就要对这个功能负责,不能说是大体测测就完了,需要考虑各种可能出现的情况,以防意外的发生。作为测试人员要对整个功能负责。

  举个例子来说,一个需求上线至少需要两个以上的测试人员共同测试完成之后才能更新到生产环境,当这个需求在生产环境上出现了问题,影响了正常的操作流程,那么有的测试人员会立即利用现有的错误数据,看有什么特殊数据或者操作,尽量快速的去复现这个问题,并交给开发人员去解决这个问题,尽快的更新到生产环境以免影响更多人的使用。

  而有一种人,遇到这类问题,就会立刻想着怎样将责任推卸出去,如何把自己从这个问题中摘出来。

  工作方式不同

  有些测试人员善于使用工具提高工作效率。一些重复性的工作,比如版本的回归测试、基础数据的增删改查测试,都可以通过自动化来实现。

  比如我们拿到一个表单的测试需求,其实逻辑很简单,但是重复性的工作很多,完全靠手工操作的话,不仅浪费时间,而且容易产生厌烦心理。

  但是如果我们将测试数据整理出来,利用自动化测试的工具,将测试数据进行参数化,那么可以极大的提高工作效率,这样既可以避免人工测试过程中的一些误操作,使数据更加准确,又节省了测试人员手工测试的时间,可以利用这些时间来研究其他工作。

  沟通能力不同

  作为一个测试人员,最基本的沟通能力是必须具备的。

  因为我们可以通过有效的沟通来解决测试过程中遇到的一些问题。

  就拿小编自己来说,我经常会遇到这种情况,就是发现自己对这个需求的理解跟开发人员实际做出来的功能有出入,那么我会怎么做呢?

  遇到这类问题,我首先会跟开发人员沟通,看看究竟是自己理解错了,还是开发人员理解错了,或者是开发人员理解没问题,就是代码写错了等等这些情况都有可能出现。

  我们在不断的沟通中能不断的发现该需求可能存在的隐藏的问题,或者通过沟通,发现对这个需求的理解更近一步了。而且通过有效的沟通,我们跟开发人员的关系也能更近一点。

  但是我发现有的测试人员,遇到这类问题,总是一遍遍的看需求文档,从不与人沟通,如果确实是开发人员的问题,也不能及时的反馈给他们,影响工作效率。

  自主学习能力差异

  一个有上进心的测试人员,在满足当前工作要求的基础上,会不断的学习新的技能。

  比如学习一些自动化的测试工具或者性能测试工具,目前可能用不上,但谁又能确定未来的工作会不会有这方面的要求。

  退一步来讲,如果我们多了一项技能,就算以后跳槽的话,也多了一项加分项。

  但是对于那种安于现状的人来讲,觉得当前的技能已经能够满足当前的工作需要,觉得不需要也不想花时间来充实自己,这样的工作态度对以后的发展也没有好处。

  当领导提出自动化或者性能测试要求时,发现一点头绪都没有,因为自己并没有花时间去了解这方面的知识。

  举个例子来说,其实在项目的不同阶段,工作强度也是有差别的,有时候项目交期紧,我们必须全身心的投入到项目中。

  当然也有项目比较空闲的时候,这个时候,有些人就会想,终于可以放松一下了,刷刷视频,上上网,一天就这么过去了。

  但是有上进心的人呢,他们都在干什么呢?主动学习新工具,新语言,不断的充实自己,为之后的工作奠定基础。

  对bug敏锐度的差异

  一般来说,经过了多个项目的测试之后,如果是一个优秀的测试人员,拿到一个需求,在经过简单的了解之后,会对一些经常出现bug的点有一定的感知能力。

  因为在过往的测试经验中,会不断总结容易出错的点,并对出错频率比较多的点多加注意,在之后的测试中也会着重的去关注这些地方。

  而对那些得过且过的人来说,测试对于他来说只是完成任务,并不会去总结什么,以前漏测的点现在还是会漏掉。

  例如,我们今天拿到一个测试订单下单流程的需求,根据以往我们对这种需求的了解,发现以前在测试这种需求的时候,在编辑订单的时候,我们所选择的某些订单信息并没有正确的显示,或者是我们编辑订单时修改的信息,并没有实际的更新到订单中,那么现在在测试这个需求的时候,我们就要对这两个点着重进行测试。

  准确复现bug及给出合理建议

  作为一个专业测试来讲,遇到问题时会准确的复现出bug并且找出bug复现的最小条件,从而利于开发人员准确快速的定位问题所在。

  而且在测试过程中,会根据实际情况提出一些合理化的建议,来增加使用的流畅性和客户的满意度。

  但是对于一般的测试来讲就是拿到需求后完全按照需求来测试,并不会考虑这样做合不合理,客户使用起来方不方便,只要完成任务就行了。

  在小编自己的日常工作中,会给开发人员提各种bug,有些bug比较简单,有些bug比较复杂。

  当我用一个复杂的步骤复现了一个bug之后(bug复现条件及步骤:条件1,条件2,条件3;步骤1,2,3,4......),我还会考虑,是不是只有这么复杂的操作才会导致这个bug的产生?

  如果我去掉几个条件,这个bug还会不会出现?经过反复验证我们发现,复现这个bug的条件和步骤只剩下几个(bug复现条件及步骤:条件1;步骤1,2,3)。

  这样经过我们的筛选,去除了不必要的条件和步骤,开发人员会更快速的定位到问题所在。

  通过上述对比,大家应该很容易就看出哪类的测试更受欢迎了吧?当然是有责任心,沟通能力强,善于花时间提高自己的更受欢迎。所以希望大家在以后的工作中,要朝着更好的方向发展。

  当然世界是公平的,你想享受什么样的待遇,就要付出同等的努力,工作是一个积累经验的过程,也是一个不断学习的过程,只有在这个过程中不断的充实自己,才能得到自己想要的结果。



作者:CICI   

来源:51Testing软件测试网原创

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 案例设计需求有一个ATM取款系统,现对于取款功能进行了需求变更:只能取面额是100元(如取500,输出5张100元)。现在功能修改为,可以取面额是10元、50元和100元的,其余功能不变,用户界面也没有任何变化,取款原则为“最优吐钞法”,有大额先吐大额,请根据需求变更进行案例设计。参考测试用例大额优先刚好整百的金额,吐出N张100元的刚好为50元,吐出1张50元刚好是50以内的整10元,吐出N张10元取款金额是N百,超过50元,吐出N张100元,1张50元,(M-5)张10元(例如380元,会吐出3张100元,1张50元,8-5张10元)如果是几十元,同时超过50元。那么会吐出1张50元,M-...
            0 0 1124
            分享
          • 在学习测试理论基础时,相信大家都曾看到这个问题“请说说软件测试分类”,其中一个答案就是:按测试阶段,软件测试可分为:单元测试、集成测试、系统测试、验收测试。那么,单元测试?单元测试?什么是单元测试呢?最初作为一个对单元测试毫无概念,对单元测试的了解仅限于官方简介说明,且只会if else基础语法的初学小白而言。觉得单元测试肯定是需要强大的代码能力,是那种能写上千万个字符代码的资深码农才会的技能。后面学习了测试开发课程后发现,其实单元测试从某种层面上可以简单的说就是测试某个单元函数方法是否满足设计的测试。在前端界面未实现的情况下,通过写单元测试代码来调用测试这个函数。例如:开发写了一个求和函数,...
            0 0 2282
            分享
          • 普通的移动app是需要安装的,但是绝大部分的app不会经常使用,但仍然会占用手机存储空间,所以开始出现免安装app,微信小程序实际是一种免安装的app。类似的比如华为、小米等手机厂商推出的快应用、支付宝小程序。微信小程序实际是运行在微信之上。小程序的类网页经过微信翻译之后以http数据的形式和服务器进行交互。小程序无法脱离微信来进行使用。微信小程序的页面可以包含:1、小程序页面(WXML+WXSS)2、M页页面(H5移动网页)3、toast信息(过一段时间会自动消失的信息,比如登录成功的提示信息,1、2秒后自动消失)4、弹窗微信小程序功能测试微信小程序分为三个版本:1、开发版2、体验版(需要在...
            0 5 8008
            分享
          •   据报道,三星电子代工厂从日本人工智能芯片初创公司 PFN(Preferred Networks)获得了其尖端 2 纳米 EUV 代工节点的量产订单。据报道,这是 2 纳米节点的首个主要第三方订单。PFN 成立于 2014 年,专注于人工智能和物联网芯片,从 Preferred Infrastructure 分离出来。  三星的 2 纳米节点被称为 SF2,有望在 2025 年交付量产芯片,这意味着 2024 年的大部分时间都将用于测试、验证和风险生产,预计该节点将在年底投入使用。  与 SF3(3 纳米 EUV FinFET)相比,三星 SF2 的能效(等时钟)提高了 25%,性能提高了 ...
            0 0 1218
            分享
      • 51testing软件测试圈微信