Методы и результаты тестирования

Тестирование было проведено с целью убедиться, что проект будет работать должным образом и поддерживать рабочие процессы, пользователей и предполагаемую нагрузку. Системные тесты дают возможность обнаружить и устранить проблемы во время развертывания системы в средах более низкого уровня сложности, в идеале до того, как они проявятся в рабочей среде. В данном тестовом исследовании основное внимание уделялось производительности системы и обеспечению наилучших условий работы конечным пользователям.

Каждый компонент отслеживался по мере того, как рабочие процессы выполнялись в соответствии с различными сценариями нагрузки. По завершении тестирования результаты были собраны и проанализированы с целью выявления как узких мест, так и компонентов системы с избыточными ресурсами. Эта информация использовалась для определения компонентов системы, которые было необходимо масштабировать в сторону увеличения, уменьшения или исключения перед повторным тестированием.

Тестирование пользовательского интерфейса проводилось вручную путем записи экрана тестировщиков рабочих процессов, чтобы удостовериться, что пользователи системы смогут продуктивно выполнять свои рабочие процессы.

Подробнее см. в разделе о том, как разработать эффективную стратегию тестирования.

Темп рабочего процесса

В этом тестовом исследовании к протестированным рабочим процессам применялась модель темпа. Модель темпа показывает, как тест должен имитировать темп работы на коммунальном предприятии, где рабочие процессы выполняются в виде некоторого числа операций в час группой сотрудников. Этот подход был основан на данных, полученных от клиентов Esri, и был направлен на то, чтобы соответствовать сценарию клиентов малого и среднего газового предприятия, на основе которого были получены данные.

Различные рабочие процессы были распределены по одночасовому тестовому периоду и сдвинуты, чтобы избежать одновременного запуска, но при этом они перекрывались друг с другом, как это происходит в реальных рабочих процессах. Эта общая разбивка темпа рабочего процесса считается «проектной нагрузкой», которой подвергается система. Затем нагрузка увеличивалась путем увеличения числа рабочих процессов до такой степени, что система уже не могла обеспечивать приемлемые ответы или поддерживать успешные рабочие процессы. Обратите внимание, что модель темпа рабочего процесса, примененная в этом тестовом исследовании, может не соответствовать типичному повседневному использованию в вашей организации.

Инструменты тестирования производительности

Поскольку ArcGIS является многоуровневой системой, тесты производительности проводились на уровнях клиента, сервиса и хранилища данных, а также на самой базовой инфраструктуре. В этом тестовом исследовании JMeter использовался для моделирования рабочих процессов пользователя и измерения производительности системы при различных нагрузках. Запросы ArcGIS Pro записывались, а затем воспроизводились для моделирования нагрузки в дополнение к ручным рабочим процессам, которые выполнялись для оценки взаимодействия с конечными пользователями. Для мониторинга использования ресурсов различными компонентами также использовались Windows Performance Monitor и ArcGIS Monitor.

Дополнительные сведения см. в разделе инструменты для тестирования производительности.

Результаты тестирования

Эта архитектура была проверена с помощью автоматических нагрузочных тестов и пользователями вручную в трех сценариях, результаты каждого из которых приведены ниже. На высоком уровне результаты тестирования показывают, что в реализованном виде система обладает достаточными ресурсами для поддержки нагрузок от проектной до 4-кратной проектной нагрузки. Испытания также подтвердили важность правильной настройки приложений и системы для обеспечения производительности. В каждом сценарии загрузка системы увеличивается пропорционально нагрузке.

Сценарий тестирования: Проектная нагрузка

• Система поддерживала нагрузку
• Загрузка ЦП на хостинговых серверах обычно составляла менее 20%.
• ГИС-серверы обычно работали с загрузкой ЦП ниже 20%, с пиковыми значениями около 40-60%
• Сервер SAP HANA обычно работал с загрузкой ЦП ниже 20%

Сценарий тестирования: 4-кратная проектная нагрузка

• Система поддерживала нагрузку
• Хост-серверы обычно работали с загрузкой ЦП более чем на 40%
• ГИС-серверы обычно работали загрузкой ЦП более чем на 60%
• Пик загрузки SAP HANA обычно составлял около 30% ЦП

Тестовый сценарий: 8-кратная проектная нагрузка

• Система не выдержала нагрузку
• Хост-серверы достигли загрузки ЦП 100%
• Серверы ГИС достигли загрузки ЦП 90%
• SAP HANA достиг загрузки ЦП 40-60%
• Количество одновременно работающих пользователей чрезмерно увеличилось из-за того, что запросы не выполняются
• Система сообщила о чрезмерном количестве ошибок

Взаимодействие с пользователем - время выполнения рабочего процесса

Пока система находилась под нагрузкой, время выполнения рабочего процесса фиксировалось по ощущениям пользователей. Это время представляет собой время, затраченное на выполнение всех шагов, перечисленных в рабочих процессах. Время выполнения рабочего процесса остается неизменным до тех пор, пока система не будет перегружена при проектной нагрузке в 8 раз.

Удобство для пользователя - время выполнения этапов рабочего процесса

Пока система находилась под нагрузкой, было зафиксировано время выполнения ключевых этапов по всем рабочим процессам. Это среднее время, затраченное на выполнение данного шага. Время выполнения рабочего процесса остается неизменным до тех пор, пока система не будет перегружена при проектной нагрузке в 8 раз.