如何对在服务器端使用JSON restful Web服务构建的Web应用程序进行负载测试？

Question

这个问题不是关于使用哪些工具进行负载测试......

这是一个关于应该测试什么的更普遍的问题。

背景：

多年前，大多数企业Web应用程序过去都被设计为前端和后端混合在一起，并且任何类型的业务逻辑都在服务器端完成。而前端的责任只是展示UI。

负载测试此类应用程序时，无论是Oracle EBS还是SAP的东西，还是使用像Struts这样的框架构建的应用程序。

我们做的是：
 1.设计用户测试用例。 （如登录，搜索，放入购物车，然后查看日志）
 2.编写测试脚本来存档这样的测试用例（下划线，它是对服务器端的纯http调用）
 3.使用LT工具一起生成大量虚拟用户来运行此类测试。 （它的行为就像有很多用户一起做同样的业务逻辑）

现在，在前端和后端完全分离后，整个事情发生了变化。

许多业务逻辑可以放在前端，服务器端只有单独的restful web服务......

我发现我们不能像以前那样进行负载测试。

仅仅因为用户的测试用例无法映射到http通信。由于某些任务完全在前端完成......

但在这样的新世界中，如何进行性能测试？只是对JSON restful Web服务进行性能测试？如何将静态资源从服务端传输到浏览器？

我需要那些为这样的JSON restful web服务应用程序完成大量性能/负载测试的建议。

Answer 1

您的负载测试不应仅限于后端。表现良好的负载测试需要尽可能接近真实用户的真实用户，包括（但不限于）：

• HTTP Headers类似于识别浏览器的User-Agent，用于内容压缩的Accept-Encoding等。
• HTTP Cookies，用于身份验证和跟踪用户会话
• Caching mechanisms - 浏览器用于下载嵌入在网页中的图像，脚本和样式，并将它们存储在本地，以便后续请求这些“重”实体不会被重新下载，而是从浏览器的磁盘返回高速缓存
• AJAX requests是异步JavaScript驱动的调用，用于动态更新页面内容而无需重新加载整页。棘手的一点是AJAX请求是并行执行的（即一个主要请求“产生”几个并行的AJAX请求）并且大多数负载测试工具无法处理这种情况

因此，您的测试目标需要前端，而不是后端，因为后端测试不会告诉完整的故事，您可能会错过重要的事情。有关适用于How to make JMeter behave more like a real browser免费和开源负载测试工具的更详细说明和示例配置，请参阅Apache JMeter文章（但该方法应与工具无关，无论负载测试是什么，都应遵循相同的步骤工具正在引擎盖下使用）

Answer 2

我同意用富客户端测试“逼真”的流量模式变得更加困难。情况也是如此，随着越来越多的事情转移到客户端，可扩展性测试变得更像是测试后端API。

像Dmitry所写的那样，测试整个内容交付系统总是很有用，但考虑到测试自己的API和提供图像的CDN之间的选择，我会说测试API更为重要。这就是您最有可能发现可伸缩性问题的地方。

我们已经意识到许多人根本没有加载测试的原因是因为它只是“太多的工作”而且对现实测试的要求是这一点的主要因素。我们写了一篇很快发布的“以开发人员为中心的负载测试”宣言，认为“简单测试总比没有测试好”。可能看起来很明显，但是大多数人今天根本没有加载测试。出于这个原因，我们提倡开始非常简单，通过小的“单位负载测试”来达到单个API端点。编写几个非常简单的测试并开始定期运行它们（理想情况是在CI系统上每晚构建），只需单独执行API端点，并查看它们可以采用的每秒请求数（或您想要测量的任何指标）。

这些简单的测试 将为您提供很多价值，只需要很少的努力 - 80/20规则的实施。他们测试整个系统中最相关的部分，你看到的任何因为这次测试而出现的烟雾都可能会告诉你当系统处于“真实”（如“现实”）压力下时会爆炸的位置。您还应该能够检测到大多数性能回归作为额外的奖励。最后，由于它们的简单性，这些小的“单元负载测试”更容易维护;它们不会像复杂/真实的测试那样快速地过时，如果它们这样做，它们就更容易更新。

当您拥有一个提供价值的“单位负载测试”测试套件时，您可以随时反复增加复杂性和真实性，直到您花费的时间的投资回报率变得太低而不能激励任何进一步的努力。这种方法与构建常规单元测试套件的标准方法实际上没有区别。