【IT168 技术文章】

    本文详细地阐述了针对企业级Java环境的性能测试方法论，详细说明了高效性能测试的每个步骤。该方法论描述了如何按照性能的需求从架构设计开始，进行单元测试，集成测试，和生产分段（productioin staging）测试等。描述了实现正规容量评估(capacity assessment)所需的过程，该量化过程可以明确指出你何时需要向你的计算环境增加额外资源。此外，该方法论还阐述了验证你的测试场景是否很好地模拟了你的最终用户的操作行为所需的必要步骤。

    通过提供的一套全面的解决方案, 本文描述Quests Application Management Suite for Java and Portals是如何与该方法论相集成，从而在应用开发生命周期的每个阶段保证您的成功。运用这套方法论和Quest的应用管理解决方案,您将充满信心地把符合性能规范的应用展现给您的用户。

    本文同时强调自动化的重要性，采用自动化方式可以创建重复的测试过程并迅速报告应用代码的质量。只有自动化方式才能保证正确地遵循这些测试过程，并且保证准确和一致地测试应用组件。

    导言

    性能测试已经成为软件开发界的一个事后总结出来的想法。IDG 的研究报告指出只有20%的上线的企业Java 应用符合他们的性能要求。如果所有上线的企业Java应用中有80%不满足他们的服务标准协议(SLAs)，那么就需要花费巨大努力去分析为什么会发生这种情况以及如何解决这种问题。要想成功满足SLA，其关键在于应该采用正规的性能测试方法论。本文将详细阐述该方法论并且指出在每个测试阶段所需使用的工具集，以成功确保企业应用的性能。

    测试主要分两类: 功能测试和性能测试。 本文专注于性能测试，因此本文中的所有提及的测试除非有另外说明，否则都指性能测试。

    性能测试的准备

    一、量化性能需求

    为了量化性能要求，我们假设您已经定义了SLA。在深入分析问题之后，关键的负责人员应该系统地定义SLA。SLA 的主要推动者应该是应用业务负责人和应用技术负责人。 应用业务负责人，有时是应用产品经理,他负责分析商业案例并把客户的需求转化为SLA。其实, 只要满足SLA, 客户的需求也会满足。应用技术负责人，有时是应用构架师,分析必要的技术需求，解释用例并"真实地检验"SLA。因此，技术业务负责人的责任就是确保服务等级是可达到的。有效的SLA具有三个关键特性:

    1.具体的。

    2.灵活的。

    3.现实的。

    一个有效的SLA 必须是一个具体的值。一个用例必须在大约五秒内完成是不准确的，因此很难检验--5.25秒钟是否是大约的五秒。一个具体的值便于QA在应用上线前进行测试，当应用上线后，SLA将提供对主动监测和被动监测两种警报(Alert)的规范。同时，一个有效的SLA在分布式的变化环境中必须也是灵活的。考虑到一些未预料到的情况，我们需要对灵活性进行测量，因此用例必须采用预先定义的时间百分比的方式满足具体的SLA值。例如，您每天使用的常用搜索引擎。当您执行一次查寻,在95%的时间里可以在2秒内完成；在每20次查询中，有一次的响应时间是7秒；通常这种变化的范围是可以接受的。但是如果每20次查询中，有10次超过7秒，你可能就会考虑换个搜索引擎了。SLA不仅必须是具体的, 也要灵活,同时必须也是现实的。你可以通过要求应用业务负责人和应用技术负责人共同制定SLA的方式保证SLA是现实的。这是一个有效用例的特别关键的特性，这是因为在大多数情况下，SLA只由应用业务负责人单方面确定，没有考虑应用技术负责人的意见。当技术小组接到这些性能需求时，他们往往会忽略，一个不现实的SLA比根本没有还要糟糕。

    二、了解你的用户

    为了保证调优努力的成功你能做的最重要的事就是安排时间了解你的用户和理解他们在使用你的应用时的行为情况。很少会在生产环境中调优应用服务器，而更多的情况是,通过写测试脚本再现为虚拟用户，在上线前的环境中执行负载并进行调优。当在上线前环境中完成调优后, 就可以安全地把配置信息应用到生产环境中。多数公司无法在上线前的环境中充分地再现生产负载。如果您在这些公司中工作,没必要失望。多数大型的公司并没有对他们的用户行为有很好的理解并且在测试环境中不能产生有代表性的负载。

    有两个共同的似是而非的理由：

    1. 生产负载太大，在上线前无法模拟。

    2. 我没有任何办法知道我的最终用户到底是如何操作的。

    针对第一点,我们可以在上线前环境中建立一个按比例缩减的生产版本，当在生产环境中部署时，再按比例放大。虽然没有做一个生产环境的镜像有效，但是有时并值得那么做。针对第二点，下面将说明如何采集最终用户的操作行为。

    由于我们需要在投入生产之前设法在上线前的环境中调优我们的应用系统，这样才能验证配置，所以一个随之而来的问题就是我们需要在这个环境中执行的负载测试脚本。对一个企业应用进行调优的步骤包括实施一些非常好的实践设置，负载测试应用，观察应用的行为，以及适当调整配置参数等。这是一个叠代过程，我们需要不断调整以达到最优的配置。一些调整可能会提高性能，而一些会降低性能。这也是为什么性能调优不应该放在开发周期后期的一个原因。

    假设我们根据我们的负载脚本进行调优，那对你又意味着什么呢？这意味着负载脚本应该真实反映现实世界用户的使用行为。假设我们在优化一个Web搜索引擎，我们可以写一个测试脚本，该脚本总是在测试苹果和香蕉，但是用户是这样使用吗？我们可以为此调整出最好的性能。但是当查询Bea和IBM时，又会怎样呢？在我的应用中，我可以将技术公司的词汇放在与水果和蔬菜不同的数据库中，那么在测试环境中，永远不会执行到那段代码，我们的调优努力也就徒劳无益了。

    更好的解决办法是确定名列前茅1000 或10,000 个查寻词组和他们频率。然后,计算每个被请求的时间百分比并且编写按照该百分比查询这些词汇的测试脚本。对于剩余的百分比，你可以把负载测试工具连到一个词典，可以随机生成查询的词汇。