怎样正确做 Web 应用的压力测试

关于工具的选择
不少答案都提到了测试工具，但其实工具并不是最重要的，那么多的测试工具，HP的是LoadRunner、IBM的是Rational Performance Tester、Apache有Jmeter（免费开源）、还有Borland的SilkPerformer，这些都是可以的。有人提到了Apache的AB，AB不是说不行的，但既然问题是"正确的压力测试"，那么还是选择一个那些容易支撑起复杂业务的性能场景的工具吧。

什么样的工具能够在脚本中让你模拟业务场景中一个用户的行为？什么样的工具能够在场景中让你模拟业务场景中一群用户的行为？什么样的工具能够让你模拟用户所处于的使用环境？什么样的工具能够让你比较方便、快捷的通过它的性能图表了解Web应用的大致性能表现？答案肯定不会是那些对某个URL不断施压的那些工具。

关于场景的设计过程
我所了解的情况来看，过半数的性能测试人员并不了解自己执行的性能测试场景代表的是用户生产环境中什么样的场景。事实上对于我来说，我也很难正确的说清楚“性能测试”、“负载测试”、“压力测试”、“可靠性测试”、“配置测试”、“疲劳测试”这些测试的概念。

但我知道，任何一个场景的设计都必须首先明确一些相关的性能指标，这些指标的阈值一旦被超出，那么场景一般是不必继续执行的。

关于性能指标我们可以几个角度来看：
首先是用户视角的性能指标，一般来说这些指标包括了测试事务的平均响应时间、最大响应时间、90%事务的响应时间、事务响应时间标准差，我们通过着一些指标来判断用户实际获得的性能体验如何。然后是运维视角指标，点击率、吞吐量、处理能力、各种硬件资源占用、运维通过这些指标来了解目前应用的处理能力，通过业务增长了解何时需要进行扩容，还有开发视角的指标，锁竞争。具体要考虑的视角由项目干系人、关键角色定义。

采用的指标确定好以后，再开始为这些指标定义阈值，例如事务的响应时间，也许用户认为请求在2秒以内得到响应是满意的，5秒以内响应是一般，超出8秒则会感觉太慢，超出10秒会超出了可容忍的上限，那么对于这一项指标来说，它的阈值可以是：
<2秒响应，优秀
<5秒响应，良好
<8秒响应，较差
>10秒响应，超出可容忍上线
关于用户性能体验的指标一般会划分为4个级别。硬件指标至少也会划分2个级别。

系统在任何时候都应该为用户提供优秀的响应体验吗？并不总是，在2倍的峰值负载中，我认为良好、甚至较差的响应体验也是可接受的。那是不是说在正常的峰值负载中，各项指标表现不在优秀范围内就是不理想呢？也不一定，要看正常的峰值负载持续时间长短是否合理。

场景的设计不合理最终将可能导致我们面对一堆性能缺陷无法确定处理的优先级。

场景设计中，重点考虑的问题：
脚本测试数据符合典型用户的数据差异（测试账号差异、操作数据差异、提交表单参数差异等）
脚本操作次序符合典型用户的操作差异（思考时间、业务间间隔等）
脚本执行符合典型用户的使用环境（浏览器缓存模拟、带宽模拟等）
测试环境的业务基础数据必须合理（0年到N年的基础数据）
测试场景所产生的负载必须合理（代表峰值的负载？代表1.5倍峰值的负载？代表促销活动的负载？）

 

一般都是使用工具，可以模拟多用户 同时/异步 地进行
比较好的工具，要钱的有loadrunner
不要钱的有JMeter

这2种工具都能自动生成图形报告。这样你就能判断出服务器的瓶颈在哪里。是需要增加内存还是提高处理器性能，或者增加硬盘。

 

 
性能/压力测试的内涵：

• 基准/基线测试 base line testing / benchmark testing
• 负载测试 load testing
• 压力测试 stress testing
• 稳定性测试 scalability testing
• 疲劳测试 endurance testing
• 组合测试 combination testing
• 远程/机房测试 remote/local testing

测试指标有哪些要关注的：

• 响应时间：从用户角度
• 服务器资源：从系统角度
• 吞吐量：从业务角度

所谓法不传六耳，一般人只会跟你讲XX工具，把你引入学工具的汪洋大海，但是打死也不会告诉你原理，会给你讲一大堆你看不懂的数学公式，但不会教你这些。了解清楚原理之后，那些数学公式仅仅是中小学生水平的，难道还会看不懂吗。