51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1027|回复: 0
打印 上一主题 下一主题

[转贴] 硬实力和软实力,哪个对测试人来说更重要?

[复制链接]
  • TA的每日心情
    擦汗
    1 小时前
  • 签到天数: 1047 天

    连续签到: 5 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-8-4 09:28:06 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    说到测试或者测试工程师,人们的第一反应大概是“找碴”、“鸡蛋里找骨头”、“背锅侠”……
      其实这是对于测试这行的一个很大的误解。测试过程对于绝大多数行业来说是非常重要的一环,厨师在烹饪的时候会尝一尝菜品的味道,一栋楼在建造之前和竣工之后要进行检测,软件在发布之前也要进行很多轮的测试来验证软件的各项性能指标。
      作者从事多年测试工作,经历了对测试一无所知到略知皮毛,也对测试工作有了更深的理解。如何成为一个合格的测试工程师是一个很大的话题,无论从事这行的工程师还是研究测试的专家都在思考怎么进行更有效的测试,如何提高相关从业者的认知水平。
      如果有人问我是不是一个合格的测试工程师?这是一个很难回答的问题。从事多年的测试工作,不可否认会积累一些知识和心得,但因为测试中需要了解的知识很多,我掌握的知识还不足以证明自己是一个合格的测试人员,但还是跟大家分享一下多年来在测试工作中体会到的心得。
      硬技能
      依稀记得入职第一家公司时,坐在工位上把崭新的电脑开机输入密码后打开outlook,邮箱里很快收到好多邮件:第一封是经理群发的欢迎新员工邮件,剩下的邮件大部分是部门同事发的测试报告,我一封封的打开看,里面写的字我都认识,合在一起就不认识了,非常多的通信行业术语。
      看着这些邮件,自己新入职的喜悦瞬间消散,心里想着自己会不会不到试用期结束就被扫地出门。
      在这里,非常感谢当时招我进公司的部门经理,当时的我根本不知道通信设备是什么,更不要说通信协议。学校学习的专业是物理学,跟通信几乎没有交集。经理居然招收了我这个超级小白,到现在我也不太明白当初经理为什么会给我offer,他帮助我开启了通信行业的大门。
      在试用期部门会给新员工安排导师,在导师的帮助下以及公司提供的各种学习文档,很快就可以学着进行测试,测试过程中遇到问题可以查找相关文档,也可以向导师求助,他会帮着我解决。
      虽然不太清楚为什么要按照用例中的测试步骤进行测试,也不太明白为什么跟预期结果不符就是问题,但是起码可以进行初步的工作。
      当试用期结束,导师和经理经过评估终于接受了我这个“门外汉”之后就开始独立进行测试了。这时会遇到各种各样的问题,导师也有自己的工作,遇到问题就去找导师不可能也不现实。
      技术深度
      从此我就开始了一段记忆非常深刻的新员工之旅——测试过程中,我发现需要掌握的东西会越来越多、越来越复杂。
      这时,就需要自己来理清楚轻重缓急。先掌握在工作中用到的最主要技术然后再慢慢扩展到人际交往、情绪管理、心理调节等方面。
      在技术方面,测试中遇到技术问题时,最好的办法是在公司的资源库里去找,无论是内部网站论坛还是文档库里,总会找到类似问题的解决办法。
      有一句话说得好:并不是你一个人遇到这种问题。做测试需要一定的广度,通俗来讲就是什么都要会一点。
      举个例子,实验室需要重新搭一套全新的测试环境,从设备的安装到调试全流程需要自己来处理。
      首先找到设备的说明书和安装调试手册,然后按照步骤一点一点进行下去。在这期间会遇到各种各样的问题:设备间需要使用交换机来连接,要配置VLAN、路由。为了解决问题,就要问熟悉相关配置的同事。
      提示一下,有些配置最好找相关的同事,因为配置不好的话不仅会影响自己负责的设备,还会涉及连接到同一个交换机上面的设备。
      把硬件安装好以后还要确认需要安装的软件版本、从什么地方能得到软件、如何安装、如果安装失败后要采用什么办法重新安装……
      当硬件、软件全部安装好以后要进行调试,包括配置各种参数,配置成功后要进行业务的调试等步骤。基站设备有非常多的参数,如果一些重要的参数没有修改正确,业务根本做不起来,更不要说测试用例
      这又是一个很考验工程师的地方,虽然有参数模板可以参考,但是有些参数是不可能全盘接收。在不断地尝试、厚脸皮问有经验的同事的过程中,了解到整个设备的运行和调试流程。
      以上步骤完成,就可以开始测试用例,基本也是一路问,一路查的节奏。从开始一天只能测一到两个用例到后来增加到四个五个或者更多……
      这就是一个新手要经历的过程,没有任何捷径能走。
      技术广度
      大约经过一年左右的时间,我们已经熟悉了测试工作中的流程,面对测试中的问题,逐渐有自己的见解和解决方法,也开始对工作中涉及的一些感兴趣的技术进行深入的研究。
      当然这个兴趣点最好是工作当中会频繁用到的,毕竟我们需要提升工作业绩来展现自己的价值。比如对编程感兴趣,那不妨继续学习下去——进行自动化测试的前提是有自动化的脚本,而写脚本的前提是要求工程师有一定的编程基础。
      再比如热衷于通信协议,那也请坚持学习下去,通信相关的协议非常多,只要把一种类型的协议精通了,大概率会成为牛人。
      在我认识的一些技术大牛中,表面上看他们貌似只对一门技术很精通,其实他们对其他的技术也非常在行。
      每一种技术是不可能单独存在的,在学习中间会遇到其他的技术问题扩展开来后会接触到更广阔的技术面。新技术也好旧技能也罢,他们之间一般都会有相关联的知识点,只要抓住核心的逻辑就能触类旁通。
      在测试工作中我们还会接触到用例设计、用例评审、测试方法等等问题。由于篇幅所限,就不在这里一一展开了。以上每一个话题都可以作为一个很大的专题来讨论,学术界和工业界对它们的研究一直没有停下,这方面有很多的书籍和文章可以供大家参考。
      软技能
      沟通能力
      在测试过程中技术层面相对来说比较简单,只要我们肯下功夫,大部分技术都可以掌握,相对来说一些软技能则需要更长时间的锻炼,比如交流沟通能力。
      这个技能在工作中会起到很大的作用。工作中我们需要与不同角色的人交流,包括同事、组长、直属经理、其他部门同事……
      对于同一部门的同事,无论是老员工还是新员工,大家的本职工作都是测试,在工作中互相帮助,八小时之外有可能会成为要好的朋友。
      在测试中如果遇到问题,应该马上跟组长或者直属领导汇报,毕竟一个小问题有可能会酿成大事故。
      这个不是危言耸听,因为测试工程师、组长、经理看待问题的角度是非常不一样的:
      工程师可能只关心今天测了多少用例,通过多少个失败几个;
      组长看到的是他负责的某一项大功能是不是有问题;
      而再高一级的经理或者更高职位的主管,他们看到的是整个项目状态的变化情况。
      所以遇到问题需要及时的沟通,也许你只是看到大楼少了一块砖,其他人却看到整栋楼都歪了。在测试中发现问题后,第一时间要找的人大概率是对应模块的编码同事,需要找这位同事确认是不是问题。
      在找对应的编码同事前,第一步要确保测试步骤是正确的。要证明别人的不合理,首先确保自己的操作是合理、遵循规范的。
      第二步是测试期间一定要保存log。详细的log有利于分析和定位问题,如果是一个可复现的问题,log可以重复抓。但是对于一些偶发性的问题,这一次没有抓到log,没有人会预测到这个问题什么时候才会出现,这会引发版本的隐性风险。
      确保这两步做完,我们就可以找编码同事确认问题,也许交流过程会很轻松,也许会出现争执,这个时候要尽量保持冷静。我们要明确的一点是:测试和编码的目的都是为了项目。
      我们在与对应的开发同事交流时,双方交流的焦点最好是集中在问题上而不是一些情绪上面,起码有一方是在关注项目,这样会减少很多交流上面的内耗从而集中精力来解决问题。
      心理状态
      心理状态也是测试工程师必须了解的一个方面。工作中难免会遇到各种各样的问题,比如问题无法复现、与同事的争执、加班太多……种种的问题都会扰乱我们的心绪,情绪越急躁,越没有办法稳妥的处理事情。
      以我自己为例,测试工程师的前几年我非常热衷于找bug,原因是我觉得如果找不到bug,是一件非常丢脸的事情,以至于自己提了很多bug,但是有效bug的数量其实并没有显著的提高,自己陷入了认为测试的价值在于不停的提bug的怪圈。
      渐渐我发现以上的做法会使自己和其他同事忙于应付源源不断的bug。当我把心态转变为注重质量——即一个高质量的bug,比提十个无效bug要有用,自己的心态会很轻松,而且也节省了公司的资源,大家可以把有效的工作时间聚集到真正的问题上来。
      在工作中也会另外一种情况:bug被提交后编码的同事会一次又一次的要求复测,原因可能是log抓得不全、怀疑测试环境有问题、还有觉得测试步骤不对……
      听到这些质疑,测试工程师肯定会觉得这是对自己的不尊重,潜意识里的想法是:我们是专业的人员,怎么可能会犯这些低级的错误?
      换位思考一下,大多数情况下编码同事也是为了确保这个bug是真正的问题,我们彼此不用为了一个无效的bug来做更多的无用功。
      如果我们测试方面多做一些,会为其他同事节省多一些时间,帮助他人也是在帮助我们自己。都站在自己的角度处理问题的话,问题会变得越来越复杂,然后事物性的问题慢慢会变成情绪性的冲突。
      很常见到的一个现象就是:一个小问题在邮件当中进行讨论,带入情绪以后邮件列表中渐渐加入彼此的组长、经理,甚至更高层级的领导。
      当我现在回想起来类似的事情,不禁会笑,也会反思,若当初大家都保持着就事论事的态度,问题会很快得到解决。
      在我们做过的很多项目中,最大的困难并不是技术层面,而是在交流沟通以及项目相关方之间的利益冲突上。如果后者出现问题,且没有处理好的话,再小的问题都会导致项目延期或者失败,给个人甚至公司带来损失。
      以上写了这么多,相信大家对如何成为一个合格的测试工程师需要具备的条件已经有了大致的了解:掌握技术的广度和深度、成熟的心智、熟练的交流能力,还有对项目的理解程度。
      我曾经的一位经理说过这样一句话:“看一个人适不适合这个工作,先要了解他的非技术能力。技术很好学的,普通人很快就会掌握一门技术,但是非技术能力才是更重要的方面。”
      现在的我更能理解这句话的含义:技术是硬技能,只要我们肯下功夫,在市场上见到的测试技术、工具或者编程语言都可以很快掌握,无论是通信测试、互联网测试,其中的逻辑都是相通的。把一件事情做到极致,与其相关联的其他方面也不会差到哪里。
      但是像沟通、心理调节这样的软技能则是需要不断提醒自己才会有一些改变。所谓江山易改本性难移,如果每次都做出一些小小的改变,那么会对自己的职业发展带来很大的提升。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-15 10:40 , Processed in 0.058890 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表