在过去的几十年里，用于性能测试的自动化工具发生了巨大的改变，从胖客户端到 Web 架构，以及随着移动互联的激进的发展，越来越的应用以移动互联的方式来提供服务。
相应的性能测试相关的自动化工具所需提供的功能也越来越面向 Web 和移动开发，而不再是支持传统的二层架构中常用的技术了。
尤其是，这是年开源社区的大力贡献，在开源领域我们有了更多的优秀的开源性能测试工具，例如：
1、Apache JMeter: https://jmeter.apache.org
2、Gatling: https://gatling.io
3、Locust：https://locust.io
这里就列出我们大家用到或容易接触到的工具，其他工具就不罗列了。
似乎我们看着这些工具都不错，但我们在实践中还是会有顾虑的：如果你的一些性能测试场景涉及非 Web 场景，那么可选的工具就会大大减少。
尽管经过这么多年，各类工具已经大有发展，但对于非 web 类场景的开源工具依旧像魔咒一样困扰着很多测试人员。
从性能测试执行和分析来看，非 web 场景的性能测试与 web 场景没多大不同，关键的难点在于其通信协议不同，报文抓取、分析工具可能不一样，以及对于测试场景脚本的开发。 对于有些应用了加密、压缩等技术的，在性能测试时，会进一步提升测试脚本的开发难度。
当然了，对于 web 应用的性能测试有时也是会有一些挑战的，例如流媒体的压测，使用了客户端证书等安全机制的，针对这些应用了特定技术的场景，大家就会发现现有的性能测试工具就无法满足需求了。
所以在进行性能测试之前，我们应该充分：考虑工具的实际功能和压测需求。
尽管在性能测试实施之际，有着各种挑战，但测试工具还是我们的必需选择 --- 因为不使用工具，我们将无法开展有效的性能测试。
所以我们要开展有效的性能测试，就必须使用自动化技术。
更多内容可以学习《测试工程师 Python 工具开发实战》书籍、《大话性能测试 JMeter 实战》书籍
下面我们就市面上常见的商业工具和开源工具进行一个大的总结，看看一般通用的性能测试工具有哪些共同点：
1、脚本模块。工具都支持终端用户行为的录制，有些工具则支持多重协议的录制，但不管是那种模式，笔者建议：尽量采用手工编码方式来实现测试脚本。
2、测试管理。工具都会支持测试场景的创建、执行，使用会话和场景来模拟不同用户的操作行为。
3、压力引擎。工具用于产生负载的核心功能，一般都支持分布式生成负载，以便支撑起大规模的性能测试实施。
4、分析模块。提供对每次测试实施所产生的数据进行分析的能力。通常包括了各种自动产生的报表、可配置的图表和原始数据。有些工具甚至提供了专家级或是更技术底层的分析能力，以帮助用户对结果进行深度分析、提炼更为重要的关注点。
5、可选能力。作为上述能力的补充，一般工具都会以插件的方式来提供丰富的可选能力，例如监控能力等等。
通过上述回顾性能测试的发展及工具的共性，我们该如何有效的选择我们的性能测试工具呢？
可能有人就会讲了，这有什么好选择的，不是 jmeter、locust、就是 loadrunner 这些常见的工具罗。
但本文的目的不是在于告诉你直接从现在市面上大家共知的工具，而是通过文章把我如何去选择一个合适的工具的经验告诉大家。
在很多时候，由于前期对工具、技术、团队、资源等评估不够，很多性能测试项目在编写脚本、性能分析阶段陷入问题的泥潭。下面是笔者如何选择工具的一些建议。
1、 协议支持。选择性能测试工具最重要的一点就是确保所选的工具能支持目标压测应用协议栈。
2、直接成本。开源工具一般来讲不存在这个问题，能直接使用工具所有的能力。但当开源工具不足以支撑我们的工作目标时，这些需要引入商业工具，就要考虑其授权方式了，例如虚拟用户授权的价格。额外协议授权的费用。额外的监控和分析插件的费用等等。
3、脚本能力。市面上大部分工具都宣称通过录制就能实现性能测试的目的，从笔者实际项目实践来看，项目实践时，录制功能是应该丢入毛坑的。所以强悍的脚本支持能力是一个工具必备的，主要体现在几个方面：一个是要有丰富的功能或是 API；一个是有这对应的详细的文档；一个是有社区的支持；一个是有完整的使用示例。
4、只是工具还是解决方案。很多工具只是一个单纯的测试工具，但有的工具则是成套的性能测试解决方案，或是有配套的开源解决方案。所谓解决方案通常包含：自动化需求管理、数据的自动构造和管理、监控和分析、结果可视化等等。
基于上述几个方面的意见，我们要根据现有团队的情况，来决定是引入合适的工具、还是解决方案还是基于开源工具进行二次开发又或是外包。
不管是哪种方式，我们要充分考虑投入产出比。现在开始有些第三方是性能测试 saas 服务商，甚至还提供基于其 saas 服务提供完整的测试实施和过程咨询服务。
具体采用哪种方式，需要大家根据投入成本、团队现状、未来团队发展等等因素来统筹考虑。