在本文中，我们将分享我们在测试运行在MS Azure云中的Web Apps应用程序（在线商店）时获得的实践经验，以及描述我们用于解决此问题的工具以及根据这些发现得出的结论。结果。
测试对象
我们选择了VirtoCommerce店面（用作在VirtoCommerce平台上创建的应用程序的前端的Web应用程序）作为测试对象。
为了真实了解系统的功能，我们需要模拟尽可能接近实际情况的用户请求。 检查可能在缓存中的主页，然后声称我们的速度为1k req / sec，这没有任何意义。 在现实生活中，这种性能指标毫无意义。
因此，为了使我们的测试结果具有统计上的意义，并尽可能接近实际流量反映性能指标，决定使用与在线商店中的实际用户行为尽可能接近的查询。
让我们详细介绍以下操作，其中包括“真实”测试：
用户操作（测试类型）
| 占请求总数的百分比
|
查看带有产品的独特类别页面
| 30％
|
查看独特的产品卡
| 40％
|
将商品添加到购物车
| 10％
|
通过唯一的关键字或属性搜索产品
| 20％
|
图 1.用户的主要行为及其特定的使用频率。测试数据准备
任何测试中最重要的阶段是数据准备。 测试数据的选择应尽可能与真实系统中的数据相对应，无论是数量还是质量（通信，结构等）。 如果可能的话，数据总量应该足够，以便在测试时尽可能少地重复调用相同的数据，这将避免频繁使用缓存，从而对系统性能产生最悲观的印象。
通常，在线商店的主要数据是：产品和类别的目录，其中包含价格，折扣和余额信息。
作为测试环境的填充，使用了真实的目录数据，这些数据将在主要生产环境中使用：
图2。 用于填充被测系统的数据。显然，对于不熟悉VirtoCommerce目录结构的读者而言，某些数据类型可能没有任何意义，但是尽管如此，我们还是会展示它们，以便至少对数量顺序有所了解。
项目准备和记录测试
作为负载测试的主要工具，我们将使用MS Visual Studio Enterprise 2017（其他Studio版本可能不支持此类项目）和项目类型
Web Performance and Load Test Project 。
图3。 创建一个新项目。创建项目后，我们将需要为每个先前定义的用户操作创建测试。 作为示例，我们限制自己为一个用户操作创建测试，因为其余的操作是通过类推创建的。
对于测试，我们将使用Visual Studio中内置的标准类型的测试Web性能测试。
我们将创建的第一个测试将是显示在线商店中产品详细信息的测试。
要创建测试，请从Studio提供的列表中选择测试类型
“ Web Performance Test” ，并设置名称
“ Storefront-ProductDetail” 。
图4。 在Visual Studio中选择测试类型。对于这种类型的测试，Visual Studio将立即尝试打开浏览器，可以在该浏览器中直接在站点上以交互方式单击必需的操作，但是我们不会这样做，而是立即关闭浏览器并停止录制。 结果，我们得到一个空的
Storefront-ProductDetail.webtest测试。
接下来，我们需要为此测试添加一个数据源，以便我们可以在同一测试中使用不同的查询参数，为此，
VS Studio Web性能测试提供了这样的机会。
作为测试的数据源，我们将使用数据库中存储产品记录的表。 之后，我们将能够在请求中使用来自连接源的数据，这将在测试的应用程序上打开产品详细信息。 这可以通过插入构造
“ {{数据源名称。表名称。列名称}}”来实现。结果，在所有操作之后，我们的第一个测试将采用这种形式。
图 5.测试内容现在是第一次运行的时候了，请尝试运行我们的测试并确保其正确运行。
图 6.一次测试的结果以此类推，我们将为所有其他场景创建测试。
图 7.结果测试套件之后，几乎所有内容都可以用来创建组合测试，以模拟用户在站点上的实际行为。
为此，向我们的项目添加一个新的
LoadTest。
图8。 创建一个新的负载测试在出现的向导中，选择“
本地负载测试 ”类型。
图 9.选择测试类型此项需要澄清，因为您正确地问：“还有什么内部部署？” 本文的主题是有关使用Teams Services和MS Azure进行测试的，但是有一点细微之处，因为我们使用表或其他外部服务形式的数据源进行测试，因此当我们尝试在云中运行此测试时可能会造成一些困难。
在徒劳地尝试使此类测试在云中运行之后，我们放弃了这项尝试，并决定使用所谓的“记录”测试进行测试，这些测试是通过记录本地运行并连接到数据源的测试生成的查询而获得的。
为了记录测试，我们使用Fiddler，它能够将请求导出为
Visual Studio Web测试格式。 我们将进一步详细描述记录此类测试的过程。
在接下来的步骤中，我们选择测试的持续时间，用户数量，最重要的是，指明我们的
MixedLoadTest将包括哪些测试以及将以什么比例使用它们。
图10。 测试组件结果，在完成所有操作之后，我们得到了一个组合的
MixedLoadTest，配置为在本地部署的应用程序上运行。
接下来，我们需要运行此测试，并尝试使用
Fiddler记录测试结果将生成的所有请求，并获得可以直接在云中运行的“记录”。
首先运行
Fiddler和我们的
MixedLoadTest测试。
图 11.测试结果处理完所有数据后，我们在Fiddler中得到这张照片
图 12. Fiddler的测试会议接下来，在Fiddler中，以“
Visual Studio Web测试”的格式保存所有会话，
依次选择 “
文件”->“导出会话”->“所有会话”->“ Visual Studio Web测试”，然后将结果文件添加到项目中。 让我提醒您，此操作对于使我们能够在不参考外部数据源的情况下进行测试是必需的，因为启动此类测试可能会在云中引起问题。
图 13.“记录”测试的细节现在几乎所有内容都可以在云中运行我们的测试了，准备测试的最后一步是在任何文本编辑器中打开“记录的”
MixedLoadTest ，并用我们在云中的商店的地址替换
localhost ：8888（代理地址，Fiddler）。
在云中运行测试
要在云中运行测试，我们需要
Visual Studio Team Services中的有效帐户。
创建一个新的LoadTest，仅这次选择
带有Visual Studio Team Services的基于云的负载测试 。
在接下来的步骤中，我们选择将从中生成测试资源流量的数据中心，以及恒定模式的最大代理（用户）数量，或者如果我们想逐渐增加负载，则需要设置适当的参数。
在选择测试的步骤中，我们选择了我们之前使用
Fiddler记录的唯一测试，它将模拟被测试资源上的“实际”负载。
创建完成后，我们将启动测试，在此期间，工作室将显示一些关键指标，例如性能和带宽，以及建立实时图表。
图 14.在云中运行测试的过程测试完成后，您还可以在VSTS中查看保存的Web报告：
图 15. Visual Studio Team Services门户上的Web报告结果分析
最重要的一点是测试结果的处理和分析。 对于有问题的任务，有必要评估在Azure Web Apps B2和B3费率的各种配置下运行的应用程序的性能。
为此，我们针对不同配置的应用程序再次运行了“记录”测试，并将结果记录在Excel文档中。
结果，我们得到了此报告：
图16。 测试结果报告在分析所获得的数据之后，有可能找出我们的应用程序可以承受的最大负载-大约60个同时用户或9个请求/秒。 平均页面返回时间为2.5秒。 该图显示，在请求数量达到某个阈值之后，性能问题突然开始。
后来发现，其原因是100％的处理器负载，这是因为我们使用了第三方库来进行服务器页面渲染，该库使用正则表达式对标记进行标记和解析。
结论
积极开发的应用程序的生产力始终具有非常强烈的降级趋势，因为任何更改，即使从开发人员的角度来看，即使是最微不足道的更改，都可能导致应用程序性能的重大后果。 在这方面，定期的性能测试是一个重要的过程，应该定期进行，并且应作为持续集成过程的一部分。
项目本身以及通过测试收到的报告可在GitHub上获得 。