本文将从负载测试的角度，来讲述要顺利进行5万并发测试需要做些什么。讨论记录见文末。步骤快速总结编写脚本使用JMeter进行本地测试BlazeMeter沙盒测试使用一个控制台和一个引擎设置每个引擎的用户数设置和测试您的集合（1个控制台和10-14个引擎）使用主/从功能实现您的***CC目标第1步：编写脚本在开始之前，确保从JMeter的Apache社区jmeter.apache.org获得最新版本。您还将下载这些额外的插件，因为它们可以使您的工作更轻松。获取脚本的方法有很多：使用BlazeMeter的Chrome扩展来记录你的场景功能/QA测试）如果您的脚本是记录的结果（如步骤1和2），请记住：您需要更改特定的内容，例如用户名和密码参数，或者您可能想要设置一个CSV文件，其值可以对每个用户不同。为了满足“添加到购物车”、“登录”等请求，您可能希望使用正则表达式、JSON路径提取器、XPath提取器来提取令牌字符串、表单构建ID和其他元素等元素，以保持脚本参数化，并使用配置元素（例如默认HTTP请求）来启用在您之间切换时，您的工作会更轻松。第2步-使用JMeter在1个线程的1次迭代中使用查看结果树元素、调试示例、虚拟示例和打开日志查看器（一些JMeter错误将报告）进行本地测试，以调试您的脚本。遍历所有场景（包括True或False响应）以确保脚本按预期运行......成功后使用一行流程测试后-将其增加到10分钟10到20个线程继续测试：如果您希望每个用户独立-是这样吗？你有没有得到任何错误？如果您正在进行注册流程，那么请查看您的后端-帐户是否根据您的模板创建？他们独立吗？从总结报告中，您可以看到测试的统计数据——它们有用吗？（平均响应时间、错误、每秒点击数）准备好脚本后：通过删除任何调试和虚拟示例来清理脚本，如果使用侦听器（例如“将响应保存到文件”），则删除脚本侦听器，请确保您没有使用任何路径！，如果它是一个监听器或CSV数据集配置-确保你没有使用你在本地使用的路径-只是文件名（就像你在同一文件夹中的脚本）如果你使用你自己的专有JAR文件，请确保它也被上传。如果您使用多个线程组（不是默认线程组）-请确保设置此值。第3步：BlazeMeter沙盒测试如果这是您的第一个测试-您应该查看这篇关于如何在BlazeMeter中创建测试的文章。将沙盒的测试配置设置为，用户300、1个控制台、50分钟。像这样配置沙箱允许您在后台测试脚本并确保一切在BlazeMeter上运行良好。为此，首先按下灰色按钮：告诉JMeter引擎我想要完全控制！-要完全控制您的测试参数您将遇到的常见问题：防火墙-确保您的环境对BlazeMeter的CIDR列表开放（它们会实时更新）并将它们放入白名单确保您的所有测试文件，例如：CSV,JAR,JSON,User.properties等可用确保你没有使用任何路径如果你仍然有问题，请查看错误日志（你应该能够下载整个日志）。沙箱配置可能如下所示：引擎：是启用控制台（1个控制台，0个引擎）线程：50-300提升：20分钟迭代：保持测试时间：30-50分钟这将允许您在提升期间获得足够的数据（以防您遇到问题），您将能够分析结果以确保脚本按预期执行。您应该查看Waterfall/WebDriver选项卡以查看请求是否正常，此时您不应该出现任何问题（除非您故意这样做）。您应该密切关注监视器选项卡并观察一段时间内的内存和CPU消耗-这将有助于您在第4步中尝试设置每个引擎的用户数。#p#step4：使用1个控制台和1个引擎来设置每个引擎的用户数量现在我们可以确定该脚本将在BlazeMeter中完美运行-我们需要计算出要在引擎中放置多少用户。如果你可以使用sandbox使用测试中的数据来做出这个决定，那就太棒了！在这里，我将给出一种无需回头查看沙盒测试数据即可计算此数字的方法。设置您的测试配置：线程数：500生产力提升：40分钟迭代：***持续时间：50分钟使用一个控制台和一个引擎。运行测试并监控（通过监控选项卡）您的测试引擎。如果你的引擎是75%的CPI使用率并且85%的内存使用率没有达到（一次性峰值可以忽略）：调整线程数为700，提交一次测试线程数，直到线程数达到1000或60%的CPU或内存使用率如果您的引擎在75%CPU使用率或85%内存使用率之后（可以忽略一次性峰值：查看您第一次达到75%的点以及当时有多少并发用户点。在运行测试之前，这次不是提升之前的500个用户的容量，而是将容量提升放入实际测试中（5-15分钟是一个好的开始）并将持续时间设置为50分钟。确保你没有在整个测试过程中CPU使用率超过75%或者内存使用率超过85%...为了安全起见，可以将每个引擎的线程数减少10%。第五步：安装和测试集群我们现在在知道我们从一个引擎获得了多少个线程之后，在本章的最后，我们将知道一个集群可以为我们提供多少用户。集群意味着拥有一个控制台（只有一个）和0-14个引擎的逻辑容器。即使您可以创建一个使用超过14个引擎的测试用例-但实际上创建了两个集群（您可以注意到控制台的数量增加了），并克隆了您的测试用例......每个集群都有最多14个引擎是基于BlazeMeter自己测试确保控制台可以控制这14个引擎对新创建的大量数据处理的压力。因此，在这一步中，我们将从第4步开始进行测试，只需修改引擎的数量，将其增加到14个。在最终测试的整个持续时间内运行测试。在测试运行时，打开Monitor选项卡并验证：1.没有引擎超过75%CPU和85%内存限制；2.找到您的控制台选项卡（您可以通过单击日志选项卡->网络信息来执行此操作，查看控制台的私有IP地址以找到它的名称）-它不应被限制在75%CPU和85%记忆。如果您的控制台达到该上限-减少引擎数量并重新运行，直到控制台低于该上限。在这一步结束时，您会发现：1.每个集群的用户数；2.每个集群的命中率。查看聚合表中的其他统计数据，并找到本地结果图以获取有关集群吞吐量的更多信息。第6步：使用主/从功能来实现您的***CC目标我们到了最后一步。我们知道脚本正在运行，我们也知道一个引擎可以支持多少用户以及一个集群可以支持多少用户。我们做一些假设：一个引擎支持500个用户，一个集群可以使用12个引擎。我们的目标是对50,000名用户进行测试。所以为了完成这个，我们需要8.3个集群。我们可以使用8个集群，每个集群有12个引擎和一个4个引擎集群——但最好像这样分散负载：我们每个集群使用10个引擎而不是12个，然后每个集群可以支持10*500=5K用户，我们需要10个集群来支持500万用户。这有以下好处：我们可以通过简单地复制现有集群来添加5K用户，而不是维护两种不同的测试类型（5K比6K更常见）我们可以根据需要继续添加现在我们准备创建最后的510,000次用户级主/从测试：将测试名称从“Myprodtest”更改为“Myprodtest-slave1”。让我们回到第5步，在AdvancedTestProperties下将Standalone更改为Slave。按保存按钮-现在我们有一个主站和9个从站之一。回到你的“我的产品测试-slave1”。按下复制按钮并重复步骤1-5，直到您创建了9个从站。返回“Myprodtest-salve9”并按下复制按钮。将测试名称更改为“Myprodtest-Master”。将AdvancedTestProperties下的Slave更改为Master。查看我们刚刚创建的所有从站（Myprodtest-salve1..9）并按保存。您的50,000用户级别的主从测试已准备就绪。通过按下主服务器上的开始按钮，对5k用户运行10次测试。您可以修改任何测试（salve或master）以来自不同的区域、具有不同的脚本/csv/和其他文件、使用不同的网络模拟器、不同的参数等。您可以在新选项卡中找到生成的聚合结果报告主报告称为“主负载结果”。您还可以通过打开单独的报告来独立查看每个测试结果。英文原文：Howtorunaloadtestof50k+concurrentusers翻译自：http://www.oschina.net/translate/how-run-load-test-50k-concurrent-users
