这个问题与进行负载测试的工具无关...
这是关于应该测试的更一般的问题。
背景：
几年前，大多数企业Web应用程序曾经设计为将前端和后端混在一起，并且在服务器端完成了任何类型的业务逻辑。尽管前端的责任只是显示UI。
加载测试该应用程序时，无论是Oracle EBS还是SAP的东西，还是使用Struts(例如Struts(构建的应用程序。
我们要做的是：
1.设计用户测试案例。(例如登录，搜索，将STH放在购物车上，然后检查日志(
2.将测试脚本编写为存档此类测试案例(下划线，它是纯HTTP调用服务器端(
3.使用LT工具一起生成大量虚拟用户以运行此类测试。(它的行为就像有很多用户一起进行相同的业务逻辑(
现在，在前端和后端完全分开后，整个事情发生了变化。
很多业务逻辑可以放在前端，服务器端仅具有单独的RESTFUL Web服务...
我发现我们无法像以前那样进行负载测试。
仅仅因为用户的测试用例无法映射到HTTP通信。由于某些任务在前端完全完成...
但是在如此新的世界中，如何进行绩效测试？只是性能测试JSON RESTFUL Web服务？从服务端传输到浏览器的静态资源怎么样？
我需要这些建议的建议/负载测试，以进行此类JSON RESTFUL WEB服务应用程序。
您的负载测试不应是仅限于后端。行为良好的负载测试需要表示坐在实际浏览器后面的真实用户，包括(但不限于(：
：- http标头，例如用户代理，标识浏览器，用于内容压缩等的接受编码等。
- 用于身份验证目的和跟踪用户会话 的HTTP cookie
- 缓存机制 - 浏览器用于下载嵌入在网页中并在本地存储在本地的图像，脚本和样式的浏览器，以便在后续请求下将这些"重"实体无法重新下载，而是从浏览器的磁盘缓存中返回li>
- AJAX请求是异步的JavaScript驱动的呼叫，用于即时无需重新加载完整页面即时更新页面内容。棘手的点是，AJAX请求正在并行执行(即一个主要请求"产生"几个并行AJAX请求(，大多数负载测试工具无法处理这种情况
因此，您的测试目标需要为 frontend ，而不是后端，因为仅后端测试并不能说明全部故事，您可能会错过一些重要的东西。请参阅如何使Jmeter更像真正的浏览器文章，以获取适用于Apache Jmeter免费和开源负载测试工具的更详细的说明和示例配置(但是，无论如何，该方法应该是工具 - 不平衡，无论如何，您都应遵循相同的步骤负载测试工具在引擎盖下使用(
我同意，与富裕客户一起测试"现实"流量模式变得更加困难。同样，随着越来越多的事物移至客户端，可伸缩性测试变得更多地涉及测试后端API。
就像Dmitry写的那样，测试整个内容交付系统始终很有用，但是考虑到测试自己的API和提供图像的CDN之间的选择，我会说测试API更重要。那是您很可能会找到可伸缩性问题的地方。
我们已经意识到，许多人根本不加载测试的原因是因为它只是"太多的工作"，对现实测试的要求是对此的主要因素。我们已经写了一份"以开发人员为中心的负载测试"宣言，即将发布，该宣言认为"简单的测试总比根本没有测试要好"。似乎很明显，但仍然大多数人今天根本没有加载测试。因此，我们提倡非常简单的启动，并以小的"单位负载测试"达到一个API端点。编写一些非常简单的测试，然后开始定期运行它们(理想情况下，在CI系统上构建(，只需单独锻炼API端点，然后查看每秒多少个请求(或您想测量的任何指标(。
这些简单的测试将为您提供很少的努力的价值 - 80/20的行动规则。他们测试了整个系统中最相关的部分，并且您看到的任何烟雾都可能会告诉您，当您将系统放在"真实"(如"现实"中(时，您的系统将在哪里爆炸。您还应该能够将大多数性能回归视为额外的奖励。最后，这些小的"单位负载测试"由于简单而更容易维护。它们不会像复杂/逼真的测试那样快地过时，如果这样做，它们更容易更新。
当您拥有一个提供价值的"单位负载测试"测试套件时，您可以随着时间的流逝添加复杂性和现实性，直到花费时间的投资回报率变得太低，无法激励任何进一步的努力。这种方法和建立常规单元测试套件的标准方法确实没有区别。