ArcGIS 系统测试应验证已实施的设计是否将按预期执行，并支持其预期用于的工作流、用户和负载。 借助系统测试，有可能提前发现和纠正生产环境中可能出现的问题。 虽然测试每个可能的组件、事件或情况可能不现实，但应该定义一些务实的方法来测试系统的关键方面。 例如，系统支持定义的工作流、从组件故障中恢复或处理新工作负载的能力。
有意识的结构化测试对于任何应用程序、工作流或系统的成功都至关重要。 在整个开发周期中，许多不同类型的测试之间都存在相关性，包括功能测试、可达性测试、验收测试和其他类型。 测试是架构流程的关键部分，因为它既有助于验证架构建议，又有助于提供可能导致建议的架构更改的输入，例如某个数据库或软件版本的性能明显优于或差于其他产品。
对于本节的目的，本主题将重点介绍性能测试 - 有助于确定是否满足系统基准性能特征的方法和过程。 测试必须与遥测监测同时进行，并且应允许测试每个受监测的组件。 随着变化被引入系统，必须重新执行测试才能识别任何降级。 还应该使用测试来根据预期的负载变化来通知潜在的架构瓶颈。
这种理想的迭代、标准化和可重复测试水平需要流程自动化才能成功。 对于 SaaS 部署模式，自动化测试的实施（尤其是性能测试）还需要与其他提供商、系统和利益相关方进行协调。
最重要的是，可靠的测试方法应该确定测试的目标、测试内容和非测试内容（范围）、测量内容（遥测）以及成功标准。
在性能测试期间，许多因素会影响工作流的性能，包括最终客户端的硬件、与后端系统的网络连接以及后端系统配置。 要了解性能测量是主要受正在测试的 ArcGIS 软件影响，还是受其他组件（例如代理、数据库或者引入延迟或中断的网络交换机）影响，必须了解上述组件的详细信息。
可以使用不同类型的测试来实现不同的目标。 例如，您可能希望：
在构建测试策略时，通过明确确定目标，其他步骤将更有效地继续进行。
许多系统维护一个用于功能或负载测试的“较低”环境（例如，测试、暂存或预生产）。 有关成功使用测试或暂存环境的详细信息，请参阅此站点中的环境隔离页面。
企业系统通常具有多个单独的应用程序，在其中执行工作流，包括桌面、移动和 Web 客户端，并且可能包括读/写和报告工作流，以及对许多不同类型用户的支持。 如果只是尝试“测试系统”而不首先定义此边界，则将导致许多测试用例，并且降低信息对进一步作有用的可能性。
一个良好的系统测试将模拟系统的使用方式，因此您知道它的功能和性能将与预期一样。 因此，测试范围应包括系统专门支持的工作流以及专门用于提供评估成功标准所需的指标的工作流。 例如，如果要在现有系统上升级软件，则范围应包括在负载（表示每小时的预期最大操作次数）下执行的所有关键工作流。
某些工作负载可能不会同时发生，例如在夜间处理导入或导出数据的脚本与正常的日间操作。 在此类情况下，系统可能会测试两次；一次是确保它将处理日间访问系统的大量人员，一次是确保在规定的时间内完成夜间处理。 当引入任何更改时，还应重新测试系统，以确定它们是否造成了任何负面影响。
遥测在系统测试期间用于收集有关系统在不同情况下的性能的信息，以评估系统是否满足要求并识别问题或异常。 虽然许多人最初可能会考虑对 ArcGIS Server 部署进行负载测试，但捕获整个系统中的遥测数据非常重要。 例如，您可能在服务器基础设施中收集到显示系统性能很高的遥测数据，但后来才知道最终用户难以完成工作流，因为他们的桌面计算机资源不足，因此后端系统的可接受性能在他们看来就像一个不可接受的缓慢系统。
一个关键目标应该是根据通过遥测监测收集的请求（包括平均请求和异常值）对测试脚本和在测试中发送的请求进行建模。 测试还应着眼于测试单个组件以及端到端流程。 由于大多数企业系统的复杂性，可能无法使用单个测试工具来执行所有测试功能，但应将自动化测试运行程序（如 JMeter）配置为允许使用标准化测试输入和输出调整测试例程。
您可以根据适当的成功标准确定系统是通过还是未通过测试，以及可能存在任何问题的位置。 您的成功标准将告知您的测试范围以及您捕获的遥测的类型和颗粒度。 标准可能包括每小时操作数、并发用户数、硬件性能或工作流完成时间等指标。
与检测相关的其他资源包括：