通过提供的一套全面的解决方案， 本文描述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 个查寻词组和他们频率。然后，计算每个被请求的时间百分比并且编写按照该百分比查询这些词汇的测试脚本。对于剩余的百分比，你可以把负载测试工具连到一个词典，可以随机生成查询的词汇。
三、使用工具分析
编写一个典型用户负载脚本的困难之处是发现你的用户是怎么使用的应用的。 这不是一门精确的学问。但是为得到一个合理的可靠的结果，第一步是看看您的访问日志。现在，我不会推荐手工做这件事，因为对于一个中型的Web应用，工作量也是巨大的。现在有大量商业或免费工具可为您分析访问日志。
这些工具将告诉你有关你的服务请求的一些情况:
a) 将服务请求按时间的百分比排序，并显示百分比。
b) 放大或缩小分析时间间隔，便于以粗粒度或细粒度方式显示结果。
c) 识别每天，周，月，年的高峰使用时间。
d) 跟踪字节传输和请求的平均时间。
e) 按照你的应用的内部，外部或地理位置，识别和分类请求的用户。
f) 汇总成功请求的百分比。
g) 汇总HTTP发生的错误。
h) 汇总顾客忠诚度， 譬如回头客和平均会话长度。
i) 跟踪从其他站点的转入情况。
无论你选择哪种软件分析访问日志，重要的是你应该做这些分析工作并且把这些信息作为编写测试脚本的基础。有时访问日志的作用是有限的，在某些情况下不能提供足够的信息。例如前端应用只使用一个URL发出请求，而通过在请求中嵌入不同的参数区分业务功能。在这种情况下，需要高级一些的工具根据不同的请求参数监测应用的使用情况和划分业务功能。
访问日志只能提供部分解决办法。接下来需要对应用本身有更深入的理解。例如，当发出一个特定的服务请求时，你应该知道其不同的选项所控制的相应行为。这些信息的好来源是应用的用例和负责该功能的架构设计人员。这些工作的目标是识别出真实世界中用户的使用行为，所以应该彻底和全面地完成此阶段任务。这里发生的错误将导致上文提到的"苹果和香蕉"搜索引擎的问题。
为了全面获得更可靠和更详尽的终用户行为信息，可以考虑Quest公司的User ExperienceMonitor(UEM)。UEM在终用户和WebServer之间，实时捕获向你应用环境发出的每个请求，可提供有关真实用户所做的详尽数据，包括连接速度，浏览器版本，按地理位置汇总等信息。由于采用了被动的网络Sniff技术，所以对应用的性能影响为零。
四、用户如何退出系统
后，有一个值得重视的问题，我们了解到目前客户在编写负载测试脚本时大的错误是：用户不知道怎样退出应用系统。不管你把退出按扭作的多大，至多只有20%用户会使用。这是由于现在将Web作为主要业务平台的必然结果。商业Web站点正式基于此而得以快速发展并统治了Internet.
因此，现在用户习惯以下面方式退出网站：
1. 离开当前网站，转到其他网站
2. 关上浏览器窗口。
由于这已是根深蒂固的Web 使用模式，
所以不能指望用户正确地退出网站。当编写测试脚本时，应用确定正确退出和非正确退出的用户比例，然后根据这个比例编写脚本。我们遇到的一个大型汽车网站，已经为此困扰了一年多，他们的应用服务器每隔几天会崩溃，他们已经习惯于在晚上重起应用服务器。仔细分析HTTP会话的使用模式，我们发现闲置的会话非常多。
我们检查了他们的测试脚本，发现每个测试场景都包含了正确的退出。他们是基于这个假设进行优化的，因此优化工作并没有触及闲置的会话内存问题。在调整测试脚本，重新优化系统环境后，由于"Outof memory"引发的强制重起问题解决了。
