最近发现一些测试岗位的薪资水平很高，然而与此形成鲜明对比的是，另一些测试岗位的回报却是少得可怜，两级分化特别严重。
我一直有这样一个观点，除去各种软技能因素，你会的越多拿的就越多。
那么当前测试同学应该具备哪些技能呢？我想大概应该有下面一些。
沟通能力我认为分为 2 种，一种是表达自己，另一种是聆听别人。
表达自己的意思就是能让其他人知道你想做什么，在做什么，有什么困难，需要什么帮助；聆听别人就是你听得懂对方在做什么，要做什么，有什么困难之类。
很多测试同学在表达自己方面能力很强，但是聆听别人方面却差强人意。经常沟通之后完全不知道开发或者项目要做什么。这应该是由于信息不对称造成的，开发和项目方面的事情大家不是很清楚，所以沟通的实话往往貌合神离，只能报以尴尬而不失礼貌的微笑。
这里特指阅读文档的能力。
文档有很多种，我们最应该读懂的是需求文档。
需求文档里可能有很多字，这时候我们需要一边读一边思考，哪些地方是合理的，哪些地方又是需要推敲的，比如根据手机壳自动变换软件主题颜色之类的需求，还是要多多讨论一下才比较好。
需求文档里面很可能就一句话，比如我要实现一个跟淘宝一摸一样的网站，这时候上文描述的沟通能力就有用武之地了。我们需要把需求一点一点的挖出来，丰富和细化，最终还原为真实需求。个人经验看来，一句话的需求往往是在表达美好的愿望，只是冰山一角，实际要做的事情往往相当的繁复。
用例设计的方法大家应该耳熟能详了，起码每次面试之前都会背一遍。但是会了那么多方法，并不一定代表你就能编写合理有效的用例。
其实我一直认为，我们所推崇的用例设计方式很多时候是很微观的，但我们设计的测试用例在大多数时候却是宏观的，两者之间似乎并不能令人信服的融会贯通。
比如边界值法，在单元测试里边界值是很容易分类 (等价类) 和枚举的，但是在设计一个真正的手工测试用例的时候，我们往往很难做这种枚举，我们可能会有一个输入范围及其庞大的无效类，叫做异常情况。如何在异常情况中再次细分，选取有代表的性的输入或操作进行测试，往往相当有挑战，这就需要真正的理解需求，理解被测系统。
所以很多时候，这种设计用例识别盲点的能力最终还是转化为，你对系统熟不熟，对业务熟不熟，知不知道用户在想些什么。
因为衡量测试输出的指标不是很多，所以有些时候我们要输出一些文档来表示我们确实在努力工作。比如
这些其实有很大的优化空间，毕竟在项目紧张的时候测试报告也就是一个结论一封邮件的事情。
测试重复性的工作很多，有一些重复性高的事情是可以用写代码的方式去快速搞定的。比如可以用写一些脚本逻辑加 sql 的方式快速生成一些测试数据之类的。有了代码能力之后，想象空间就会变大相对大一些。
手工执行用例也是一种能力，并不是测试用例写的好换谁执行都一样的。但是自动执行用例的能力也是当前的测试人员所需要掌握的。
自动化的用例执行可以节约成本，提升执行效率，加速回归测试，不过需要找到投入和产出的平衡点。
把一些回归用例用代码的方式实现并维护其实蛮有挑战的，毕竟学会写代码是需要一个过程的。
掌握一项专项测试能力，比如性能，app 之类的，毕竟说不准什么时候项目就要求你这样做，能顶上去才有更好的发展空间。
不知道大家觉得还有哪些能力是必备的，欢迎留言讨论。