分类：
2008-10-15 16:42:44
通过提供的一套全面的解决方案, 本文描述Quests Application Management Suite for and Portals是如何与该方法论相集成，从而在应用开发生命周期的每个阶段保证您的成功。运用这套方法论和Quest的应用管理解决方案,您将充满信心地把符合性能规范的应用展现给您的用户。
本文同时强调自动化的重要性，采用自动化方式可以创建重复的过程并迅速报告应用代码的质量。只有自动化方式才能保证正确地遵循这些过程，并且保证准确和一致地测试应用组件。
导言
性能测试已经成为软件开发界的一个事后总结出来的想法。IDG 的研究报告指出只有20%的上线的企业 应用符合他们的性能要求。如果所有上线的企业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. 我没有任何办法知道我的最终用户到底是如何操作的。
针对第一点,我们可以在上线前环境中建立一个按比例缩减的生产版本，当在生产环境中部署时，再按比例放大。虽然没有做一个生产环境的镜像有效，但是有时并值得那么做。针对第二点，下面将说明如何采集最终用户的操作行为。
[1]
