㈠ web压力测试 要测试哪些方面
web压力测试通过产生真实压力来发现问题需要关注以下方面：
1、对要测试的系统进行分析，明确需要对哪一块做压力测试。比如：淘宝网站双十一期间，秒杀跟支付，此模式用户操作中占比比较大
再比如：游戏，登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大
那么就可以针对这种占比比较大的模式进行压力测试
2、明确了要测试的点后，如何对这些测试点进行施压呢？
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作；
第二种方式就是借助一些压力测试工具如:JMeter或LoadRunner
3、如何对这些测试点进行正确的施压呢？
那么就需要用压力测试工具或者其它方法来录制脚本，模拟用户的操作
4、对测试点该施加多大的压力比较合适？该施加多少的数据才能找出系统的瓶颈？
那么就需要明确压力测试所限制的数量，即用户并发量，这里分3种情况来明确：
1）根据上级的明确规定数量，来设定最确大值，然后根据情况往上或往下增减
2）上级未规定，由自己判断，从1开始慢慢递增。如：1，5，10，20等等
3）若做过压力测试，则可以根据上次的压力测试结果为基数进行测试
5、测试完之后，如何通过这些数据来定位性能问题呢？
虽然通过这些测试结果我们可以得到TPS(吞吐量)，平均响应时间等这些数据，可判断出服务器是否存在问题，但却不能定位问题。
㈡ 怎样正确做 Web 应用的压力测试
你好，一个完整的压力测试需要关注三个方面：如何正确产生压力、如何定位瓶颈、如何预估系统的承载能力
(1)
首先说一下如何产生压力，产生压力的方法有很多，通常可以写脚本产生压力机器人对服务器进行发包和收包操作，也可以使用现有的工具(像jmeter、LoadRunner这些），所以说产生压力其实并不难，难点在于产生的压力是不是真实地反映了实际用户的操作场景。举个例子来说，对游戏来说单纯的并发登陆场景在整个线上环境中的占比可能并不大(新开服等特殊情况除外)，相反“登陆-开始战斗-结束战斗”、不同用户执行不同动作这种“混合模式”占了更大的比重。所以如何从实际环境中提炼出具体的场景比重，并且把这种比重转化成实际压力是一个重要的关注点。
(2)
产生压力之后，通常我们可以拿到TPS、响应时延等性能数据，那么如何定位性能问题呢？TPS、响应时延只能告诉你服务器是否存在问题，但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合作用的结果，这时候可以先关注系统的CPU、内存、IO、网络，对比在tps、时延达到瓶颈时这些系统数据的情况，确定性能问题是系统哪一部分造成的，然后再回到代码的逻辑中逐个优化这些点。
(3)
当服务器的整体性能就可以相对稳定下来，这时候就需要对自己服务器的承载能力有一个预估，通过产生真实压力、对比系统数据，大致可以对单套系统的处理能力有个真实的评价，然后结合业务规模配置服务器数量。
㈢ 如何对Web服务器做压力测试
apache压力测试
ab -n 1000 -c 1000 http://test.com/index.php
㈣ 如何进行需要登录的WEB系统的压力测试
0
一般压力测试工具都有录制功能，也就是可以把你的操作“录”下来再“重放”。你可以用录制工具把登录的动作录下来，再进行压力测试。
我用JMeter做过压力测试，使用过badboy录制过，很好用。如果你用的是loadrunner，也有相应的工具。不过很难找到这些工具
㈤ 关于Web系统的压力测试
压力测试没有一个固定的数值，一般凭经验或客户要求。
压力测试不达标一般是2种情况。
1.程序出现异常，大量数据的读写可能会出现代码或数据库的异常。根据异常的不同修改就是了。
2.效率低下。就是程序不会有问题就是执行时间太长了，这个需要改善就麻烦了，一般从SQL语句上节省数据库访问次数，再就是从逻辑上避免多重循环等方法解决。
-------------------------------------------
大公司的话一般设有专门的测试人员，现在这个领域还没有专门的书籍或标准，基本都时凭借经验。
㈥ 怎样正确做 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种工具都能自动生成图形报告。这样你就能判断出服务器的瓶颈在哪里。是需要增加内存还是提高处理器性能，或者增加硬盘。
㈦ 怎样测试服务器压力
下载并安装WAST；
1．设置并行连接数；
2．设置持续时间；
3．其余设置；
注：所有以上的选项可以根据自己的需要进行设置。
设置完成后就可以进行压力测试。测试的步骤如下：
第一步，点击工具栏上的“New Script”按钮，在打开的面板中点击“Nanual”按钮创建一个新的测试项目。在打开的窗口中对它进行设置，在主选项中的Server中填写要测试的服务器的IP地址。这里我们填写192.168.1.20。在下方选择测试的Web连接方式，这里的方式Verb选择get。Path选择要测试的Web页面路径，这里填写/Index.asp即动网的首页文件，WAST可以设置更多的Path。
第二步，在“Settings”功能设置中将Stress Level （Threads）线程数设置为1000。然后点工具中的灰色三角按钮即可进行测试。测试过程中我们可以从服务器的任务管理器中看到CPU使用率已经达到100%，损耗率达到最大。在CMD窗口中使用命令netstat -an，可以看到客户端的IP地址在服务器上的80端口进行了非常多的连接，而且Web网站已经打不开了，提示过多用户连接。
