① 如何对Web应用程序进行负载测试
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 1000 名典型用户在站点活动时的情形。您需要定义测试用例以代表各种用户活动：例如，购买股票或注册新的帐户。接下来，您必须估计用户在这些测试用例上的分布。对以下数据进行假设，即模拟真实用户与应用程序交互时，需要多长的思考时间（或等待时间）。因此，负载测试期间活动的可从某个方面大致反映出同样数量的真实用户在站点活动时的情形。 这种方法有几个不足之处。首先，其结果不会比您做的假设更好。显然，不正确的假设将使结果出现偏差。 其次，估计真实用户需要大量客户端硬件。如果对每名虚拟用户给定需要的处理能力和内存量，则典型的客户端计算机可以处理大约 200 名虚拟用户。因此，对 2000 名用户并发处理级别的测试需要 10 台客户端计算机 — 这是一笔重大投资。测试使用 HTTPS 的站点将需要多得多的客户端硬件。 最终，此方法难以向您的开发团队提供以操作为导向的信息。当某处出现故障时，常常难以再现该问题。 作为备选方案，我们建议您围绕以下这些关键问题设计测试用例： �6�1 系统瓶颈在哪里？系统能同步处理多少个并发请求？ �6�1 在响应时间变得不可接受之前，一台机器能处理多少名不同步的超级用户？ �6�1 添加额外的硬件时，结果是线形增长的吗？ �6�1 有任何稳定性问题会妨碍站点运行于生产环境中吗？ 此方法将使用开发团队（此开发团队参与可能出现问题的领域）提供的附加信息。请关注这些领域。对于上一个示例，其瓶颈可能出在定单提交领域。从这里您可以派生出更具体的问题，例如“提交流程可以同时处理多少个请求？”攻击这些特定领域是最快且成本最小的方法，用来向开发团队提供以操作为导向的信息，以便他们能改进系统。在使用这种方法的同时，我们推荐您记住遵循以下建议。 关注负载测试正如我们已提到的那样，首先要做的是构建导致潜在瓶颈和稳定性问题的脚本。这种“数据第一，假设第二”的方法使您能够从应用程序收集原始数据，然后根据假设确定更高级别的结果。不用担心为识别低风险站点的脚本编写问题。例如，为站点的帮助领域或只读文档领域编写脚本不大可能出现系统瓶颈。 同步请求使用同步请求攻击瓶颈。此处的这个主意是模拟最坏的情况：即，站点上的用户精确地在同一时间攻击瓶颈。通过使用户同步，您可以重复进行此测试。如果不同步结果，则难以再现故障情况。可以使用同步点做到这一点，同步点是大多数较健壮（成本也较高）的测试工具中提供的一项功能。同步点迫使每名虚拟用户一直等到剩余的用户到达脚本中定义的点后，才能开始下一请求。它允许您精确并重复地确定站点的潜在瓶颈区域能处理的并发用户数。例如，下限可以是 7 名并发同步用户。 创建循环测试用例脚本使测试用例循环。在另一种方法中，每次测试用例迭代前后，站点应处于相同状态。这允许您长时间地重复运行测试用例。 使用超级用户最后，使用我们所称的超级用户。正如前面所提到的，超级用户运行时思考时间设置为零。请记住，思考时间假设是用于常规测试中，以使虚拟用户模拟真实用户。但是，如果将虚拟用户思考时间减半，则服务器的实际负载将加倍。在另一种方法中，服务器真正关心的与负载有关的变量是每秒的请求数。虚拟用户的数量及其思考时间结合起来生成该负载。 让我们进行一些数学运算以使此概念更清晰。下面的公式计算访问站点的真实用户生成的负载（请求数/秒）： 例如，某个站点有 100 名并发用户，假设下载时间为 10 秒，思考时间为 30 秒，则每秒将生成 2.5 页。如果我们假设每页 3 个请求，则在 Web 服务器上将转化为每秒 7.5 个请求。 以超级用户运行测试时，观察每秒请求数，并与刚刚计算的值比较。根据我们的经验，真实用户数与超级用户数的比例通常约为 15:1。对于同一个示例，这意味着 (100/15) 名超级用户将生成与 100 名普通用户相同的负载。再举一个例子，假设在 10 名超级用户之后响应时间变得不可接受。请注意转换回真实用户数的该点每秒请求数。现在您可以进行任何希望的思考时间假设，甚至可以更改它而无需重新运行测试。在几天的测试之后，您将能根据直觉从超级用户数转换成真实用户数。此方法允许您保持用户数可控，减少所需的客户端硬件数量，并包含负载测试软件的成本。 这些超级用户测试用例对于多机测试很有用。要测试站点的可伸缩性，可添加第二台 Web 服务器和一个负载平衡器，并重复超级用户测试。理想情况下，在看见相同的相应次数之前，您将能加倍超级用户数量。 要回答稳定性问题，可运行测试，以在延长的时间段内维持合理数量的并发且未同步超级用户。我们在上一个项目中熬了很多个通宵，甚至 24 小时昼夜不停，但持续时间与应用程序有关。我们称之为“内置”测试。一旦您已采取步骤识别并潜在地解决了找到的瓶颈，则重复同步点测试，看下限是否有所增长。然后用所支持的新的并发用户数重新运行“内置”测试。以努力提高此数字为目标重复该循环，直到达到质量条。 但是有多少用户呢？ 尽管此方法向开发团队提供了有价值的信息，但它使得您更难于回答会议室的问题。不过，您可以近似地估计答案。例如，假设站点的最坏情况瓶颈显示，每台计算机多于 20 名超级用户的情况下，响应时间超过 10 秒。根据您从我们建议的公式计算的结果，近似地估计有 300 名真实用户（20 名超级用户 × 15 名真实用户）。此时，您可以做出与常规用例中相同的假设。通常情况下，有百分之多少的用户正在使用站点的此领域？假设预期 50% 的用户正在使用此领域，而其他领域，例如文档或数据库读取，用户比例则没有这么大。这意味着具有一台 Web 服务器的系统将处理大约 600 名用户。 到目前为止，我们已讨论了在能明确地指向站点的一个瓶颈领域的情况下该如何做，但如果影响性能的领域不止一个时您又应如何做呢？答案是创建单独查看各个领域的测试脚本。首先孤立地运行这些脚本，然后一起运行。再比较结果，看站点的一个领域对另一个领域的影响有多大。
② 如何使用websocket压力并发测试工具
apache自带的ab.exe 可以
如果没有理解错误，websocket是依托于web server，
比如IIS，Apache.所以性能测试也是针对他们提供的socket模型进行.
③ Web压力测试常用的工具有哪些
可以使用以下几种常用工具：
- bullbench
- jmeter
- webbench
- tcp
祝楼主早日找到合适工具
④ Web 压力测试有什么低成本的方法
loadrunner搞起~~~~~~~~~~~~~如果熟悉协议，还有些免费发包工具可以自己定制报文流程。
⑤ 如何利用VS2013 做Web性能测试和负载测试67
定义测试策略 到目前为止，您肯定参加过这样的会议，客户倚靠在宽大的会议桌上，问您：“这个系统能处理上千个用户吗？”传统的负载测试方法要求您编写脚本并执行测试，以试图给出此问题的精确答案。对于这种测试，您需要定义“处理”的含义以及 100...
⑥ 怎样正确做 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种工具都能自动生成图形报告。这样你就能判断出服务器的瓶颈在哪里。是需要增加内存还是提高处理器性能，或者增加硬盘。
⑦ 如何正确的做WEB端的压力测试
1、对要测试的系统进行分析，明确需要对哪一块做压力测试。比如：淘宝网站双十一期间，秒杀跟支付，此模式用户操作中占比比较大
再比如：游戏，登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大
那么就可以针对这种占比比较大的模式进行压力测试
2、明确了要测试的点后，如何对这些测试点进行施压呢？
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作；
第二种方式就是借助一些压力测试工具如:J
⑧ web压力测试 要测试哪些方面
web压力测试通过产生真实压力来发现问题需要关注以下方面：
1、对要测试的系统进行分析，明确需要对哪一块做压力测试。比如：淘宝网站双十一期间，秒杀跟支付，此模式用户操作中占比比较大
再比如：游戏，登录--开始战斗--结束战斗这种混合模式在用户操作中占比较大
那么就可以针对这种占比比较大的模式进行压力测试
2、明确了要测试的点后，如何对这些测试点进行施压呢？
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收包操作；
第二种方式就是借助一些压力测试工具如:JMeter或LoadRunner
3、如何对这些测试点进行正确的施压呢？
那么就需要用压力测试工具或者其它方法来录制脚本，模拟用户的操作
4、对测试点该施加多大的压力比较合适？该施加多少的数据才能找出系统的瓶颈？
那么就需要明确压力测试所限制的数量，即用户并发量，这里分3种情况来明确：
1）根据上级的明确规定数量，来设定最确大值，然后根据情况往上或往下增减
2）上级未规定，由自己判断，从1开始慢慢递增。如：1，5，10，20等等
3）若做过压力测试，则可以根据上次的压力测试结果为基数进行测试
5、测试完之后，如何通过这些数据来定位性能问题呢？
虽然通过这些测试结果我们可以得到TPS(吞吐量)，平均响应时间等这些数据，可判断出服务器是否存在问题，但却不能定位问题。
⑨ 关于Web系统的压力测试
压力测试没有一个固定的数值，一般凭经验或客户要求。
压力测试不达标一般是2种情况。
1.程序出现异常，大量数据的读写可能会出现代码或数据库的异常。根据异常的不同修改就是了。
2.效率低下。就是程序不会有问题就是执行时间太长了，这个需要改善就麻烦了，一般从SQL语句上节省数据库访问次数，再就是从逻辑上避免多重循环等方法解决。
-------------------------------------------
大公司的话一般设有专门的测试人员，现在这个领域还没有专门的书籍或标准，基本都时凭借经验。