概述
在之前写的一文中，提到了测试工程师至少具备的能力，但是并没有提到优秀测试工程师应该具备的能力，下文简单的谈一谈。当然这些全部都是我的个人理解。
能发现问题，还能定位问题，而且能给研发解释得清楚
在实际的工作中，你可能会遇到很多测试人员在测试功能模块的时候，一遇到问题，马上就来找开发，由开发来定位问题。测试人员发现功能不对，我们可以理解为【开发人员研发的系统的功能跟产品经理的需求不一致】，属于【发现问题了】。这个没问题，但是测试人员能不能静下心来，自己先研究一下发生问题的原因呢？相信很多开发人员经常会遇到，测试人员提的bug其实跟代码没关系，而是环境问题或者数据问题等。
可能有人会问，怎么定位呀？其实手段多得很，例如，看日志、抓包、看代码、debug代码、分析数据、分析业务流程、分析请求走过的节点等等，进行多方面的求证。如果实在找不到原因，才来找开发。
如果测试人员找到原因后，还能跟开发人员解释清楚，那就非常了不起了。因为这里除了涉及到专业能力外，还涉及到测试人员的沟通表达能力。
提一个自描述的BUG
你没有遇到这种情况，测试人员提的bug单里，只有几句简单的描述。这样会加大开发人员定位问题的难度。遇到这种bug单，我通常都是建议让测试人员补充一些内容。
-
导致这个
bug的上下文入参； -
必要的截图；
-
用简单清楚的文字描述bug原因、背景；
有一些测试人员文字表达能力很差，
bug单的描述很让人费解，文字功底一时半会是改进不了，那么可以通过提供截图的方式来补充一下。
至于入参，这个必须要提供，不然会极大的加长bug定位的时间。
提有意义的bug
动不动提bug不是一个高效友好的方式，而且正如我上面提到的，很多测试人员文字功底很差，提的bug很让人费解。更为高效的方式就是直接沟通。
除非是重大缺陷或者很有意义的缺陷，值得后续用来做bug分析、追踪、总结的，才建议记录一个bug。
能独立搭建测试环境
开发人员提测后，就应该可以进行下一个功能的开发了，测试环境问题，开发是无需关心的。如果提测后，还需要协助测试搞测试环境的话，那是很浪费时间的。因此，测试人员应该能独立搭建环境，不管MQ、Redis、微服务等，都能搭建好。并且要保证测试环境是足够稳定的。
这里涉及到的知识点也是很多的，像Linux、Shell、网络协议等。
能开发造数据的工具
测试人员在做功能测试的时候，有一个重要的阶段，便是造数据，这个不是一个简单的事情，尤其是公司的微服务越来越多的时候，一个请求通常需要走过很多节点，每个节点都会取数据，如果没有一个造数据的工具，将大大加大测试的难度。
总结
简单说，就是具备一定开发能力知识面广，且沟通表达能力强的测试人员。有些人可能会问，测试人员不是要懂业务、压测、逻辑思维要好吗？ 这个其实基础来的，一定要懂的，具体请看