本节书摘来自异步社区《应用程序性能测试的艺术（第2版）》一书中的第2章，第2.1节性能测试工具架构，作者【新西兰】Ian Molyneaux（莫得尼克斯），更多章节内容可以访问云栖社区“异步社区”公众号查看。
第2章 选择合适的性能测试工具
应用程序性能测试的艺术（第2版）
生活中，人们只需要两种工具：让设备运转起来的WD-40（一种润滑剂）和使其停滞的冷缠胶。
——G. Weilacher
用于性能测试的自动化工具在过去20年的大部分时间里都以某种形式存在。在这期间，应用技术发生了巨大的改变，从胖客户端到Web架构，到如今越来越多的应用以无线的方式来提供服务。相应的，自动化工具所需提供的功能也越来越面向Web和无线开发，而不再是支持传统的二层应用架构中常用的技术。应用技术的集中化对于性能测试人员来说是一件好事，因为市场上有很多自动化工具供应商都能很好地支持Web和无线技术，测试人员可以根据需要选择物美价廉的工具。同时，开源社区中也不乏一些优秀的性能测试工具。
听起来不错，但用户还是得当心：如果你的一些性能测试涉及非Web场景，那么可选的工具会迅速变少。尽管经过这么多年，自动化工具的技术魔咒依然存在。通常开源工具对于非Web场景的性能测试支持都比较弱，这就意味着性能测试的工具开销不可避免。对于非Web场景，性能测试的执行和分析并没有多大不同，关键的难点在于应用操作的录制，以及针对录制脚本的后期编辑。有些技术比如“加密”、“压缩”会给性能测试工具带来更大的麻烦，甚至我们有可能根本无法录制，只能通过手工编码或者针对性地开发一些测试组件才能满足性能测试的需要。Web应用的性能测试有时候也会遇到挑战，比如流媒体的压测、使用了客户端证书的安全机制等，针对这些场景，不是所有的性能测试工具都能满足你的需求。在最终决定使用哪个工具之前，你应该充分考虑工具的实际能力和你的压测需求，我强烈建议在购买工具之前先做一个概念验证（Proof of Concept，POC）。尽管有着诸多挑战，但是压测工具还是我们的必需选择——如果不使用工具，我们无法开展有效的性能测试。在第1章我也提到了这个观点，它也是为什么许多应用在上线之前没有进行有效性能测试的原因之一。如果要开展可靠的、可重复的性能测试，我们必须使用自动化技术。
自动化的性能测试工具可以帮助我们简化测试流程。工具通常允许用户对终端用户的操作进行录制，进而产生对应的脚本。这些脚本会被用来创建性能测试会话或者场景，这些会话/场景模拟了一批典型用户的操作行为。这才是真正意义上的性能测试，它们可以非常方便地反复执行，这是人工测试所不具备的一个重要优势。同时，性能测试自动化工具会自动存储测试结果，并且可以方便地对多次测试结果进行比较，因此可以显著提升性能结果分析过程的效率。
2.1 性能测试工具架构
性能测试自动化工具通常由以下模块组成。
脚本模块
支持对终端用户操作行为的录制，有些工具会支持多种中间件协议的录制。允许用户对录制下来的脚本进行编辑，关联脚本内部和外部的数据，对响应时间度量的粒度进行控制。“中间件”在这里是指应用用于客户端和服务端通信的主要协议（对于Web应用来说，主要是指HTTP或者HTTPS）。
测试管理模块
支持性能测试会话或者场景的创建和执行，使用会话和场景来模拟不同用户的操作行为。这些会话/场景使用指定的性能测试脚本和一个或者多个施压引擎（取决于需要多大的负载）来产生期望的负载。
施压引擎
产生负载——通常使用多台工作站或者服务器，需要使用多少台取决于期望达到的负载。通过部署在相对少量的物理机或者虚拟机上的施压引擎来产生大量虚拟用户（Virtual User，VU）来模拟大量的终端用户操作行为。用户客户端本身对于内存和CPU资源的消耗很大程度上决定了一个施压引擎能够产生多少虚拟用户，进而决定我们需要部署多少施压引擎。
分析模块
提供对每次测试执行所产生的数据进行分析的能力。数据通常包括各种自动产生的报表、可配置的图表和数据表格。有些分析模块还提供专家功能，帮助用户对结果进行深度分析，提炼重要关注点。
可选模块
通常作为上述模块的补充用来对测试环境中的服务器和网络进行性能监控，或者用来集成其他类型工具帮助分析。图2-1展示了一个典型的性能测试工具部署结构。应用的终端用户被一批工作站或者服务器取代，这些机器通过创建虚拟用户来给目标应用施加负载/压力。
