Разработка эффективной стратегии тестирования

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

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

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

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

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

Понимание основ ИТ

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

Определение целей тестирования

Для достижения разных целей можно использовать разные типы тестирования. Например, вам необходимо:

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

Четкое определение целей при построении стратегии тестирования позволит более эффективно выполнять дополнительные шаги.

Во многих системах поддерживается «низкая» среда (например, тестовая, промежуточная или подготовительная), предназначенная для функционального или нагрузочного тестирования. Дополнительные сведения об успешном использовании тестовых или промежуточных сред см. на странице изоляции среды на этом сайте.  

Определение области действия

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

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

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

Сбор телеметрии

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

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

Определение критериев успеха

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

Дополнительные ресурсы, связанные с тестированием, включают:

Top