2.1　选择合适的性能测试工具

自动化工具在大约15年前就已经出现了，在这段时期，应用程序技术早已日新月异，从标准的“胖客户端（fat client）”发展为Web应用。因此，目前的自动化工具必须更偏重于支持Web应用，而支持传统的基于两层应用架构的系统需求则越来越少。这种“注重Web应用”的情况对于性能测试人员来说是个好消息，因为现在即使是您没有太多的预算，在市面上同样有很多自动化工具厂商可供选择，除此之外，还有许多免费或开源的共享软件可供使用。

随着面向服务的架构（Service Oriented Architecture, SOA）体系的出现，还可能会发生另外一些巨大的变化，我们关注的性能将不再仅仅针对最终用户的事务（Transaction），而且还包含了业务流程。对于目前的这些性能工具来说，这个概念通常显得有点抽象，但是它使用了类似Web Service技术的相关业务流程组件，我们同样可以对其进行测试。我将在第5章中讨论SOA和其他一些技术。

应用程序技术的发展，对于Web应用程序的性能测试技术的支持和工具的支持对测试人员来说是很好的帮助，但是这也有一些缺陷。比如：当您需要做非Web应用的性能测试时，工具厂商的选择空间就会大大减少，而且在技术方面也同样存在着挑战。这些问题的核心并不在于执行测试和分析结果，而是如何成功地录制应用程序的操作，增强并生成测试脚本的过程^[2]。在性能测试过程中，“加密”和“压缩”技术往往是生成测试脚本的难题，因为由于系统的这些技术可能导致无法开发测试脚本。如果不影响到最终的测试结果，最好在测试过程中屏蔽这些技术。

即使是基于Web的技术也同样可以暴露性能测试工具的问题。举例来说，假如您需要处理流媒体或客户端认证技术，那么并不是所有厂商都可以提供解决方案。因此在对测试工具进行最终选择之前，应该仔细地考虑您需要性能测试工具提供的功能，而且我建议在决定购买之前先做一次概念验证（Proof of Concept, POC）

尽管存在着上述内容中的挑战，在正规的性能测试中仍然有必要引入自动化工具。这也是我在第1章中提到的为什么许多应用程序在部署前没有进行正确的性能测试的原因。因为不使用自动化工具，就没有办法执行可靠的、可重复的性能测试。^[3]

因此，任何自动化性能测试工具的目标就是简化测试过程，测试工具一般是通过提供录制用户操作，并将其转换为事务或脚本来实现的。这些脚本被用来创建负载测试的会话和场景，并以此模拟典型的最终用户对业务的操作。这才是真正的性能测试，一旦创建，便可以很容易地重复执行，这正是它与任何手工测试相比最大的优势所在。

与手工测试相比，自动测试还有另外一个巨大的优势，它能够快速地从不同的系统资源（比如服务器，网络和应用程序响应时间）获取的性能数据关联起来，并且在同一个视图中展现。这些信息在每一次测试运行过程中都会记录下来，这样就可以很容易地比较多次性能测试的结果。

2.1.1　测试工具的构成

自动化性能测试工具通常由以下组件构成。

脚本模块

提供录制最终用户操作的功能，并支持很多不同的中间组件协议。允许修改录制脚本以关联内部/外部数据，以及配置响应时间度量的粒度。

测试管理模块

提供创建和执行负载测试的会话或场景，并以此模拟不同用户混合业务的操作。这些会话负责调用指定的脚本，以及调度一个或多个负载生成器。

负载生成器

从多个工作台或服务器上创建一般负载，创建负载的大小视负载需要而定。分析模块提供对每次测试执行过程中收集到的数据分析的功能。这些数据通常是由一些自动生成的报表和图形，或者是表格形式的报告组合而成，可能还会提供自动分析结果并将关注的重点区域进行突出显示等一些“高级”功能。

除了以上这些模块，还要再加上一个在负载测试运行过程中监控服务器和网络性能的模块。图2-1展示了一个典型的自动化性能测试工具配置情况。由负载生成器生成的“虚拟用户”代表了应用程序的实际用户。

[1]这句话出自古罗马一位著名哲人的诗句，有因小失大之意。

[2]脚本开发的一般过程包括：通过录制生成脚本框架、编辑并增强脚本、调试并最终确认脚本。

[3]合理的性能测试工具的引入，是应用程序性能测试成败的关键技术之一。