2.1.2　自动化性能测试工具要寻求什么

我们的性能测试，不管是为客户提供性能测试服务，还是在内部执行的性能测试，都需要确保所选用的测试工具确实适用于应用程序的技术。这一点是十分显而易见的，然而许多性能测试项目在脚本阶段遇到问题都是由于对所使用的工具没有做足够的评估而造成的。很多测试服务提供商从不同的工具厂商那里得到了“工具箱（toolbox）^[1]”解决方案，这样可以让他们为特殊的性能测试订单选择最适用的性能测试工具。我会在第5章中详细讨论不同的技术对性能测试造成的影响，在以下内容中我先指出评估一个性能测试工具应该包括以下几个步骤。

工具厂商支持

确保性能测试工具厂商“正式”支持您的应用程序技术，特别是应用程序客户端与下一个应用层的通信。例如，一个典型的基于浏览器的客户端在大多数情况下是使用HTTP或HTTPS作为主要通信协议。

认证模式

大多数性能工具都提供两种认证模式。

图　2-1　典型的高性能工具部署

·性能测试过程中能够执行的最大负载测试依赖于虚拟用户数

这种许可模式可能是单独或打包授权，或许会提供一个基本的100个用户，如果需要增加，则要另外多付钱。您可能还会发现提供无限制的虚拟用户数的工具厂商的固定成本更高。

·工具支持的应用程序技术

您可能已经购买了一个支持HTTP协议的工具，但在随后却需要它支持其他协议，比如说，Citrix。那么就需要增加额外的费用。应用程序技术可能关联虚拟用户也可能不关联。某些厂商还提供了短期授权的模式，即可以为了满足有些一次性或偶然性需要更多虚拟用户的测试需求而暂时增加您的许可证支持虚拟用户数的情况。

概念验证（POC）

您需要针对您的应用程序去试用工具，所以请坚持采用POC的方法。确定录制的事务类型至少有两种：一种是“只读”^[2]（例如，一个简单的搜索动作，并返回一组或多组结果），另一种是插入或修改数据库。这个概念可以帮助您检查录制的事务是否确实正确回放。如果您的系统是“只读”的，那么请检查回放日志，以确保每个事务在回放过程中没有出现错误。

脚本效果

许多性能工具厂商声称通过他们的工具生成的脚本需要做的手工改动很少，或者根本就不需要做手工改动。对于不涉及很多页面的简单浏览器事务来说，可能确实是这样，然而实际上在某些方面，您将不得不深入研究一下事务脚本中的代码。

因此，您可能会发现，为了让您所录制的事务能够成功回放，许多手工的改动还是必要的。如果使用一个工具录制的每一个脚本，进行这些改动都需要很多时间，而使用另一个工具，却看起来好像都可以自动处理，那么您就应该好好考虑一下是否有可能缩减成本，以及在您的性能测试项目中这些额外工作量与人力的影响了。另外，还要考虑到您的测试团队的技能水平。如果他们有着深厚的开发背景，那么让他们跟一堆垃圾代码打交道估计不会有什么问题。然而，假如他们对于编程相对不那么熟悉的话，您可能最好要考虑使用能够提供向导驱动功能的测试工具，以便帮助他们创建和准备脚本。

解决方案与负载测试工具

一些厂商只提供负载测试工具，而另外一些厂商则提供性能测试的解决方案。获得解决方案难免成本更高，但是它一般在分析测试结果方面提供了更精细的粒度。除了负载测试，它们可能包括以下几项内容中的一项或几项：自动管理需求，自动创建和管理数据，在应用程序调整和优化前的性能测试，响应时间的预测和容量建模，应用服务器的组件级别分析，以及部署后的最终用户体验（End-User Experience, EUE）。

内部执行还是外包

如果您内部资源有限，或者在时间进度上也受到严格限制，可以考虑将性能测试项目外包给外部的服务商。某些工具厂商会提供从工具的购买、部署的支持直到一个完整的性能测试服务的整个服务范围，也有许多专业的测试公司能够提供同样的服务。他们在经过分析和评估后，会选择一个合适的性能工具以完成工作。这样做有一个优点就是可以避免商务上的东西，而把注意力转移到时间和资源上，并且免去为了不知如何选择一个合适的测试工具的烦恼。这种方法的主要缺点是：“如果您需要频繁执行性能测试，每次测试的成本将很快就会彻底超过购买一套性能测试解决方案。”

[1]不同的测试工具的集合。

[2]在测试工具中没有报错并不意味着事务的回放就是正确的，对于“只读”的事务来说，如果搜索的结果不是你所预期的，这表明脚本回放出现了错误。