在日常工作中，不免需要学习各类工具。关于工具的学习，笔者简单分为三类：
为了解决当下某个具体的内容而学习。这类的学习，更多的就是面向搜索引擎学习，有不懂的，就通过关键字来查询相关资料，快速解决问题。
想要系统性地学习某个知识体系或者工具。这类学习需要有系统性和技巧，笔者会结合自己的实践，详细展开来聊。
还有一种，就是兴趣驱动，没有那么大的功利性，根据自己的兴趣爱好来学习。这类学习会是持续且高效的。
01
对于工作上遇到的问题，第一类学习方法可以快速解决当下的问题。但不能仅停留在第一类，因为那样的知识是不成体系的，很容易在之后的一段时间内被遗忘。当我们需要系统性的学习某一类知识或者工具时，需要有一定的方法。笔者总结如下图所示。
02
不论是工具还是技能，都是为了解决某一类特定问题而存在的，所以在学习这类知识之前，首先需要了解它能解决什么问题，为什么需要掌握它。
比如，我们学习Jmeter工具，是为了解决压力生成的问题。它既解决不了业务建模的问题，也解决不了监控的问题。所以，当有人使用Jmeter来解决接口问题时，我就会感到非常的奇怪，虽然Jmeter能解决一些接口的问题，但那不是Jmeter的核心功能啊。
还有会经常有人问到Jmeter的哪些插件比较好用，比如一些监控工具如何集成到结果报告中。这样做监控的数据不一定准确，还会有一定程度上影响到TPS等相关真正需要被关注的指标，得不偿失。
所以，了解一款工具或者知识点的背景及解决场景，非常的重要，不要把好的工具，用在错误的场景中。
03
接下来，就要弄清楚这些工具或者知识点背后的原理是什么，它们是通过什么方式来解决问题的。这样会让我们更好地去理解和使用这些工具或者知识点。
继续以Jmeter为例，当我们知道了它是为了解决压力生成的问题后。我们就需要去了解Jmeter是如何发送请求的，底层的实现逻辑本质上是线程池 HttpClient的组合使用。那么你就能清楚地知道它的适用场景是什么了。常见的Http请求压测它都能胜任。
但是HttpClient的缺点，Jmeter都会有，比如每次发起http请求都会new httpClient，会打开许多套接字，比你实际的需求多许多，这极大地增加了负载机的负载，而且，这些套接字实际上不会被using语句关闭。相反，它们是在应用程序停止使用它们几分钟之后才会关闭。所以在Windows环境下，端口的占用一直是Jmeter很大的痛点。
所以，在实际的执行过程中，我们会在Windows环境下编写、调试Jmeter脚本，但是在实际的压力测试过程中，一定会把它丢到linux环境中，用非GUI模式去运行。
04
理论的东西理解了之后，接下来就是不断地实践和尝试。只有理论没有实践，就是无根之萍，并不能解决实际问题，但也不能忽视理论。
继续以Jmeter为例，它有那么多的元件需要我们去了解，结合不同实际场景去做组合。需要你通过Json提取器来获取需要关联的内容，需要学会通过BeanShell元件来做定制化的参数处理，需要知道通过各类Manager来控制请求头信息，等等。
这些能力只能通过不断地练习来提升熟练度。你不能每次写脚本的时候都去现查。这样你的效率就太低了。很多人说我没有环境来做练习啊，公司也没要求我们做性能测试。
其实，练习工具最好的环境就是你的被测系统啊。用Jmeter写写脚本，总可以的啊。不但能练习脚本能力，还能好加熟悉系统，还能和开发多沟通，一举多得。
知识体系也是一样的。比如中间件的学习。最好也是能够结合当下你们的被测系统，去了解这些中间件到底是怎么被开发使用并解决实际场景问题的。
05
通过更多的练习和思考，你就会更明白它的原理和优缺点。在后续的其他场景中，你就会有更有针对性地选择。如果只是一味地为了使用工具而学习工具，效果并不会太好。
同时，在学习这些知识的过程中，一定要想办法和你已知的知识点建立链接。把知识点串起来，把知识形成网络，这样才能碰撞出新的火花，也能把知识点记忆得更加牢固。单点的知识很容易被遗忘。
小结下，学习工具三部曲：
想明白：为什么要学习这个工具，能解决什么问题；
懂原理：去了解工具的优缺点是什么，怎么去运用它
多练习：多用，多练，多思考，唯手熟尔。
往期推荐：
测试质量保障的影响因素
测试如何构建快速反馈的能力
测试用例设计的故事
测试人员如何甩锅
我建星球啦，你想加入么
END
标星、点赞、关注三连走起，感谢支持。
如果想阅读更多文章，请关注我的公众号。
