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

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

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

沟通能力

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

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

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

阅读能力

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

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

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

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

设计用例的能力

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

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

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

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

写文档的能力

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

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

一定的代码能力

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

执行用例能力

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

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

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

专项测试能力

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

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


↙↙↙阅读原文可查看相关链接,并与作者交流