测试方法和结果
测试的目的是验证设计是否按预期执行并能够支持工作流、用户和预期负载。 系统测试提供了在较低环境中的系统部署期间发现和纠正问题的机会，理想情况是在问题出现在生产环境之前进行修正。 对于这项测试研究，测试方法的重点是系统性能和最终用户体验。
在针对不同的负载场景执行工作流时，每个组件都受到监控。 测试完成后，对结果进行了汇总和分析，以确定系统的瓶颈和资源过多的组件。 此信息用于识别在重复进一步测试之前需要扩展、缩减或缩小的系统组件。
通过捕获工作流测试人员的屏幕记录来执行手动用户体验测试，以确保系统用户能够高效地完成其工作流。
有关详细信息，请参阅如何设计有效的测试策略。
工作流节奏
该测试研究将节奏模型应用于测试的工作流。 节奏模型显示了测试打算如何模拟公共设施公司的工作流，其中的工作流为员工资源团队每小时执行一定数量的操作。 此方法基于 Esri 客户输入，旨在匹配数据所基于的中小型电力公司客户场景。
各种工作流在一小时的测试时间段内分散开来，并交错进行以避免同时开始，并且像实际工作流一样相互重叠。 工作流节奏的总体细分被视为系统承受的“设计负载”。 负载随后通过倍增工作流的方式持续增加，直到系统无法再提供可接受的响应或支持成功的工作流。 请注意，本次测试研究中采用的工作流节奏模型可能与贵组织的日常使用情况有所不同。
性能测试工具
由于 ArcGIS 是一个多层系统，因此跨客户端、服务和数据存储层以及底层基础架构本身进行了性能测试。 在本测试研究中，使用了 JMeter 模拟用户工作流并测量不同负载下的系统性能。 除了为评估最终用户体验而执行的手动工作流外，还记录并重现了 ArcGIS Pro 请求以模拟负载。 还使用了 Windows 性能监视器和 ArcGIS Monitor 来监控不同组件之间的资源利用率。
有关详细信息，请参阅性能测试工具。
测试结果
此体系结构已在四种方案下通过自动负载测试和手动用户操作进行了验证，您可以在下面看到每种方案的结果。 高层面来看，测试结果表明，按当前实施情况，系统配备了充足的资源，能够支持从设计负载到 8 倍设计负载的使用量。 测试还进一步验证了正确进行应用和系统配置对性能的重要性。 在各个测试方案中，系统资源利用率均随负载成比例增长。
测试方案：设计负载
-
系统以较低的整体资源使用率支持负载
-
未使用 ArcGIS Data Store（关系）- 底图作为矢量切片服务访问
测试方案：4 倍设计负载
- 系统支持负载
- 托管服务器的 CPU 利用率通常低于 10%
- GIS 服务器的 CPU 运行率通常低于 20%
- PostgreSQL CPU 利用率保持在 20% 以下
测试方案：8 倍设计负载
- 系统支持负载
- 托管服务器的 CPU 利用率通常低于 20%
- GIS 服务器的 CPU 运行率通常低于 35%
- PostgreSQL CPU 利用率保持在 40% 以下，有几次负载高峰在 65% 左右
用户体验 - 工作流执行时间
当系统处于负载状态时，捕获了用户体验的工作流执行时间。 这表示完成工作流中列出的所有步骤所花费的时间。 在系统负载达到设计负载的 10 倍之前，工作流执行时间保持一致。
用户体验 - 工作流步骤执行时间
当系统处于负载状态时，捕获了所有 8 个工作负载中关键步骤的工作流执行时间。 这表示完成给定步骤所花费的平均时间。
