• 0
  • 0
分享

  前两天有个做测试的小伙伴加我微信问我测试相关的一些事情。

  她自己是从学习毕业就开始进入到互联网行业做测试的,到现在三年工作经验。她现在都不太敢跳槽,因为觉得自己没有什么核心竞争力,平常就是点点鼠标,看看有没有报错、结果和需求是否相符这样。

  其实很多测试人员的处境都是如此。

  造成这个局面的原因可以找到很多,大家经常会说的借口是:工作太忙,没时间也没精力。其实你自己去看看手机记录的屏幕使用时间。你平时有花里面30%的时间用来提升自己吗?

  测试相比开发的工作门槛和天花板都低一些,这也导致了一些想进入软件开发行业但是又对自己掌握开发能力没信心的人所做出的保守选择。

  但是如果后续自己并没有找到发力点去提升自己,那么的确很容易在工作两三年后就达到“巅峰”,碰到天花板。

  在聊我的建议之前,先来聊聊手工测试这个岗位的现状。从名字也能看出,这是一个体力活。一般手工测试也被称作黑盒测试,它是从产品交互的角度去检验软件是否符合预期。当然这里的预期除了是否符合需求原型之外,还有是否符合人的操作习惯。

  不过,现实是,有不少黑盒测试的人员,对「是否符合人的操作习惯」并不敏感,或者说不太关注。这其实是在给自己挖坑,因为这是证明你比别人优秀很好的一个途径。相反,对比是否符合需求原型是一些机械式的活,谁都能干,如果未来用AI来替代测试的工作内容的话,这大概率是首先考虑的。

  另一个现实是,不管多么牛、多么先进的公司都需要黑盒测试。因为它的前置成本比较低,无需过多的准备工作就可以开展。所以,在一些经常变动的功能或者新功能上运用比较普遍。

  总结一下现在黑盒测试的处境就是,上手门槛和天花板低,运用面广,每个公司都需要。

  想在黑盒测试的范围内如果要做得优秀,我觉得有两个方向可以走,「业务」和「体验」。而且基于这两个方向你可以平滑地延展自己的职业发展道路。

  /01 业务方向/

  每个软件系统背后自然是有一个逻辑来支撑的,这就是业务。对业务的熟悉度越高,你越能发现一些长链路上的bug,以及间接的关联bug。这样一来,你的测试质量自然相比其他人会更高,别人更信任经过你测试的项目。

  一旦你成为了大家眼中的业务专家,这就让你往「管理线」发展打下了很好的基础。因为对于管理线来说,业务>管理>技术,你说这是不是很大的优势。更加重要的一点是,由于工作性质的原因,测试在业务广度上的理解会比开发多。开发相对来说花了更多时间在业务的深度上。但是做管理,广度自然比深度更重要。

  可能你会说根据身边的情况来看,升任管理的人还是开发偏多。在我看来,出现这个现象主要有两个原因:

  对大多数公司来说,开发人员的数量比测试多(一般至少3:1吧),所以从人群基数上看,概率自然会大一些。

  最重要的一点是,你看看有多少测试仅仅起到了对比需求原型的作用?如果是这样的作用,话语权自然比不过在业务深度上更深的开发。

  /02 体验方向/

  黑盒测试本身就是以用户视角在测试项目,而且是不断地反复。我认为这是一个非常好的契机去培养自己对用户体验的感觉。可以说,在公司内部,测试使用产品的频次并不亚于它的设计者产品经理,甚至还要高。

  一旦你对用户体验的理解能力培养起来,那么后续你可以很自然地往产品经理转,毕竟产品经理的职业天花板可比黑盒测试高得多。

  不过,能不能对用户体验有感觉,还是需要一定天赋的。比如,你得有足够的好奇心,会去关注新事物,会经常去深度体验那些新出的APP,并且能够通过自己的体验得出它设计好和不好的地方以及背后的目的。

  另外,往产品经理这条路发展,相比通过业务走上管理少了对“坑位”的要求,完全凭能力说话,理论上道路更加宽广。但是说实话,要形成自己对用户体验的理解所需的独立思考能力,在这个时代还挺难的,因为到处都是别人投喂的加工好的信息。

  /03 开发方向/

  除了以上两个方向外,如果对自己够狠,愿意跳脱出黑盒测试范畴来考虑。那么培养自己的代码能力,往测试开发方向发展,可能是更宽的一条路。这条路的市场接纳度相比前面两条更高,也就是说机会更多。

  但是,我见过了太多人在这条路上半途而废了。原因就是前面提到的「行动力不足」。

  很多人会觉得测试开发太难,因为每次参加开发人员的分享会完全听不懂他们在说什么。这其实是提前给自己的内心打了退堂鼓。

  其实测试开发对代码能力的要求没有常规开发那么高。因为测试开发大多数是在做一些标准化的工具型项目,这些项目一般规模都不大,哪怕没有什么架构设计也能做出来。并且,没有常规项目开发在做业务迭代时的时间压力,只要利用好搜索引擎,完成工作是完全没问题的。有些工作内容实在不行,自己上手工测试也能应付。

  只不过,如果选择走测试开发这条路,你的目标(不管是中级目标还是终极目标)都必须要进到开发流程规范的企业(一般也就是大企业了),只有在这样的企业里测试开发才会受到重视。毕竟对大多数还处于温饱甚至还没温饱的企业来说,测试只是一个支撑型岗位而已,黑盒测试就足够了。

  当你成为了测试开发之后,如果对代码感兴趣,有意愿更加深入的话,还可以考虑转做常规的项目开发,只要将对应语言的类库弄熟了,然后学习一些架构设计知识,并在日常工作里用起来。这样你所具备的能力就和大部分开发人员无异了。

  除了这3条路还有吗?有,但是路都很窄。比如安全测试、性能测试。首先对这些方面有需求的企业几乎都是大企业,小企业几乎都不太考虑这些问题。这就导致了这些技能的实践机会变很少,掌握它的人自然也不多。但是他们的薪资水平不亚于开发,毕竟物以稀为贵嘛。如果能顺利成为测试开发的话,可以考虑一下这些方向。

  说实话,每次招人的时候,给黑盒测试开的工资并不高,但是收到的简历却明显比开发更多。我觉得这是一个“后浪”特别汹涌的岗位,所以,如果你正好是一位黑盒测试,请正视自己的未来,除非你打算几年之后转行。

  好了总结一下,这篇是Z哥和一位测试小伙伴聊完后的一些感想。主要是给测试工作两三年后觉得比较迷茫的人一些建议。

  我的建议是三条路。

  首先两条路是平滑的:

  往业务发展可以走管理路线。但是比较看机遇,毕竟需要有管理坑位给你。

  往体验发展可以走产品经理路线。但是比较看天赋,还需要培养独立的思考能力。

  还有一条路需要你咬咬牙跨越一下的:学习代码,尝试着用代码去编写工具完成你的一部分日常工作,转做测试开发。

  希望对你有所启发。


作者:Z哥

来源:https://zhuanlan.zhihu.com/p/144598219


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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 写测试用例的时候,不能想到什么就写什么,要按照一定的测试用例模板去写,要有自己的思路,不能完全去套用模拟以前的测试用例,按照一整套的测试流程来分析重要的关注点,时间长也会有自己积累的一套的测试模式,按照框架的思路,可能会达到事半功倍的效果哦!功能测试框架一般情况就是包含以下几类:界面友好性测试、功能测试、页面链接测试、容错测试、稳定性测试、性能测试(简单方面)等等。1.1.1界面友好性测试风格、样式的协调性是否合理界面布局是否整齐,尽量不要使用滚动条界面操作、标题描述要恰当操作符合大众的常规习惯提示界面符合规范(不要出现中英混写)界面中各个控件是否整齐美观日期控件是否可正常编辑、长度是否合理,...
            0 1 1252
            分享
          • 前言前面对脚本的基础配置、公共配置进行封装完成后,下一步便是对公司内部的业务进行分模块,按照模块进行对应的封装业务逻辑的封装目的将整个应用抽离分成哥哥公共模块,以便在不同的业务场景内直接复用对应的脚本文件;例如:将登录分成引导页模块、登录模块、注册模块、签到模块等等,各个模块根据业务能力划分,独立封装对应的脚本,便于后续业务功能发生变更时,快速的维护和调用脚本。脚本目录以下脚本分别对登陆模块和退出登陆模块两个模块进行独立封装本地对应的文件夹目录:脚本简述其中登录模块的测试脚本,包含了:登录的整个操作流程login_action()校验是否登录成功check_login_alter()
            0 0 1333
            分享
          •   引言  如何保证测试的数据质量,说白了,就是如何保证测试数据的准确性。  深聊测试数据  我们想一个问题:在实际的项目测试中,我们的数据质量与什么有关呢?  是 测数数据的多少,还是测试数据的内容?  同样,我先不回答, 我们继续往下聊。  回顾,你在整个项目的测试中,我们这里以接口为例,  你会花费很长时间去构造数据,以保证每次的数据质量都是完美的吗?  纵观整个测试行业,虽然相对于早些年,现在的测试开发工程师的测试质量逐年提升,测试技术也逐年提升。  但是,随着企业的版本迭代的加速, 却很少会有测试开发工程师花费大部分时间在测试数据质量上,  或者说,不是太多的测试开发工程师具备数据质...
            0 0 1305
            分享
          •   简介  基于模型的测试(简称MBT),是属于软件测试领域的一种测试方法。  与常规的设计测试用例,然后运行测试用例,验证运行结果与用例期望值是否一致的测试方法不同。MBT首先对被测软件系统进行建模,制定行为和行为之间的关系以及行为和系统的关系(有限状态机)。  其次,使用建模模型根据被测系统的状态、之前设置的限制条件和策略来生成很多用例,测试结果受一系列操作的影响。MBT可以产生更多不确定性的用例,更能发现一些意料之外的软件缺陷。  MBT主要包括:分析被测系统、选择测试模型、构建测试模型、生成和执行测试用例、收集和分析测试结果几个步骤。  其中最重要也是最难的几点就是选择测试模型、构建测...
            13 13 2107
            分享
          •   1.制作下来菜单  1.1先选中某列,再点击数据  1.2设置值为“通过”、“未通过”注意中间为英文逗号!!!  2设置单元格值为某个值时,背景颜色发生变化  2.1先选中该列,再点击开始  2.2设置单元格值等于某值时的颜色变化  3.设置自动统计自己案例的执行比,插入countif函数(注意双引号为英文的双引号)  3.1通过数  3.2不通过数  3.3执行比(通过数+不通过数)/总数  在我们测试工作中大多数测试人员使用的用例设计方法都是黑盒用例设计方法,其中使用最多的方法就是等价类划分法和边界值分析法,这两者也是所有的用例设计方法中最简单的,但是有一个缺点是如果我们稍不注意就会造...
            0 0 9859
            分享
      • 51testing软件测试圈微信