概述
在之前写的互联网高级测试工程师至少具备的能力一文中，提到了测试工程师至少具备的能力，但是并没有提到优秀测试工程师应该具备的能力，下文简单的谈一谈。当然这些全部都是我的个人理解。
能发现问题，还能定位问题，而且能给研发解释得清楚
在实际的工作中，你可能会遇到很多测试人员在测试功能模块的时候，一遇到问题，马上就来找开发，由开发来定位问题。测试人员发现功能不对，我们可以理解为【开发人员研发的系统的功能跟产品经理的需求不一致】，属于【发现问题了】。这个没问题，但是测试人员能不能静下心来，自己先研究一下发生问题的原因呢？相信很多开发人员经常会遇到，测试人员提的bug其实跟代码没关系，而是环境问题或者数据问题等。
可能有人会问，怎么定位呀？其实手段多得很，例如，看日志、抓包、看代码、debug代码、分析数据、分析业务流程、分析请求走过的节点等等，进行多方面的求证。如果实在找不到原因，才来找开发。
如果测试人员找到原因后，还能跟开发人员解释清楚，那就非常了不起了。因为这里除了涉及到专业能力外，还涉及到测试人员的沟通表达能力。
提一个自描述的BUG
你有没有遇到这种情况，测试人员提的bug单里，只有几句简单的描述。这样会加大开发人员定位问题的难度。遇到这种bug单，我通常都是建议让测试人员补充一些内容。
- 导致这个bug的上下文入参；
- 必要的截图；
- 用简单清楚的文字描述bug原因、背景；
- 如果是小程序或者app等前端bug，也可以录制视频，上传上去，能更加直观的展示问题；
- 如果公司用的是微服务，且用了调用链跟踪，那就把trace Id也填进去，方便开发跟踪；
有一些测试人员文字表达能力很差，bug单的描述很让人费解，文字功底一时半会是改进不了，那么可以通过提供截图的方式来补充一下。
至于入参，这个必须要提供，不然会极大的加长bug定位的时间。
提有意义的bug
动不动提bug不是一个高效友好的方式，而且正如我上面提到的，很多测试人员文字功底很差，提的bug很让人费解。更为高效的方式就是直接沟通。
除非是重大缺陷或者很有意义的缺陷，值得后续用来做bug分析、追踪、总结的，才建议记录一个bug。
能独立搭建测试环境
开发人员提测后，就应该可以进行下一个功能的开发了，测试环境问题，开发是无需关心的。如果提测后，还需要协助测试搞测试环境的话，那是很浪费时间的。因此，测试人员应该能独立搭建环境，不管MQ、Redis、微服务等，都能搭建好。并且要保证测试环境是足够稳定的。
这里涉及到的知识点也是很多的，像Linux、Shell、网络协议等。
能开发造数据的工具
测试人员在做功能测试的时候，有一个重要的阶段，便是造数据，这个不是一个简单的事情，尤其是公司的微服务越来越多的时候，一个请求通常需要走过很多节点，每个节点都会取数据，如果没有一个造数据的工具，将大大加大测试的难度。
总结
简单说，就是具备一定开发能力知识面广，且沟通表达能力强的测试人员。
写在最后
现在很多软件测试人员，都会陷入到一个怪圈：看到别人升职加薪，又觉得为啥别人运气总是那么好，我和他差不多时间进公司的啊！然后去跳槽，发现，现在的面试这么难的嘛，动不动就自动化测试，动不动就测试框架，软件测试不好做了，做软件测试的人太多了，我还是转行吧。
归总到一点，就是没从自己思考，从身上找原因。对于软件测试员来说，想要涨薪升职，自己的能力肯定要跟得上，而唯一的办法就是通过学习来提升自己。下方这份完整的【软件测试】视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】
