职业经验 当前测试人员应该具备的基本技能

easonhan007 · 2018年08月10日 · 最后由 taflo 回复于 2018年08月13日 · 1151 次阅读

最近发现一些测试岗位的薪资水平很高,然而与此形成鲜明对比的是,另一些测试岗位的回报却是少得可怜,两级分化特别严重。

我一直有这样一个观点,除去各种软技能因素,你会的越多拿的就越多。

那么当前测试同学应该具备哪些技能呢?我想大概应该有下面一些。

沟通能力

沟通能力我认为分为2种,一种是表达自己,另一种是聆听别人。

表达自己的意思就是能让其他人知道你想做什么,在做什么,有什么困难,需要什么帮助;聆听别人就是你听得懂对方在做什么,要做什么,有什么困难之类。

很多测试同学在表达自己方面能力很强,但是聆听别人方面却差强人意。经常沟通之后完全不知道开发或者项目要做什么。这应该是由于信息不对称造成的,开发和项目方面的事情大家不是很清楚,所以沟通的实话往往貌合神离,只能报以尴尬而不失礼貌的微笑。

阅读能力

这里特指阅读文档的能力。

文档有很多种,我们最应该读懂的是需求文档。

需求文档里可能有很多字,这时候我们需要一边读一边思考,哪些地方是合理的,哪些地方又是需要推敲的,比如根据手机壳自动变换软件主题颜色之类的需求,还是要多多讨论一下才比较好。

需求文档里面很可能就一句话,比如我要实现一个跟淘宝一摸一样的网站,这时候上文描述的沟通能力就有用武之地了。我们需要把需求一点一点的挖出来,丰富和细化,最终还原为真实需求。个人经验看来,一句话的需求往往是在表达美好的愿望,只是冰山一角,实际要做的事情往往相当的繁复。

设计用例的能力

用例设计的方法大家应该耳熟能详了,起码每次面试之前都会背一遍。但是会了那么多方法,并不一定代表你就能编写合理有效的用例。

其实我一直认为,我们所推崇的用例设计方式很多时候是很微观的,但我们设计的测试用例在大多数时候却是宏观的,两者之间似乎并不能令人信服的融会贯通。

比如边界值法,在单元测试里边界值是很容易分类(等价类)和枚举的,但是在设计一个真正的手工测试用例的时候,我们往往很难做这种枚举,我们可能会有一个输入范围及其庞大的无效类,叫做异常情况。如何在异常情况中再次细分,选取有代表的性的输入或操作进行测试,往往相当有挑战,这就需要真正的理解需求,理解被测系统。

所以很多时候,这种设计用例识别盲点的能力最终还是转化为,你对系统熟不熟,对业务熟不熟,知不知道用户在想些什么。

写文档的能力

因为衡量测试输出的指标不是很多,所以有些时候我们要输出一些文档来表示我们确实在努力工作。比如

  • 测试计划
  • 测试用例
  • 测试报告

这些其实有很大的优化空间,毕竟在项目紧张的时候测试报告也就是一个结论一封邮件的事情。

一定的代码能力

测试重复性的工作很多,有一些重复性高的事情是可以用写代码的方式去快速搞定的。比如可以用写一些脚本逻辑加sql的方式快速生成一些测试数据之类的。有了代码能力之后,想象空间就会变大相对大一些。

执行用例能力

手工执行用例也是一种能力,并不是测试用例写的好换谁执行都一样的。但是自动执行用例的能力也是当前的测试人员所需要掌握的。

自动化的用例执行可以节约成本,提升执行效率,加速回归测试,不过需要找到投入和产出的平衡点。

把一些回归用例用代码的方式实现并维护其实蛮有挑战的,毕竟学会写代码是需要一个过程的。

专项测试能力

掌握一项专项测试能力,比如性能,app之类的,毕竟说不准什么时候项目就要求你这样做,能顶上去才有更好的发展空间。

不知道大家觉得还有哪些能力是必备的,欢迎留言讨论。

共收到 13 条回复 时间 点赞

沙发,顶一个

板凳,第二个

加班能力

jjj0817 回复

噗呲.....

代码能力,代码能力,还是代码能力

测试最好是一种全能型人才,敢于产品pk业务,敢于开发讨论代码,能够hold住全局。

沟通协调能力、执行力、理解表达能力、逻辑思维能力、情绪控制能力等等类似这些都属于软性素质,测试岗位确实非常看重这些,其他岗位多少也类似。

说的不错,沟通和技术能力一样重要

iqianxing 回复

能够hold住全局?能不能不起飞脚踏实地?

taflo 回复

+1 务实,不要直接一来就平地起飞

taflo 回复

hold全局是从业务上来讲的,一旦测试参与了产品多个环节,测试对产品的理解更深更细,能够把控项目的进度、产品的业务风险。

iqianxing 回复

一旦测试参与了产品多个环节,测试对产品的理解更深更细

这点我部分同意。

能够把控项目的进度、产品的业务风险

这点我就不同意了,这2点明显是老板们说的算啊,虽然测试能提供些建议但和“把控”没有一毛钱关系啊。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册